A11Y-Love: help us with the following!!!!

Support the GNOME Project

Become a Friend of GNOME and help the GNOME community continue to provide great free accessible desktop software.

Active Projects

GNOME Outreach Program: Accessibility

A11Y-Love: we need a list currently active projects here and who's working on them. For example, Orca, GOK, AT-SPI over DBus, pyatspi, etc. We also need a good list of applications for people to test.

Areas Needing the Most Attention

A11Y-Love: everything is important, of course, but we cannot do it all at once. Based upon feedback from the community, we've identified these areas as needing the most work right now.

GNOME Outreach Program: Accessibility

The GNOME Foundation is running an accessibility outreach program, offering US$50,000 to be split among individuals. This program will promote software accessibility awareness among the GNOME and broader Free Software communities, as well as harden and improve the overall quality of the GNOME accessibility offering.

The program is sponsored by GNOME Foundation, Mozilla Foundation, Google™'s Open Source Program Office, Canonical, and Novell. This is the second in a series of outreach programs coordinated and run by the GNOME Foundation.

GNOME Outreach Program: Accessibility starts accepting applications on March 1st and will run towards the end of the year. There will be two tracks to the program: In the first track accepted individuals will work towards accomplishing one of the major projects nominated for the program, earning US$6,000 and can take up to six months to complete the task. The second track will reward contributors US$1,000 for fixing five bugs out of a pool of accessibility bugs nominated by the program judges.

Individuals interested in participating in the program should check out http://www.gnome.org/projects/outreach/a11y. More information about the program may be found at the same location.

Bug Fixing

As with any project, there is no shortage of bugs:

• Bugs not in the core AT-SPI Infrastructure or Assistive Technology Areas -- these are critical to us and we have few cycles to spend on them.

• Bugs in the core AT-SPI Infrastructure or Assistive Technology Areas -- these generally have decent coverage, but your help is welcome.

Please feel free to 'cherry pick' and help get the bug count down. There are also a number of very specific bugs listed in the GNOME Outreach Program: Accessibility Short Term Tasks. These are the most important and you get a prize if you fix 5 bugs.

Fix Speech

GNOME Speech provides a decent infrastructure for speech synthesis, but it is based upon the out-of-fashion ORBit/Bonobo platform, which essentially binds it to GNOME. It is also fraught with the problem of being dependent upon the speech synthesis engine (e.g., festival, eSpeak, DECtalk, Cepstral, Loquendo, etc.) to manage the speech output and other tasks such as verbalized punctuation. It can also contend for speech resources, competing with other things such as emacspeak and speakup.

Based upon real world use via Orca, and based upon feedback from end users and operating system integrators, the general belief is that gnome-speech may have reached the end of its purpose in life. We need someone knowledgeable in the space to create a speech solution that can do the following:

• Work with the desktop, mobile, and embedded spaces (e.g., GNOME, KDE, OLPC, Maemo, Nokia, etc.)
• Adapt to the existing audio solution(s) for the platform
• Address i18n/l10n and multilingual issues
• Meet the needs of screen readers, both from the functionality and performance/responsiveness points of view
• Support both free and commercial speech engines
• Provide a shared speech service for a variety of applications to use

• Work as desired on a system where many seats might be served by one server (e.g., Sun Ray)

• Address the usual litany of concerns: security, system performance, licensing, etc.

The person doing the work should also provide a migration path away from the current gnome-speech solution to the new solution (e.g., "how will it work with Orca?") and get buy-in from at least the GNOME community that this will be a supported solution. A possible starting point might be Speech Dispatcher, though existing concerns with quality, configuration, and feature completeness need to be addressed.

AT-SPI on DBus

We need to look to migrating away from CORBA (ORBit/Bonobo) since the rest of the community is doing so. If we don't migrate away, GNOME Accessibility will become the de facto maintainer of this code. In addition, small platforms such as OLPC and embedded systems such as OpenMoko are looking to not include ORBit/Bonobo. So, work is needed to help migrate AT-SPI to DBus, gnome-mag to something (see above), and gnome-speech to something (see above).

