What is the open AT collaboration project?

The open AT collaboration project is a community partnership between Mozilla and developers of assistive technologies which was established to:

• coordinate our efforts
• improve existing technologies for a better user experience
• create new technologies to ensure the diversity of the web and desktop is revealed in accessible and unified way

We at Mozilla are very friendly to AT and work hard together. Unfortunately our effort is not always coordinated and that brings us into situation when AT work is blocked by Gecko or changes requested by one AT aren't suitable for others. We need a place to get everybody in touch and make sure new solutions and ideas work for everyone.

Who we are

This project was created by Mozilla, Igalia and NVAccess. But all individuals and companies who are passionate about making the web and desktop accessible are encouraged to join us. If you are:

• a screen reader developer, become a part of Mozilla's accessibility progress;
• a desktop server or browser developer, help us ensure we expose content in consistent way;
• a web developer, tell us how to make your job easier and we'll do our best.

Your interest is welcome. Your feedback is appreciated. And your voice is respected.

Our goals

• Provide a complete, correct, consistent and robust implementation of accessibility APIs for the web and desktop.
• Create a clear, performant and compelling AT implementation for the web and desktop: no ifelses, no bugs, no surprises, no headaches.
• Found a bank of ideas regarding the best way to expose content, turn these ideas into proposals and make those proposals reality.

Our values

• Work as one team.
• Establish an open place for discussions, feedback and voting (mail lists, wiki, bugzilla, meetings).
• Collect ideas.
• Be driven by a general plan and priorities of the group.
• Collaborate with existing groups like IAccessible2, ATK, HTML and ARIA working groups.

Our plan

• Get ATs providing a more consistent experience where possible
• Get ATK and IA2 as synchronized as possible
• Get Gecko and other toolkits as synchronized as possible
• Document the expected implementation
• Create regression tests (both ATs and Gecko)

How we work

Bank of ideas

Here's our repo of ideas and proposals. Check it out. That's something we currently look at.

You have an idea

If you've got an idea then break it into statements and run it through our mailing list. After discussion we will put the idea summary, pros and cons into the repo. Then if the idea meets the group priorities, we will put it into our planing page where we plan our activities and divide priorities into tasks.

Throughout analysis

If you are an AT developer then you can do individual analysis of the present state based on missed features, bugs, questions, complaints, requests. Then prepare a list of ongoing activities, motivation for each of them and break the list into ideas and run them through mailing list.

Planning and implementation

This section describes activities of Mozilla and participating ATs, in other words how we (a project subgroup) breathe life into ideas.

So we have ideas at our repo, their summaries, pros and cons. Each party set up its own priority. Based on that we do a group priority for each item. Then work on proposal and make sure it suits everyone. Each party estimates the timing required for implementation. During time planning each party estimates their other activities and provides real time they are able to spend for the project. Based on that split activities into quarter goals and create milestones. For each milestone create a tracking bug.

These activities are documented on planning page and entered in bugzilla so everyone has an idea what we will be doing next.

Time conflicts

We follow general guideline:

1. Analysis
   1. Individual analysis by all parties of present state in details
   2. Public discussion, conclusions, bug filing (get a chance to the 3d parties to provide feedback)
2. Implementation
   1. Implementation in Gecko, support added to ATs
   2. Documentation and regression test writing
   3. Regression fixing

1st item remains unchanged for every party each quarter. 2nd might be altered if required. For example if we can't get solution that works for everyone or proposal requires feedback from other groups. Also that can happen when the party realized that it has better or worse implementation that it was expected on planning stage and it requires time lesser or more than quarter. If anything like this happens then team figures out the next step.

Areas we are looking at

1. Widgets
   1. Hierarchy (all kinds of widgets: HTML4/5, ARIA, XUL)
   2. Events
   3. Attributes, states and properties
2. Navigation and AT-Unique Object Interaction
   1. Caret navigation and text interface
   2. Object navigation
   3. Actions
3. ARIA, HTML5 (everything that doesn't fall under Widgets section).

Refer to our ideas bank for specifics.

Contact us

If you have a question to ask or an idea to share then please send it to our mailing list. This is a generic Mozilla accessibility mailing list so please include [openAT] prefix into message subject.

If you need to contact us directly then here we are:

• Mozilla
  • Alexander Surkov
  • David Bolter
  • Marco Zehe
• NVAccess
  • James Teh
  • Mick Curran
• Igalia
  • Joanmarie Diggs
  • Alejandro Piñeiro