Comment 1 by jteh on 2013-05-22 00:23
NVDA already supports the headers attribute in both Firefox and Internet Explorer. This test case doesn't work because some of the header cells listed in the headers attribute are data cells (td), not header cells (th). Cells listed in the headers attribute must be headers (th). Note that Firefox is enforcing this too; it is not something only NVDA enforces.
Changes:
Added labels: worksforme
State: closed

Comment 2 by spanchang02 (in reply to comment description) on 2013-05-26 17:33
Hello,
Your argument that Firefox requires cells listed in the headers attribute to be TH cells only is untenable.
An id-value can be assigned to any HTML element including a TD in a table.
And the Web page validates alright using a 'strict' doctype declaration.
It is the business of the assistive technology to interpret the accessibility attributes correctly and the onus is on NVDA to announce all id values within the headders attribute regardless of whether it refers to cells marked up as TH orTD.
JAWS does it in Internet Explorer and Firefox. So does Window-Eyes.
So Firefox has nothing to do with 'enforcing' headers-id only for cells marked up as TH as you maintain.
Kindly please review the issue and fix NVDA and not close the issue prematurely. It will help users.
Thanks,
Sailesh Panchang
Replying to spanchang02:

Implementing support for headers-id method of associating header and data cells for complex tables is necessary to make them accessible with NVDA.

Example file at:

http://mars.dequecloud.com/demo/Census_2013.htm

Note:

The second table on this page is the same as the first marked up differently so that headers-id markup is not needed.

It uses NVDA's feature of reading cells in multiple columns marked up as TH. The h3 markup for group-row-headers also enhances table comprehension and navigation.

Yet, more complex tables rely on headers-id markup only.

Thanks,

Sailesh

Comment 3 by jteh (in reply to comment 2) on 2013-05-28 04:02
Replying to spanchang02:

An id-value can be assigned to any HTML element including a TD in a table.

And the Web page validates alright using a 'strict' doctype declaration.

WCAG technique H43 clearly distinguishes between header and data cells, though it isn't clear about the header cells being th. However, all the examples use th for header cells. HTML 4.01: header information with data cells does likewise.

So Firefox has nothing to do with 'enforcing' headers-id only for cells marked up as TH as you maintain.

Actually, it does. WE and JAWS interrogate the DOM directly for Firefox, bypassing accessibility APIs. NVDA uses accessibility APIs only for Firefox. Firefox enforces this for accessibility APIs.

Kindly please review the issue and fix NVDA and not close the issue prematurely. It will help users.

Kindly check your facts before stating that an assertion is incorrect.

Comment 4 by spanchang02 on 2013-05-29 16:07
Hello,

WCAG technique H43 clearly distinguishes between header and data cells, though it >>isn't clear about the header cells being th.

Perhaps you interpreted this statement in WCAG2 - H43 technique description as 'lack of clarity':
"It also adds an id attribute to any cell used as a header for other cells."
Actually this is deliberate and has its reasoning in the note on the HTML 4.01 link in your message:
"Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate."

You see it is not always possible / desirable by authors to mark up a cell as TH in a complex table.
Also in a left to right reading order system, you do have situations when the header is on the right of the data cell.
The headers-id method is to make complex tables accessible - not straight forward simple vanilla tables . The technique would not be required otherwise.

Take a look at the"Travel Expense Report" table on the same HTML 4.01 specs page under 11.4.2 for an example of TD cells with an id value:
the date cells are row headers and are TD.

So please fix NVDA so it reads all id values within the headers attribute regardless of whether they reference TH or TD. You will do users a great service.
Thanks,
Sailesh Panchang

Changes:
Removed labels: worksforme
State: reopened

Comment 5 by jteh (in reply to comment 4) on 2013-05-29 20:41
Thanks for providing this useful information. I apologise for missing that note in the HTML 4.01 information. One curiosity:

Replying to spanchang02:

Also in a left to right reading order system, you do have situations when the header is on the right of the data cell.

Why should that affect whether the cell is th, though? There's no reason the cell on the right couldn't be th.

On further testing, it looks like Firefox does correctly associate headers pointing to td elements if the td elements have a scope attribute. Arguably, this does conform to the spec:

You should use the TD element for such cells together with the id or scope attributes as appropriate.

The controversy is in the definition of "as appropriate". You could argue this means that you don't necessarily need to include the scope attribute if it can be inferred or you could argue that "as appropriate" means that you must choose the correct value of scope for your particular case. This is probably something we need to discuss with Mozilla. As I explained above, for Firefox and any browser other than IE (IE's exposure to accessibility APIs is seriously deficient), we rely on accessibility APIs, so this change needs to be made in the browser.