For AT-SPI, Rob Taylor and Mark Duffman have done an AT-SPI over DBus Feasibility Study. The results look promising with very positive feedback from the Open A11y Community. We need to find ways to fund the migration plans.

Develop an 'Uber GOK' Project

The GOK maintainers are looking for help and are also interested in migrating GOK (or GOK ideas) to Python. There are also additional ideas for enhancements and additional features to support a wider range of users. This task is to help organize those ideas into a project plan and prototype for an "Uber GOK". This proposal should include the development of Personas, user requirements, and design for the project. The work should involve the creation of an "on screen keyboard" community. The personas and requirements will be developed as a result of direct interaction with end users in this community.

This should provide 1st class access to people who don't use mouse or keyboard or need tweaks to them to support poor motion control (e.g sticky keys, delay click, dwell select). This covers people with physical disabilities and aging population. Should be available out of the box and also work on thin client (implies good X support). It should support text input, application control, overlays (manual and UI grab), direct in app control, attractive visuals (e.g SVG), multimedia 'selection sets' for education, editor, shared resources/community

Starting points include OnBoard and Jambu, but should also incorporate the following ideas:

Improve efficiency of the GNOME desktop for people without problems to move the pointer, but that cannot use a hardware keyboard

Here are the features that an efficient onscreen keyboard should probably have to provide:

