Divya Manian kicked off a good bout of discussion of HTML semantics with her post Our pointless pursuit of semantic value. It called into question the amount of time we spend on identifying the Right and Best ways of marking up our content while highlighting details of some of the consumers of semantics like assistive technology (AT). Jeremy Keith responded in Pursing Semantic Value. I wanted to chime in on Jeremy’s post so, I’ve published below my comment from the original post:
Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors.
Jeremy’s gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1’s depending on section nesting. Recent browsers do indeed style the h1’s different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1’s all as top level headlines or a mishmash of heading nesting levels that don’t match any expected behavior (As an aside, this is completely unrelated but if anyone’s curious what CSS it takes to make that new h1 styling work across browsers… feast your eyes on this beauty)
Additionally, <hgroup> is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke’s comment digs in deeper to the messy semantic state of the outlining algorithm.
The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn’t complete unless you’re listening to the results in a screenreader.)
My recommendation: follow the work of Steve Faulkner and Jason Kiss. These two guys are publishing the only data that illuminates what’s actually happening at the AT level in response to our work. Steve’s comment on this post does a solid job of unraveling this complex topic by showing all the many layers involved: specs, editors, authoring experience, aria, browser impl, screenreader compliance.
Also if you’d like to investigate what’s happening under the covers, I recommend:
- HTML to Platform Accessibility APIs Implementation Guide – Understand how HTML elements and attributes map to accessibility APIs
- HTML5, ARIA Roles, and Screen Readers in March 2011 – Implementation of HTML5 elements in screenreaders isn’t perfect yet.
- HTML5 and the myth of WAI-ARIA redundance – Will HTML5 make the use of WAI-ARIA in HTML redundant? Definitely not.
- JAWS Support for ARIA – Originally published by Freedom Scientific as a MS Word document. *facepalm*
- html5accessibility.com – Also from Steve Faulkner; this research is hugely comprehensive and backs up the examples Divya provided
- delicious.com/paul.irish/aria – My own bookmarks on semantics, aria and accessibility.
In summary, I think it’s best to ground our efforts in pursuing semantic value by identifying precisely what the results will be. A fair rule of thumb: when it comes to semantics, if it’s confusing enough for you to ask a question about it, chances are the answer won’t make a realistic difference. Let’s build incredible stuff on this impressive platform and avoid getting mired in semantic inconsequentialities. There’s also room for more author engagement and screen-reader involvement in the standards process regarding these issues; but that’s a large topic I’ll have to save for another day.