Comment 6 by jteh on 2013-05-29 21:02
Filed MozillaBug:877386.

Comment 7 by spanchang02 (in reply to comment 6) on 2013-05-30 18:37
Hello,
Sorry I do not know your name.

Anyway, cell to the right may be TH or it could be a data cell (TD) that also serves as a header to other cells.

Refer to specs: You should use the TD element for such cells together with the id or scope attributes as appropriate.
"As appropriate" means:
Generally when headers-id method is used there is no need for 'scope' because the headers points to all associated heading cells (Th or TD).
(I have also seen tables that use header-id for some cells and rely on TH for other cells!)
Scope can be used on TD like in example 9 on
http://www.eramp.com/david/tablesample2.htm
(This is a resource#3 link from technique H63. Example #1 and 9 are mine).
Example#9 is given as the example for H63 but they have now goofed it up I see by making all the cells TH instead of TD ... does not correspond to the text above the table.

Secondly, It is important to use scope=row for TH cells in column #1 of a table that serves as row headers for most tables.
Just TH is not enough because, NVDA and JAWS will read all cells marked up as TH above the current cell as one moves right to left to column#1 of the table.
See issue #3245 filed for a related improvement.

So 'as appropriate' means it is up to the author to use the attribute suitably. The AT has to obey the attribute: announce a cell as header based on scope value regardless of whether header cell is TH or TD.
Thanks,
Sailesh
Replying to jteh:

Filed MozillaBug:877386.

Comment 8 by jteh (in reply to comment 7) on 2013-05-30 23:51
Replying to spanchang02:

Anyway, cell to the right may be TH or it could be a data cell (TD) that also serves as a header to other cells.

I mean why would you ever want to make it a td instead of a th if it is a header? I haven't seen a single good example of that yet. Even the example you cited could easily use th instead of td as far as I have examined it; e.g. there is no way "Age:" isn't a header. This is a curiosity; as you've demonstrated, the spec does allow for it.

So 'as appropriate' means it is up to the author to use the attribute suitably. The AT has to obey the attribute: announce a cell as header based on scope value regardless of whether header cell is TH or TD.

My point is that "as appropriate" is still a bit ambiguous here. On a th, it's okay for scope to be inferred, but on a td (which normally isn't a header), supplying scope might be appropriate.

Certainly, it's very difficult to handle this from an implementation point of view if we have no idea that a data cell is a header while we're processing it. Essentially, we have to assume that all data cells with id attributes are potential headers, which is downright ugly. Even if Mozilla can make this work for Firefox, doing it for IE will be fairly difficult and probably won't happen for some time.

Comment 9 by spanchang02 on 2013-05-31 16:24
Hello,
See the data rows in the 3-col table 'Characteristics with positive and negative sides' on
http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#table-descriptions-techniques
The cells under Characteristic are TH semantically but some authors will mark it up as TD.
Also H63 notes (actually my wording):
"- header cells marked up with td instead of th. Sometimes, authors use this to avoid the display characteristics associated with th and also do not choose to use CSS to control the display for th".

The point is TH and "scope" attributes are what I term "general" techniques for marking up header cells in a table.
The scope of TH extends to all cells to the right/below ("inferred" as you said) unless it is limited with "scope" attribute.
The scope attribute also expends the header association to a block of cells based on scope value.
That's why they are general.
On the other hand header-id method is "specific" method which overrides the general TH/scope methods of header association.
The assistive technology should associate all cells that the headers attribute points to.
Also note: a cell may be a header cell for some cells but also a data cell in relation to some other header cells.
So a cell can have an id attribute and a headers attribute.
e.g. the date cells in the Travel Expense Summary' on HTML 4.01 page I pointed to in an earlier email.
The browser really has no role to play except to style cells marked up as TH distinctly (unless author has overidden that).
It is the assistive technology that should interpret and render the headers-id association for the end user.
You term it as 'ugly' and it may be so for you and me who respect the standards.
When rowspan is used or rows are grouped, visually one can see the structure and determine the header-data cell association. Or authors may style the cells differently and not mark them as TH.
This is the real world reality and yet the tables need to be made accessible to screen reader users like me.
Thanks for re-opening the issue.
By 'minor' you mean from implementation-effort viewpoint? For accessibility, it is a 'major' issue.
Sailesh

