Re: Complex Table Examples

I have to thank you (quite sincerely) for the amount of research you have 
done here. I do not share your conclusions -- I think scope="" handles the 
cases you have presented, while still being simpler -- but it is certainly 
refreshing to have actual data presented to back up a proposal.

On Thu, 17 May 2007, Laura Carlson wrote:
> >
> > * What are the use cases?
> The headers/id technique for complex tables is used in:
> - Official United States Postal Service policy (AS-508-A Section 508
> Technical Guidelines) are used in statements of work, vendor
> requirements, both internally and externally. - per Norman B.
> Robinson.

It's somewhat of a stretch to say that the above guidelines are actually 
using the headers="" attribute, given that the only actual "use" is an 
example that has been lifted straight from the HTML4 spec, *and then 
broken* so that it doesn't actually use the attributes the HTML4 spec 
introduces -- all the examples in that document use 'header=', not 
'headers='. Furthermore, all the sample tables in that section can easily 
be done using scope="".

> - Dutch Accessibility Law (R-pd.11.5).
> English Translation via Babel:

My dutch isn't very good, but I didn't see any mention of the headers="" 

> - National Science Foundation Policy and Standards manual.

This example uses header="" instead of headers="" at least once, and uses 
IDs with spaces, and thus would not even remotely work. This looks very 
much like an attempt at cargo-cult accessibility authoring -- people said 
headers=""/id="" were a good way to do accessibility, and so that was 
emulated, without understanding what was being done.

Furthermore, it would be far easier to do this example using scope="".

Are there actual examples of real tables following this best practice?

> - National Oceanic and Atmospheric Administration: National Weather
> Service, Section 508 policy.

The guideline itself says that it doesn't work, referring to "tomorrow's 
smart browsers". Furthemore, the actual example wouldn't work, because the 
IDs point to <span> elements, not <td>s/<th>s as required by the spec.

Furthermore, the example table here can already be done without headers="" 
using scope="" as described in HTML5. (This is already partly done in this 

> - University of Wisconsin Accessibility policy. 

This example can trivially be done using scope="", with much less markup 
that headers="" and id="". (Also, frankly, any page that uses that many 
nested layout tables has absolutely no business talking about 
accessibility requirements.)

> - California State University Policy

There are no use cases described here, so it's hard to determine whether 
this requirement is there for cargo-cult reasons ("accessibility experts 
talk about this so we'd better talk about it too") or whether there are 
real reasons.

Do you know of any pages actually following this guideline?

> - WCAG

This example is easily done using scope="".


This is just saying "use HTML's features"; if we had more complex 
features, it would say to use them; if we had fewer features, it would 
not have mentioned the need for complex ones.

> - Section 508

This requirement could as easily be referring to <th> or scope="" as it 
could to headers="" or axis="".

In any case, these rules are somewhat academic -- what's actually 
important here is examples in the wild, as you cite below. The main reason 
headers="" isn't currently in the HTML5 spec 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. (I'd love for someone 
-- maybe me, in due course -- to do a more in-depth study to check for the 
accuracy of these assertions.)

> Examples "in the wild":

That table could be done using scope="" without sacrificying much, if 
anything, in the way of accessibility. I'll take my hat off to you, 
however, that really is a real world example that would work.


That can be done using scope="". In fact, based on the markup, I'd say it 
was expanded from a system that used a scope="" model in the first place, 
so using scope="" may in fact help whoever authored that have a better 
roundtripping experience.

> "Fidelity Investments depends heavily on complex tables for displaying
> product and customer account information. Portions of the web site
> have been using complex table markup for years to improve
> accessibility. Unfortunately, most of the examples I am familiar with
> are behind the customer password.  For those with personal Fidelity
> accounts, look in the Accounts and Trade section...Id/headers are used
> in dynamic tables for grouping rows and/or columns (e.g. Large Cap
> Funds, International Funds, etc). Id headers are used on dynamic
> tables with irregular shapes, where the table provides a "total" row
> in a larger, more prominent font that will not fit in the regular
> cell. Cells are then merged in that row, breaking the standard
> connection to the TH for that column..."  - Jeanne Spellman.

The e-mail thread quoted above mentions actual examples. Would it be 
possible to get a hold of actual examples (not samples) that demonstrate 
its use in the real world?

> > * What problems it solves and how?
> [...] In contrast, headers/id attributes are used to specify information 
> per cell. In complex tables where not all column headers are relevant to 
> all cells in the column etc the headers will be announced on a per cell 
> basis when the headers/id technique is used.

The vast majority (in fact, the totality) of examples of real data tables 
that I have seen so far, including all those that are put forwards as 
examples of tables that "need" headers=""/id="" support, can in fact be 
done more simply using scope="".

I'm not denying that it is possible, of course, to come up with tables 
that couldn't be done using scope="", but I _am_ saying that the number of 
such tables is so insignificant, so small, that we should not have 
features to support them. If we agree that one tiny use case is enough 
here, then we will be going down a slippery slope of adding all kinds of 
random features with tiny use cases. In fact, there are features with many 
more use cases that don't make the bar -- e.g. dashed lines in <canvas>, 
to cite a recent controversial example.

> Scope attributes are used to specify table information per rows/columns. 
> Assistive technology (AT) (e.g. screen readers) assumes that all 
> columns/rows of headers should be announced. Currently WinEyes does not 
> support the scope attribute. [...]
> In a data table accessibility test, Roger Hudson and Russ Weakley 
> describe how "At this stage, it appears that id and headers are the most 
> effective way to make complex data tables accessible. Although id and 
> headers are slightly more difficult to code than scope, the apparent 
> poor screen reader support for scope means that this is probably not an 
> effective accessibility option." 

Lack of support isn't an argument against the simpler solution, since 
anything we do here is not going to be relevant for years.

> > * Who benefits and how?
> The vision impaired and the blind benefit because they can access 
> information on a per cell basis. Without proper markup to associate data 
> cells with header cells, table information is useless. Those who use 
> screen readers listen to data, without any visual cues. When this 
> technique is used it enables the user to determine which particular data 
> matches with which particular headers.

I agree with the use case. I'm just saying we have a simpler solution, 
scope="", that handles the overwhelming majority of cases better.

> Example id/header markup:

This example could easily be done using scope="".

> How it sounds in a screen reader:

That's... horrific. Wow.

> > * The incentive that authors will have to actually use it.
> It provides accessibility.

That's not an incentive, sadly. Evidence suggests that we should design 
features such that using them in a way that results in a good presentation 
is enough to get good accessibility.

> Incentives include:
> - It is good business practice. People with disabilities comprise of 
> approximately 600 million or 10% of the world population that form a 
> potential market which is untapped.

The Web clearly indicates that this is not an incentive. headers=""/id="" 
on tables is orders of magnitude harder than simple things such as using 
<h1> instead of <font>, yet the Web is full of the latter.

> - Access for people with disabilities to web sites is law or policy in 
> many places.

It's not clear to me that this incentive is working either. You provided a 
whole two examples of real world use of these attributes. Furthermore, 
even the laws themselves, as your citations above showed, often fail to 
follow their own rules.

> - It is socially responsible and equitable. It demonstrates that you 
> care about providing access to information for those who would otherwise 
> be locked out and lose their opportunity to use the web.

That's the same as the earlier incentives.

> - Many companies, organizations, and governments have train developers 
> and designers in the technique.

That's not an incentive.

> - Many tutorials, books, and courses are already in place.

That's not an incentive.

> For instance:

Oh look, that same W3C copyright example again, which can be done using 
scope="". :-)


