Comment 1 by jteh on 2010-10-28 23:24
Reporting of table headers only works in Mozilla Firefox for now. This will be implemented for IE and Adobe Reader in a future release.

Using the top row/left column as headers can lead to inaccurate reporting of headers. I'm reluctant to do this for the same reason that we won't have NVDA try to guess form field labels. Users will leave it enabled (or ask for it to be enabled by default) and then wonder why they are getting inaccurate information. Accuracy is a prime concern.
Changes:
Milestone changed from None to None

Comment 2 by andrewd (in reply to comment 1) on 2010-10-28 23:53
While taking your point about importance of accuracy, having a cell in a large table announced in isolation is, at best difficult to interpret and, at worst completely ineffective. A train timetable with over 200 columns with station names in the leftmost column cannot be navigated effectively with NVDA (see www.cityrail.com.au). If correct markup were used the issue would be resolved, but the number of tables with incomplete markup is so large that not allowing the user to decide what are headings makes NVDA unviable in many situations.
Replying to jteh:

Reporting of table headers only works in Mozilla Firefox for now. This will be implemented for IE and Adobe Reader in a future release.

Using the top row/left column as headers can lead to inaccurate reporting of headers. I'm reluctant to do this for the same reason that we won't have NVDA try to guess form field labels. Users will leave it enabled (or ask for it to be enabled by default) and then wonder why they are getting inaccurate information. Accuracy is a prime concern.

Comment 3 by parham on 2010-10-29 05:52
I agree with the poster of the ticket. If the current mode is more accurate, then this could be the default mode unless otherwise changed by the user. However, still this feature would be very useful to be implemented since HTML allows its authors to do many things that might or might not be standard, and hence it's always hard for screen readers to anticipate all the options. The tables with their headers at the left and not using the table-header tag are one great example of this.

Comment 4 by kevinchao89 on 2011-11-08 00:35
Provided one's using Adobe Reader X and a very good tagged PDF document, including a table with table headers for row/column. Is the issue that Adobe Reader does not provide sufficient information via an accessibility API of some kind, which Mozilla Firefox and Thunderbird does provide? Of course, I'm not expecting or wanting NVDA to provide a blanket rule, such as left/top are automatically considered headers, which results in guessing/inaccurate information. I'm wanting to know the technical reason why this cannot work and would Adobe' grant/funding allow for this to be resolved?

Comment 5 by dave090679 on 2015-06-11 07:07

I think, ccording to Microsoft Word, this ticket can be closed using #3110.
Regarding Microsoft Excel, this ticket can be closed using #3568.

Comment 6 by andrewd (in reply to comment 5) on 2015-06-15 22:43
When I raised this issue, my goodness, five years ago I was thinking of HTML material. I still believe there is a strong case for allowing the user to have the top row and/or left column treated as headings in that environment. That is what is now provided in Word and Excel files, albeit by changing code in the document.
Andrew

Replying to dave090679:

I think, ccording to Microsoft Word, this ticket can be closed using #3110.

Regarding Microsoft Excel, this ticket can be closed using #3568.

@jcsteh: do you agree with a close here given your opinion in #1004 (comment)?

I'm still against doing this by default. However, I wouldn't oppose providing the set row header and set column header commands for browse mode to ease navigation of tables which don't specify headers. How we would persist these (or whether we do at all) is an open question.