Comment 1 by jteh (in reply to comment description) on 2013-10-22 22:46
Are you testing this in Firefox or IE?

Replying to kennpetri:

As an example, the last cell in the table has text of "9/7/2005." That data cell is associated through the headers attribute with "Approval" and "Date" header cells. NVDA reads the cell as "Approval 9/7/2005." It leaves out the Date header, though the headers for both Approval and Date are properly associated.

No scope attribute is specified, so the browser/AT has to guess. The browser/NVDA is treating Date as a row header, not a column header, since column headers are normally vertically distant from their data cells, not horizontally distant. (If you move up into the table from the bottom, you'll notice NVDA announces the Date header in Firefox, since you're moving into a new row.) Specifying scope="col" would fix this.

If I move back to the "Date" header cell, NVDA reads "Approval, Unit Cost, Items, Supplier Information, Requester Information, Date." The Date header cell has no headers attribute and other headers in the table are in no other way associated with the Date header cell. It appears that NVDA is reading all previous header cells that might align with the Date cell's column, moving up the table column from the Date header cell.

The browser/AT has to guess headers when no headers attribute is provided. Otherwise, simple tables would not work. Unfortunately, there's no way for the browser/AT to know whether it should or shouldn't do this for a given cell, since there's no way to specify that there are explicitly no headers as opposed to indicating that the AT/browser should guess.

I'm open to suggestions as to how we/browsers can work around these issues, but I think you'll find that these are difficult to solve without breaking other test cases.

Comment 2 by jteh on 2013-10-22 23:05
Correcting version, since 2013.2 wasn't previously an option. See #3499.

Comment 3 by kennpetri (in reply to comment 1) on 2013-10-23 02:37
Replying to jteh:

Are you testing this in Firefox or IE?

Firefox 24

Replying to kennpetri:

As an example, the last cell in the table has text of "9/7/2005." That data cell is associated through the headers attribute with "Approval" and "Date" header cells. NVDA reads the cell as "Approval 9/7/2005." It leaves out the Date header, though the headers for both Approval and Date are properly associated.

No scope attribute is specified, so the browser/AT has to guess. The browser/NVDA is treating Date as a row header, not a column header, since column headers are normally vertically distant from their data cells, not horizontally distant. (If you move up into the table from the bottom, you'll notice NVDA announces the Date header in Firefox, since you're moving into a new row.) Specifying scope="col" would fix this.

But shouldn't it just read the contents of the ID-associated cells, in the order they are listed in the headers attribute? That is, it should read "Approval, Date, 9/7/2005."

Like you said, I have to leave the bottom of the table and come back in from the bottom to get Date to be read. But the cell has explicit associations. Shouldn't the associated headers be read regardless of where I'm coming from? -- moving vertically or horizontally should not make a difference. The developer explicitly wanted all associated headers to be read, and in a specific order. It seems to me to make the most sense to just honor the web page developer's explicit instructions.

If I move back to the "Date" header cell, NVDA reads "Approval, Unit Cost, Items, Supplier Information, Requester Information, Date." The Date header cell has no headers attribute and other headers in the table are in no other way associated with the Date header cell. It appears that NVDA is reading all previous header cells that might align with the Date cell's column, moving up the table column from the Date header cell.

The browser/AT has to guess headers when no headers attribute is provided. Otherwise, simple tables would not work. Unfortunately, there's no way for the browser/AT to know whether it should or shouldn't do this for a given cell, since there's no way to specify that there are explicitly no headers as opposed to indicating that the AT/browser should guess.

That's right. There are explicitly no headers. So it shouldn't make a guess. Or at least, that would be one way to approach it: Assume the developer of the table has something specific in mind when she omits scope or headers-id associations. Assume that the developer is aware of how to code a table accessibly/properly.

I completely understand that in many cases this is not a safe assumption. But perhaps the assumption could be drawn from evidence in the table. For example, if the table uses the scope or headers-id attributes anywhere, make the assumption that the developer knows what she is doing. If there are no accessibility attributes included, assume that the developer is clueless and needs NVDA's help.

I'm open to suggestions as to how we/browsers can work around these issues, but I think you'll find that these are difficult to solve without breaking other test cases.

