Accessibility

From OLPC
Revision as of 00:43, 16 March 2010 by FGrose (talk | contribs)
Jump to navigation Jump to search

There is an accessibility mailing list - please join and introduce yourself.

Worldwide need for accessibility support for people with disabilities

Finding good data about disability incidence worldwide is challenging. In America and Europe, we have some general statistics:

  • Half of all disability incidence numbers are from people over 65 years of age
  • Roughly 0.1% of the population is blind
  • Roughly 0.1% of the population has a speech impairment (could benefit from their computer talking for them)
  • Roughly 0.05% of the population is deaf, while 0.2% is hard of hearing

Since we tend to get more disabilities as we age, we would expect these percentages to be lower in children. On the other hand, health issues like West Nile Virus that are a huge cause of blindness (and the altitude in places like Tibet, another cause of blindness) aren't significant issues in America and Europe - so you would expect that the incidence of disabilities in the OLPC markets will be higher.

So, until we get better data, it probably makes sense to adopt as rough numbers for OLPC children the general percentages from America and Europe taken across all age ranges.

This means that if the OLPC project reaches every child (so roughly 1 billion systems), we will need to serve 1 million blind children, and 1 million children who have a speech impairment, and 2 million children who have difficulty hearing.

Accessibility and Assistive Technology

Even in "first world" countries like the USA, Assistive Technology and Accessibility adaptations are expensive. People with physical or mental disabilities are often, due to their disability, in the lowest income classes, and have difficulty affording the technologies required.

In the Open Source Software community, a fair amount of software already exists to aid the disabled. However, they are often not installed or configured by default, and can be extremely difficult to add by any user.

Under this area, we should seek to list specifically:

  • What Assistive Technology software packages should be included in the default olpc distribution
  • How they should be configured by default
  • What technologies need to have improved documentation to be useful

Accessibility ideas for the OLPC laptop

For people with physical impairments

Main article: Accessibility/Input

Physical impairments range from fairly minor (difficulty using the mouse), to more significant (unable to use a normal keyboard, but still have a fair amount of upper body dexterity), through to being paralyzed from the neck down. Repetitive stress injury is another issue, though incidence of that is currently probably quite low in OLPC's target market.

Roughly 0.2% of the U.S. population has "difficulty using hands and fingers, e.g. to pick up a glass or grasp a pencil". By our logic above, that works out to 2,000,000 target OLPC users

  • First and foremost, making the OLPC accessible to the disabled should be added to the mission statement of the project. Given the higher percentage of disabled children in developing countries, this would see that proper attention is given to seeing that any proven inexpensive hardware and open source software be added as the default configuration.
  • OLPC should be fully operable from the keyboard, without requiring the trackpad for operation. Something like a painting program might be an exception; but otherwise, tasks like launching programs and browsing the web and reading a book (and ideally most games) should be fully operable from the keyboard. There should be a visible indication of which object has the keyboard focus (and this visual indication should become more obvious in various themes for vision impairments)
  • OLPC should support the AccessX suite of keyboard enhancements (StickyKeys, MouseKeys, BounceKeys, etc.). For a current workaround, see the AccessX page. AccessX type software is shipped by default in every other OS. OLPC should not be an exception.
  • OLPC should support external keyboards & mice/trackpad devices.
  • OLPC should support an on-screen keyboard (e.g. [GOK]), and likewise support hardware input from switches (USB, but perhaps also inexpensive ones connected via the microphone port), and also head mice (USB, but perhaps also one that uses the built-in camera tracking a reflective piece of clothing or dot pasted onto a persons forehead or glasses) - I think trackers that use reflective technology (clothing or dots) use infrared to avoid interference with visible light. Since the OLPC doesn't have infrared technology something else will need to be used. A bright LED attached to the persons head with a headband might work. Not sure how it would do in sunlight though - some experimentation would be necessary. -- BenKonrath <ben at bagu dot org>
  • OLPC should ship with a trackpoint style pointing device as touchpads won't work with artificial limbs. This would greatly improve the usability of the mouse. This could be added in addition to the touchpad, or as an alternative, allowing more space for the keyboard. The trackpoint is a proven technology and should cost very little to add. The added bonus is many able bodied people prefer the trackpoint to the touchpad.
  • Open source screen reader software should be added to enable use by the visually impaired.


The "red" sensor on most digital cameras, perhaps including the one built in to the OLPC, actually extends farther into the infrared than your eyes. Try pointing your TV remote at your digital camera someday - you can see a flicker if you watch closely. (Much harder to see with computer IRDA infrared ports which are much dimmer). So, maybe all you'd need would be a light source (infrared LED) connected to a USB port - the parts list would cost pennies. Homunq 11:33, 2 August 2007 (EDT)
  • The XO's camera could be used with something similar to this setup, using a lightweight rechargeable supercap + IR LED setup attached to a headpiece to control the pointer.
  • While it is true that CMOS sensors can see pretty far into infrared, for this very reason, most have IR filters to keep the image looking as close as possible to what the human eye sees. Testing with a 880nm IR LED, the camera on the XO shows only a faint glow, almost invisible in daylight. It may be necessary to use visible light, or at least a shorter wavelength of IR.

