(I was sent a free ebook of this title. That hasn’t influenced my review. This ebook is published by Smashing Magazine and costs €10.95. There’s a sample chapter available. I have no financial connection with the publisher or author.)
When I read about this book I was excited to read it. I don’t need Yet Another Accessibility Book (I co-wrote one a long time ago) but wanted something that delves deeply into WAI-ARIA and how it interacts with HTML5 and assistive technologies. As this book’s blurb says “the underlying theme of this book is about making the interactivity of web applications include keyboard and screen reader users”, it seemed like the book for me. It’s also tech-reviewed by Steve Faulkner who’s my go-to Bogan for practical accessibility information, so I was pretty sure I could trust it.
WAI-ARIA is one of the vital specifications for making the web accessible. There are three problems with using it, though: firstly, the spec is hard to read and understand, even in the context of specs’ inherent indigestibility; secondly, it’s hard to understand how its concepts intertwine with other specs like HTML and, thirdly, most developers don’t use assistive technologies so are unable to understand or test the output of their ARIA pages.
Therefore, I greatly appreciated that author Heydon Pickering is a developer, so keeps the book practical. ARIA is used, in conjunction with markup and script in situations that you’d really encounter. The problem to be solved is elucidated, and the output is clearly explained. It goes deep, too; I learned a great deal and plan to re-read it soon.
It’s a short book (but quite dense) and Heydon’s prose style is clear and occasionally humorous. But don’t let that fool you; this is an important book because it’s the only one that thoroughly explains the technical merits and use of ARIA (and doesn’t browbeat the reader about accessibility).
Without hyperbole: every developer should read this book, and put its techniques into practice. Now.
A little over ten years ago, on 4 June 2004, Opera employee Ian “Hixie” Hickson sent a mail titled WHAT open mailing list announcement announcing
a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties. The group aims to develop specifications based on HTML and related technologies to ease the deployment of interoperable Web Applications
Ten years is a long time, especially so in software, but nevertheless, the achievements of WHATWG have been remarkable. Hixie wrote
The working group intends to ensure that all its specifications address backwards compatibility concerns, clearly provide reasonable transition strategies for authors, and specify error handling behavior to ensure interoperability even in the face of documents that do not comply to the letter of the specifications.
Core aspects of the web platform were never adequately specified. XMLHttpRequest, for example, was shipped in IE5 in March 1999, and reverse-engineered and shipped in Firefox, Opera, Safari and iCab, but never actually documented until Anne van Kesteren co-specified it in WHATWG in a Working Draft of 5 April 2006. Anne’s currently working on the Fetch Standard, which defines something as basic as “requests, responses, and the process that binds them” and the Encoding Standard:
While encodings have been defined to some extent, implementations have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification attempts to fill those gaps so that new implementations do not have to reverse engineer encoding implementations of the market leaders and existing implementations can converge.
Of course, the poster children of WHATWG are the slew of new APIs that “HTML5″ brings us – Web Workers, Web Sockets, native video and audio etc etc. There have been mistakes along the way (of course there have, in a decade!). Last year, Hixie told me
My biggest mistake…there are so many to choose from! pushState() is my favourite mistake, for the sheer silliness of ending up with an API that has a useless argument and being forced to keep it because the feature was so desired that people used it on major sites before we were ready to call it done, preventing us from changing lest we break it. postMessage()‘s security model is so poorly designed that it’s had academic papers written about how dumb I was, so that’s a pretty big mistake. (It’s possible to use postMessage() safely. It’s just that the easiest thing to do is not the safe way, so people get it wrong all the time.) The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution, and I’m still trying to fix that mess.
But to me, the biggest triumph of WHATWG has been error-handling and interoperability (actually, two sides of the same coin). We’ve moved from a vision of the future where everything was supposed to be XML and browsers were to stop parsing if they met malformed markup, to a present where every browser knows how to construct an identical DOM from the most mangled/tangled HTML. We’re moving to a world where interoperability is paramount, and where specifications are made in the open, in constant consultation with developers (for example, Service Workers, Web Components) based on real use-cases.
I think the existence and the work of WHATWG has secured the viability of the web platform. Happy 10th birthday. And thanks.
Matt Wilcox asked “I still don’t bother with <header> <footer> etc. I assume all widely used browsers support them now. But, do they do anything more than div?”.
It’s a good question. The answer I gave is “yes”. These two elements (and <nav> and <main>) give value to users of some assistive technologies on some browsers.
In the HTML5 spec, HTML elements are mapped to ARIA information. Some of those may be over-ridden by authors, but if they aren’t, they have default implicit ARIA semantics. A <header> element that is not a descendant of an article or section element maps to ARIA
role=banner, for example. You don’t need to add any ARIA information; it’s included, free, in the HTML element.
These aren’t necessarily implemented everywhere; Steve Faulkner’s excellent html5accessibility.com keeps tabs of implementation. As an example, <footer> causes Chrome to expose the element with a footer role in IA2, and Firefox to exposes as ARIA landmark role=”contentinfo” (when not a child of article or section elements).
These are useful to people, as we can see in WebAIM’s 5th annual screenreader users’s survey (which encouragingly tells us “For the first time in 5 years of surveys, respondents are more positive about web accessibility progress than in the previous survey”).
When asked “How often do you navigate by landmarks/regions in your screen reader?” (such as “contentinfo”, “banner”, “main”, “navigation”), 26% said “whenever they are present”.
20% thought 1-3 landmarks/regions per page is optimal; 29% thought 4-6 is the right number.
So my advice is: yes, use them – especially the main <header>, <footer>, <nav> and (once per page) <main>. On browsers/ ATs that don’t support them they do no harm. But don’t use billions.
Added 13 May to clear up confusion:
- Use <header>, <footer> as often as your content requires – only the main header and footer carry implicit banner and contentinfo roles. At a minimum, use them once (assuming you have a page header and footer, that is).
- Always use <nav> for the primary navigation.
- Use <main>, but only once per page.