Firefox and OS X’s VoiceOver … Reading the Magic 8 Ball

Intro

Macs are quickly gaining popularity — they simply rock for mainstream users. Macs continue to make inroads for people with disabilities as well, via Apple’s proprietary built-in tools such as VoiceOver. However, while Firefox has recently made amazing strides on the Mac, Apple’s assistive technology tools are not compatible with it. Firefox users with disabilities are simply not included in the OS X party.

Apple users with disabilities should be able to enjoy the same level of Firefox support that they have on Windows and Linux. For example, VoiceOver users should be able to take advantage of accessibility features such as Web 2.0 accessibility support via WAI-ARIA. They should have the advantage of the WebVisum extension, which enables the community to share accessibility repairs across the web, performs OCR on images missing alt attributes, and even solves captchas. These are just a few of the accessibility benefits of Firefox, and users should be able to take advantage of them regardless of their chosen operating system.

Developers would also benefit from Firefox accessibility on OS X. If the Mozilla platform were accessible on all major desktops, developers would be able to implement accessible UI’s with XUL, HTML or JavaScript/ARIA widgets, while remaining insulated from the vastly different architectures on each desktop.

But how do we get there? The community needs to mull over some difficult decisions regarding how we implement Firefox accessibility on OS X.

Approaches to OS X Accessibility

We have three choices:

