Six months ago, the implementation of accessibility-friendly W3C standards, especially in relation to media players and screen readers, seemed pretty clear, with all web browsers having some level of implementation of HTML5 except for Internet Explorer 8. The HTML5 standard has since evolved rapidly, particularly in January and with updates in April. We’ve also seen two major browser releases in Microsoft’s Internet Explorer 9 (IE9) and Mozilla’s Firefox 4.
Despite Microsoft’s claims to the contrary in its IE9 developer notes, this really is their first serious attempt to release a web browser that incorporates the HTML5 working draft standard, and it is a massive step forward from IE8. It supports most elements such as <section>, <nav>, <header>, <footer>, <video> and <audio>, none of which were supported in IE8. Related technologies such as Scalable Vector Graphics (SVG) and web storage are also well supported.
For Firefox 4, although the browser interface has received a much improved facelift, its HTML5 update has been far more incremental given that it had pretty good support in its recent 3.x versions of browsers. So, given the updates to HTML5 and the general improvements of web browsers and screen readers, how does the access stack up?
According to a great review of HTML5 and WAI-ARIA screen reader support conducted by Accessible Culture in March, and confirmed by internal Media Access Australia testing, there are unfortunately still some major issues. While both Firefox 4 and IE9 provide good support for HTML 5 and WAI-ARIA in most respects, the accessibility of the HTML5 elements comes down to the screen readers that support them.
NVDA provided good HTML5 element support for Firefox, announcing nav, banner, contentinfo, header and footer elements, although the header and the footer were a bit quirky in their implementation, and this has been logged with Firefox as a bug. Although IE9 supports these features in the browser, NVDA did not pick them up. JAWS 12 did not find anything on either Firefox or IE9, while VoiceOver did not find any HTML5 elements using Safari on Mac.
Given the importance and potential accessibility benefits of HTML5, this may seem disappointing. Even if the browsers get it right like the significant set-up of IE9, it seems that we still don’t have much in the way of assistive technology to support it.
An important point to be made though is that HTML5 is still an evolving standard, and it is likely to be a year or so before it becomes a standard. When taking this into consideration, it’s not so surprising that the support is limited, but it’s a reminder of how important it is for both the web browser and the assistive technology products to work in harmony.
So what happens, then, if we take the same test but this time add in WAI-ARIA roles? Given that WAI-ARIA development is accessibility-specific and further along in its development than HTML5, will we see better results with the screen readers?
The answer is yes. Firefox and NVDA announced all explicitly identified landmarks, although there were some issues with the document structure roles, and again NVDA did not make much progress with IE9.
However, while JAWS 12 again failed to read out anything much on Firefox, it demonstrated that while it lacks HTML5 support, it has significantly improved support of WAI-ARIA on Microsoft’s browser, announcing the landmarks’ roles and also correctly announcing the document structure.
VoiceOver with Safari had some minor improvements but still not effective WAI-ARIA implementation. Media Access Australia has also conducted some internal testing using the recently updated version of NVDA on HTML5 and WAI-ARIA pages with Firefox 4 and IE9 with similar results.
Again, not quite the universal result that many would have been hoping for, and it does serve as a warning that developers should not at this stage be relying on HTML5 or WAI-ARIA as stand-alone accessibility options. If even the latest cutting-edge browsers and screen readers have limited support, the majority of users who have an older browser or screen reader will gain no benefit at all, and more traditional accessibility techniques outlined in WCAG 2.0 should continue to be the default coding position for accessibility.
But there are some positives to be drawn out for developers. Firstly, WAI-ARIA support is improving. Secondly, browser creators, assistive technology providers and the W3C are working to provide accessibility in this area, which is great news for future access. Thirdly, it highlights the common usage patterns of screen readers by people who are blind or vision impaired being either JAWS with Internet Explorer or NVDA with Firefox.
Developers can work with these two combinations for testing, and now that IE9 supports HTML5 its likely screen reader support will rapidly improve. Developers should still consider implementing advanced accessibility features like WAI-ARIA techniques, but in addition to standard accessibility techniques rather than as an alternative.
Other W3C news and resources
WAI website revamp
For those of you that haven’t seen the WAI website for a while, you may want to head over there and see its new look.
PDF techniques for WCAG 2.0
One of the drafts in development that turned up during the launch of the new WAI website was some draft PDF techniques for WCAG 2.0 and Flash techniques for WCAG 2.0, which are definitely worth a look.
Flash techniques for WCAG 2.0
One of the most common questions we get asked at Media Access Australia is, ‘How can I make Flash accessible?’ The W3C has released the useful draft Flash techniques for WCAG 2.0.
Top of page