For people with minor physical impairments

For people with minor impairments who find using pointing devices difficult, or even unimpaired young children who don't yet have fully developed fine motor skills, a USB mouse or trackball with reduced sensitivity may be beneficial. Sensitivity can be adjusted by creating the file ~/.xsession with the following line: xset m 1 0

This will not work if the usb device is unplugged and plugged back in after the XO has booted. Adding a udev rule like: SUBSYSTEM=="input", RUN+="/usr/bin/xset m 1 0"

doesn't seem to work. Anyone who's gotten this working please edit.

For people with visual impairments

There is a fairly wide range of vision impairments Including;

  • Visual Acuity (sometimes but not always correctable with eyeglasses)
  • Visual contrast (including albinism (a lack of eye/skin pigmentation) partially correctable with dark glasses)
  • Choroideremia, Keratomalacia (night blindness)
  • Color blindness (trouble distinguishing red, green, blue, or mixtures of these colors)
  • Cataracts (Non-transparent or cloudy area in the lens of the eye)
  • Glaucoma (loss of peripheral (side) vision), etc...
They can range from the fairly minor(and correctable) to pretty significant (18 point text isn't large enough), all the way through to total blindness.

For people with minor visual impairments

  • Sugar and all OLPC application should use a luminosity contrast ratio of at least 3:1 by default; ideally 5:1
  • Color should never be the only indication of something (e.g. using red text to set off something from black text)
  • Sugar should include several "themes" for vision impairments, including several with different contrast settings (e.g. a "high contrast" theme) and large print. All applications should respect these settings. The interface for launching applications should be enlarged in the large print theme (cf. the themes in the default GNOME desktop).
  • Applications should be fully tested in the high-contrast themes. (Many Windows applications are not tested by their developers in the high-contrast themes, and contain display bugs that can seriously impair their usability in those themes. Please test.)
  • 8% of males of European descent have color blindness; 1% of females of European descent. Numbers are lower for Asians and Native Americans; lowest of all for blacks.
  • Web Safe Color recommendations for colorblind users from British Telecom Labs [1] and VisiBone.com [2]. 5% of European men with deuteranopia don't see green and 1% of European men with protanopia don't see red. A sample of the differences [3] from BTLabs. More website resources from Vischeck.

For people with 'low vision'

  • OLPC should support software magnification. Magnification should track keyboard focus and the text input caret. It should also magnify the mouse cursor.
  • Mouse-only enhancement would be useful (mouse-trails & separate mouse cursor enlargement, to help locate the mouse cursor)
  • It would also be useful if applications could be set to display their contents in a reduced area where possible, so that the magnified desktop does not have to be scrolled around so much. For example, if editing a document, try not to make the document window larger than the viewing area if it doesn't have to be.
  • It would be a plus if the magnified application's fonts can still be rendered at the screen's high resolution, rather than being blocky. However, this should not be done at the expense of making the graphical controls too small. Everything should be magnified, including any icons, window controls, etc (the absence of this in desktop environments is why some low-vision users prefer to run in a low resolution rather than or as well as changing font sizes, see for example http://people.pwf.cam.ac.uk/ssb22/setup/ )

Roughly 0.2% of the U.S. population has "difficulty seeing words in newspaper". By our logic above, that works out to 2,000,000 target OLPC users.

For people who are blind (from 'legally' blind through to totally blind)

  • A screen reader which supports text-to-speech and works with all applications (Orca is the obvious choice here)
  • Lightweight text-to-speech in all languages (eSpeak is a good candidate)

Roughly 0.1% of the U.S. population has "Unable to see words in newspaper at all, or self identify as 'blind'". By our logic above, that works out to 1,000,000 target OLPC users.

For people with hearing impairments

The main things we need to do for folks with for hearing impairments are:

  • Not use exclusively audio for getting the attention of a user (e.g. the ShowSounds feature to flash the menu bar / screen during a system beep)
  • Ensure that all media players support captioning, and all media is captioned
  • Investigate language-learning activities specifically tailored to students who do not acquire written language via normal methods.

But beyond that, thanks to the built-in video camera in the OLPC, we have the possibility of supporting sign language chat. In the BTest-2 systems, using the bulit-in camera application the frame rate seems to be on the edge of good enough for this (in an informal test performed at the CSUN Conference on Technology and Persons with Disabilities). With a promised 30fps frame rate of 640x480 resolution, this ought to work. Further tests need to be carried out over a wireless video chat to be certain.

Roughly 0.2% of the U.S. population either has "difficulty hearing normal conversation" or is "unable to hear normal conversation at all, or self-identify as 'deaf'". By our logic above, that works out to 2,000,000 target OLPC users.

Children who are born deaf, particularly children born to hearing parents, often face considerable challenges in acquiring language. Immersion within the first two years of life is critical. Without that, the cognitive centers of the brain which handle language do not form properly. This, in addition to the fact that deaf kids cannot learn to read by "sounding it out," can create lifelong difficulties with literacy skills. The problem is aggravated in countries where deaf kids have no access to schools or peers due to limited (or non-existent) sign language skills in teachers, and societal attitudes towards the abilities of deaf students to learn.

The XO offers a vast potential for communication in a native sign language via a built-in webcam, combined with an icon-based interface...

For people with cognitive impairments

The Sugar user interface already addresses many of the needs of people with cognitive impairments. It has very limited use of text, and provides an uncluttered interface. However, there are a number of additional things we can do for folks with cognitive impairments:

  • Provide assistance with reading comprehension via context-sensitive word definitions (ideally of every piece of text on the screen)
  • Provide assistance with text composition via context-sensitive spelling lookup (ideally everywhere that text can be composed)
  • Provide assistance with text composition via context-sensitive synonyms and antonyms (ideally everywhere that text can be composed)
  • Provide reading assistance by optionally reading text aloud via text-to-speech, and further optionally highlighting the words as the are read, synchronized with speech (see TextHelp's Read & Write product family for an example of this from the Windows world, and see Planetread for a similar application for general literacy in India).
  • Provide the capability for teachers and therapists to [videos for parents] of interventions parents can do at home.

Statistics on cognitive impairments are very difficult to come by, as they include such a broad range of needs (e.g. we don't have statistics on things like dyslexia, which would be aided by optional text-to-speech). We do know that roughly 0.1% of the U.S. population either has "has mental retardation, developmental disability, Alzheimer's, or serious problem with confusion/forgetfulness". By our logic above, that works out to 1,000,000 target OLPC users. However, as noted, the number of people who would be aided by these features is far larger.

For people with speech (generation) impairments

There are a variety of conditions that impact someone's ability to speak intelligibly. These include disabilities that impact muscle control of the vocal chords, and various developmental disabilities. Here what would be most helpful is to use the OLPC as a communications device (think of Stephen Hawking). The formal names of this use are "Augmentative Communication" or "Speech Generating Device" (the latter is a U.S. health insurance term). What is needed for this use is:

  • A text-to-speech engine in the user's language (note: this is also needed for blind users)
  • A library of pre-recorded phrases
  • Typically a special "communication" program that allows the user to easily indicate phrases to be spoken
  • Typically a special input device (like a single switch or head mouse, or a special keyboard) so that a user with limited physical dexterity can indicate their choice of phrase

A good example of a powerful augmentative communication device is the tango!, or the line of products from DynaVox which are purpose-built hardware communications devices.

Roughly 0.1% of the U.S. population either has "difficulty having their speech understood". By our logic above, that works out to 1,000,000 target OLPC users.

Tasks toward making the OLPC accessible

  • We need to define what "accessibility" means in the OLPC context (this is primarily for Sugar, and would likely feed into some place like the Sugar accessibility design guidelines
  • We need to make the GNOME accessibility framework work on OLPC/Sugar, in order to support assistive technologies (right now we have ATK, but AT-SPI depends upon CORBA and Bonobo which are presently too big to fit comfortable in the OLPC hardware envelope). This might mean putting the existing AT-SPI infrastructure on a major diet, or it might mean moving to something like DBUS (which is attractive for other reasons)
  • We need to define & implement a handful of accessible themes for Sugar
  • We need to ensure that Sugar & all OLPC Activities (the concept of "application") implement ATK and work with AT
  • We need to ensure that Sugar & all OLPC Activities support these accessible themes (large print, high contrast, etc.)
  • We need to bring software AT to the platform
  • ...

Miscellaneous software ideas of interest

The following pages in this wiki may be of interest.

XOj in monochrome

Accessibility Computing Numerical Pointer

Sugar Labs

See http://wiki.sugarlabs.org/go/Features/Improved_Accessibility

Resources

Blindness resources

Deafness resources

Alternative Input Devices

Accessibility Common Room

merged from the old page by that name

Please raise issues of accessibility, perhaps seek a solution to a problem, perhaps suggest a solution to a problem.

See Also


This page needs clean-up and editing for coherence, clarity, and completeness.

Please improve this article if you can.

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Accessibility&oldid=233425"