The first European Accessibility Forum in Frankfurt was a resounding success. I had fun moderating the panel on Accessible Web Applications. Paul, Christian and Saqib were all excellent. We could’ve talked all day.
The rest of the day featured a mixture of technical, governance and legal panels. Personally, I enjoyed diving into the technical stuff. I really enjoyed listening to the mighty Steve Faulkner talking about ARIA.
A question from the audience brought up the subject of the crossover between HTML5 structural elements and ARIA landmark roles. There seems to be a lot of opposition—even downright hostility—from the HTML5 group towards WAI-ARIA. I’m sensing a lot of Not Invented Here thinking; a conclusion documented by Sam Ruby as already having been reached by the Technical Architecture Group:
The HTML5 community would define themselves as encompassing all Web technologies, i.e., if it’s not HTML5 and implemented in a browser, it’s not the Web.
Part of the opposition to ARIA is based around a perceived conflict with HTML5 structural elements:
For example, if ARIA defines a feature to say that something is a header, this will conflict with the HTML5 header algorithm.
So there’s an ARIA landmark role of banner that appears to align with the HTML5 header element. But if you look more closely at the specs, they’re actually defined in different ways. A banner is a region that contains the primary heading or web site title
whereas a header is the header of a section
. One is unique per document whereas the other can be used multiple times in the same document. To put it another way, banner is like an ID and header is like a class name.
Steve pointed to another false clash. HTML5 contains a value of search for [the type attribute of the input element. ARIA has a search landmark role. Sounds like a duplication, right? But the landmark role is typically applied to a form element, not an input element.
So on an HTML5 site like Huffduffer, I should be able to write:
<form method="get" action="/search" role="search">
<label for="query">Search</label>
<input type="search" name="q" id="query">
<button type="submit">Go!</button>
</form>
Alas, the HTML5 validator will throw an error (although it is using an experimental HTML5+ARIA schema). Ah, well.
Still, there’s no reason not to start using ARIA roles today: browsers, libraries and screenreaders already offer a good level of support and it’s only going to get better. If we start adding ARIA roles to our websites—and in our CMS themes—then if the HTML5 community stays true to its stated principal of paving the cowpaths, the pragmatic here-and-now solution should triumph.