Visualising browser accessibility bugs
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.
Making it real: From reading the bug report it seems rather technical and obscure, but what effect does it have?
Instead of 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!
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
They will get this:
label text label text
While everybody else gets:
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?