User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 When present in a data table, correctly applied id and headers attributes link the header cell with the associated data cell(s). This allows screen readers to present the tabular information in a meaningful manner. This has been supported in IE for some time, but is still not supported in Firefox. The above URL has a simple example. Moving down the right column will cause the material in the left column to be presented before that in the right column. Reproducible: Always Steps to Reproduce: 1. 2. 3.Ask the screen reader to announce by table attribute Actual Results: Only the current cell is presented Expected Results: The material in the associated header cell should be presented first

This works fine for me using JAWS 9.0 and Firefox 3.0. When I am positioned on the cell containing the actual dimensions of the unit, pressing CTRL+ALT+NUM PAD 5 gives me the "Dimensions" header info first, then the actual value. Likewise when going up and down by table navigation using CTRL+ALT+UP and DOWN ARROWS when positioned in a cell of the righthand column gives me the header info from the left first. The same happens when using it with IE7. Am I missing something?

Both JAWS and Window-Eyes can use the markup to associate header cells with data cells in IE but not in any version of Firefox

Afaik, we don't process advanced HTML header markup, like scope/headers/axis. To be honest we're never asked for it and I generally don't run into tables with this markup. I think the markup has just been too hard for authors to understand.

"The HTML working group have decided not to include the headers attribute in the HTML 5.0 working draft, as they believe the scope attribute is sufficient for associating header cells with data cells." That statement comes from an article on the debate here: http://juicystudio.com/article/html-scope-headers-debate.php In any case, we'd still need to implement scope.

I'm wrong. Here's what Ben Millard (who did some HTML table studies) says: > The quote from Juicy Studio is out of date. During tables research from > myself and various others, including detailed analysis by Ian Hickson, > headers+id was added to HTML5: > * http://lists.w3.org/Archives/Public/public-html/2007Sep/0563.html > * http://lists.w3.org/Archives/Public/public-html/2008Mar/0215.html > * <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular.html#td> > It is restricted to point at <th> elements, a decision which I disagree > with. It also prevents headers being associated with other headers, another > decision I disagree with: > http://lists.w3.org/Archives/Public/public-html/2008Jun/0350.html > James Graham, Simon Pieters and myself had developed a different algorithm > called "Smart Headers" before Ian developed his own one for HTML5: > * http://simon.html5.org/discussions/table-header-algorithm > * http://lists.w3.org/Archives/Public/public-html/2007Aug/thread.html#msg480 > http://lists.w3.org/Archives/Public/public-html/2007Sep/thread.html#msg99 > Both algorithms are experimental, imho. I expect them to gradually converge > with each other over time. headers+id is integrated into both, although > slightly differently: > http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular.html#header-and-data-cell-semantics

It seems to me that the best way to implement this would be to implement the association algorithm that ends up in HTML5 (I don't expect the current algorithm to be final) and expose the resulting relationships to AT so that the AT doesn't need to care whether the relations came from headers/id or otherwise from the markup structure of the table.

This is a matter of exposing the right relations for each cell and for headers. I think we want to do this with describedby on each cell. To be honest I'm not sure I'd waste my time doing description_for on the header cells, and force ourselves to compute all the cells related to a header -- there's not much of a use case there and it's expensive. I believe we'll need to write separate methods to: 1) GetColHeadersForCell() 2) GetRowHeadersForCell() The general algorithm for that is apparently here: http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#header-and-data-cell-semantics These should also check for aria-describedby pointing to a role="rowheader" or role="columnheader" object. If it's not one of those then I think we have to figure out based on its position in the table. Then the describedby relation can reuse those 2 new methods. Next, nsIAccessibleTable::GetColumnDescription() and ::GetRowDescription() should be mplemented to use the 2 methods we created to get the column or row headers for a given cell. http://mxr.mozilla.org/mozilla-central/source/accessible/src/html/nsHTMLTableAccessible.cpp#670 Finally, we need to ask various screen reader vendors to use GetColumnDescription() and GetRowDescription()

Also, GetRole() should be fixed to take into account the scope attribute. "row" or "rowgroup" -> ROLE_ROWHEADER "col" or "colgroup" -> ROLE_COLUMNHEADER Any other value -> automatic based on position in the table. We need a smart algorithm for this. I'm not sure if the algorithm on the HTML 5 spec gives us the answer (http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#header-and-data-cell-semantics)

fixed by bug 512424, @header attribute is taken into account in exposed heading information.