Re: Taking another round at @summary

Hi Denis (and others),

This issue has been discussed at length before. Many of the points you  
mention have been raised before, as have the counterpoints posted by  
others, and the counter-counter-points raised in response to those. If  
we can make progress on this issue, or add new information, then that  
is great. And I appreciate your desire to find points of agreement.

But I encourage everyone to think about whether your points have been  
made before (check the archives if needed) and try to avoid repetition.

Please all, keep in mind that this topic is one of the few that tend  
to devolve into perma-threads, and discussion in the past has gotten  
quite heated. Be cautious with your phrasing, and please try to avoid  
the same points to excess.

Regards,
Maciej

On Jan 5, 2010, at 10:19 AM, Denis Boudreau wrote:

> Good day everyone,
>
> There has been a lot of talk about the @summary in the past few  
> months, and since a consensus has yet to be established between us,  
> I thought I'd try to highlight how removing attributes like @summary  
> might delay the widespread adoption of HTML5 in some countries, like  
> parts of Canada for example.
>
> I think we can all agree that navigating through complex data tables  
> is one of the most difficult tasks we can ask an AT user to perform  
> on a web page. When integrated properly, @summary helps those users  
> by announcing what lies ahead.
>
> That being said, I believe one of the responsabilities of this  
> working group is to make sure that HTML evolves intelligently (which  
> I think it does, for the most part) while solving known and  
> identified problems for all users, not by creating new problems to  
> disabled users for the sake of evolution.
>
> Agreed, @summary, as it is, might not be a perfect solution. But  
> removing it altogether from HTML5 is a sure way to add to the  
> difficulties users with disabilities already experience when trying  
> to access tabular data. It's broken? Bad authors who write bad code  
> don't use it properly? Then I say let's roll our sleeves up and work  
> on improving it, instead of removing it altogether from the spec.
>
> Even if another mechanism was provided to replace @summary, we're  
> still removing something that is useful to a lot of AT users today.  
> 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?
>
> I have some faith that we may be able to come up with a solution in  
> the long run, whether it's through WAI-ARIA, HTML5, buddhism,  
> quantum physics or whatever. I also have faith that it will probably  
> be awesome, but if users can't afford to upgrade their AT to a  
> version that supports it, then they won't be able to benefit from  
> this improvement at all... then what will we do, as authors who care  
> about the accessibility of our content for all users, regardles of  
> their ability to follow the evolution of technology? Revert to HTML  
> 4.01 or XHTML 1.0, for an alternate version for users of out-of-date  
> AT versions? Hardly seems like an improvement to me... yet, this is  
> something that might very well happen down here in the trenches.
>
> Not everybody knows there are some free alternatives like NVDA out  
> there: when will the users be able to upgrade to an AT version that  
> support this new mechanism? And who will pay for those upgrades?  
> It's not because ATs upgrade their software that users are able to  
> afford the newer versions that come out.
>
> Tools like JAWS are quite expensive and most people I know, work  
> with or work for can't afford to keep up. As a result, most are  
> always stuck a few versions behind. At the end of the day, with  
> @summary gone, users will remain caught with that same old AT  
> version, but now, their tools won't be as reliable as they once were  
> since there won't be anything left to describe a table like @summary  
> used to do it for them.
>
> I understand all the concerns expressed in the editor's draft about  
> summary and table, but it doesn't change the fact that this is not a  
> theoretical debate : outside our ivory tower, there are people with  
> visual or cognitive limitations who need to have the table described  
> to them and there are sighted users who couldn't care less about  
> such an explanation because they can see it for themselves. We need  
> something that's transparent for them while being noticeable by AT  
> users. And @summary does just that today.
>
> Again, as a responsible member of this working group, I can't agree  
> on a decision that might mean more accessibility barriers for the  
> users I choose to represent here. Not when this standard comes from  
> the same Consortium that develops the likes of WCAG. I need  
> coherence. The W3C needs coherence. We all need coherence. The left  
> hand needs to know what the right hand does and vice versa. It would  
> be nonsense for HTML5 to go against the most basic accessibility  
> requirements that were just adopted last year by the WAI. And I'm  
> betting all my money that it's certainly not something the W3C wants.
>
> I humbly believe we are missing the broader picture. Look at it from  
> a government perspective:
>
> For instance, here in Quebec (Canada), like most public  
> administrations, we are putting together our own adaption of WCAG  
> 2.0, an accessibility standard called SGQRI 008. All in all, it's a  
> fairly good document that goes farther than most government  
> adaptation I've seen to this day. Again, not perfect, but it's got  
> teeth nonetheless and it's already done a lot to promote  
> accessibility in our local industry.
>
> In that standard, the use of the @summary is mandatory for complex  
> data tables. Mandatory. This standard is not going to change for at  
> least another 5 to 7 years. What that means is that every government  
> website, intranet, extranet developed by or for the government that  
> contains such elements have to have a @summary or else they fail at  
> compliance and are subject to reddition (which is not a good thing).  
> Removing @summary from HTML5, in our case, means that the Quebec  
> government will be forced to stick to HTML4.01 or XHTML 1.0, whether  
> they like or or not. @summary might be taken out of our standard  
> eventually, everything is possible. But it's going to be difficult  
> to do so because :
>
> a) it's part of the accessibility culture,
> b) it's widely implemented in the ATs,
> c) users expect it in a data table and
> d) I, the accessibility-guy who tells the government what to do with  
> accessibility, strongly believe in it.
>
> Don't get the wrong idea: I'm not asking to adapt HTML5 to the needs  
> and expectations of the people from Quebec. I know better.
>
> I'm simply pointing the fact that we've built our standard based on  
> existing material and any new stuff that comes out and throws away  
> the existent might have a hard time getting adopted. Not only  
> because it's very difficult and costly to open a standard and change  
> it, but it's also nearly impossible, when you're a public  
> asministration who's taken a clear position on digital inclusion, to  
> replace something that works with the promise of something might  
> work much better one day.
>
> It's a simple question of going by the book. We may not be the only  
> province/country that goes down that route. Amazing how a simple  
> little detail like that is likely to throw off the adoption of the  
> otherwise quite promising HTML5 up here.
>
> If our government is likely to have that kind of logic, same goes  
> for others as well. Same also goes for authors out there who care  
> about making sure their creations are accessibles to all. Same also  
> goes for those who won't be able to use all the shiny bells and  
> whistles of the new ATs that will happen to support our great  
> replacement for @summary.
>
> I'm all for a new mechanism that does a better job (but I've yet to  
> see any proposal of that), but even the best mechanism doesn't mean  
> we need to take out something that works for some people today.  
> Especially when I can't think of any reason why they could not co- 
> exist in HTML5.
>
> In a context where more and more people care about accessibility and  
> demand it, it would be wise to make sure we don't jeopardize the  
> little gains we've managed to make in the past 10 years when it  
> comes to accessibility. Above all else, this is a responsability I  
> feel is incumbent to our editors, as they shape the spec this group  
> works towards.
>
> I'd hate to see HTML5 get bad-mouthed or delayed for such reasons,  
> but as a consultant that has a lot of influence over my goverment  
> when it comes to accessibility, as of now, I have no choice but to  
> advise them to stay away from a version of HTML that prevents them,  
> even in the slightest, from completely achievement their goal for  
> digital inclusion.
>
> And it's sad because otherwise, HTML5 can bring a lot of good in  
> terms of accessibility, structure and semantics: all sorts of things  
> we love and want.
>
> 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