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.

Areas Needing the Most Attention

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.

Evangelize

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

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 useful 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 -- both on the graphical desktop and the character-cell console

• 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.

Fix Linux Audio

This Quixotian Quest involves working with all Linux distributions to come up with a common audio solution that meets the requirements of the assistive technology user. This includes fast response times, automatic audio mixing, resolving issues with device contention, allowing users to select which audio devices are used for speech vs. other audio playback, etc.

Develop an 'Uber GOK' Project (Alternative Input Solutions)

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 who can move the pointer, but cannot use a hardware keyboard

The MouseTweaks assistive technology allows the user to invoke mouse button actions via mouse movement alone. This gets us some fundamental support for users who can only move the mouse, but more is needed. 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 prioritize recently used words. I think regardless of how the prediction engine determines what words to propose, it should prioritize 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;...
• Autopunctuation: 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 autopunctuation 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 might be nice to have the onscreen keyboard automatically appear and disappear when the user enters/leaves a text entry area.
• 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.

See also OLPC's Line-Based Interface work.

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). Also see OpenGazer and MouseTrap for software gaze-tracking with a normal webcam.

NOTE: The MouseTweaks project is working on providing this solution.

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.. There is also WYNN (What You Need Now). Language support is also generally useful in education.

NOTE: There has been interest from community members to modify Orca so that it can be used for this purpose. Some of the work includes restricting what Orca speaks as you tab around and also incorporating better highlighting support.

Magnification

Task: improve the magnification support. See the GOPA task for magnification which is currently being worked on.

NOTE: The AEGIS work may also include a magnification component that can build on the GOPA work.

Additional Ideas

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

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., make Skype accessible)

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

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. We could make a great open accessible 'appliance' using the ASUS eee PC + Ubuntu-eee or other UMPC and distro.

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.

NOTE: Benetech is being funded by the Mozilla Foundation to create a DAISY Renderer for Firefox. One of the AEGIS deliverables may be a DAISY content generator for ODF (e.g., "Export to DAISY..." for OpenOffice).

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).

NOTE: Benetech is being funded by the Mozilla Foundation to create a DAISY Renderer for Firefox. One of the AEGIS deliverables may be a DAISY content generator for ODF (e.g., "Export to DAISY..." for OpenOffice).

RFB&D Media Reader

Task: create a RFB&D media reader.

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.

Word Prediction/Completion Service

Task: create a component or system service 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. This could be a new D-Bus system service, for example.

Closed Captioning (CC)

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

NOTE: the UK has '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. Tesseract, in particular, seems to be popular. Cuneiform also seems to be emerging.

See also http://members.iinet.net.au/~ddalton/projects/ocr/howto_configure-ocr_linux.html

Speech Synthesis (TTS)

There are a number of open source speech synthesis engines, such as Festival, Flite, FreeTTS, gnuspeech, 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.

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 supports liblouis.

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

Task: 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.

NOTE: The RedHat folks have done some work in this space for GNOME 2.24.

IDEs

Task: provide code authoring assistance in IDEs such as NetBeans, Eclipse, and Forte to encourage good accessibility programming.

Testing

Task: see the GOPA Testing Task.

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