This is an update for all who are interested in our Mac accessibility implementation.
After I blogged about this topic last time, we entered into a bit of a rough time having to do with the text interface of the Universal Access protocol. If you want to read the full details, look at this epic bug.
After that was finally done, which added the capability to interact with text using regular VoiceOver commands, and an associated children caching bug was also fixed, work has now picked up pace again in implementing the finer points of web content accessibility:
- Password fields are now accessible, as well as many other types of edits.
- Labels are now properly exposed. This includes that input elements nested within labels are now being seen by VoiceOver.
- List items on web pages will very soon be exposed properly.
With these all out of the way, I believe it’ll be very very soon that we can offer you all a build to test.
A few known issues we will be working on next:
- Firefox doesn’t tell VoiceOver when a page has finished loading. This bug actually has a patch, but it appears to emit the wrong notification. VoiceOver still doesn’t see our page loads. If any of our readers happens to know the correct notification, feel free to lend a hand in letting us know!
- VoiceOver says the word “text” after each chunk of text it reads inside paragraphs. Not critical, but still annoying, since this isn’t done in Safari, and it interrupts a fluent reading process.
- Various form element states not communicated to VoiceOver.
- WAI-ARIA landmarks are not communicated to VoiceOver.
So the list is down, and I actually don’t deem any of these bugs critical in blocking a release to a wider audience. But I am not the one making that decision here, so this is not an announcement. 😉
Stay tuned to this blog for further information if you’re interested in testing out a Firefox build on the Mac that has VoiceOver support enabled!