• Zehe - implementation

Automated test scripts can be developed to look for accessibility issues by:

1. looking directly at XUL source -- this has the advantage of showing where in the XUL the error may be
2. testing via the scriptable accessibility core -- this is easiest to implement tests that work on any platform
3. the platform accessibility APIs -- this catches the most bugs

There are a number of things to test, such as:

1. test a set of HTML pages and the XUL interface's API support against known correct versions
2. have a number of test assertions for a good XUL user interface, testing both a11y API support and the keyboard user interface (e.g. tab order and use of accesskey mnemonics)

There are a number of places to add these tests:

1. Addons.mozilla.org -- part of the review process for new extensions
2. In Tinderbox, to catch errors early
3. In developer tools such as DOM Inspector and Firebug

P1

This should come before most of the other items. It is crucial to help solidify Mozilla accessibility, given the complex nature of our accessibility API support. It's very easy for patches to have unintended side effects. Although manual testing will always be important, good automated testing should help us avert problems earlier.

Mozilla a11y still does not have support of some important features, such as:

1. ARIA tree grids are not correctly supported, and tree grids in general are supported differently in different places.
2. The owns relationship is not fully supported, and in general multiple relations are not supported. Relations need to be implemented in a cache for performance reasons.
3. The list of known important core bugs and RFEs is here: xxx

Fixing these issues will lead to some Mozilla a11y core code rethinking and reorganization.

P1

Many of these issues were delayed until after Firefox 3, but are still very important. For example, tree grids are a very important widget in web mail applications.

• Zehe - design lead
• Surkov - implementation lead

Firefox has now reached a point where screen reader access is top notch, but some small annoying issues may hold users back from migrating. We need to discover what those issues are, as well as find ways to innovate beyond what's expected.

Many usability improvements can be had by tweaking the keyboard user interface to the XUL UI. Other usability improvements may be related to adding new preferences that benefit accessibility.

Some usability improvements are in the a11y core. Performance and footprint reduction are obvious usability wins. In addition, Mozilla should implement a repair heuristic for missing text equivalents. For any given image that has neither a title or an alt attribute, Mozilla should expose a text equivalent guess, by using the image file name, the link URL for the image (if any) and the title or content of any page pointed to by that link (if any). Major work has been done on this in bug 277469, although it will take a fair amount of work just to merge that with trunk, since the last patch was a couple of years ago.

Finally, many usability issues are just a matter of getting Gecko and AT bugs fixed. The accessibility team needs to push on developers (and projects) to fix important bugs, especially those related to focus, keyboard navigation and high contrast theme support. One particularly egregious area that must be addressed is keyboard navigation in plug-ins. Marco must also continue to utilize the community to push for fixes in both open source and proprietary ATs.

Usability is not just limited to Firefox. Thunderbird a11y could really use some work. Marco Zehe will lead the effort there.

P1

Usability is often low-hanging fruit that makes a big impact in terms of end-user adoption.

• Surkov

Mozilla's Mac a11y support was begun in 2006 by Hakan Waara. There is an incomplete list of open bugs. However, in general, the UA support has the following gaps which we will address:

1. Fix performance issues which require working with Apple to resolve: Hakan prepared set of wiki pages where he outlined this and other issues in the current state of UA support.
2. Reorganize crossplatform code to make it better match platform a11y APIs. The core a11y implementation is available via Javascript and should work the same on all platforms. Gecko still has platform depending implementation that should be movedinto cross platform code (e.g. trees and menus need to be dealt with intelligently in the XP a11y layer).
3. Fix web page transitions: changing web pages makes ATs confused. When the webpage is changed, a large number of accessibility objects go away. The a11y hierarchy may become jumbled.
4. Implement missing widget implementations: we do not expose the entire set of HTML/XUL/ARIA semantics and widgets via Universal Access (UA) for the semantics it does provide
5. Implement missing Universal Access semantics: UA does not provide properties for everything possible in XUL and ARIA. We must work out a proposal for what is missing, reach a consensus with other participants such as Apple, Opera and Adobe, and finally move forward on that while collaborating with other groups.

P1

Supporting Universal Access in Mozilla would allow HTML, XUL and ARIA developers to have accessible applications on all platforms. This would be a first.

Having at least 1 open source piece of software that implements the 3 major accessibility APIs would be a great reference for a11y developers. Understanding the differences between the 3 a11y APIs will be easy, and that enables improvements in the a11y APIS. It also leads the way to the potential development of a future universal a11y API.

Finally, supporting Universal Access is necessary to act like a native application on Mac. There are tools that utilize a11y support, for example a popular dictionary lookup tool that will use the word under the mouse pointer.

• Leventhal - standards
• Surkov - implementation

First, a standard must be agreed on for exposiing mathematics via the open accessibility APIs (ATK/AT-SPI and IAccessible2), via discussion in the Linux Foundation. Once a standard is a agreed on we must take that to Apple, Opera and Adobe and work on something that is in sync for Universal Access. After the standard is agreed on we must implement it for the complete set of MathML markup supported in Mozilla (presentational math, not structural).