Beyond the above assumption logic, or instead of it, perhaps there could be an "interpret data tables strictly" option in the NVDA preferences. When the option is ticked, NVDA treats tables with the assumption that the web page developer is clued in to accessibility practices. If not ticked, NVDA takes heroic measures.

Comment 4 by jteh (in reply to comment 3) on 2013-10-23 02:59
Replying to kennpetri:

Firefox 24

Table headers are determined by Firefox, not by NVDA, so any fixes here need to be made in Firefox.

But shouldn't it just read the contents of the ID-associated cells, in the order they are listed in the headers attribute?

That might be best for this table, but in the majority of cases, that would be extremely annoying. It normally doesn't make sense to read a row header when you're moving between columns. Imagine a row where you have 15 columns. I'm sure you wouldn't want to hear the same row header over and over again as you move through the columns.

One option might be to treat a referenced header as both a row and a column header when scope isn't specified.

The browser/AT has to guess headers when no headers attribute is provided.

There are explicitly no headers. So it shouldn't make a guess.

Personally, I agree with you; explicit is always better. However, web guidelines do not require the headers attribute to be used and thus there are a huge number of cases in the wild that are considered "correct" but don't use the headers attribute. In particular, WCAG technique h51 states that headers doesn't need to be specified.

I completely understand that in many cases this is not a safe assumption. But perhaps the assumption could be drawn from evidence in the table. For example, if the table uses the scope or headers-id attributes anywhere, make the assumption that the developer knows what she is doing.

That'd require the browser/AT to walk the entire table before being able to determine anything about headers. Also, what if the table is updated dynamically; e.g. it had no scope/headers attributes but then a cell was added that does? Handling this case means the browser/AT has to walk the entire table every time a cell is changed, which is hugely inefficient and therefore infeasible.

Comment 5 by kennpetri (in reply to comment 4) on 2013-10-23 03:42
Replying to jteh:

Replying to kennpetri:

But shouldn't it just read the contents of the ID-associated cells, in the order they are listed in the headers attribute?

That might be best for this table, but in the majority of cases, that would be extremely annoying. It normally doesn't make sense to read a row header when you're moving between columns. Imagine a row where you have 15 columns. I'm sure you wouldn't want to hear the same row header over and over again as you move through the columns.

Yes. That level of verbosity would be annoying. However, if I forget what row I'm in, it would be good to have a way to check it without moving out of the row and then back in. This is especially important in the case of tables with column or row spans, when moving out and into a spanned row or column and then back into the cell I was in can actually cause me to lose my place -- I move up from a cell in the third column with a header that spans three columns into the header, and when I move back down, I've jumped from the third column back to the first.

To address this problem and the other issues with column/row headers that are non-explicitly associated, what about a keystroke that allows me to "inspect cell attributes," or something like that. If I'm in a cell, I can hit the special keystroke (maybe Ctrl + Alt + i) and NVDA would read only the explicitly associated headers (associated via scope and/or via headers-id association).

As noted in the concluding remarks of #3600 (comment), we may want to morph this ticket to propose a new keyboard shortcut for 'inspecting cell attributes'. A few thoughts in that regard:

• NVDA+E sounds like a fitting keyboard shortcut for this purpose, though there could be several other varied suggestions for the keystroke such a feature should be designated. Regardless, I propose reporting cell attributes upon single press and reporting table attributes upon double press.
• Cell attributes may include the row and column count of the cell, the row and column headers of the same with respect to the cell, perhaps followed by more advanced cell information.
• Table attributes may include the number of rows and columns in the table, the table header (if I am not wrong in recalling that such a thing exists), perhaps followed by more advanced table information.
• The list of cell attributes and table attributes I have provided above is very limited since I have little knowledge about tables, let alone those that are complex, layout tables, etc. Thus, I would like to kindly request others to fill in those gaps so as to make this feature request well-defined.

This is still reproducible in Firefox 66.0.5 and other browsers. I am not sure if this is an NVDA bug though.
cc: @jcsteh as far as I understand, the last cell in the table should be reported together with "Aproval" and "date". But it is reported only with "aproval" as heading. "date" is being ignored.

The link does not work anymore.
@kennpetri could you please update with a minimal test case or a new working link?
@jcsteh maybe you can still reproduce this?

We didn't get any updates from the initial author since many years, and a propper test case is missing. I am closing as abandoned. Please comment if you are still having this issue and we can reopen.