We're in the process of making a number of data tables accessible. In several examples on the web, I see the "id" attribute being used with the "headers" attribute in the same <th> cell.
You can see what I mean under "Very Complex Data Tables" at:
Or the markup at the bottom of:
While in other examples on the web, <th> is only used with the "id" attribute, and <td> is only used with the "headers" attribute.
Which is more correct for accessibility?
It always depends upon the TABLE structure itself. The TH is a table header cell. Whereas the 'headers' attribute specifies the list of header cells that provide header information for the current data cell. The ID is likely to match something 'very disorientated' or nested several layers deep. If you can use scope (and it still makes sense) that should be fine. Though obviously if the table is really complex or awkward you'd also use ID where appropriate. Basically; 'scope' is a simpler alternative to using 'headers' if the arrangement of header cells is not too complex.
And yet the HTML5 people thought it was a great idea to deprecate scope. This is one area where I strongly push people to ignore validation warnings. Same with table summary.
Both the usability.com.au site and the yahoo site are using headers attributes the same way: there are id's on things (headings/titles) you would like to be announced when the td with the headers attribute is accessed.
deep in table...
td headers="someid, alsopossiblyanotherid, andsoon..."
In several examples on the web, I see the "id" attribute being used with the "headers" attribute in the same <th> cell.
In the accessibility.psu.edu example, the only thing they are doing differently from the other examples is, they are using th instead of td to start their rows.
This is appropriate if the furthest-left table cell of a row would really semantically be a heading.
Like, in ecommerce, it would not be:
number product name price
1 Foobar bedsheets 500,00E
3 Scooby-do undies 34,99E
7 snotrags 50,00E
Here, the number of items wouldn't be a heading to the rest of the row. At least not to me. The only headings would be "number", "product name" and "price". Number of items is just a data point.
But in the accessibility.psu.edu example, they've coloured grey what they believe to be headings, and I can go with that.
The point is simply that a given cell can announce its contents along with manually-associated headers (referenced by ID). This is supposed to imitate what a sighted person's eyes do when they scan down a column or along a row.
Honestly screen readers need to work better with tables, and for any non-complex table I believe they should work without needing manual headers attributes. I see headers as for special cases where manual human intervention is necessary because software can't understand context, not even of data.
Detlev Fischer posted some disappointing table results:
and a test with aria-labelledby for funs http://3needs.org/en/testing/code/aria-labelledby-simple-table.html
unfortunately these tests do not include Orca (Linux) or VoiceOver (mac, iOS) which are important (but he didn't have access to them).
That said, I tend to use scope=row and col, and I don't use headers generally (I would if I had an insanely deep complex table, but then again, that's something I would try to avoid in the first place. They're often complex for many sighted people as well).
One place I do still regularly use headers attributes is when I have an ecommerce shopping cart table. Usually I set the subtotal and total amounts (and maybe shipping too) in the tfoot, so there I like to make sure with headers that the total amount is announced as the "total" and the subtotal as "subtotal", since usually I have td's with multiple colspan in those instances.