This blog can't be viewed on LiveJournal. Instead see

Accessibility Requirements in HTML5

28th May 2008

There is an ongoing debate within the W3C's HTML working group about what should be done about alternative text on images. As far as I can tell, one side of this argument is that the W3C's accessibility team has found that including alternative text for purely visual content is important for accessibility, while the other side of the argument is that it is not always possible or realistic to provide alternative text for a given element.

I'm sure this isn't a popular opinion, but including this sort of thing in the HTML specification seems like both a layering violation and a duplication of effort. The W3C's accessibility specifications already describe in detail the requirements for creating an accessible document, so why should parts of this be duplicated in HTML? The HTML specification is about the wire-syntax of the language and the meaning of the elements; the WAI family of specifications describe how to use HTML (and other web technologies) as a tool to produce accessible documents. I don't see that there's any problem with a particular HTML document being correct as per HTML but not correct as per WCAG. That is, documents don't necessarily have to fail both if they fail one; obviously in an ideal world all authors should aspire to pass both.

The HTML specification needs to provide authors with a way to comply with the accessibility specifications, but it does not need to enforce compliance with them. By providing the alt attribute and saying that it is for the alternative text, HTML provides authors with a means to produce documents that are compliant with WCAG 1.0 Core Techniques section 2 and WCAG 1.0 HTML Techniques section 7.1. Having HTML duplicate the requirements of the latter seems to me to be like including advice from The Elements Of Style to help authors with their writing. A single, comprehensive document about all aspects of writing web pages good is likely to be impossible; is it not better to let the experts in each aspect of this process write their own, smaller document?


  • Do both

    Considering how poorly the accessibility encouragements in the current HTML specifications have pushed web developers to create accessible markup, I really don't think accessibility statements can be mentioned too often. I get your point of HTML5 being a markup serialization and object model specification, but as most internet specifications need security assessments, I think content and markup specifications need accessibility requirements.

    If these requirements only point out the relevant parts of WCAG 2.0 or not isn't really important, but not mentioning accessibility in the HTML5 specification at all would be a step in the wrong direction for accessibility on the web, which in these Ajax days are pretty bad already. It's better in some areas (the markup has improved) and worse in others (there's more JavaScript and Flash now than ever).

    I indeed think referencing WCAG 2.0 from the HTML5 specification is a superb idea, because it lifts the burden of specifying the accessibility requirements from the HTML WG and promotes the work of WAI and the WCAG specification itself.

    PS: Enabling spell checking in the comment preview HTML encodes everything (including inserted BR tags) twice it seems.
    By ext_102221 at 09:00 am on 29th May 2008
  • Blame HTML 4

    Well, in order to write an HTML validator, you need to know which attributes are required and what their possible values are. You could make the case that the HTML specification shouldn't go into quite so much detail about how to use @alt properly, but frankly, the examples in the HTML 5 drafts are better than anything that's ever come out of the WAI working group. (That's not a terribly popular opinion either, I'm afraid.)
    By ext_69754 at 04:46 pm on 29th May 2008