X and accessibility
In April, 2007 David Andersson summarised the development of, and differences between, HTML5 and XHTML2 and concluded that the web’s future lies with HTML5. I think he’s generally right, though XHTML2 has never been a likely successor to HTML4/XHTML1. The real question is what will become of the X in XHTML given that most authors are doing it wrong?
HTML5 is looking so strong because it’s a pragmatically driven project that incorporates much of what people are already doing—stealing XHTML’s thunder by keeping the standards-based focus while decoupling the web’s primary language from XML. (HTML5 is homologous to XML—it can even be served as XML—but most browsers will never see it that way.) And because it’s well-grounded it’s already being implemented.
Despite the efforts of the W3C to absorb HTML under the XML project, it seems that the two vocabularies will remain on separate paths, running parallel for now. This threatens the W3C’s goal of a semantic (machine-readable) web in its idealist form. WHATWG’s efforts which, like those of the microformats community, are grounded in popular practice, will get us only part-way there, but unlike XHTML2 they promise us something we can use here and now.
So is HTML5 a fait accompli? Taking the contrary view in a recent article, James Edwards still favours the current XHMTL standard, served as XML where possible, over HTML5 for accessibility reasons. He doesn’t mention XHTML5 explicitly (i.e. HTML5 served with an XML MIME-type), but he does say he’d rather stick with XHTML1 than adopt HTML5’s markup spec, which drops support for several accessibility features, including the
alt attribute for images and the
headers attributes for tables.
Edwards and Gez Lemon, linked above, are right that this is a problem, especially regarding the
alt attribute (given the prevalence of images over correctly marked-up complex data tables). This needn’t be a practical quandry: Edwards is taking a stand on principle in sticking with XHTML1 because the spec recognises these accessibility features.
So what should an organisation that is concerned about accessibility do? This is a question I’m trying to answer. Two new sets of guidelines are particularly relevant: WCAG+Samurai released on February 26 (see commentary by Joe Clark and Roger Johansson), and the W3C’s much-revised WCAG 2 Candidate Recommendation released on April 30 (discussed in interviews with Patrick Lauke and Lachlan Hunt).
The two questions that need to be addressed:
- Which set of normative rules, if any, should guide the organisation?
- Which X/HTML syntax, if any, maximises access for both assistive technologies and mobile user agents?
“If any” is important: I don’t want to presume that a single choice must be adopted in either case. It may be true, for example, that more than one versions of HTML could be used without any significant detriment to accessibility, or that neither set of accessibility guidelines is completely appropriate or usable. (I doubt that, but let’s see.) Nevertheless, being able to specify one in each case is desirable, and so is testing and evaluating the results.
I’m planning to follow up on this post once I’ve read the two documents and done some testing, and I’m interested in hearing what people think.