Summary

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. With simple and most complex tables, this is a reasonable assertion, but doesn't work with overlaid and irregular tables, where the associated headers aren't in the same column or row.

Author: Gez Lemon

Contents

Use of scope and headers

There has been a lot of debate on the HTML mailing list and in the blogging community about the lack of the headers attribute in the current HTML 5.0 working draft for the th element and the td element with data tables. HTML 4.01 includes a headers attribute for th and td elements that allows a space separated list of cells to be specified as headers for the cell containing the headers attribute. The headers attribute is vital for associating headers in irregular tables, or even quite simple tables with data that is overlaid.

The HTML 5.0 working group's stance is that the scope attribute should be sufficient to describe complex tables.

The main reason headers="" isn't currently in the HTML5 specification is not that there are no people talking about headers="", it's that there is little to no use of headers="", and that the little use there is is either incorrect or simple enough that scope="" handles the cases fine anyway.

[Back to the contents]

An Overlaid Table Example

It's not difficult to come up with an example where the scope attribute alone is not sufficient to describe the headers for a particular data cell. Consider the overlaid table below. The table has a conceptual divide that runs from the top-left corner to the bottom right, creating two triangles. There are four rows of headers along the top, right, bottom and left. Data cells on the shared hypotenuse have the same row and column headers. Data cells that belong to the lower-left triangle are headed by the left and bottom header cells, and the data cells that belong to the upper-right triangle are headed by the top and right header cells.

To help aid understanding the table, cells on the hypotenuse are white on a black background; cells in the lower-left triangle have a light green background; cells in the upper-right triangle have a transparent background. For example, cell 14 in the upper-right triangle has headers of D and 8; cell 19 is on the hypotenuse, so has headers of I, 4, 9, and D; cell 24 in the lower-left triangle has headers of I and 5.

Simply Complex
A B C D E
1 Cell 1 cell 2 Cell 3 Cell 4 Cell 5 6
2 Cell 6 Cell 7 Cell 8 Cell 9 Cell 10 7
3 Cell 11 Cell 12 Cell 13 Cell 14 Cell 15 8
4 Cell 16 Cell 17 Cell 18 Cell 19 Cell 20 9
5 Cell 21 Cell 22 Cell 23 Cell 24 Cell 25 10
F G H I J

If the column and row headers were marked up with scope, the relationship wouldn't be correct, as each row would be headed by the header cells on both sides of the row, and each column would be headed by the header cells at the top and bottom of the column.

[Back to the contents]

Backwards Compatibility

Overlaid and other types of irregular tables are very rare on the web, but we still require a mechanism to mark them up correctly. Ideally, we could do with something more generic, like the labelledby attribute from WAI-ARIA's state and properties Module, as this could be used to describe the associated headers for each cell, label for a form control, and so on. There is no mention of a generic attribute for labelling objects in the HTML 5 global attributes. Also, backwards compatibility is a concern for the HTML 5 working group, as they include a font element for backwards compatibility with older WYSIWYG editors.

The font element is purely presentational - if it wasn't supported, the worst thing that would happen in a user agent is that the text would be displayed without the presentational information. It doesn't create an accessibility barrier in the same way that removing something as vital for comprehension as the headers attribute would.

There is no doubt that we require something that allows irregular data tables to be marked up so that they are understandable by assistive technology, and this is something that the headers attribute does adequately right now. I would love to see something more generic introduced that would also work in other areas or rich internet applications, like WAI-ARIA's labelledby attribute, but at the same time, we need to ensure whatever is proposed doesn't break the web. W3C technologies should be built considering accessibility from the ground up. I do hope that the HTML Working Group participants change their stance on this issue and consider keeping the headers attribute, as we definitely need it to support accessibility.

[Back to the contents]

Category: Accessibility.