Comment 10 by jteh (in reply to comment 9) on 2013-06-02 23:39
Thanks for your examples and clarifications.

Replying to spanchang02:

The browser really has no role to play except to style cells marked up as TH distinctly (unless author has overidden that).

That's not quite correct. Browsers with decent accessibility provide this information via accessibility APIs, as assistive technology software really shouldn't be walking the DOM; browsers have a far better idea of web standards (and are better suited to making those decisions) than AT does. The only exception is IE.

By 'minor' you mean from implementation-effort viewpoint? For accessibility, it is a 'major' issue.

If you're talking about the priority assigned to this ticket, it's minor in terms of NVDA implementation priority. I haven't seen any tables that this affects in the wild and users aren't reporting this as a common problem. It's quite difficult to fix for IE. For Firefox, the work needs to be done by Mozilla.

Comment 11 by jteh on 2013-06-03 01:43
Just to make matters more confusing, HTML 5 says that the headers attribute should only point to th elements:

The td and th element may have a headers content attribute specified. The headers attribute, if specified, must contain a string consisting of an unordered set of unique space-separated tokens that are case-sensitive, each of which must have the value of an ID of a th element taking part in the same table as the td or th element .

See also MozillaBug:704465.

Comment 12 by spanchang02 (in reply to comment 11) on 2013-06-08 07:47
Hello,

1. First and foremost, NVDA is an assistive technology:
   "Assistive technology: Any item, piece of equipment, or system, whether acquired commercially, modified, or customized, that is commonly used to increase,
   maintain, or improve functional capabilities of individuals with disabilities". ... from U.S. federal law.
2. "The first thing to look at is how does screen reading software typically interact with a Web page. Usually the software pulls data out of some model representing the Web page, interprets it, and presents it to the user. The data could be coming directly from the browser and the DOM or through the operating system’s accessibility layer." [So it is fine to maintain in a perfect world that
   "Browsers with decent accessibility provide this information via accessibility APIs, as assistive technology software really shouldn't be walking the DOM; browsers have a far better idea of web standards (and are better suited to making those decisions) than AT does."
   Surely assistive technologies should recognize and interpret standards-compliant markup, but by its very definition, it also attempts to compensate for limitations in the environment to make an inaccessible world accessible to its constituency.
   So screen readers do need to walk the DOM and scour all resources to extract accessibility info to help the user as best as it can. We are not dealing with pages that have 100% valid markup most of the time.
3. Quite a few things about HTML5 are restrictive and out of sync with reality and it has scant regard for 'backward compatibility'.
   This is an example where it is not in sync with the reality captured in the note in the HTML 4.01 I referred to in my first response to you :
   "Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate."
   Also review the "Travel Expense Summary" table on the HTML 4.01 page I pointed to earlier.
   In any case,as far as HTML 5 is concerned, if a non-TH cell is referenced by the headers attribute, it should only fail document validation for those who care.
   The assistive technology's responsibility does not change. It should announce the TD with an id as a header as intended by the author.
   Even that invalid HTML5 page is rendered in the browser for all to consume but the non-sighted user will be at a disadvantage if that cell is not announced as a header and NVDA will have failed terribly as an assistive technology.
   So my recommendation is go by the HTML 4.01 note.
   NVDA will work for valid HTML 4 docs with TD that has an id and it will work for valid/invalid HTML5 docs.
   But always remember NVDA and screen readers/magnifiers/voice input programs are assistive technology first.
   [1](1]

3.) http://accessibility.oit.ncsu.edu/blog/2013/05/31/screen-readers-at-a-crossroads/
Thanks,
Sailesh

Again
"Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate."

Replying to jteh:

Just to make matters more confusing, HTML 5 says that the headers attribute should only point to th elements:

The td and th element may have a headers content attribute specified. The headers attribute, if specified, must contain a string consisting of an unordered set of unique space-separated tokens that are case-sensitive, each of which must have the value of an ID of a th element taking part in the same table as the td or th element .

See also MozillaBug:704465.

Comment 13 by jteh on 2013-06-08 08:07
We will not walk the DOM for Firefox. Our approach with Mozilla is generally to do things properly, since Mozilla are very responsive.

Here is the situation with this issue:

1. This issue has been fixed for Firefox 24. Once Firefox 24 is released, this will just work as expected.
2. For IE, the change needs to be made in NVDA. This is probably quite involved and affects few users at this point, so it's unlikely to happen soon, but we've accepted it as a valid issue.