• The onscreen keyboard should emulate all the functions of a hardware keyboard: for example, pressing shift on the onscreen keyboard should produce the same effect (for example in conjunction with mouse operations) as pressing shift on the hardware keyboard
• It should have a good word prediction engine (not only word completion), with a learning mode that can easily be activated and deactivated (I don't want my passwords to be in the dictionaries). Maybe a button directly on the osk. Example, on my current onscreen keyboard, when I type ons it proposes among other words, the word onscreen (word completion), and immediately afterwards (without typing anything) it proposes among others the word keyboard (word prediction).
• The word prediction engine should prioritise recently used words. I think regardless of how the prediction engine determines what words to propose, it should prioritise the words that were recently used, as they have a greeter chance to be reused in the particular context about which the user is writing at that moment.
• It should have an interface to edit the dictionaries; by entering single words and learning from a text file. Indeed, to create a dictionary, the ability to learn from a text file is useful, but once the user has dictionaries that suit him, he might keep the learning mode deactivated in order to not mess up the dictionaries and only enter a single new word when needed. But this will probably depend on how the prediction engine works.
• It should be easy to switch language; think at people that speak several languages: they write English in a forum, than write an email in their native language to a friend; than go back to the forum;...
• Autoponctuation: for example automatically type space after selecting a predicted word; when typing a dot, automatically remove the space, write the dot, automatically write a space and automatically activate the shift key;... The activation and deactivation of the autoponctuation should be directly clickable on the onscreen keyboard, because the user has to often toggle its state (it disturbs for urls, in the terminal,...).
• Then onscreen keyboard should be resizable and in a floating window.
• It should be possible to minimize it to a floating little resizable icon. Currently, when minimizing a window, it goes to the bottom panel with the following two disadvantages: it is not always at the same place on the panel and the pointer has to travel from the panel to the keyboard after unminimizing it. Having a floating resizable icon, the user can place it on the desktop where he wants. And if the location of the icon is around the location of the onscreen keyboard, the pointer will be directly on the onscreen keyboard after changing from the iconized to the keyboard form.

Hardware Integration - PnP support of alt input devices

Make on-screen keyboard switches "just work". For example, for usb switch hardware, work on hardware recognition (plug and play), probably to use vendor and product ID, as this hardware usually masquerades as keyboard and/or mouse switches. Include: switches, joysticks (switch and continuous), graphics tables, touch pads etc. Need a test panel and easy config UI (e.g the Windows Games controller in control panel). Suitable devices should be usable as the X pointer controller. Thin Client support. In general, this can also be writing UNIX drivers for AT hardware such as the inexpensive head mice that are available.

Cheap Head Mice

Do research and development into inexpensive 'head mice' that might be able to take advantage of built-in cameras on some machines or low cost add on cameras. This breaks down into head and eye tracking. It might be possible to get good results with visible spectrum cameras which are cheaper than Infra Red solutions (see lightweight eye tracker for a hack).

Related

See also OLPC's Line-Based Interface work.

Evangelize

We need more people to spread the word. Include accessibility in your talks! Write more testimonials and case studies.

Additional Ideas

This section contains a list of all the ideas we've come across to date, not including the ones mentioned above.

Applications

GPS

• Task: GPS system support, integration (with speech, Braille, Magnification). The Geoclue folks might have something. Also look to something similar to Humanware's GPS Solutions (e.g., Trekker) on a Maemo or OpenMoko (e.g. Navit) or Loadstone GPS. See discussion on gnome-accessibility-list.

VoIP/Skype

• Task: develop an accessible VoIP solution (e.g., Skype)

Flash/Firefox

• Task: Implement support for accessible Flash content. (See WebAIM's overview among others.)

MathML/Firefox

• Task: Look at making MathML accessible

Database/SQL

• Task: Look at database accessibility. Look at phpMySql, Aqua Data Studio for more information.

Document Content Authoring Assistance

• Task: work with ODF, PDF, etc., content creators to incorporate accessibility checking into document. ""This document is inaccessible. You can't save it until you make it accessible."

IDEs (NetBeans, Eclipse, Forte, Anjuta, etc.)

• Task: Work with IDEs to help encourage good accessibility programming

Bugzilla

• Task: Work with Bugzilla team to make the content more accessible/navigable by people with disabilities

Infrastructure

Much of the infrastructure work needed is to look at eliminating the CORBA dependency of the various components that use it. The latest fashion in interprocess communication is DBus, so much of the work will probably revolve around retooling the infrastructure components for DBus.

Webkit Accessibility

Webkit is turning out to be the latest hotness in HTML/CSS rendering. A lot of GNOME modules, like Yelp and Epiphany are flirting with the idea of switching to Webkit for rending HTML content. Other programs like Liferea might follow suite. There is also talk of bundling Webkit with GTK+. While a lot of work has gone into Firefox a11y, specifically in enabling web applications to be accessible via live regions, the initial work on Webkit needs to be fairly basic - exposing the document model via AT-SPI. This will allow programs like Yelp to use webkit and continue to be accessible. Of course as full featured browsers like Epiphany utilize Webkit, a more comprehensive a11y solution will need to be put in place, similar to Firefox 3.

References:

• Alp's blog

• WebKitGtk

Small/Embedded Devices

• Task: Investigate GNOME accessibility on OLPC and other embedded systems (e.g., OpenMoko). What are the platform requirements? What are the dependencies? What will it take to get it to work? These devices have the potential to make effective communications aids for AAC.

Assistive Technology and Other Work

Media Readers

Bookshare Reader for UNIX

• Task: create a Bookshare reader for UNIX. This could be a UNIX edition of something like the Victor Reader Soft software Bookshare (and DAISY) reader. There is a binary unpack tool for Bookshare for Linux.

DAISY Reader

• Task: create a good DAISY/NIMAS player. This could be a UNIX edition of something like the Victor Reader Soft software DAISY (and Bookshare) reader. Note: Possible starting point could be the fairly recent "The DaisyPlayer Project" for the Norwegian Skolelinux effort. See also Iduna and Jos Lemmens' Daisy Player. Note also that the DAISY Reader should add support for people with cognitive impairments as well (e.g., highlighting of the text being spoken).

Text mining features

• Task: develop a text mining library for summarizing texts, discovering the structure of a raw text (headers, paragraphs) and more generally speed up access to information.

RFB&D Media Reader

• Task: create a RFB&D media reader.

Dyslexia and Learning Disabilities

• Task: research and development into solutions for people with dyslexia and/or learning disabilities. The Windows state of the art here is Read & Write Gold from TextHelp Systems, Inc.. Language support is also generally useful in education.

Word Prediction component

• A component to supply word prediction to various editing applications. Common dictionary is better than separate one for each program. Useful for LD and OSK, speech and general input.

Closed Captioning (CC)

• Task: develop or document existing solutions for adding closed captioning to media. See the discussion on gnome-accessibility-list.

• In the UK we have 'subtitles' which may or may not be very similar.

• NOTE: we also need other projects for people with hearing impairments.

OCR

• Task: create a high quality OpenBook (unbound) software equivalent. This is a self-voicing OCR package that automatically reads text to you, or works with your screen reader. See a recent thread on Blinux.

Speech Synthesis (TTS)

There are a number of open source speech synthesis engines, such as Festival, Flite, FreeTTS, and eSpeak.

• Task: work on high quality text-to-speech in many languages. The more viable approach may be to work on localization of eSpeak for your favorite locale(s).

Speech Recognition (ASR)

The end goal is to get a speech recognition engine similar to Dragon Naturally Speaking, a dictation and command-and-control application and ASR engine. As such, this can be two tasks:

• Identify/create/enhance a speech recognition engine that supports command and control and dictation
• Use the engine to provide a compelling speech input experience for the desktop

See simon, Sphinx-4 and OSSRI as potential starting points. Note also that there have been reports that Dragon Naturally Speaking seems to be working OK now under wine, so that might be an alternative as well.

Alternately, check how tonguing or other elementary sounds could be helpful as a complementary input method to speech (e.g. in a noisy environment). Read as example this publication by Takeo Igarashi and John F. Hughes: Voice as Sound: Using Non-verbal Voice Input for Interactive Control.

Braille Translation and Formatting Software

Duxbury Equivalent

• Task: create Duxbury equivalent. This is end-user software that takes text in a variety of formats (e.g. UNICODE, ODF) and turns it into Braille format for printing and other uses (BRF). See also TurboBraille. Would be good to create a standard API for communicating with Braille translation and formatting engines.

Braille Editing in OOo

• Task: provide braille editing capability inside Open Office. This will allow users to flip back and forth between a print and braille view of the same document, editing in either form. A standard API for communication with braille translation and formatting engines as described in the previous item would be useful for this. Various engines could be used together within the same document, for different kinds of content, such as mathematics and different languages. The same engines could be reused by various editors that support braille, etc.

Drivers for Braille Embossers

• Task: create drivers for a variety of braille embossers. Should consider working with ONCE on this since they already are working on drivers for Impacto, Porta-thiel, BetaX3 and Vax. Also see liblouisxml/xml2brl/tiger from http://www.jjb-software.com/index.html. Should probably find its way in CUPS.

• NOTE: Orca currently looking at rolling in support for liblouis for GNOME 2.22.

TTY Interface

• Task: create a TTY interface to talk with Baudot, and new TTY (also IP/TTY interoperability)

Haptics

• Task: Use Haptics as user input. Determine what can be legally developed (e.g. search the web: "haptic patent portfolio").

Tactile Graphics

* Create/use tactile graphics software that makes use of tactile graphics to convey information to people with visual disabilities. See John Gardner's Resource Guide.

Usability Testing

• Need end user usability testing and usability studies of GNOME accessibility by people with disabilities. Brette Luck w/Novell and Dave w/ITD may be willing to help with this.

Additional Documentation

• AT-SPI implementation "best practices" documentation - what should implementors of AT-SPI do?
• 5000' view presentation to policy-makers.

Accessible Login

• Task: get Accessible Login enabled by default on all distributions

• Make the presence of AT visible at the login screen: for example currently, it is possible to start gok with a mouse gesture. But GNOME users will not know about it unless they dive into the documentation about the assistive technologies. See bug 463713 and the passing of activated ATs to the GNOME session might also be of interest.

R&D

Research and development projects should explore innovative ways to improve accessibility and usability of upcoming and existing technologies. Some activities include:

1. Staying abreast of trends in technology to ensure GNOME accessibility is prepared to handle the "next big thing."
2. Making sure infrastructure work doesn't preclude advancement.
3. Brainstorming / developing improvements that push the envelope in the user experience.

University GNOME-based A11y Research Projects

• Brett Clippingdale at the University of Michigan, Ann Arbor: intelligent, adaptive user interfaces, particularly for the elderly and/or users with disabilities.

• @todo: get more university projects using GNOME listed here

CategoryAccessibility