We must keep a close eye on where the HTML 5 working group decides to take math. It has been suggested that HTML 5 will just include MathML markup. This would increase the popularity of using mathematics on the web, because the XHTML mime type would not be required. If it appears that this will indeed move forward, then it may be necessary to wait before implementing accessible math support.

P2

Mathematics has only been made accessible for 1 application at a time, for one particular output type (text-to-speech, hardcopy Braille and interesting hybrids of sound with speech, or Braille with raised graphics). These solutions have never been for mainstream products with mainstream assistive technologies. They have never used widely.

By separating the model from the view, and getting math support into open source assistive technologies, Firefox can start a new movement for more widespread accessible mathematics. This is not just a matter of support in screen readers. Ultimately math editing should also be available to users of alternative input technologies.

Mathematics are basic type of information, and essential for students and in many high paying jobs that could be open to individuals with disabilities.

• Leventhal - standards
• Surkov - implementation

The accessibility architecture diagram at the introduction of this article is an example of something we should be able to make accessible without description. It consists of a series of nodes and arrows. Diagrams tend to contain relationships, spatial information, object types or a combination of the above. There are many types of diagrams.

In addition, the objects within a diagram may be interactive widgets in their own right. For example, a circuit diagram may allow parts of the circuit to be open or closed. Diagrams may have individual objects that, together as a collection, form a new widget entirely.

Although using color alone is considered a violation when authoring accessible information, objects diagram naturally tend to use color to express properties. However, another possibility is to use shading or shapes.

SVG is a good way to author diagrams; however, SVG does not have native semantics on its own. It really needs ARIA markup to provide a way to add semantics.

What is needed is a community consensus on new ARIA markup to allow for the most common types of diagrams. It may be necessary, for innovative, interactive or live diagrams, that authors have a way be able to create custom ARIA roles with author-defined properties of various types.

For the moment, the WAI PF has decided to postpone discussion of ARIA in SVG until after ARIA 1.0 is released. Because the standards will be a challenge to complete, it is unlikely that implementation can begin until Q4.

The job of finally exposing this information in accessibility APIs will likely be:

1. Implement support for multiple relations via the relationship cache. The cache is necessary to make multiple relationships feasible and performant.
2. Determine how to expose custom properties -- either via object attributes or a new interface, and implement.
3. Determine how to best provide useful hints about spatial information, and implement
4. Follow documentation recommendations for exposing SVG accessibility information to AT. This includes the support of

equivalent alternatives for content and active element support.

1. Address keyboard navigation: work with SVG developers to drive keyboard navigation. We'll need help here -- we can't implement everything in the a11y team
2. Work closely with AT developers in tight feedback loop on implementation

P2

The challenge of making diagrams is a long term one, but, it is one that must be solved, because diagrams are a basic, common way to express information. Whereas charts and graphs can often be easily re-expressed in a table, there are many cases where data is difficult to express without a diagram that shows relationships between the items.

Diagrams have not yet become a major problem for the web, since using SVG still requires the XHTML mime type. However, a number of Javascript toolkits are starting to use SVG here and there. It is likely that such toolkits either already or soon will ultimately include libraries for providing diagrams.

Unlike the situation with MathML, if the HTML WG begins to work on integrating SVG, it doesn't really affect this work. That is because all of the semantics will come from ARIA, not from the host SVG markup.

• Owner unknown

The accessibility API support in Firefox is capable of providing excellent support for voice input software such as Dragon Naturally Speaking, as well as next generation alternative input software such as Jambu.

However, because the accessibility APIs have not been heavily exercised by these tools in the past it is likely that a good number of small bugs will be found that need to be fixed.

In addition, some evangelism is needed, at least to get Dragon Naturally Speaking to start using IAccessible2 (allowing them to implement Select and Say for Mozilla products).

P1

Users with physical disabilities are as important as any other users. Unfortunately, even in the world of accessibility, focus tends to first go to users with visual impairments. That's partly because tools for users with physical disabilities are still very primitive and are only just starting to utilize accessibility APIs. It's also because some vendors, such as Nuance, do not concentrate on outreach so we need to reach to them.

HTML 5 accessibility

• Owners unknown

Some HTML 5 elements are already being implemented in Mozilla. Within the Mozilla 2 timeframe it is likely that many more pieces of HTML 5 will be implemented.

This work is to ensure the standards work for us and to keep up with the Mozilla pieces being implemented, in terms of exposing those pieces via a11y APIs, documenting the support, and working directly with AT developers.

P2

We must ensure that the HTML 5 proposal is compatible with our a11y implementation.

• Surkov

This is a normal part of the hardening process

• Surkov plus a superreviewer

P2

This was recommended by David Baron at one point. Because we have been going without sr='s for most of the Firefox 3 timeframe it seems wise.