Examples of complex tables in the wild needed
Tommy Olsson (aka "TOOLman" aka "AutisticCukoo") has written an article summarising HTML5 Tables.
Terrence Wood recently got some New Zealand disability research tables onto my radar. These are using the headers+id association method. It seems (theoretically) unnecessary for most of them so these will make good additions to the collection.
(EDIT) Jake's recordings show complex regular tables are already somewhat navigable with minimal markup in one present-day AT. Better defining (and supporting) how <th> and <td> get associated without attributes could be an effective way to reduce authoring labour and improve user experience at the same time?
(EDIT2) The Office for Disability Issues tables collection is now up.
Terrence Wood recently got some New Zealand disability research tables onto my radar. These are using the headers+id association method. It seems (theoretically) unnecessary for most of them so these will make good additions to the collection.
(EDIT) Jake's recordings show complex regular tables are already somewhat navigable with minimal markup in one present-day AT. Better defining (and supporting) how <th> and <td> get associated without attributes could be an effective way to reduce authoring labour and improve user experience at the same time?
(EDIT2) The Office for Disability Issues tables collection is now up.
Meh, it's been a week so double-posting is an acceptable evil. If it isn't, what are you gonna do? I'm a mod, dammit!
There's now a Data Table Collections (Research) thread on W3C's public-html mailing list.
I added some astronomy tables and contacted EatYourGreens about locating any more.
There's now a Data Table Collections (Research) thread on W3C's public-html mailing list.
I added some astronomy tables and contacted EatYourGreens about locating any more.
Joshue O Conner from the Centre for Inclusive Technology (CFIT), Ireland has made available disabled users with data tables testing footage. I haven't watched them, yet.
Responses can be navigated via the public-html thread view. Discussion can take place anywhere. WHATWG have seen and discussed them briefly. You can talk about them here and myself or someone else will link the group to anything substantial.
I started Heuristic Tests for Data Tables (Discussion) last month which has continued this month. James Graham has been implementing table algorithms so we can test different approaches against real tables.
I'm not making progress with the table collections. I might dump the links for all the tables I've bookmarked but haven't worked on into a web page. At least that way other people interested in table headers can review the interesting things authors are doing.
Responses can be navigated via the public-html thread view. Discussion can take place anywhere. WHATWG have seen and discussed them briefly. You can talk about them here and myself or someone else will link the group to anything substantial.
I started Heuristic Tests for Data Tables (Discussion) last month which has continued this month. James Graham has been implementing table algorithms so we can test different approaches against real tables.
I'm not making progress with the table collections. I might dump the links for all the tables I've bookmarked but haven't worked on into a web page. At least that way other people interested in table headers can review the interesting things authors are doing.
Financial statement from Telecom (using my dreamweaver extension and recommendations).
http://annualreport07.telecom.co.nz/performance/financial-statements/income-statement
http://annualreport07.telecom.co.nz/governance/remuneration/employees
http://annualreport07.telecom.co.nz/disclosures/shareholder-information
On Cerbera's earlier comment about the unnecessary table mark up on some of the ODI tables: Yes, I agree, the markup may be over the top in places - it's a belt and braces approach - but, the point is that it is largely automated. From a content management perspective having a consistent policy on how tables should be marked up means there are no decisions to be made (on an ad hoc basis) by people who may not be qualified to make those decisions
http://annualreport07.telecom.co.nz/performance/financial-statements/income-statement
http://annualreport07.telecom.co.nz/governance/remuneration/employees
http://annualreport07.telecom.co.nz/disclosures/shareholder-information
On Cerbera's earlier comment about the unnecessary table mark up on some of the ODI tables: Yes, I agree, the markup may be over the top in places - it's a belt and braces approach - but, the point is that it is largely automated. From a content management perspective having a consistent policy on how tables should be marked up means there are no decisions to be made (on an ad hoc basis) by people who may not be qualified to make those decisions
That's a good point, Terrence. If tables need lots of special markup applied on a case-by-case basis to be accessible, it's unlikely those tables will be made accessible. headers+id can be applied to regular tables in a generic way and is probably the best supported technique around at the moment. But in a regular table, using <th> for header cells and <td> for data tables may well be enough to make them natively accessible. If we develop a good enough set of algorithms and ATs implement them, authoring an accessible regular table will become dead easy.
Despite searching hard for them, I'm not finding many irregular tables. Some expertise is probably inevitable for these tables and we should support those which already exist. But new irregular tables may just have headers+id in a few places to patch up things the algorithms couldn't figure out. It won't be needed on every cell, so even irregular tables should require less authoring effort.
For this stuff to work, the algorithms we develop must be built around ongoing research, development and testing. We have years to get it right. Everyone is invited to help.
Despite searching hard for them, I'm not finding many irregular tables. Some expertise is probably inevitable for these tables and we should support those which already exist. But new irregular tables may just have headers+id in a few places to patch up things the algorithms couldn't figure out. It won't be needed on every cell, so even irregular tables should require less authoring effort.
For this stuff to work, the algorithms we develop must be built around ongoing research, development and testing. We have years to get it right. Everyone is invited to help.
Steven Tew has raised doubts about the reliability of inferring semantics from presentational markup. Specifically, inferring <th> from <td><b>.
In the tables I've seen, <td>-only data tables are the most common. So if we can reliably determine when a <td> is being used in place of a <th>, that would make lots of existing tables more accessible. <td><b> is one of the most common techniques to indicate a table header. It is rarely used for other purposes in the tables I've seen, although it does happen.
So if Steven and anyone else feels like helping with HTML5, here's one of the many things you could help with. Go on a field hunt for data tables (the more mainstream the better, imho) which use <td><b> and link to them here. Summarising which use it as a header, which use it for something else and which use it for both headers and something else would help spread the workload.
Feel free to investigate any other authoring trends in data table headers.
In the tables I've seen, <td>-only data tables are the most common. So if we can reliably determine when a <td> is being used in place of a <th>, that would make lots of existing tables more accessible. <td><b> is one of the most common techniques to indicate a table header. It is rarely used for other purposes in the tables I've seen, although it does happen.
So if Steven and anyone else feels like helping with HTML5, here's one of the many things you could help with. Go on a field hunt for data tables (the more mainstream the better, imho) which use <td><b> and link to them here. Summarising which use it as a header, which use it for something else and which use it for both headers and something else would help spread the workload.
Feel free to investigate any other authoring trends in data table headers.
RNIB have written Better Connected, Better Results: Table Headers. It's a friendly and straightforward article about why users really do need headers need to be marked up. Always cool to see articles written about what really does work.
I guess this means HTML5 really does need to define how headers work. We can't just leave it to users to muddle through data tables and for ATs to apply crude heuristics like assuming the first row and the first column contain headers. And I guess there is a lot of potential value in finding reliable ways to infer headers in tables where <th> hasn't been used, since that's "One of the most common accessibility problems [RNIB] find".
But things would be a lot easier if everyone started using <th> and retrofitted it to every table in existence!
Interestingly, they find that neither scope nor the headers+id method are necessary in regular data tables. That seems to support what Jake found with Home Page Reader when testing the minimal.html variant I made for the Gorleston Tide Table. RNIB only tested with JAWS, afaict.
I guess this means HTML5 really does need to define how headers work. We can't just leave it to users to muddle through data tables and for ATs to apply crude heuristics like assuming the first row and the first column contain headers. And I guess there is a lot of potential value in finding reliable ways to infer headers in tables where <th> hasn't been used, since that's "One of the most common accessibility problems [RNIB] find".
But things would be a lot easier if everyone started using <th> and retrofitted it to every table in existence!
Interestingly, they find that neither scope nor the headers+id method are necessary in regular data tables. That seems to support what Jake found with Home Page Reader when testing the minimal.html variant I made for the Gorleston Tide Table. RNIB only tested with JAWS, afaict.
Just as a point of interest, there is an extant International Standard for HTML: ISO-HTML
[url="http://jp29.org/"]Pickering Pages[/url] - XHTML served using Content Negotiation
XHTML+RDFa | DC Metadata | RDF | XML | FOAF | RSS Feed
[url="http://jp29.org/"]Pickering Pages[/url] - XHTML served using Content Negotiation
XHTML+RDFa | DC Metadata | RDF | XML | FOAF | RSS Feed
Ian Hickson has gotten to table issues. You can track changes to the specification so see what is being changed. The headers attribute has been added to the <td> elememt. It seems he will be building on existing research, noting URLs to tables, checking photos of tables from Joe Clark and analysing what he's finding and looking for patterns. He's seen the proposed smart headers algorithm text and has started updating the HTML5 header association algorithm for data tables.
Not really the actions of someone who wants to block accessibility, eh?
Oh, Zcorpan linked me to this interesting diagram. It summarises some common or noteworthy table patterns and assesses whether they would work with an algorithm.
(EDIT) I think the timezone difference means I'm doomed to miss the tables party on IRC.
Last edited by Ben Millard on 21 Mar 2008 09:35 pm; edited 2 times in total
Not really the actions of someone who wants to block accessibility, eh?
Oh, Zcorpan linked me to this interesting diagram. It summarises some common or noteworthy table patterns and assesses whether they would work with an algorithm.
(EDIT) I think the timezone difference means I'm doomed to miss the tables party on IRC.
Last edited by Ben Millard on 21 Mar 2008 09:35 pm; edited 2 times in total
| ben wrote: |
| headers attribute has been added to the <td> elememt. |
Due in no small part to the work carried out by you and Jgraham.
Thanks Ben!
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Cheers Steve. Quite a few people have contributed to the development of table accessibility in HTML5, including yourself and several other Accessifiers. Updates to the Acknowledgements section of the HTML5 draft reflect this. I'm dead chuffed to have my name somewhere on the draft of a W3C spec, I must admit!
An explanation of the photo:
So there you go. Now there's a reasonable collection of data tables (me), a prototype implementation (James Graham) developed with feedback from various people (notably Simon 'zcorpan' Pieters) and draft spec text (James Graham again) the cogs are whirring as promised.
An explanation of the photo:
| Ian Hickson wrote: | ||
-- Ian Hickson |
Please take a look at the order comfirmation form on http://www.next.co.uk. The more items you add with different delivery methods (courier, colect from store, 2 man delivery, item delayed etc.) the more complex the table becomes.
There's most porbably a better way to display this informatio, but you wanted a real world example right?
There's most porbably a better way to display this informatio, but you wanted a real world example right?
Thanks Steven. Can you get a screenshot showing it? Saves everyone having to browse around that rather slow website adding things to a shopping basket just to analyse one data table.
No rest for the wicked! I've published a comparison of Smart Headers and HTML5, which was listed as Action 85 in the HTMLWG Tracker. I've created a thread on the Public HTML mailing list, so if you're a Participant in HTMLWG you can reply to that with any feedback. Otherwise, you can leave a reply here.
You can also discuss it on your blog, another forum, a publicly archived IRC channel or whatever. Just e-mail me a link if I'm to see it.
Feel free to spread the news around any other communities who would be interested in reviewing this.
You can also discuss it on your blog, another forum, a publicly archived IRC channel or whatever. Just e-mail me a link if I'm to see it.
Feel free to spread the news around any other communities who would be interested in reviewing this.


