Yes, many of you have been waiting for this to happen, and now it’s finally there! From the April 30, 2012 Nightly build onwards, Firefox for the Mac comes with VoiceOver support turned on by default. All you have to do is turn on VoiceOver, or launch Firefox Nightly from Finder or LaunchPad with VoiceOver already running. No extra switches or other steps need to be performed.

This is a raw diamond that still needs quite some love before we can call it fit for wide-spread use by customers. But if you like to play with early development software, want to provide feedback or just get a glimpse at what’s hot and new, feel free to download the latest nightly build for the Mac. I do not recommend using this as your default browser just yet!

Known issues

Here are some known issues we need to address:

That’s our biggie at the moment. Compared to Safari, we’re still very slow and unresponsive. Navigating via the VoiceOver commands takes longer, and when a page initially loads, you’ll hear VoiceOver often say “Nightly busy” before you can actually do something.
Firefox does not yet notify VoiceOver when a page finishes loading.
This has been known, and we’re working on it to address the issue as soon as possible. We think we are sending the right notification, but VoiceOver does not pick it up. Once a new page loads, and you start navigating, VoiceOver correctly sees the new content, though, so you are able to surf to more than one page within a session.
All controls within a multi-tab XUL dialog is visible.
Within Preferences and other dialogs, VoiceOver sees all the content of all the tab pages, even those that are currently hidden. This makes navigating this type of dialog a bit cumbersome for now.
Some control states not correctly reported.
The initial control states of check boxes in XUL dialogs is not yet reported correctly. The initial question whether Nightly should be used as your default browser, for example, speaks an unchecked checkbox, when it is actually checked. We are aware of the issue.

How to install

You install the app by opening the downloaded DMG, focusing “Firefox” and copying and pasting it into your Applications folder, like you do with any other app. Sighted users can, of course, do their usual drag and drop from the DMG to the Applications folder. You then launch it like any other app.

Providing feedback

Beat it, hammer on it, install your favorite extensions into it that you might know from the Windows or Linux worlds, for example the WebVisum extension, surf to your favorite web sites and do the stuff you’d normally do. But expect a lot of things to not work yet as you would expect them to! Like I said: This is a raw diamond still.

To provide feedback, either comment to this blog post, and I will triage and file bugs as appropriate. Or if you’re familiar with our bug tracking system, feel free to file a bug yourself. If you use this link, things like platform, component and product are already preset for you correctly.

If you’re not a VoiceOver user, we still want to hear from you! Our goal is that you should not notice a difference in daily browsing and working with everything you work with usually. If there are changes that aren’t explicable, please provide us with that feedback, too!

This is my first real new platform accessibility roll-out, and I’m excited as hell about what’s to come from you all over the next couple of weeks!

This blog post is once again prompted by something I encountered in the wild. The other day, I was testing‘s account manager for accessibility and encountered some inconsistencies in keyboard navigation and screen reader usage. For one, there are “edit” buttons next to the “Your E-Mail addresses” and “Password” headings whose usability wasn’t obvious to me. To my screen reader, the “remove” buttons next to the e-mail addresses linked to my account, as well as the two password entry fields, were visible without me having to actually press these “edit” buttons at all. I could perform all actions without a hitch, so these buttons seemed superfluous and just adding noise. Secondly, even when just navigating through the page via the tab key, I couldn’t find anything that these “edit” buttons could be used for.

The solution came to me when I asked my significant other, who is sighted, to look at the page with me. For her, the “remove” buttons and password entry fields were not visible on initial page load. When I started navigating the page with NVDA’s virtual cursor, the buttons magically appeared. When I moved in the opposite direction, they disappeared again. When I navigated via tab, they appeared and remained visible from then on.

The problem here was that the content “hiding” was done in a way that visually hides the content from the naked eye, but not from my screen reader. Furthermore, the fact that this page has different interaction models for keyboard and mouse users was not taken into account. In short: a wrong technique was used to hide the content.

This blog post is an attempt at explaining the different “hiding” models as well as trying to get rid of some of the misunderstandings and misconceptions I’ve encountered over and over over the past ~10 years.

Some basics

