It’s unsurprising, I suppose, that if a group of like-minded individuals go into conclave to write a specification, they will be angered and annoyed when that spec is criticised and questioned by outsiders. This is what has happened when the microformats spec and HTML 5 specs came under scrutiny.
Testing shows the gulf between theory and practice
Most microformats adherents seem to agree with an article that James Craig and I wrote, hAccessibility, that pointed out that the current spec’s use of the
abbr element is inaccessible to some users. In theory, “Austin, TX” is an abbreviation of “30.300474;-97.747247”. In practice, it doesn’t work (mp3).
It shocks me that when this flawed idea was originally mooted, a trivial test with a forty-minute demo version of JAWS would have shown it was inaccessible, yet no-one thought to do it. As they say, in theory, theory and practice are the same. In practice, they are not..
Creators of new techniques and specs need accessibility at the heart of their specs, and that means testing.
Goodbye headers, hello again <kbd> and <samp>
A similar problem is happening with the HTML 5 group. Like many people, I haven’t paid much attention to the WHATWG until now, because it was
“a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties” with an
“invite-only steering committee”. It all seemed highly pie-in-the-sky, and there were other, more immediate tasks at hand, like evangelising accesibility in existing technologies like HTML, or emerging technologies like microformats.
Now that the WHATWG spec is to be the basis of HTML5, a lot more scrutiny is directed at the spec.
The HTML5 spec ruled nothing in and nothing out. The criteria for retaining an element or attribute is that of usefulness. I personally question whether the computer-science
samp elements should go in there (really, when was the last time you used these on a client’s business site?), but that’s not the reason for my rant.
As Roger Johansson recently noted, the HTML5 spec drops two useful attributes from data tables – the
summary attributes that WCAG recommends.
Lachlan Hunt, who’s heavily involved in HTML5, wrote,
They haven’t been removed. They just have not been added yet due to lack of evidence to support them.
The headers attribute: I’m aware that this one currently has better support in ATs than the scope attribute does, but for most cases it’s redundant.
If the problem is just associating cells with their headers, we should investigate alternatives that would make it easier, such as defining an algorithm for more accurate implicit association.
That would be better because it increases accessibility, while reducing the requirements on authors. However, that needs research and evidence to determine if it can cover sufficient use cases reliably, which will allow us to figure out if headers is still required.
Now, in my opinion, one of the reasons that screenreaders are the Netscape 4 of the assistive technology world is precisely because they try to use heuristics to figure things out, rather than use the specified standards. If, for example, everyone had used the (now-deprecated)
menu element for navigation, assistive technologies wouldn’t need to try to guess where content starts, and authors wouldn’t need to code the dreaded “skip links”. But that’s another side issue.
The burden of proof
Testing is vital, particularly at the border of accessibility theory and practice. I wonder, for example, if
accesskey would have made it to the HTML4 spec if there had been full testing with assistive technology users?
What I really want to know from the HTML5 people is who they think is going to do this research that will provide the evidence that their gang requires before useful attributes are restored to the specification.
The WHATWG spec is funded by big business, all of whom have millions in the bank. Maybe now the spec is “official”, they will be funding user research with disabled people using assistive technologies. Perhaps they will invite representatives from the manufacturers of the big screenreaders to work with them. They could even fund those representatives, given that assistive technology vendors aren’t anything like as rich as Apple, Opera, Mozilla and Google.
After all, it’s impossible to imagine that they would make arbitrary decisions to remove or retain certain elements, all with unknown accessibility side-effects, and put the burden to prove the usefulness of removed attributes on a small group of volunteers, isn’t it?
Also see Gez Lemon’s more sober article, The HTML Scope/Headers Debate.