Re:retention of summary attribute for TABLE element (with addendum on id/headers)

Thanks Laura for the link please see me comments below.

Laura said:
> Some of the rationale from the headers issue [1] may be applicable to
> the summary issue.

I think you are right. To be clear, from what I can see in the arguments
for and against @header and @summary - I would suggest the addition of
both to HTML 5. Most of my comments below relate to both.

> welcome joshue!

Thanks Gregory, also I love the quotes from Ambrose Bierce in your
mails, I am also a fan, he had a rare acidic intellect and he was funny.

I was going to change the subject of this thread to "Why changes what
works, with something that is not supported today and may not be
tomorrow?" but I will include it here anyway as it sets the tone for
what follows. Before I even start I wish to say that the successful
definition of standards is something that has to be in harmony with real
work use, if not then the greater the disconnect between the standard
and its use in the wild, the greater the potential problems for users of
assistive technology in particular. Just to be clear these problems are
not esoteric, abstract or theoretical - they can effect quality of life
for people with disabilities when they use on-line services.

In relation to @summary (but it could also be true for id/header), if
leaving an element or attribute within the future HTML5 specification
will have a low load, or drag on the specification, whatever you wish to
call it, then I suggest you leave it especially if the suggested change
may not be correctly supported by UA vendors and will certainly not be
backwards compatible.  I have also experienced enough problems getting
authors to learn how to correctly author HTML and do not wish to have to
learn or teach a different way of, for example marking up a table, when
solutions already exist, but that is not such an important issue. These
solutions may not be ideal and indeed there is always need for
improvement but change for changes sake is not wise. Backwards
compatibility is really important unless it is envisaged that authors
will just continue to use HTML 4 rather than HTML 5 if it does not have
suitable elements and attributes to mark up content correctly. In truth
this would not happen. Most authors would just use HTML 5 anyway even if
it means they are producing inaccessible content especially if
accessibility is low on their radar, as it often is. They will want to
use the shiny new coding language even if it is flawed or its use has a
real world negative impact on users of assistive technology, that they
also may not even be aware of.

Regarding

>> 1. James Graham's Reservations Concerning Invisible Metadata

> I think the fact that @summary is explicity invisible metadata is a reason to remove it, so that argument should go into that section. 

I don't think that @summary should be thought of as meta-data in the
sense that we usually think of it, sure it is strictly speaking "data
about data" but it has accessibility implications as it is used to
explicitly describe the purpose of a table and I don't think this is
sufficient a reason to suggest removing it. I agree with the conclusion
from,

> 1. The Importance of the Summary Attribute to the Navigation and Perception of Tables
> 
> Proposed: Retain the "summary" attribute from HTML 4.01 for HTML5

that "Summary is to the visual construct TABLE as "alt" is to IMG, and
title and description are to SVG"

Here are some comments below on the Issue: The "headers" attribute
currently is not in the HTML 5 specification from the ESW wiki.

> The scope/group technique handles the majority of use cases.

I have found UA support for @scope is patchy in user tests with JAWS,
especially older versions (<6). There are still many people with
disabilities using older assistive technology and its vital that they
are still supported. Newer versions of assistive technology cost a lot
of money that often is just not there.

> An insufficient amount of use cases exist to justify id/headers.

I don't know if that is true. Many screen readers support @header and
AFAIK it is certainly better supported than @scope.

> Complex tables are very rare on the Web. If something is rare, then it shouldn't be supported.

That is not a logical or rational statement. Many diseases are rare but
does that mean that there should be no treatment for them?

> The id/headers technique is sometimes used incorrectly.

The web is full of code that is applied incorrectly. If you randomly
pick a site from any random Google search will it more than likely be a
nice semantically correct, accessible website or a badly designed table
layout with sliced PSD files (with no alt text of course)?

> Adding headers to the specification will cause code bloat.

But if it is supported already by User Agents and if taking it out will
cause more problems than it will solve - it is a small price to pay.
Also there are acceptable levels of bloat.

> By the time HTML5 becomes widely used, one would hope assistive technology would support scope/headers. 

That is woolly logic and not good enough reason to remove a working
useful element from the specification to replace it with something that
may or may not be supported by UA's in the future.

> 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.

That sounds great. So I suggest retaining what works for backwards
compatibility such as @header and @summary and rolling out the new wave
for UA's that will support it.

> People suggesting including id/headers haven't demonstrated that it is needed.

Gez Lemons article on Juicy Studio makes a good case in point of one
that does. [1]

To sum up, I pretty much agree with all of the points in the rational
for why @headers should  be included in HTML 5 but some particularly
salient points are:

>Accessibility features address failure modes that are infrequent, but
critical when they occur.

Catering for people with disabilities takes energy thought etc for when
the services that they use are inaccessible that has a tangible 'real'
effect. Please do not take this logic lightly.

> The id/headers technique provides functionality today.

Which is a pretty good reason to keep it if for nothing else than for
backwards compatibility. If the solution (or suggested improvements) can
also be included and used when supported. The same can be said of @summary.

 If it is to be worked out of the system, it should not be an abrupt drop.

In the final analysis, chances are that it would.

Josh

[1] http://juicystudio.com/article/html-scope-headers-debate.php

Received on Thursday, 14 June 2007 11:45:41 UTC