Tag: JAWS

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

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

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… Continue reading

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

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

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

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

HTML5, ARIA Roles, and Screen Readers in May 2010

Note: Updated research and results for March 2011. There are some good, helpful examples and work out there already showing how some screen readers deal with various HTML5 constructs and ARIA roles. I know the specs are not finished yet and assistive technology vendors are always working on it, but I wanted to play around a bit and confirm for… Continue reading

Variations on Ginader’s [Awesome] Accessible Tabs

Skip to Ginader’s Original Accessible Tabs Example Skip to the test cases Background Dirk Ginader’s Accessible Tabs jQuery plugin is just awesome. I love it. Providing straightforward, accessible solutions like this to such commonly used, and very often inaccessible, web interfaces is the way to go. The key to the plugin, as Ginader clearly explains, is ensuring that navigation takes… Continue reading