Main Menu

Breadcrumbs

Header Elements Removed

A few weeks ago, it was discovered that JAWS 10 and 11 (and so far, JAWS 12 beta), when used in conjunction with Firefox 3.6 (or Firefox 4 beta), simply cannot find or use any content contained within the HTML5 header element. Terrill Thompson's test page makes this clear. It turns out that it is a bug with Freedom Scientific's screen reader. Whether or not it will be fixed for the final release of JAWS 12, or a patch for JAWS 10 or 11 provided, remains to be seen.

In any case, without knowing what the future holds, or exactly what combination of JAWS and Firefox a user might have, I've been compelled to go through this site and remove all instances of the header element. Honestly, and quite sadly, with the problems some popular Windows-based screen readers have with basic HTML5 elements, especially when combined with WAI-ARIA attributes (see HTML5, ARIA Roles and Screen Readers in May 2010), I'm really starting to reconsider my decision to use HTML5 at all at this point.

About This Article

2 Responses to Header Elements Removed

Seems a lil unwise to implement html5 if you are hoping for accessibility…. let’s adopt cutting edge practices before they are released as a standard… hrmn… and current and older things don’t work well with it…who knew?

I don’t disagree. Though it depends, I suppose, on the purpose of and known or intended audience for the site in question, and what one means by implementing HTML5.

You can do nothing but add < !DOCTYPE html> to the top of your page, and you’ve got HTML5, and while I’m fairly certain that no browser/AT combination will have issues with this, it doesn’t seem that meaningful to call it an implementation of HTML5. Using elements like header, section, article, footer, etc., is more clearly an implementation of HTML5, albeit still a relatively simple one. While I doubt that anyone expected such basic elements to present the problems that at least one of them, i.e., header, has, we’ve discovered that there are issues that need to be worked around should support for this or that AT/browser combination be important. I’m not even talking about the use of things like audio and video elements, though interestingly, with current browser support, the potential for fallback content, and the APIs for those elements, it seems possible to implement audio and video in an accessible manner.

As you suggest, I don’t think we should be totally surprised by these problems. That said, it shouldn’t be that long (I can hope!) before newer versions of browsers and AT provide support for the improved semantics that come with the basic HTML5 elements. Still, unless support is provided in the form of updates to earlier versions of JAWS, for example, which enough people will continue to use for a few more years, it may be even longer before we can implement certain HTML5 elements like header and know that most or all users are able to access our content. And this will be the case, I suspect, even after the HTML5 specification is finalised.

Unless one is willing to make the concessions and workarounds necessary, it is likely easiest, where accessibility and support for popular AT is a concern, to stay with HTML4.01 or XHTML 1.0 Strict markup for the time being, whether or not one also wants to use the HTML5 doctype and call it HTML5.

In the case of this site, and despite my somewhat despondent admission that I’m reconsidering using HTML5, part of my intent was and is to experiment with and research the accessible implementation of basic HTML5.