1. Continue to invest in utilizing the native Mac OS X accessibility protocol: this protocol is comprised of two parts: NSAccessibility, which Cocoa applications use to expose their UIs and content, and the AX API, which assistive technologies use to access that information. Using these native APIs is how OS X’s built-in VoiceOver screen reader operates. Other OS X features such as Screen Zoom, Sticky Keys and the built-in dictionary can also take advantage of this support, and there is no doubt that other future tools will as well. Firefox 3 already has support for the Mac OS X accessibility protocol, thanks to Håkan Waara and a grant from the Mozilla Foundation. Unfortunately, VoiceOver compatibility issues remain unaddressed, and development is on hold. Håkan made multiple attempts from 2006-2008 to get assistance from Apple, and received replies but no follow-up.
2. Utilize an open source solution on Macs (help improve a DOM solution such as Fire Vox or WebAnywhere, or port the NVDA or Orca screen reader). The DOM based solutions would still rely on VoiceOver for access to the actual OS X desktop and native applications. Porting an open source screen reader would either need to do the same, or require that those screen readers have a way of dealing with Universal Access.
3. Prioritize the open source solution (option #2) but also continue to request help from Apple on the issues in native API mappings (option #1) for at least moderate support of Apple’s suite of built-in tools. This is the hybrid approach.

So what does our magic 8 ball say? Any of the approaches has pros and cons, and no matter which we chose, there is no escape from the profusion of work necessary to make that approach succeed.

However, one major difference is how far we can ultimately take each approach. The issue with using the Mac OS X accessibility protocol, as we have seen, is that the Mozilla accessibility team does not have adequate access to the VoiceOver team.

Firefox can’t just use NSAccessibility and hope that everything will just work with VoiceOver. In the history of making browsers hyper-accessible, close cooperation with the screen reader developers has always been required. We have already hit major snags just trying to make basic document content accessible. But, this is just the tip of the iceberg for Firefox, which pushes the forefront of accessibility. As Firefox pushes Web 2.0 accessibility forward, there is a need to work with the VoiceOver team to help define new ways of using the Mac OS X accessibility protocol to expose new capabilities introduced by WAI-ARIA or XUL. Properly exposing all the nuances for something like live regions requires working directly with the developers. In addition, it is necessary to influence development priorities such that quality support for the new semantics is incorporated into the actual VoiceOver software.

The web is like the wild west of technologies – it’s a chaotic, unpredictable situation at times, and is only growing in complexity. Having usable screen reader support always depends on addressing hundreds of annoying, detailed fixes in both the screen reader and the browser.

Painful isn’t a strong enough word to describe the situation when screen reader developers have another browser that matters more to them. I know this firsthand – we had this problem for years on Windows.

Linux

Contrast this with the situation on Linux — Orca is an open source screen reader and Firefox is a crucial browser under Gnome. Between Sun, volunteers such as the unsung heroine Joanie Diggs and Mozilla grantees, Firefox access keeps shooting forward under Orca, and we’re able to push the known limits of accessibility on that platform. The developers are easily reachable and we never reach “sorry, there are other projects we need to prioritize”. The Mozilla team reciprocates; it takes the job of fixing bugs that affect Orca very seriously.

Windows

Evaluating the situation on Windows for a moment, it wasn’t always good for Mozilla. In the beginning, it was extremely difficult for Firefox to be noticed, despite Mozilla doing everything it could to lay the red carpet out for Windows screen reader developers. Fortunately, Window-Eyes decided to support Firefox early in the game, even letting me work side by side with their developers in Fort Wayne, Indiana. However, Mozilla ultimately had to account for JAWS users being the majority and it has taken years to bring a satisfactory experience to those users.

Now things are getting interesting, because NVDA is also part of the race, and is moving forward with excellent Firefox support. At first NVDA did this because they generally care about other open source products and because Firefox simply had the best accessibility API support. The goals of both projects line up nicely, and the NVDA work is accelerating under a Mozilla Foundation grant.

What Succeeded?

What have we learned? We’re successful at accessibility when we become important enough to the screen reader developers to get their full attention. When we don’t get that attention, it’s just a slow, maddening road to unsatisfactory support.

Here are three ways to get screen reader developers to work closely on compatibility with your application:

1. Become the main browser or application of that class on the given platform (IE on Windows, Firefox on Linux, and Safari/WebKit on OS X).
2. Contract with a 3rd party screen reader vendor. This involves offsetting the vendor’s cost of doing the work. What you pay them, plus the income from upgrades they will sell due to support for your product, must be a fair amount more than the development costs. There may be side benefits for the vendor, such as the improvement of code they utilize elsewhere, which can factor in the price. On the other hand, hidden costs exist; for example, the difficulty of finding and managing an additional developer. Furthermore, because the revenue stream is short term, the vendor must consider the project’s aftermath. In the end, contracting with a third party vendor can be expensive, but it is effective. The need for vendors to offset costs is understandable. The market is small and the complexity involved in making screen readers work is significant and not generally appreciated. Moreover, as much as we wish otherwise, it is not easy to sell enough screen readers or upgrades because of Firefox support, to warrant extra development costs.
3. Assist an open source screen reader project. This is an ideal approach to make Firefox accessible on OSX.

No options on OS X

Unfortunately, Mozilla does not currently have any of the above choices on OS X. The bottom line is that there is no incentive for Apple to spend resources supporting someone else’s browser, and there is no possibility for Mozilla to contribute to a solution. This is not a reflection on Apple — it’s just a realistic statement.

Mozilla’s goals of quality access to both tradition web content and Web 2 are in jeopardy if it depends on Apple to devote significant time to support those goals. And, in the case of advanced topics such as WAI-ARIA, Mozilla is usually in the lead. For leading edge accessibility there is often nothing available yet in WebKit for Mozilla to imitate.

Let’s take an example. Think about full featured access to online office suites. What incentive would there be for Apple to spend significant amounts of time making these complex pieces of software, which have never been made 100% accessible in any browser-screen reader combination, work cleanly in Firefox with VoiceOver?

Would a third party make it different? Probably. If Berkeley Access was still around making Outspoken for the Mac, we could pursue them as a potential partner to make things really work. (For those who knew Berkeley Access back in the day, they were a ragtag bunch and lots of fun at conferences.) Unfortunately, this is not the situation. Apple owns both the screen reader and the main browser for the platform, and they have enough problems dealing with their own products to worry about Mozilla’s needs.

What if VoiceOver was open source?

We can’t expect this of course; but we can hope. It would mean that the Mozilla Foundation could provide grants to individuals to fix Firefox-related bugs in VoiceOver.

Apple may be reluctant to open source VoiceOver. There is some setup required for Apple to do this, and to be honest open source may not gel well with the way the Apple accessibility team works comfortably.

Before people cry “open source zealot”, let me assert that this is a practical issue, both for Mozilla and for Apple. Apple would gain much more than it would lose. It has been shown that external developers are of great benefit to Apple. WebKit originally came from an open source project called KHTML. And, WebKit continues to benefit from being open source, for example via the recent development of an amazingly fast JavaScript engine. In the end, open source costs less to develop while both the product reach and quality increase.

You don’t believe that Apple accessibility will receive help from the open source community? People like Alp Toker are already contributing. Alp is working to make WebKit expose ATK/AT-SPI so that WebKit can be accessible on Linux.

So what are the actual disadvantages for Apple? VoiceOver can’t really be used anywhere but on Apple, so I don’t see a concern about third party redistribution. It is not even necessary to open source the entire codebase – we only need the parts that process the AX API. Anything else, such as modules that are an integral part of the OS, could remain proprietary (although ideally the architecture has a clean separation from OS internals).

The open accessibility community would love to work together as a team with Apple on improving accessibility for all. The question is, would the VoiceOver team also thrive on working with the community? There is no doubt that they would, as the community respects Apple’s leadership and goals for VoiceOver.

Let us imagine the possibilities if the community were allowed to help improve VoiceOver. The community at large could help add new features, support for new types of content, help fix bugs, improve performance or usability, and in Mozilla’s case, add support for advanced web applications. Apple would remain in control over what goes into the main distribution that comes with OS X.

Summary

For Mozilla and the community to help push forward accessibility on the future of the Web, we need to be able to get bugs fixed along the entire chain of technology, all the way to the user. The community needs to influence fixes in authoring tools, UI toolkits, testing tools, browsers and certainly in assistive technologies.

A healthy situation on OS X would present no barriers to Mozilla developing innovations in web accessibility. Either a third party should be responsible for screen reader customizations or, an open source screen reader is necessary. At this time, the Mozilla accessibility team would have to consider solid proposals to develop an alternative open source screen reader for OS X. However, that would be an unfortunate waste of resources. The cleanest solution for everyone involved would be if VoiceOver simply became an open source project. This would maximize the potential for beneficial collaboration. It is very clear that users would benefit the most from the scenario where VoiceOver is open source.

An open source VoiceOver would accelerate the evolution of accessibility for everyone’s benefit while keeping control in Apple’s hands. Come on Apple! Invite the community to join your efforts!

Advertisement