A little over a month ago, I removed the header elements from this site because content within a header is inaccessible to JAWS users with Firefox. Since then I've been thinking more about it, and have decided to put them all back.
Reasonable Accommodation
As developers, we do all sorts of things to ensure that our content will work across the greatest number of browsers and devices. We might add extra container divs and use conditional comments to load special stylesheets in order to accommodate Internet Explorer 6. We provide Flash video as fallback for those browsers that don't support the HTML5 video element. We might even do something like put the WAI-ARIA role="navigation" attribute and value on an extra div wrapping the HTML5 nav element instead of on the nav element itself in order to overcome Window-Eyes' problems with HTML5 and ARIA roles.
In each of these examples, while they involve what some might consider extra work, we are in no way prevented from using any of the CSS or HTML that we otherwise want to use. But where JAWS, Firefox and header elements are concerned, at the moment the only way to ensure access for all JAWS and Firefox users is basically not to use the header element. I am no longer willing to do this.
Using HTML5
While accessibility support in browsers for HTML5 is rather limited, there are equally very few drawbacks to using things like the HTML5 sectioning elements (e.g., section, article, nav, header, etc.). With the exception of JAWS and Firefox with the header element, all browsers and assistive technologies seem readily able to access any content contained within the HTML5 sectioning elements, effectively treating them as if they were simple divs. As browsers and assistive technologies continue to develop over the next few years, the semantics these elements offer should become natively available. In the meantime, we can supplement these elements with the relevant WAI-ARIA roles and provide an accessibility boost right now for supporting technologies. To hold back from using one of these elements simply because of a bug in one particular piece of software does not seem reasonable to me.
Were we all to change our coding practices to accommodate this bug in JAWS by never using the header element, Freedom Scientific, the screen reader's maker, would have little reason to improve its product regarding this issue. Instead, I will continue to use the header element according to its, albeit unfinished, specification.
Alternatives and Solutions
As more and more sites start using HTML5, users of JAWS 10 or 11 who prefer to browse with Firefox will either just miss out on content wrapped in a header element, or they will switch browsers or screen readers. Some of them, of course, will upgrade to the latest version of JAWS, assuming it will have fixed the header bug, but such upgrades are significant financial investments that not all users will be able or willing to make. Update (October 22, 2010): The header and Firefox bug is indeed resolved in JAWS 12.
Switch to NVDA
Fortunately, there is a free alternative, NVDA, that doesn't suffer from the bug, works very well with Firefox, and is probably the most advanced Windows-based screen reader around where support for some of the latest technologies such as WAI-ARIA are concerned.
A Firefox Add-On
There is also a new Firefox add-on for JAWS users that rewrites the header element as a prefixed h:header element, which makes the content usable and accessible to JAWS in that browser. It is still experimental at this time, and could use more input from the community, but it does represent a decent third-party attempt to provide a solution, and such attempts should be applauded. Additionally, that some JAWS users might install the add-on to make basic HTML5 content accessible to them may also serve to highlight the screen reader's shortcoming, and possibly further motivate Freedom Scientific to fix its product. In the meantime, if you have an idea or suggestion for improving the add-on, please post a comment to the add-on's page.