Comments

  1. [html-scope-headers-debate.php#comment1]

    Interesting example. I wonder 1) how many people are using such tables today and 2) how many of those people mark them up in an accessible way?

    Also, I don't think that's the HTML WG position. That's just what Ian concluded based on the discussion so far.

    Posted by Anne van Kesteren on

  2. [html-scope-headers-debate.php#comment2]

    Hi Anne,

    1) how many people are using such tables today?

    Overlaid and irregular tables are very rare on the Web, but do exist; mostly in scientific/engineering disciplines. Despite being rare, it's still important that we're able to mark it up so that data cells can unambiguously be associated with their header cells.

    2) how many of those people mark them up in an accessible way?

    I suspect it's very rare, although we have helped clients create accessible overlaid tables, such as the example demonstrated here. Whether these types of tables are marked up correctly is a bit irrelevant (obviously, we wish they were all accessible); the point is that developers should be able to make overlaid and irregular tables accessible.

    Also, I don't think that's the HTML WG position. That's just what Ian concluded based on the discussion so far.

    That's better than I thought, and I hope I haven't misrepresented the working group with my comments here. The headers attribute isn't included in the current working draft, and reading through the mailing list, there appears to be considerable resistance to putting it back or providing another mechanism for labelling objects.

    Posted by Gez on

  3. [html-scope-headers-debate.php#comment3]

    Advice from WAI and the PFWG on the potential accessibility impact of the absence of the headers attribute for HTML 5 will be forthcoming.

    Re: headers attribute debate:
    http://lists.w3.org/Archives/Public/public-html/2007May/1208.html

    Will get back to you Re: headers attribute debate
    http://lists.w3.org/Archives/Public/public-html/2007May/1218.html

    Also, per Don Raikes, "Oracle's web-based solutions all use the headers= attribute and have since roughly 2001/2002."
    http://lists.w3.org/Archives/Public/wai-xtech/2007May/0072.html

    Posted by Laura on

  4. [html-scope-headers-debate.php#comment4]

    Thank you for the extra context, Laura. There are also other tools that use the headers attribute - XStandard, arguably the most standards compliant WYSIWYG editor, automatically inserts the headers attribute to associate headers with data cells. Personally, I would rather it didn't, as it unnecessarily bloats the markup for simple data tables, but they've made the decision based on the fact that assistive technology traditionally has very poor support for the scope attribute, and very good support for the headers attribute. I'm also aware of a few companies that have style guides that insists that data cells are associated with their headers using the headers attribute for the same reason.

    Posted by Gez on

  5. [html-scope-headers-debate.php#comment5]

    Gez, if very few people to no people use the feature, how does it help accessibility? It seems better to try thinking of a way that makes it more accessible without requiring authors to do anything besides the logical things.

    Posted by Anne van Kesteren on

  6. [html-scope-headers-debate.php#comment6]

    Hi Anne,

    Gez, if very few people to no people use the feature, how does it help accessibility? It seems better to try thinking of a way that makes it more accessible without requiring authors to do anything besides the logical things.

    The headers attribute at least provides a mechanism to make complex data tables that cannout be made accessible with the scope attribute accessible to assistive technology. Few people provide alternate text for non-text content, but we wouldn't want an HTML specification to drop support for alternate text because of uninformed or lazy designers/developers. We most definitely do require a markup language with an infrastructure that supports accessibility.

    It's an ongoing battle that we also need to persuade authors, authoring tools, and user agent vendors to support and provide accessibility enhancements, but it is essential that the underlying infrastructure is in place to afford that. If there is a way to make something accessible without requiring complex markup, I would fully support it - unfortunately, the scope attribute in its current form isn't going to be sufficient.

    Posted by Gez on

  7. [html-scope-headers-debate.php#comment7]

    I can't recall ever seeing a table like that with different headers on opposite sides. At first glance, I didn't understand the structure at all until I read your explanation.

    It would help if you could provide some real world examples of tables like that, or at least some plausible use cases for it. If it doesn't occur frequently on the web, does it occur in books or something?

    Posted by Lachlan Hunt on

  8. [html-scope-headers-debate.php#comment8]

    There definitely has not been any decision made on this yet. Right now the problem is lack of research. We need to know whether headers="" is used correctly more often than not, to determine whether or not it's actually helpful. We need to study exactly what speech readers do (in case it's not what the spec says to do). We need to study what authors need. We need to work out how we can make more tables accessible despite the way that most authors are ignoring the available features.

    Regarding one of the earlier statements, though, I have to be clear. We are not going to have semantics for everything. If something is rare, then it won't be supported. It really is that simple. This is about achieving the 80% common case, it's not about making a language that does everything. There are hundreds of things that people have asked for which are not included because right now they simply don't have the demand. For example, there's no way to mark up the relationship between two SPAN elements containing the name of a lion and the name of its kitten. There's no way to mark up the relationship between two numbers in a big table (e.g. "that number is twice this number"). If the occurrences of such tables are rare, then that, on its own, is an argument against this feature.

    We have to have this razor, this restraint in adding features, because otherwise our language will become bloated and incomprehensible.

    Finally, a general point on accessibility. It is FAR better to come up with technologies that result in the default case being accessible than it is to come up with technologies that require extra work from the author to be accessible. If we have to add markup for accessibility then the disabled users have ALREADY LOST, because most authors won't add it. It's worth bearing this in mind when trying to design features. Accessibility is like security -- it's not something you can tack on afterwards. You have to bake it in from the beginning so that there is simply no way to use the features in a way that is NOT accessible.

    Posted by Ian Hickson on

  9. [html-scope-headers-debate.php#comment9]

    I often come across very weirdly-laid-out tables in old books ... which I then turn into HTML eBooks for Project Gutenberg. Since learning about accessibility I have been using the headers attribute for them, and scope really wouldn't do.

    Over on accessifyforum some of us have been discussing this issue, and I posted links to 5 examples from eBooks.
    http://www.accessifyforum.com/viewtopic.php?t=8083

    Posted by Laura on

  10. [html-scope-headers-debate.php#comment10]

    Hi Lachlan,

    It would help if you could provide some real world examples of tables like that, or at least some plausible use cases for it. If it doesn't occur frequently on the web, does it occur in books or something?

    I can't provide any real-world examples, as the only examples that spring to mind are used in a closed environment. This is an example of a plausible use case, though, as overlaid tables are often used for comparing and contrasting data; I just don't have the URL of a live example on the web right now. I suspected this question would be asked, and spent a considerable amount of time last night trying to find a real non-copyrighted example, but was unable to. That doesn't invalidate this example, though.

    Although it's rare, there are probably tens of thousands of real-life example of this type of relationship, but will be difficult to find amongst the several billions of websites out there. Also, as Anne pointed out, if I could lay my hands on an example that I could demonstrate, it would be unlikely that it would be marked up correctly, and I wouldn't like to see this example dismissed for using invalid markup, as other examples were dismissed on the HTML mailing list for being inaccessible. Regardless of how people markup complex table now, which is generally quite well when accessibility is a consideration, we must to be able to unambiguously associate data cells with their appropriate header cells; I am all in favour of keeping it as simple as possible, but we also need to be able to handle complex irregular data tables and overlaid data tables.

    Posted by Gez on

  11. [html-scope-headers-debate.php#comment11]

    Hi Ian,

    The first part of your message is very encouraging. I'm sure you'll be amazed to discover that screen readers rarely do what specifications say they should do, but do work remarkably well with headers markup. I would also encourage you to investigate WYSIWYG tools such as XStandard, if you haven't already examined them.

    Regarding one of the earlier statements, though, I have to be clear. We are not going to have semantics for everything. If something is rare, then it won't be supported. It really is that simple. This is about achieving the 80% common case, it's not about making a language that does everything. There are hundreds of things that people have asked for which are not included because right now they simply don't have the demand. For example, there's no way to mark up the relationship between two SPAN elements containing the name of a lion and the name of its kitten. There's no way to mark up the relationship between two numbers in a big table (e.g. "that number is twice this number"). If the occurrences of such tables are rare, then that, on its own, is an argument against this feature.

    By definition, people with disabilities are a minority. Comparing people with disabilities with a casual request to provide a relationship between two span elements containing the name of a lion and the name of its kitten is completely outrageous, and trivialises accessibility.

    Finally, a general point on accessibility. It is FAR better to come up with technologies that result in the default case being accessible than it is to come up with technologies that require extra work from the author to be accessible. If we have to add markup for accessibility then the disabled users have ALREADY LOST, because most authors won't add it. It's worth bearing this in mind when trying to design features. Accessibility is like security -- it's not something you can tack on afterwards. You have to bake it in from the beginning so that there is simply no way to use the features in a way that is NOT accessible.

    I completely agree with the concept of including accessibility as a core part of the infrastructure, which is why I'm taking the stance that it's inevitable that there will be complex relationships that must be able to be modelled with markup alone. If it's a simple structure, I completely agree that authors should be encouraged not to add redundant markup to maintain a relationship that can easily be deducted from basic markup. With that, we have to accept that complex relationships also have to be able to be marked up with core HTML, which is why there is a requirement for the headers attribute, or an equivalent, such as the labelledby attribute suggested by WAI-ARIA. Personally, I would advocate for both, as the headers attribute would afford some backwards compatibility, but the labelledby attribute provides a more generic mechanism that could work for labelling any complex object.

    It is completely unacceptable to state that because something is only applicable to people with disabilities, hence, less than 80% common, that it will not be provided. The W3C process requires that technologies must be accessible, so hopefully that will help change your view that accessibility provisions are similar to pandering to people's whims, rather than provisions for people who cannot readily change aspects about themselves.

    Posted by Gez on

  12. [html-scope-headers-debate.php#comment12]

    provide some real world examples

    I am getting quite sick and tired of this tact of reasoning from some members of the HTML 5 working group.

    When pray tell will we see real world examples of <canvas>? And if there are none to be seen, why are we adding this "bloat" to the code-base? Because there have been requests for it?

    OK then, we are "requesting" THAT YOU NOT REMOVE AN EXISTING MARKUP CAPABILITY THAT WE REQUIRE (that should be used more often than it currently is), IS CURRENTLY SUPPORTED BY REAL WORLD USER AGENTS, AUTHORING TOOLS & APPLICATIONS (Oracle's web-based solutions all use the headers= attribute and have since roughly 2001/2002), AND IS CURRENTLY MANDATED BY NUMEROUS OFFICIAL INSTITUTIONS.

    The continued insistence that the current authors/editors know better then the collective voice of those who specialize in online accessibility issues is far more telling than all of the "we get accessibility" platitudes they continue to spout in response to the complaints being voiced by experts in OUR community. The web accessibility community does not need to be told that:

    Accessibility is like security -- it's not something you can tack on afterwards. You have to bake it in from the beginning.

    ...we've been telling others that for years now. Can you be any more condescending?

    The continued refusal to acknowledge real and critical comments leaves me with no other feeling that what will ultimately emerge is a fractured landscape where rather than one common markup code, authors will be required to choose one over the other - and browsers will be left with no other choice than to support both: HTML5 for fancy pictures and visual rendering, and XHTML1 (or 2) with robust semantic support for accessibility considerations. I honestly didn't think that when Tim Berners Lee made his announcement last fall that this is what he had in mind - lord knows it's not what I was expecting.

    Smooth moves gang!

    Posted by John Foliot on

  13. [html-scope-headers-debate.php#comment13]

    I've used the headers attribute a couple of times in production situations at my job. Both times it was for tables like this:

    -----------------------------
    | TH 1 | td 1 | TH 2 | td 2 |
    -----------------------------
    | TH 3 | td 3 | TH 4 | td 4 |
    -----------------------------

    I've no idea how many people are using tables like this, or marking them up in an accessible way. And I can see the sense in leaving out something that isn't used, cos it makes things simpler.

    But the headers attribute allows web authors to make some tables more understandable for screen readers (and other software we haven't even dreamed up yet). The font element allows web authors to, what, avoid learning a little CSS? Great.

    Paving the cowpaths is a good principle. It's not the only principle.

    Posted by pauldwaite on

  15. [html-scope-headers-debate.php#comment15]

    Gez, you're basically saying I have to take your word for it and, as much as I trust you're not lying to me, it's just not quite good enough. Surely you could make up some example tables using realistic example data. If you really can't publish them publicly for whatever reason, feel free to email some examples directly to me. Just put fake, but realistic data in them.

    John, I find you're attitude to be rude and unproductive. If you can't provide any actual real world evidence that a feature is either used, or at least some examples where it should be used, then you're effectively saying: this will be useful for these situations that never actually occur, which is simply unacceptable.

    Regarding canvas, there are plenty of examples of real world use. There are various graphs, games and utilities made using it. See these, for example.

    http://www.liquidx.net/plotkit/
    http://canvaspaint.org/
    http://canvex.lazyilluminati.com/

    Posted by Lachlan Hunt on

  16. [html-scope-headers-debate.php#comment16]

    Gez, I think Ian meant with the 80% case that the table you provided is not a common table ("outside" the 80%). I don't think the 80% point has anything to do with accessibility.

    Posted by Anne van Kesteren on

  17. [html-scope-headers-debate.php#comment17]

    Lachlan,

    It appears then that we both share one thing in common - we believe that the other's "attitude" is rude and unproductive.

    There have been numerous examples offered illustrating the need for these constructs, including the key fact that Oracle based tools are already using @headers in tables, as well as the fact that at least one other authoring tool (XStandard) is also enabling their use. Repeatedly, valid studies have pointed that @headers *TODAY* are better supported by Adaptive Technology tools then @scope, and clear articulate examples have been provided to the HTML5 working group from varied sources. Institutional requirements for their need have also been provided: developers who are *mandated* to use these constructs, today, now, in production. In each instance, these comments and examples have been dismissed perfunctorily as being obscure, irrelevant or not sufficient.

    As for "plenty of examples of <canvas>"... gimme a break - 3 experimental examples you provide, including one that states: "...The primary goal wasn't to build a painting web app, but to experiment with <canvas>..." {CanvasPaint}, and an other that is so inaccessible as to be almost criminal: 

    
<h1> Screenshot</h1>
<p>If you do not see the above, this is what you should have seen:
</p>
<p> <img src="http://media.liquidx.net/static/plotkit/plotkit-demo.jpg" alt="PlotKit Screenshot"/> 
</p>

    And you criticize Gez for a non-real world example?

    It is clear to me, and others who have written to me directly, that some of the members of the working group have pretty much made up their minds what should and should not be in HTML5, and to hell with anyone else's concerns, comments or criticisms. You may not like my attitude much, but rest assured, my attitude is not the only one being criticized "in the wild".

    Gez, I apologize in advance if this has gotten "flamey", and will now bow out. Thank you for trying to move this forward.

    JF

    Posted by John Foliot on

  18. [html-scope-headers-debate.php#comment18]

    Hi Gez, I'm glad you raised this issue here; thanks. A week ago I received an email from Ben 'Cerbera' Millard saying that WHATWG was considering removing the headers="" attribute for HTML 5 and asking "Do you find irregular table to be so rare they are safely ignored?"

    My answer was "No!" And I pointed to a couple of complex tables. Ben's response was that those tables could be handled with scope, colgroup and rowgroup and he referenced the marked up versions. Ben also pointed to an algorithm to associate headings with data cells for such complex tables http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tabular.html#header-and-data-cell-semantics.

    Although headers/id markup is relatively complicated it can be explained with a couple of examples. The algorithm that Ben referenced is incredibly obscure. I can't imagine trying to explain that or including it in our Accessibility training! And perhaps most importantly, in order to apply the scope/group technique, the table must be restructured. You can't just add markup to an existing table as you can with headers/id. More often than not, the people adding the accessible markup are not the ones who created the table.

    Those people are probably US Federal employees (probably also non-technical) because Federal agencies are required by Section 508 to have accessible web content. When 508 became effective, screen readers (for crying out loud they are NOT "speech readers"!) did not support headers/id. Now they do. Screen Readers do not support scope very well and the rowgroup, colgroup elements, not at all. Before they decide to eliminate headers="" I hope they contact Section 508 Coordinators of US Federal agencies - they are the ones who know about complex tables and I suspect they will be very upset if headers="" is removed.

    Posted by Jim Thatcher on

  20. [html-scope-headers-debate.php#comment20]

    @Gez: I'd like to start by complimenting you on another timely and informative article. I hoped my round of e-mails [1] would prompt some level-headed accessibility expert heads like yourself to look into this issue. Good linking, too.

    My thanks go to all who responded (listed in [1]). I haven't asked to make their messages public yet.

    @Laura: Your work on this issue is exemplary, imho. In fact, it's what inspired me to see if I could help.

    @John: I can understand your point of view. When I first came across WHATWG's work I started reading the rationale for decisions by its main contributors. At first, it seemed somewhat dismissive of community feedback and rather exclusive (even elitist).

    However, as I've learnt more about the group and the issues involved I've appreciated the difficult choices they have to make. I think it is an honest attempt to improve the web...they are just tackling it with "a different kind of approach"[2] than us.

    When Ian (and others) ask for more research to back up claims that headers="" is worth keeping for accessibility reasons, my feeling is that query is genuine.

    Working in the field of present-day web accessibility is a struggle. It affects the quality and equality of people's lives, which makes it an emotive subject. But I think we'll better serve our purpose through reasoned discussion and study, even if it means considering ideas which may at first seem reckless.

    You've probably learnt all this in the past, so I hope it doesn't seem belittling for small fry like me to repeat it.

    @Ian, Anne, Maciej, et al: I'd like to acknowledge the generally tactful responses of the main WHATWG contributors here and elsewhere.

    HTML may just be a file format, but the social equality made possible by web accessibility can impassion the point of view of us principled web developers. Please don't take it too personally and do stay open to feedback from us!

    Also, I've noticed you keeping track of accessibility in the "blogosphere". That's commendable outreach at a level I don't often see from W3C.

    @Jim: I too felt my brain being tied up in knots by the WHATWG prose for a scope="" algorithm. I dare say the writing style makes sense to UA programmers but it could hardly be called "plain English". (I should e-mail Tommy Olsson [3] to see if he'd study it and write a tutorial for what it means. Maybe it's already been done?)

    Basically, I think it ends up doing the same thing as the scope="" attribute in HTML4 would do, which is intuitive apart from the "colgroup" and "rowgroup" values. In HTML5, when scope="" is absent from a table header the "auto state" is used: the header is applied to the right of and also downwards from its position. HTML4 suggested something like this might be used in tables where no cells contained accessibility markup. [4]

    The markup I produced for his two example tables are [5] and [6].

    @Ian: The problem is you're asking us to provide evidence on current use when we don't have the resources for the scale you want. AFAIK, you're the only person who has. I can appreciate you have other duties, but so do we. Plus, we aren't at Google.

    Your HTML markup study from December 2005 [7] included some measurements for tables [8]. Do you still have the figures for elements and attributes not shown in the SVG? They could be helpful, particularly the numbers for headers="", scope="" and abbr="".

    A list of the URLs of pages found using headers="" would be ideal. That would allow volunteers (like me) to check how the attribute is being used in a representative sample. We tend to have day jobs, so checking all the pages you found is unlikely to happen (there might be millions).

    In May 2007 you claimed all the table examples Laura Carlson provided could have been done in scope="" [9]. You didn't provide markup samples or test cases to prove your claim. Although you are a world expert on HTML, being an expert apparently isn't enough: accessibility experts are being required to provide exhaustive proof for things they are expert in.

    I've been testing the practical abilities of scope="" when faced with "in the wild" tables [10]. Would you like me to try applying scope="" to the ones you didn't do in [9]?

    [1] http://www.accessifyforum.com/viewtopic.php?p=52862#52862
    [2] http://annevankesteren.nl/2007/05/xtech-html5
    [3] http://www.autisticcuckoo.net/about/toolman.php
    [4] http://www.w3.org/TR/html4/struct/tables.html#h-11.4.3
    [5] http://sitesurgeon.co.uk/!dev/tables/thatcher/01-water/
    [6] http://sitesurgeon.co.uk/!dev/tables/thatcher/02-monitor/
    [7] http://code.google.com/webstats/
    [8] http://code.google.com/webstats/2005-12/tables.html
    [9] http://lists.w3.org/Archives/Public/public-html/2007May/1036.html
    [10] http://sitesurgeon.co.uk/!dev/tables/

    Posted by Ben 'Cerbera' Millard on

  21. [html-scope-headers-debate.php#comment21]

    I didn't come to this page with any strong feelings one way or the other, but it does seem that if a feature is out there already and working well, you need a DAMN good reason to remove it. If it goes, I suspect it'll end up like the target attribute - if people have a need for it and it works in browsers, people will use it, and to hell with whatever the W3C say.

    If we had an existing set of elements for identifying lion-kitten relationships (don't lions have *cubs* btw) then I'd be in favour of retaining them, regardless of how obscure the use case is, unless there was something specifically wrong with them. So what's wrong with headers?

    Having said that, I find Gez's example has very poor accessibilty. Sighted readers, who won't be able to refer to a headers attribute even if it exists, are gonna really struggle to figure out what's going on in that table, particularly if they have a cognitive disability to contend with. If your table is so complex that you have to mark up where each cell's headers are, it should be a warning sign that you should consider other ways of presenting the data - such as using multiple simple tables, instead of one overly complex one.

    Posted by Chris Hunt on

  22. [html-scope-headers-debate.php#comment22]

    Having said that, I find Gez's example has very poor accessibilty. Sighted readers, who won't be able to refer to a headers attribute even if it exists, are gonna really struggle to figure out what's going on in that table, particularly if they have a cognitive disability to contend with.

    The example is very accessible. We're looking at complex tables, so the table is meant to be complex. As the table is marked up correctly, tools can be used to transform the view to make it more understandable, particularly for people with cognitive disabilities. For example, view it with the table inspector. If the table wasn't marked up properly, there would be no way to deduce that relationship.

    Posted by Gez on

  23. [html-scope-headers-debate.php#comment23]

    I've created a demo page that has the same data as your complex table, but split up to two tables. That way it is probably easier to understand for sighted users, and using the header cell/data cell association algorithm in HTML5, doesn't need either of scope or headers attributes. I don't know how it performs in screen readers compared to your table, though. I also realise that it isn't always possible to split up complex tables (e.g. because you're not allowed to alter the original work).

    http://simon.html5.org/sandbox/html/simply-complex

    Posted by zcorpan on

  24. [html-scope-headers-debate.php#comment24]

    I've created a demo page that has the same data as your complex table, but split up to two tables.

    The data is originally from two separate tables - that's the point of overlaid tables; they merge tables to contrast and compare results. All three tables would be shown at once - data from table 1, data from table 2, then the overlaid data as an aid to understanding the data.

    There should be a way to markup overlaid and irregular tables in HTML 5.0, as there currently is in HTML.

    Posted by Gez on

  26. [html-scope-headers-debate.php#comment26]

    As the table is marked up correctly, tools can be used to transform the view to make it more understandable

    Well, with the tools available to me - a standard browser and the mark 1 eyeball x 2 - that table makes no sense at all. I suppose some real world data instead of the A, B, C, Cell 1, 2, 3 stuff might make it more obvious what's going on though.

    I'm not saying that there are no occasions where a complex, headers-attribute-requiring table would be the best choice. I am saying that if you have a table that can *only* be understood with the aid of assistive technology, maybe you should try to find a better way to do it.

    Posted by Chris Hunt on

  27. [html-scope-headers-debate.php#comment27]

    Ian wrote:

    You have to bake it in from the beginning so that there is simply no way to use the features in a way that is NOT accessible.

    Ian, unfortunately, you do not practice what you preach.

    1. Take for example h1 to h6. Very few people use these elements correctly and cause great accessibility problems. Yet you won't replace them by "h" element or another element.

    2. So long as inline formatting is supported, people will use formatting instead of heading.

    3. How about requiring that "blockquote" does not have a default indent formatting. That way authors won't use "blockquote" for indenting.

    4. How about removing support for nested tables. Then tables will more likely be used for storing data and not for layout. While you're at it, you can remove the "border" attribute and require that user agents render tables with a 1 pixel border by default even if cells contain no content.

    5. How about removing elements used strictly for formatting like "font", "i", "b", "small" etc.

    HTML 5 adds nothing to accessibility and it definitely does not have accessibility "baked" in.

    Posted by J.T. on

  28. [html-scope-headers-debate.php#comment28]

    Yeah, the HTML5 kids have already decided everything. They'e out-WCAGging WCAG. And yeah, they're making topic experts jump through hoops while they never have to back up any claims that derive from their own expertise. And yeah, Hixie can just run a search on his own previous Google dataset. And no, Foliot wasn't being "rude."

    Bravo, kids.

    Anyway, the definitive analysis of complex HTML tables is still Steve Ferg's:

    http://www.ferg.org/section508/accessible_tables_recommendations.html

    (Also, what's up with the borked previewing of Unicode characters in these comments, like â??quotation marksâ???)

    Posted by Joe Clark on

  29. [html-scope-headers-debate.php#comment29]

    Well, with the tools available to me - a standard browser and the mark 1 eyeball x 2 - that table makes no sense at all.I suppose some real world data instead of the A, B, C, Cell 1, 2, 3 stuff might make it more obvious what's going on though.

    Real world data would make the table obvious to a subject specialist; it's unlikely to make it clear to you personally, unless you were a subject specialist in the particular example shown. With regards to the tools available to you; that was a point raised by you - if a subject specialist with cognitive disabilities is having problems understanding the complex table, there are tools they can use, although it's slightly off-topic.

    Broadly speaking, there are three areas of responsibility in accessibility - the author (developer/designer), to ensure the underlying structure of the content is accessible; user agent manufacturers, to ensure their tools allow content to be rendered accessibly; and the user, to ensure they're using the correct tools. This post is only concerned with the author's role, and that the markup language they use is sufficient to create content that can be viewed by people with disabilities. People with disabilities can have tools made available to them to make the content accessible, but only if the underlying structure is correct (the subject being discussed here).

    I'm not saying that there are no occasions where a complex, headers-attribute-requiring table would be the best choice. I am saying that if you have a table that can *only* be understood with the aid of assistive technology, maybe you should try to find a better way to do it.

    The table can't *only* be understood by people using assistive technology - it would be understood by a subject specialist. Assistive technology is used by people with disabilities to help understand the content (the whole point of this post); it is a way of aiding people understanding the content (a point raised by you).

    Overlaid tables are a mechanism to *help* people understand comparisons of complex data. Requesting that tables aren't complex is patronising to people with disabilities, and not helping anyone - it's equivalent to not bothering to make an online store accessible, and thinking that a telephone number that can be used in the day is an equivalent.

    We need a way of marking up tables so that they're accessible to everyone; we have this at the moment, and we need it for the future.

    Posted by Gez on

  31. [html-scope-headers-debate.php#comment31]

    Once again many thanks to Gez and Juicy Studio for throwing some light on an important accessibility issue.

    Headers work with almost an infinite variety of tables and are well supported by screen readers. Scope works with only some table styles (albeit the most common ones) and screen reader support is patchy. These obvious facts have resulted in at least one bank in Australia recommending the use headers with all their data tables.

    And, we want to get rid of headers and rely instead soley on scope. I just don't get it!

    It seems that the only argument in favour of removing headers is that some people find them hard to use and other people use them incorrectly. Well excuse me, but I would not be alone in saying there are many, many sites where the img alt attribute is either not used at all or used incorrectly. And, don't get me started on the failure to explicitly associate form labels with thier inputs.

    Surely the failure by some people to implement a standard is not in itself sufficent justification for getting rid of that standard.

    Posted by Roger Hudson on

  33. [html-scope-headers-debate.php#comment33]

    I think the HTML Working Group should include the headers attribute in the HTML 5.0 working draft and move onto other issues regarding HTML 5.0 *wink*

    Posted by Alice on

Comments are closed for this entry.