Visualising browser accessibility bugs

Posted on Sunday, 8 July 2012 by Steve Faulkner

On revisiting what I believe to be a simple to fix bug, filed in January on Webkit’s ARIA implementation, unsurprisingly I found it not yet fixed. Part of the reason this occurs is because there is limited resources available and accessibility bugs often are not a priority as their negative effects are not apparent and they generally don’t negatively impact many users.

Example 1 ARIA spinbutton role incorrectly mapped in webkit

Making it real: From reading the bug report it seems rather technical and obscure, but what effect does it have?

For users of assistive technology who encounter a JavaScript spin button widget such as the DOJO spinner widget, they will ‘see’ this:

A grey horizontal bar, part of which is a darker shade.

A progress bar as displayed in Chrome is what an AT user 'sees'.

Instead of what everybody else sees:

A text box with small up/down buttons on the right side.

A spin button displayed in Chrome is what everybody else sees.

Consider how long this bug would be open if the bug affected the visual display and interaction as shown above. I say interaction because, although a user can theoretically still interact with a spin button whose role is a progress bar, how does the user know? Both the role and the visual display of the control convey essential information on what the control is and how to interact with it. Progress bars are usually non interactive, they just convey information, the whole point of a spin button is for the user to change its value to input data.

Now in the case of this bug, I emailed the guy who the bug had been assigned to and got a reply almost immediately saying he would look at it this week, so fingers crossed.

Update: this bug is now being fixed!

Example 2 when using aria-labelledby acc name is duplicated in acc description

This is a bug I filed a few days ago, for a behaviour I initially discovered back in January. My bad for not filing a bug earlier, I thought I had…

Making it real: Again the bug report is dry and technical, but how does this bug affect users of Assistive Technology (AT)?

For an AT user who encounters a check box, for example, labelled using aria-labelledby:

They will get this:

label text label text

While everybody else gets:

label text

Same question as before. How long before a bug like would be fixed if it affected not only AT users, if the label text was visibly duplicated on the page?


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

  1. Not a bad idea kind of like a feature in iOS Simulator with a little running dialog box that would give you feedback about ARIA elements. Obviously it gives you more than that but something like that is what I mean. Maybe a Chrome Plugin, Chrome HTML5 Rocks team are pretty cool, maybe there’s something you can in there dev tools kit that could be installed.

  2. Steve,
    Not sure how these bugs in Webkit filter down to iOS Safari but I’ve encoutered some bugs as well. Probably more of a VoiceOver bug than anything. But between tapping on a link, input item, etc.. an moving to another page often VoiceOver doesn’t start at the top of the page but leaves its reading focus where ever it last was. Drives me crazy. I had to create a whole system of blank page loads between search and result querries so that VoiceOver would reset and read from the top of the page. I’m a iOS dev but really a newb so I’ve been using PhoneGap/Cordova Framework to create a compiled app that really is nothing much more than HTML5, JS, & CSS. Continue the good fight. Nice work.

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

Having worked in accessibility for quite some time I can tell you that TPG's Steve Faulkner is one of the top technical accessibility talents, and leaders, in the field and I have no reservations in giving him my endorsement.

Richard Schwerdtfeger, Distinguished Engineer and CTO for Accessibility of IBM Software