One of the goals of the meeting is to do a gap analysis of existing technology to identify solutions that need to be addressed by the open source accessibility community.

If you haven’t already shared your thoughts on this matter with someone else going to the meeting I’d be happy to bring your ideas forward to the meeting.

Here is a list of attendees.

Below is a summary of the input I received from some of my associates in the field of accessibility architecture and development.

Steve Lee

• AAC (Augmentative and Alternative Communication) solutions including symbols and portable devices, e.g. straight-street.com.
• Alternative access, e.g. Jambu
  • Head/eye tracking
  • Switch
  • Voice recognition
• Simplified access for cognitive/dementia users, e.g. Maavis
• Magnification as good as ZoomText
• Reading support, e.g. Project Possibilities PowerReader
• Mobile device access

Additional notes:

• Support all platforms, including mobile.
• Packaging and support are very important for a market unfamiliar with procuring FOSS.
• Rather than specific disabilities, address an individual’s combined set of requirements.
• Ease of use is key.
• Allow individualization, e.g. allowing for needs that change over time.
• Provide for a wide range of environments, e.g. corporate, education, individual users, and non-technical facilitators. Installation, deployment, and support are a bit different in each environment.

David Banes, Director of Development, AbilityNet

To Steve’s list add:

• Touch and gesture recognition
• A more powerful OSK
• Important: interoperable solutions

Michael Meeks, Distinguised Engineer, Novell

The last thing that concerns me about the Linux accessibility architecture is to get the infinite space problem done right. The infinite space problem occurs in cases of a very large collections of objects as occurs with very long documents or very large spread sheets. I believe the right solution isn’t to use life cycle management of objects, with all of its associated problems, but to only expose peers for objects that are in an “accessibility view port” around a “accessibility point of regard”, similar to how apps manage the subset of objects that are to be displayed in or near an application’s active view port. The similarity of approaches will allow for the accessibility solution to be a good fit with an app’s current design.

Over the last three years I lead a team developing the IAccessible2 interface, defining how screen readers and a11y enabled applications interact with each other.

IAccessible2 is often called IA2. IA2 extends MSAA allowing additional capability such as full access to information about a table or the offset of the caret in a text field. This work was done as an IBM employee under the direction of Rich Schwerdtfeger, Distinguished Engineer, IBM Software Group Accessibility Architect/Strategist. My IA2 work included:

• Chairing the regularly held meetings
• Responding to issues on the IA2 list
• Updating the spec’s commentary to remove ambiguities
• Providing implementation guidance to AT and application developers
• Acting as liaison between the AT and application developers

On January 21 I was part of a large resource action at IBM, suspending further IA2 development.

I believe the IA2 work is important. The advanced accessibility provided by IBM Lotus Symphony and Mozilla’s Firefox proves the benefits of IA2. I think the work should continue. But how?

I would like to continue the IA2 work – provided an organization commits to, and funds, the IA2 effort.

I’m asking for your feedback.

Thanks, Pete