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 your and our products work consistently;
• 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

You've got an idea

Here's our repo of ideas and proposals. Check it out. If you've got an idea then break it into statements and run it through our mail list. We will put the idea summary, proposal, pro and contra into the repo where everybody can see it. Then if the idea meets the group priorities then we put into into our planing page where we plan activities and divide priorities between tasks.

Throughout analysis

AT parties do individual analysis of present state based on missed features, bugs, questions, complaints, requests. Prepare a list of ongoing activities, motivation for each of them. Figure out priorities. Break your list into ideas and run them through mailing list.

Planning and implementation

So we have ideas at our repo, their summaries, pro and contras. Each party set up its own priority. Based on that do a group priority for each idea. Then work on proposal and make sure it suites everyone. Each party estimates the timing required for implementation for each item. 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 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 can't get solution that everyone is ok or implementation is depended on feedback from other groups. Also that can happens 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).

Contact us

Use the mail thread if you have questions or have an idea to share. 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