RE: Taking another round at @summary

Jeremy Keith wrote:
> 
> Denis asked:
> > What garantee do we have that authors would provide a better, more
> > suitable description for content associated with aria-
> > describedby="table-description" referenced somewhere else in the
> > page with <div id="table-description">This-table-presents-blah-blah-
> > blah...</div> than they already do for a simple description with
> > <table summary="this-table-presents-blah-blah-blah..."></table>?
> 
> Because invisible data rots (see: <meta> keywords).
> 
> http://tantek.com/log/2005/06.html#d03t2359
> 
> That's a crucial difference between @summary and aria-describedby. The
> contents of aria-describedby can be made invisible, if the author
> wishes. The contents of @summary cannot be made visible.

Why can't the contents of @summary be made visible? Is there something in
the current or (more importantly) future spec that *forbids* user-agents
from making that kind of information available to all users? Surely even
today a clever fellow like you could bang together a Greasemonkey script
that could make the value of the summary data available to any user upon
request, as it is but text data in the DOM, just like the 'tags' that
Tantek made visible in the post you reference. 

As well, given the predominance of WYSIWYG editors and 'untrained' content
contributors in larger CMS type installations, if the content of the
aria-describedby data field (paragraph) is 'hidden' from onscreen view
(via CSS), then how will it change the "invisible data rots" problem? The
untrained content contributor doesn't see the text on screen, and so still
has no idea that it needs updating.  

Further, because that data has been disambiguated one step from the actual
table (i.e. content in a paragraph that the table references, rather than
data explicitly linked to the table element) editor tools might have a
harder time ensuring that when one element is updated that the other
should be as well (which may or may not be the case for any given table).
There *is* a value to a tighter binding of the data to the element than
the association that aria-describedby might provide. All WYSIWYG editors
that I have seen today that allow for the insertion of table summary
content allows for that insertion at the point when you are working on the
table itself, not elsewhere in the workflow (like creating a reference
paragraph after making your table, then hiding that paragraph away via
CSS). 

> 
> Personally, I think that this distinction that @summary draws between
> users of AT and other users isn't a helpful one. If history has taught
> us anything, it's that accessibility features turn out to be useful
> for everyone (e.g. the invention of the typewriter or closed
> captioning on television).

And history has also taught us that there is a difference between
Universal Design features and Accommodation Features, and @summary has its
place in the latter group - it is, at the end of the day, there primarily
for a specific sub-group of users, as Gregory Rosmaita has already pointed
out:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0039.html 

And you know what? That's OK - some accessibility features have remained
pretty much exclusive to disabled users too (e.g. the invention of
Braille, Wheelchairs, Hearing Aids...)

JF

Received on Friday, 8 January 2010 01:07:05 UTC