scope="" handles that fine. Note, especially, the comment on that page: 
"It should be used with tables of a more complex nature, where the scope 
attribute will not work."


The scope="" feature handles that example fine. In addition, that page 
even suggests people not use headers=""/id="" but instead split tables 
into smaller tables, which is pretty good advice IMHO.


I covered this example above (it's the one you gave sample audio for).


I covered this example above (the Wisconsin one). Note, by the way, that 
this page also suggests splitting complex tables into multiple smaller 


All the examples for headers=""/id="" (even the "very" complex ones) can 
be done using scope="" as defined in HTML5. That page does reiterate the 
argument above that scope="" isn't as well supported as headers="", but 
that's feedback for the AT developers, not us. By the time HTML5 becomes 
widely used, one would hope the ATs would have addressed this. HTML5 
actually goes some way towards helping with this, by providing exact 
algorithms for associating table header cells with data cells, resulting 
in exactly the same data structures as headers="" provides.


Hey, it's the HTML4 example again. It's almost as if headers="" was so 
complicated to understand that the people suggesting its use couldn't come 
up with their own examples! ;-)


This refers to a number of sites, many of which are mentioned in this 
e-mail already. It doesn't make any specific suggestions.


scope="" handles this fine.


These aren't arguments in favour of headers="" or id="" specifically.

> - Current tools exist that help authors with this technique. These
> include but are not limited to:
>  Complex Table Inspector - Gez Lemon.
>  Table Inspector - Gez Lemon.

(Hey look, the HTML4 example again.)

These provides access to axis="" and scope="" as well as headers="".

>  Accessible Table Builder - Ian Lloyd.

This tool supports both scope="" and headers="" -- but, ironically, the 
complex tables it can create can all be handled by scope="" trivially.

>  WAVE - Temple University Institute on Disabilities and WebAIM.

I don't understand what this does with respect to tables.

>  Web Developer - Chris Pederick.

I couldn't really see what this tool does specifically with headers="", 
but I've installed it and will keep looking.

>  Cynthia - HiSoftware, ICDRI and The Internet Society
>  Disability Chapter.

It doesn't seem that this actually supports headers=""/id="", but I could 
be wrong.

>  Functional Accessibility Evaluator - Center for
>  Instructional Technology Accessibility.

This just seems to check for <thead> and <th>, not headers="".

>  Deque Ramp

I couldn't work out what it did with headers="".

> > * How it could be implemented.
> It already has been implemented via HTML 4.

Indeed, the "how" of implementing headers="", as well as scope="", seems 
well-understood. (Though, given the example you posted above, I'm not 
overly impressed. That's sad.)

> > * The incentive that UA vendors have to implement it.
> AT vendors already implement it.


To conclude, I must once again give you my thanks for these links. I'm not 
sure, however, that they support the argument in favour of headers="" 
specifically being put in HTML5, given scope="" and the definition it has 
in HTML5.

Do you agree? If you don't agree, what would be really helpful is an 
explanation of what it is that headers="" does that scope="" does not.

I can immediately grant you two things:

 1. headers="" is more widely implemented than scope="",

 2. headers="" handles some edge cases that scope="" cannot.

However, in the case of the second of these points, I do not think that we 
should necessarily optimise for such rare cases, and in the case of the 
first, I think it would be more helpful to have input from AT authors to 
explain *why* scope="" hasn't been implemented as widely. Is it simply 
that AT implementors haven't gotten there yet? Is the HTML4 definition to 
vague? Does the HTML5 definition help? Is the feature somehow 
fundamentally flawed?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 17 May 2007 22:08:42 UTC