Taking another round at @summary

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