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 developed the IAccessible2 interface, defining how screen readers and a11y enabled applications interact with each other.