Accessibility/OpenATCollaborationProject

What is this

The open AT collaboration project is an open community project of Mozilla and assistive technologies vendors that was started in order to coordinate an effort of Gecko and AT developers, adapt existing technologies for a better user experience and create new ones to make sure 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. Here's a right place to get everybody in touch and make sure new solutions and ideas work for everyone.

Who

Originally this project is started by Mozilla, Orca and NVAccess. But if you are an individual or a company who is passionate about making the web and desktop accessible then please join us. Everybody interested is welcome. Your feedback is appreciated, the voice is respected.

If you are

• screen reader developer then you would like to follow Mozilla accessibility progress and be part of it;
• desktop server or browser developer then you would like to join to make sure we expose content in consistent way;
• web developer then you might have ideas how to make web authors life easier and we'll be glad to make this.

Goals

• Provide complete, correct, consistent and robust implementation of accessibility APIs for the web and desktop.
• Clear, light and nice AT implementation for the web and desktop, no ifelses, no bugs, no surprises, no headache.
• Found a bank of ideas how to expose the content the best way, turn them into proposals and put them into life.

How

• Create the group and work as one team.
• Make 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 guideline

• Get ATs providing a more consistent experience where possible
• Get ATK and IA2 as synchronized as possible
• Get Gecko and other toolkits (e.g. Gtk+) as synchronized as possible
• Formal documentation of the expected implementation
• Create regression tests (both ATs and Gecko)

How does it 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, pro and contra into the repo. Then if the idea meets the group priorities then we put it into our planing page where we plan our activities and divide priorities between tasks.

Throughout analysis

If you are AT developers then you can do individual analysis of 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, pro and contras. 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 suites 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 settled down in bugzilla so everyone can get clever idea what we are 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 is depended on 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 or idea to share then please file 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
• Orca
  • Joanmarie Diggs