Comment 14 by jteh on 2013-06-08 08:12
You may wish to verify that this works as expected with Firefox nightly.

Comment 15 by spanchang02 on 2013-06-23 16:04
Ref. the bug you pointed me to #704465 for Firefox
(https://bugzilla.mozilla.org/show_bug.cgi?id=704465#c12)
I see the following comment on that thread
"For a browser, you only want to be looking at the conformance requirements for user agents, which do require that headers="" work whether pointing to a or a ..."
Sailesh

Comment 16 by jteh (in reply to comment 15) on 2013-06-24 00:03
Replying to spanchang02:

"For a browser, you only want to be looking at the conformance requirements for user agents, which do require that headers="" work whether pointing to a or a ..."

Yes, i saw this. This has now been fixed in Firefox, which is why I suggested you test with Firefox nightly in comment:14. See comment:13 for information regarding IE.

Comment 17 by paulbohman on 2015-02-13 20:11
NVDA still seems to have trouble reading headers and ID appropriately. The first table on the following page uses traditional id + headers markup: https://dequeuniversity.com/testsuite/tables/spanned-headers

The first column in this table has cells that span multiple rows (grouping results by males and females). When navigating side to side within the table, NVDA usually reads the relevant row headers (such as "females Mary"), but says "column 1" or "column 2" etc instead of saying the actual column header text, which should be "1 mile" or "5 km" or "10 km." Sometimes NVDA reads only the rowgroup header ("Females" or "Males") and not the person's name. I know that the pattern in some screen readers is to read only the new information and not repeat things the user has already heard (for example, it shouldn't say either "Females" or "Mary" if you navigate to the right within the row that belongs to "Females" and "Mary"; it should say only the column header. And it would be ok if NVDA were following this pattern, but that's not what's happening. It seems somewhat random and buggy, though I'm sure there's an underlying pattern to it.

When navigating vertically, NVDA sometimes reads the row header in the second column ("Betsy" or "Matt" for example), but it does not read "Females" or "Males" and sometimes it doesn't even read the name of the person. "Mary" and "Matt" don't seem to get read at all when navigating vertically. Both of those headers are in the first row of their respective groups (Females and Males), so I wonder if there is a pattern of only reading the last row header, or of skipping the first row header (it's hard to tell, since there are only two rows in each of the groups).

As it is right now, I have to navigate in multiple directions after arriving at a cell to hear all of the headers.

Also, if you go to the "Betsy" cell, NVDA reads "Mary" as the header for that cell, even though the "Betsy" cell does not reference any headers at all in the code. NVDA seems to be guessing here that Mary is the proper header, but the guess is wrong, and there is no reason to guess in this table, because all of the associations are laid out clearly in the HTML via the headers and id attributes.

Comment 18 by paulbohman on 2015-02-13 20:20
There are similar issues with scope="colgroup" and scope="rowgroup" not being recognized by NVDA. See https://dequeuniversity.com/testsuite/tables/colgroup-rowgroup

Comment 19 by paulbohman on 2015-02-13 21:29
I did my testing with this configuration:

NVDA 2014.4
Firefox 35.0
Windows 8.1

Comment 20 by paulbohman on 2015-02-17 04:53
For those who may have tried to access my example files in the last couple of days, I didn't realize that I had left them with some experimental test markup in them. Sorry about that. I've fixed the markup and added a few more test tables, including tables with row group headers and tables with column group headers. Overall, there is better support for column group headers than for row group headers, but even the column group functionality is either quirky or broken. The test pages are here:

headers + id: https://dequeuniversity.com/testsuite/tables/spanned-headers
rowgroup and colgroup: https://dequeuniversity.com/testsuite/tables/colgroup-rowgroup

@jcsteh's #3244 (comment) states that the reported issue has been fixed for Firefox 24, and thus the remaining work needs to be done internally in NVDA for Internet Explorer only. Could someone please check if this still occurs in Internet Explorer 11 as well? This is because if not, we may safely close this ticket given that we are no longer addressing issues specific to older versions of IE.

We did not make any effort to address this in Internet Explorer 11. Again like with other Internet Explorer issues, we'll accept a PR, but we are not placing priority on these.

@jcsteh is this still an issue in Firefox?@LeonarddeR I guess many organisations still use IE and I am thinking of SAP netviewer where you have very complex tables. Do you think there is any Chance that maybe you at Babbage look into this?

If this is not an issue in Firefox anymore, I suggest to close it because IE will probably not get and enhancements from NVDA's side sofar.