To understand what’s happening, you need to know (or remember) this: Screen readers as well as other assistive technologies for people with disabilities use a collection of objects to convey information about the web page to the user. These objects are structured in a tree-like structure, with the document being the root, the navigation area, headings, sections etc. being this root’s children and so forth. Accessibility techies call this the “accessible tree”. It is a sub set of the tree built from the HTML source code in the browser’s document object model (DOM). Not all elements need a representation in the accessibility tree, so the mapping isn’t always 1:1.

The rendering engine, in Firefox’s case Gecko, applies several attributes to these accessible objects that relay important information to the user with disability. For this information, the engine does not only use attributes supplied by the individual HTML tags, but also some styling information from the CSS. An example of this CSS-based information is that about text styling and attributes, colors etc.

Some information, however, is not used, like the final position of a container via CSS. A div container may, for example, be shown in the upper right-hand corner of the site, right next to the navigation bar, but its code may be somewhere at the end of the source file. The screen reader will find the text in that container near the end of the accessible tree, not right next to the navigation, because the styling information for this position is not used. If you’d like to know more about this, read this article of mine.

Hiding is not equal to hiding

Some CSS statements, however, are being followed to the letter. In IE, the screen reader does it, in Firefox, the Gecko engine does it for the screen reader, and has being doing so for over ten years now. Elements styled with “display: none;” or “visibility: hidden;” are not included in the accessibility tree! Only if that element’s styling is changed via JavaScript or similar to make it visible, it is being inserted into the accessible tree, and an event is being emitted to let the screen reader know that this insertion just occurred.

Other statements for “hiding” like “left: -9999px; top: -9999px;” are not being used. These elements appear to the screen reader just as any other currently visually visible element on the screen is.

Once again so this sinks in: Elements styled with “display: none;” or “visibility: hidden;” are always hidden from screen readers as well. This is true for screen readers on Windows like NVDA or JAWS, and has been so for at least the last ~7 years. Orca on Linux, VoiceOver on OS X and iOS also adhere to this rule. JAWS has consistently supported this since version 7, which was released in 2005. All other screen readers I know do this right, too, and have been for ages. Why this rumor that one can provide extra content to screen readers via elements styled with “display: none;” keeps sticking around, I have no clue. It is definitely wrong! Screen readers completely ignore elements styled with “display: none;” or “visibility: hidden;”.

So when do I use what?

If an element or group of elements should only become visible after the user performed a conscious action, use “display: none;” or “visibility: hidden;”, depending on your requirements. A good example of this can be seen by many bloggers each time they’re in their WordPress 3.3 backend. The main menu items like “Dashboard”, “Article”, etc., have menu items hidden that only become visible if a) one hovers the mouse over them or b) one navigates there via tab and presses enter. Some magic is performed, and the “display: none;” styling is removed, and the elements become visible. In addition, WordPress correctly uses the WAI-ARIA attribute aria-haspopup=”true” on these menu items to indicate that there are items that become visible once a particular action is performed.

Had the WordPress folks used a technique to merely remove the elements from the visible view port, my screen reader would see all sub menu elements of all categories. My user interface would be much more cluttered than that of sighted people. All advantages of a lean and mean interface would be gone. And yes, I, too, enjoy the niceties of a clean interface where I can show and hide the stuff I need to work with or not. If, like in the WordPress case, the correct markup is being used, I do not need to see all content immediately to know that it may be there if I need it. On the contrary, if it were all shown, my interface would be cluttered and difficult to navigate, too!

The wrong method to use is the one I explained at the beginning of this article. The “remove” buttons and password entry fields of the BrowserID account manager were merely moved out of the visible view port rather than completely hidden.

Another useful application of content moved out of the view port are “skip” links. WebAIM have an article on these if you want to dive into this matter further.

In conclusion

It is my sincere hope that this blog post helps to clear up some confusion about the types of “hidden” content, the effects “display: none;” vs. negative positioning has, and when to use what properly. A good rule of thumb might be: If something should remain hidden until the user performs a conscious action, use “display: none;”. Should something, on the other hand, become visible when navigated to via the keyboard, or be discoverable by screen reader users right away, use negative positioning.

Questions? I’m sure there are! So feel free to post them here! And don’t be shy. Only who asks no questions will remain in the dark. 🙂

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:

  1. Password fields are now accessible, as well as many other types of edits.
  2. Labels are now properly exposed. This includes that input elements nested within labels are now being seen by VoiceOver.
  3. 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:

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!