With the rapid development in certain user agents (take that, Firefox!), I’m a little late in getting these up, but I figure some of them are still useful to share. In any case, I posted to YouTube five videos of various screen readers interacting with basic HTML5 section elements and ARIA landmarks. These are videos I presented at the 2011… Continue reading Videos of Screen Readers with Basic HTML5 and ARIA Landmarks
My slides from the OZeWAI 2011 conference:
If you use explicitly ranked h1 to h6 headings nested in HTML5 sectioning elements, as opposed to using exclusively h1 elements, JAWS 12.0.1170, as well as the JAWS 13.0.171 beta, will misrepresent the heading hierarchy. Headings in HTML5 The HTML5 outline algorithm allows us to use the h1 element for every heading on a page, and depending on the nesting… Continue reading JAWS, IE and Headings in HTML5
When Chris Coyier presented his approach to responsive data tables, I wondered about the implications for accessibility, particularly for screen readers. This was especially so since the approach involves replicating each of the table’s column headers as CSS-generated content for the relevant table cell, and presenting each data cell, together with this generated header text, as a block-level element. In… Continue reading Responsive Data Tables and Screen Reader Accessibility
display:none: Return to 2007I was recently asked if JAWS and Window-Eyes still displayed the bugs described by Gez Lemon in 2007 whereby content hidden using display:none was read by the screen readers under certain conditions. The JAWS Bug Back then, the situation with JAWS 7.1 was that it announces content in a span element hidden with display: none if it is in an… Continue reading JAWS, Window-Eyes and display:none: Return to 2007
Last year, in HTML5, ARIA Roles, and Screen Readers in March 2010, I took a look at how then current screen readers behaved with some of the HTML5 section elements and related WAI-ARIA document and landmark roles. Now that the major screen readers have all seen some significant updates, and both Firefox 4 and Internet Explorer 9 have officially been… Continue reading HTML5, ARIA Roles, and Screen Readers in March 2011
alert Test CaseI put together a few examples of ARIA alerts and tested them with JAWS and NVDA in Firefox 3.6, Internet Explorer 7 and 8. The interesting bit is how alerts can be improved for JAWS 10 in Internet Explorer by adding an aria-live attribute value of “assertive”. Continue reading An ARIA alert Test Case
role="application"There are currently some great examples of WAI-ARIA-enabled widgets out there making the rounds. In particular, there’s Hans Hillen’s JQuery Widget Samples and the collection from the OpenAjax Alliance. These are nothing short of very useful. After all, ARIA is yet to be a full W3C recommendation (or standard, if you prefer), and we are all, or at least I… Continue reading Not All ARIA Widgets Deserve role="application"
Dennis at WebAxe recently called 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. 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? Continue reading An HTML5 plus ARIA “Sanity Check”: Working Around Bugs in AT
The Problem I noticed some interesting behaviour with VoiceOver 3 when working with data tables whose first cell in the first, or header, row is an empty td element. In these cases, VoiceOver does not correctly associate data cells with their proper column th header cells. Instead, VoiceOver seems to shift the header cells one column to the left, such… Continue reading VoiceOver and Tables with an Empty First Header Cell