Tag: research

Responsive Data Tables and Screen Reader Accessibility

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

HTML5, ARIA Roles, and Screen Readers in March 2011

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

An ARIA `alert` Test Case

I 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

Not All ARIA Widgets Deserve `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"

VoiceOver and Tables with an Empty First Header Cell

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

Title Attributes as Form Control Labels

Sometimes, often as a result of a web page’s layout or design, a label element cannot be used to identify a form control. Certainly, one can always use a visually hidden label, which is my preferred approach: you never know how the design might change in the future, at which point, if you’ve already got the label in the markup,… Continue reading Title Attributes as Form Control Labels

Accessible ARIA Tabs

The WAI-ARIA specification remains unfinished and its implementation incomplete. All the same, some of it, e.g., landmark roles, can be used right now to improve the accessibility of web content and applications without causing a detrimental effect in older browsers or assistive technologies. I’m a big fan of WAI-ARIA, and think it is already a very useful collection of techniques… Continue reading Accessible ARIA Tabs

NVDA and JAWS with Links to Previously Hidden Anchors

Each of the anchors (both the a elements and heading anchors) below have an id and tabindex=”-1″. Target anchors 3 and 6 are hidden with display:none until they are targetted with the link at which point they are made visible and focus is set to them. 1. Link to visible simple anchor 2. Link programmatically setting focus to visible simple… Continue reading NVDA and JAWS with Links to Previously Hidden Anchors

`tabindex`, Keyboard Focus and Some ARIA in Screen Readers

These test cases are in no way comprehensive or robust: They should really be supplemented with examples using a greater variety of HTML5 elements and ARIA roles, but I just can’t be bothered at this point. Nonetheless, they reveal some interesting, if not slightly worrying, behaviour on the part of at least two screen readers. At least two things are… Continue reading tabindex, Keyboard Focus and Some ARIA in Screen Readers

In-Page Links and Input Focus [Again]

That in-page links work and properly update the page’s input focus can be crucial for users that rely on keyboard navigation, especially if they do not also use a screen reader. Often discussed in the context of “skip links”, this has been something of an issue for years, the various reasons for and effects of which have been documented well… Continue reading In-Page Links and Input Focus [Again]