W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Taking another round at @summary

From: Denis Boudreau <dboudreau@webconforme.com>
Date: Tue, 05 Jan 2010 18:12:54 -0500
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, HTML WG Public List <public-html@w3.org>
Message-id: <EBB531C0-9435-4137-911A-8BBA4D4F7973@webconforme.com>
To: Jonas Sicking <jonas@sicking.cc>
Hi Jonas,

On 2010-01-05, at 4:54 PM, Jonas Sicking wrote:

> On Tue, Jan 5, 2010 at 10:24 AM, Denis Boudreau
> <dboudreau@webconforme.com> wrote:
>> Even if another mechanism was provided to replace @summary, we're still
>> removing something that is useful to a lot of AT users today.
> 
> Really? Do you have data showing that is the case? All the data I have
> seen indicates that @summary is used extremely rarely, and when it is,
> it's often used in the wrong way.

What kind of data would you need? I'd be happy to provide. 

For every screen reader user that I put in front of two similar complex data tables, one accessible and one that's not, I'm pretty sure 100% would come to realize that the accessible version, thanks in part to the description provided through @summary, would actually be much easier to understand.

How many names do I have to come up with for this data to be receivable? ;p


>>  Why not simply add a new mechanism and keep a new-and-improved @summary safe and sound in HTML5?
> 
>> As a responsible member of this working group, why should I sign a blank check on something as important as this when I have no garantee that this new mechanism - that we have yet to envision - will do any better than @summary already does?
> 
> It seems to me that the WAI already has come up with a better solution: aria-describedby. This attribute has two advantages:
> 
> 1. It encourages the description to be visual to all users, not just users of AT tools. While still allowing the description to be only visual to AT users when that is desired by the page author. 2. It can be applied to all elements, not just tables.
> 
> 2. This attribute is already supported in HTML5.


Good solid point, thank you. OK, so maybe theoretically @aria-describedby is the new-and-improved @summary I was calling for. But it seems to me the main argument for getting rid of @summary in the first place was that people weren't using it properly, no?

I may be wrong (please correct me if I am), but with @aria-describedby, we seem to be stuck with a description for the table that's now available for everyone as content, including 99% of the people who don't need, nor require it to understand what the table represents. 

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

I mean, if they couldn't get THAT ONE right before, what makes us think they'll get it once HTML5 comes out?

But now, with @aria-describedby, we have to hide that content through CSS so sighted users don't have to "suffer" it's presence in the page. What kind of gain is that? And what real improvement have we provided for users accessing data tables? This is exactly the kind of result we're already getting with a well-defined @summary - without the hassle of managing an out-of-screen chunk of content for authors. We're pretty much asking authors to provide the same type of content: a table description will always be a table description. 

Once we realize authors keep using it wrong, will we consider throwing @aria-describedby out the window as well? ;p

So again, I ask : why should I sign a blank check on @summary when I have no garantee that @aria-describedby or or whichever other mechanism will do any better than what @summary already does? 

But what disturbs me the most is that it doesn't seem to solve anything for users with disabilities (for which we are doing this in the first place) : how well will this new mechanism work, for users who won't be able to upgrade their ATs to a version that actually supports @aria-describedby or whatever other mechanism we eventually come up with in HTML5?

Best regards,


--
Denis Boudreau,
Président

Coopérative AccessibilitéWeb
1751 rue Richardson, bureau 6111
Montréal (Qc), Canada  H3K 1G6

Téléphone : +1 514.312.3378
Sans frais : +1 877.315.5550
Télécopieur : +1 514.667.2216
dboudreau@accessibiliteweb.com
http://www.accessibiliteweb.com/
http://ww.twitter.com/dboudreau
Received on Tuesday, 5 January 2010 23:15:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT