HTML 5 and accessibility
As I touched upon in Another look at HTML 5, probably the most worrying thing about the HTML Working Group is the lack of respect for differing opinions that some working group members have. The apparent disinterest in accessibility is another troublesome factor.
Bruce Lawson brings up the accessibility problems in A rant: HTML5, microformats and testing accessibility, and specifically asks about who the HTML WG expects will make sure HTML 5 enables accessibility:
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?
We’ll see. I’m not entirely sure the answer to that question is “yes”.
One of the arguments for removing the headers attribute is that the scope attribute should be enough to associate table data cells with their corresponding header cells. To show that that is not enough, Gez Lemon provides an example of a complex overlaid table in The HTML Scope/Headers Debate.
That table cannot be made fully accessible with the scope attribute. The counter-argument is that such tables are very rare and that nobody marks up data tables properly anyway, so there is no reason to even make it possible to do so since it will just clutter the spec.
Well, the same can be said for lots of other things in the HTML 5 specification…
So it looks like we will need to fight for accessibility in HTML 5. That’s why I was relieved to read Patrick H. Lauke’s headers attribute debate message sent to the public-html mailing list. It clarifies that the HTML WG will not be able to simply ignore accessibility needs:
WAI’s Protocols and Formats Working Group (PFWG) has, as part of its mission, reviewing specifications under development in other W3C Working Groups in to ensure consideration of accessibility-related needs.
And the HTML WG charter contains this:
The HTML Working Group will cooperate with the Web Accessibility Initiative to ensure that the deliverables will satisfy accessibility requirements.
And finally some good (I think) news: In the last couple of weeks, several HTML Working Group members have been doing a lot of work trying to save the headers attribute, among other things creating the HTML/IssueTableHeaders Wiki page. That is a major amount of research, references, and use cases. And just maybe it will be enough to save the headers attribute, ensuring that tables can be marked up in an accessible way no matter how complex they are.
I am looking forward to seeing similar amounts of work done to argue for each and every element and attribute in the rest of the HTML 5 specification.
- Previous post: Software update day: Netscape, Camino, NetNewsWire, Movable Type
- Next post: WCAG Samurai Errata published
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
What disturbs me is the "if it's not widely used or rare" attitude then we are not going to use it.
True complex tables are somewhat of a rare thing on the web, usually used on educational or government sites. And yes, most of the tables are incorrectly marked up in the first place, but if we are trying to improve HTML then why take a step backwards? We still need to have a way (an accessible way) for header cells and data cells to play nice with one another.
As stated before, accessibility and HTML need to live in harmony and the only way to do this is to look at accessibility effects and issues first.
For what it's worth. HTML5 was developed from scratch. No research was done so far for the
headersattribute so it was not added to the language. Ian Hickson has said that he will do the research if nobody else will (as he has done for the features already in HTML5), but since then several people have done research for the attribute.I've locked horns with Gez over on his blog about whether it would actually be better (in some cases) to simplify the table rather than complicate the markup. I don't see the point in removing the headers attribute though.
We have an attribute in HTML4 that is widely supported by browsers and works for those that need it. Why remove it in favour of something that isn't and doesn't?
I can see the sense in setting the bar high when admitting new elements and attributes into the language. Is it really useful? Is there a better way of doing it? But when its already a feature of the language I think you need to find a really good reason why it shouldn't be retained.
I'm yet to see that reason expressed.
I've been following the working group closely (but for some reason am having difficulty posting to it - my unfamiliarity with mailing groups, and a complete lack of instructions on how to use the thing are not helping. Why is the W3C so user unfriendly? Ironic really).
It's worrying what gets proposed on there, but the headers debate is one I need to catch up on - there's been so much activity in it, and I missed two days worth of messages. I sure hope it gets saved.
[edit] Turns out members need to set their options so that mails can be archived publicly. Unfortunately, every time I've tried to post the system has mailed back telling me I need to set that option before it will proceed - but every time that message has been filtered to my junk folder. So I've never seen what was wrong. headache Why isn't there just a forum?! Mailing lists are so archaic!
You could use the WHATWG HTML5 forums.
The attitude of "they are rare AND people never do it correctly anyways" is a very scary one indeed.
I must admit it is definitely a bit frightening if these so called "smart" people working on the spec take the opinion I just mentioned above. If that truly is the case I think they will destroy HTML 5 before it is even finished.
The point of creating something is not to dumb-down to the least intelligent person. The point is to create something that allows people to move forward, while not completely ignoring those stuck in the past.
My point is this, we shouldn't get rid of things (or add them) simply because people don't use them correctly right now. That is an absurd idea to base decisions around.
I say, all of us web designers should band together, boycott HTML5 and move on to XHTML.
It sounds to me like the HTML WG is a bunch of whiney egotistical little brats.
The full statement from WAI and the PFWG on the "headers" issue: http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html
Anne wrote "HTML5 was developed from scratch". Really? HTML 5 sure got a lot of HTML 4 junk in it like FONT, I and B. Or did Anne invent the FONT tag from scratch?
Hell no, that would be even worse. The XHTML2 guys wanted to get rid of the img element for flips sake.
W3C, WHATWG, other-standards-making-kinda-bodies for heaven's sake do SOMETHING NEW and FINISH IT. Don't faff about ripping up and rehashing existing standards because you've thought of another way of doing it. Maybe your way is better, so what. That train has left the station and it's too late to change.
There are LOADS of things that are crying out for attention - CSS 2.1 onwards being the obvious example - that really need more time than this pointless and stupid argument.
Headers are here to stay. They're supported by today's browsers. They'll be supported by tomorrow's browsers. If they're not in the HTML5 spec, it's HTML5 that will be the loser. So put up, shut up and move on!
Well, it will be interesting to see which User Agents will actually follow the "new vapour markup" language several years from now...
Sorry, comments are closed for this post.