I appreciate Dennis at WebAxe calling for developers to take a "sanity check" when working with HTML5. His point was not to dissuade us from developing with HTML5, but to remind us to do so "caution and care"
, in particular because of the current level of support among different browsers and assistive technnologies (AT) for HTML5 and WAI-ARIA.
Working Around Bugs in AT?
As always, and especially with HTML5, progressive enhancement is the best approach, implementing fallbacks and workarounds as appropriate. But what do we do when faced with a user agent or AT that, as a result of a bug in its software, and instead of simply ignoring what it doesn't understand, actively misbehaves when it comes across this or that HTML5 construct or ARIA attribute? Is it reasonable to provide a workaround? I would like to say yes, if only for the sake of providing access to more users. But things are really quite tricky when the specifications are to some degree still in flux and, more importantly, when we don't know exactly how future browsers and AT will end up implementing them. Proceed with caution and care, indeed.
As has been noted here in previous posts and research, JAWS 10 and 11 in Firefox have a bug related to the header element, while Window-Eyes versions 7.2 and below exhibits bugs with the ARIA role attribute.
The JAWS header Bug
For the JAWS header bug, since resolved in JAWS 12, I decided that I was not going to worry about it. I would let the software's vendor and users take responsibility for the screen reader's shortcomings. I decided this way for a few reasons. The only real workaround from the developer's perspective seems to be simply not to use the header element, and I don't think it's reasonable to avoid using a valid and (eventually) useful semantic element because of what is clearly a bug in a certain piece of software. There is also a viable alternative for Windows users in the form of NVDA, a free screen reader that works very well with HTML5 and ARIA.
The Window-Eyes ARIA Bug and Workaround
Meanwhile, for Window-Eyes, I went with an easy workaround that allowed me to continue using the HTML5 semantic elements and ARIA landmark roles while reaping their benefits. In short, instead of using the role attribute on the HTML5 element itself, I just wrapped the HTML5 element in a div to which I applied the landmark role. For example:
<div role="navigation">
<nav>
<ul>
<li><a href="#">link #1</a></li>
<li><a href="#">link #2</a></li>
</ul>
</nav>
</div>
It should be noted that nesting the div with role="navigation" inside the nav element accomplishes the same thing.
This was all well and good, it seemed. It provided supporting screen readers with access to the ARIA landmarks, and enabled the use of HTML5 semantic elements as appropriate. A JAWS or NVDA user could navigate by ARIA landmark, and then access the contents of that landmark more or less as if the ARIA role attribute had been used on the HTML5 element itself. And Window-Eyes users could equally access the HTML5 element's contents without difficulty.
Alas, it now appears as if this approach, a modification of ideal HTML5 plus ARIA markup developed solely to accommodate a bug in Window-Eyes, will lead to its own problems. Specifically, it will cause needless repetition for users with screen readers and browsers that properly support both HTML5 and ARIA, such as NVDA and Firefox 4, once it is released.
Additionally, had I, in retrospect, read Section 3.2.6 of the HTML5 specification more diligently, I might have noted how this workaround, at least where the nav element is concerned, would pose a problem. The HTML5 spec requires user agents to implement the "navigation" role on nav elements, which would naturally lead to a duplication of the role were one to use the proposed workaround for Window-Eyes.
Firefox 4's New Accessibility Mappings
In early November, it was announced on Marco Zehe's blog that Firefox 4.0 will add accessibility support for some HTML5 semantic elements by mapping them to ARIA landmark roles. For instance, the nav element will be mapped to the "navigation" landmark role. Interestingly, in what is undoubtedly nothing but a good-faith effort to help users, all header and footer elements will be mapped to the "banner" and "contentinfo" roles, respectively; while the article element will be mapped to the "main" role. There is also the intention to map aside to the "complementary" role.
Let's leave aside, for the purposes of this post, the question of mapping every header, footer, and article to roles that are not (currently) specified as those elements' default semantic roles, and that most web pages should only have one of. These issues have already been raised in comments to Marco's post, and in a Mozilla bug report. How they will be addressed in the final build of Firefox 4.0 remains to be seen. The issue I want to highlight has to do with how the improved HTML5 support in the upcoming browser release will cause the workaround for Window-Eyes to negatively affect the experience for NVDA users.
How the New Mappings Affect the Window-Eyes Workaround
Using the latest nightly build of Firefox, version 4.0b8pre, and working from the example above, the nav element is registered as a "navigation" landmark, but is itself wrapped in a div explicitly set with role="navigation". As such, NVDA will actually find two "navigation" landmarks, and announce them both: one for the div and one for the nav element.
Further, in NVDA's Elements List dialog, which lists all the links, headings, and landmarks on the page, what is conceptually just a single "navigation" landmark gets identified as two "navigation" landmarks, one nested within the other. If you've got three nav elements on your page marked up using the workaround, all of a sudden you have six "navigation" landmarks as far as NVDA is concerned.
While these might not be the most egregious problems that a screen reader user has ever faced, they are certainly not ideal, and could easily lead to confusion.
Working Around Bugs in AT: Take #2
Certainly, where browsers or AT are lacking support for this or that feature, a workaround can be fairly straightforward when it produces an effect or behaviour that we know future versions of the user agents will be providing themselves, and when we know the workaround won't have any negative side effects once that support is natively there. But when it's a matter of a full-on bug in some particular software, I'm increasingly reticent to bother doing anything about it. We need to draw a line somewhere, if only to allow the web to develop and to force vendors to fix their faulty software for the benefit of their users.
The number of sites being built with HTML5 and/or ARIA is increasing rapidly, and if AT vendors are going to serve and keep their customers, they'll have to keep pace with changes in the use of web technologies. It also wouldn't hurt if they played a more active role in the specification process, something most of them have not done. Neglecting to participate helps no one, especially the users who end up suffering from the inadequacies of software they rely on, and who may feel forced to switch to other products that do work for them.
I'm Saying No to This One
So, as regards the Window-Eyes bug, I've decided to stop providing this workaround, at least when I'm working with HTML5. Firefox 4.0 and NVDA get it right, more or less, and I don't see any reason to degrade the experience for users of compliant browsers and AT for the sake of lacklustre software that doesn't. Fortunately, it will only take a small amount of work, and Firefox 4.0 is not out yet. When it is finally released, however, those of its users with an ARIA-supporting screen reader will not have to deal with any undue noise or redundant landmark structures on my account.
Just to be clear, it doesn't make me happy that, as a result of this decision, some users will have significant difficulty accessing some of my content. But there needs to be a limit to what developers alone are responsible for when it comes to making their sites accessible.
Other Options
Using HTML5
If you are determined to maximise your site's accessibility for all screen readers, including those with major bugs, but you want to use HTML5, then you likely have no choice but to avoid using the header element. If you do use it, JAWS 10 and 11 users with Firefox will not be able to read or interact with any content it contains. There is a Firefox add-on that deals with the JAWS header bug, but it's probably not reasonable to expect that your users will know about and install it. It's also true that this bug has been fixed in JAWS 12, but remember that there is bound to be a good number of JAWS 10 and 11 users for several years to come. Somehow I doubt that Freedom Scientific is going to offer any free bug fixes to those users since it would no doubt prefer that they pay for the latest version of JAWS.
You'll equally need to avoid adding ARIA landmark roles to your HTML5 semantic elements. Otherwise, users with Window-Eyes 7.11 and below will have a really hard time, to say the least. Sure, the upgrade to version 7.2 from 7.11 is free, but you'll still need to make sure that you don't use an ARIA role on any ul, ol, or dl elements, because version 7.2 just can't handle it.
Staying with HTML 4.01 or XHTML 1.0
Perhaps you are thinking that you will just forego your desire to use HTML5 and instead stick with good, old HTML 4.01 or XHTML 1.0. Not a bad idea, but do note that even with those document types, Window-Eyes 7.2 suffers the same problems when an ARIA role is used on a list element. To combat this, you would need to make sure that the ARIA role is always implemented on a div wrapping the list element.
To be sure, using HTML 4.01 or XHTML 1.0 with ARIA, and adding an extra div here and there to help Window-Eyes, isn't a significant burden. For the time being, it is probably the most accessible approach for the widest range of AT software. You'll avoid both the JAWS header and the Window-Eyes ARIA bugs. You'll also be missing out on the new functionality in HTML5 that some browsers support today, and the accessibility improvements that more and more AT will be supporting in the very near future. However, and quite rightly, this may not concern you. Depending on your situation, HTML 4.01 or XHTML 1.0 plus ARIA may be your safest bet. As always, it's up to you to weigh and consider all the options.
It's Not Evil if You're Responsible About It
Personally, I'm happy enough using ARIA and HTML5 today, taking caution and care as I do so.
Still, I don't think that we should be catering to major bugs in user agents or AT, unless we are assured that our workarounds will be harmless once they are no longer needed, and if they don't prevent us from using the technologies as designed. We should adopt progressive enhancement, providing workarounds and fallbacks as appropriate and where we can; but otherwise, I think that we should go ahead and use the technologies in accordance with their specifications and best practice guidelines. If we do these things, I would say that we should feel comfortable in having done a responsible job.
Bruce Lawson put it well more than a year and a half ago:
Let me put my cards on the table: if you correctly use a W3C specification, like this one, and obey WCAG, then I believe that your responsibility as a web author is done. I won’t delay using a technique because a user agent can’t deal with it (although I will try to give extra help where I can). Call me evil, but that’s how I feel today.