Design is not simply skin deep, it interacts with deeper layers in software programs. And it is not just for people who point and click to use applications. It also affects people who cannot distinguish certain colours, who cannot use a mouse, who are confused by complex user interfaces, etc. What can designers and developers in open source projects do to make their software more accessible? What do they need to know about people with disabilities? What tools are available to help them? What are example projects that have worked to improve accessibility?
23. 23
1. Define “Accessible”
●
Web Content Accessibility Guidelines 2.0
●
European standard ETSI EN 301 549
●
ISO/IEC TR 13066-3:2012: IAccessible2
API
●
ISO 14289-1:2012: PDF for Universal
Accessibility (PDF/UA)
33. 34
Where is this being done?
●
Debian:
http://www.debian.org/devel/debian-
accessibility/
●
Gnome:
https://wiki.gnome.org/Accessibility
●
Mozilla:
https://developer.mozilla.org/en-
US/docs/Web/Accessibility
One of the groups I represent is Liberté #0 / Freedom #0, a fairly young association that promotes accessibility in free and open source software. The association’s wiki is available at http://liberte0.org/wiki/. The wiki is currently in French only, but there is also an English mailing list at http://sympa.liberte0.org/sympa/info/tech.
I also represent the European project Cloud4all, which is one of the projects that is contributing to the Global Public Inclusive Infrastructure or GPII. One of the goals of GPII is to make user interfaces adapt to the needs and preferences of the user. (More about this will be said in the second half of this presentation.)
Accessibility is usually defined as the extent to which products, devices, services or environments can be used by people with disabilities. Persons with disabilities are often seen as a niche market. Looking at a few statistics may confirm this idea …
Roughly 0.4% of the population is blind.
(Blind persons can use a screen reader to access a computer. A screen reader attempts to identify and interpret what is visible on the screen and output it as Braille or synthetic speech. The image shows a laptop resting on a Braille display. Braille displays are very expensive devices and not every blind person knows Braille, so many people simply use synthetic speech instead of Braille.)
Roughly 0.1% of the population is deaf.
(The screenshot show SignLinkStudio, a tool for signlinking, i.e. adding links directly into sign videos on the Web. See http://www.signlinkstudio.com/. People who were born deaf typically use a sign language as their native language.)
Image source:
http://www.signlinkstudio.com/en/index.php (copyright Ryerson University, The Canadian Hearing Society, ATRC, Signencode & Canadian Heritage).
Roughly 0.1% of the population cannot use their fingers. This can have a variety of reasons, such as missing limbs, extreme tremor, quadriplegia, muscular dystrophy, multiple sclerosis (MS) or amyotrophic lateral sclerosis (ALS). The theoretical physicist Stephen Hawking has been paralysed by ALS. A recent article in Wired describes his assistive technologies: he uses an on-screen keyboard, word predction software and a “cheek switch”.
See “Giving Stephen Hawking a Voice”, Wired, 2 Dec. 2014.
The animation on the right shows how scanning an on-screen keyboard works.
Image sources:
https://archive.org/details/200804210005HQ (public domain)
https://commons.wikimedia.org/wiki/File:AnimatedTyping_by_ScanningExample.gif (CC-BY-SA 3.0)
At least 1% of the population is dyslexic (estimations vary greatly).
Image source: https://commons.wikimedia.org/wiki/File:Europe_population_over_65.png (public domain, based on materials that originally came from the United States Central Intelligence Agency's World Factbook). Image used in https://en.wikipedia.org/wiki/Ageing_of_Europe.
Image source: https://commons.wikimedia.org/wiki/File:Percentage_of_the_World_Population_Over_65_-_1950-2050.png (CC-BY 3.0; source: UN World Population Prospect, 2008.)
60 or 65 years of age may seem a long time in the future for many of us, but we will reach that age and by likely to be faced with one or more of the impairments on the previous slides. For this reason, practicing accessible design is also designing for our future selves.
Accessibility can be thought of as the outcome of several steps or components as defined in the Open Accessibility Framework (OAF). The concept of the OAF was formulated by Peter Korn during the AEGIS project (2008-2012, http://www.aegis-project.eu/).
See also https://www.youtube.com/watch?v=X8miIhqQ3MU and https://en.wikipedia.org/wiki/Computer_accessibility#Open_Accessibility_Framework.
Quoted from https://en.wikipedia.org/wiki/Computer_accessibility#Open_Accessibility_Framework
The “creation” steps describe the necessary precursors and building blocks to enable developers to create accessible applications and products. They are:
Define what “accessible” means for the platform: It must be clear what is meant by “accessible” because this will differ according to the modality and capabilities of each platform. The definition may include accessibility features such as tabbing navigation, theming, and an accessibility API.
Provide accessible stock user interface elements: Pre-built “stock” user interface elements, used by application developers and authoring tools, must be implemented to make use of the accessibility features of the platform.
Provide authoring tools that support accessibility: The tools used by application developers and content authors must be implemented to encourage use of the accessibility features of the platform. This may include features such as encouraging the use of accessible stock user interface elements, prompting for information required to properly implement an accessibility API, and accessibility evaluation and repair tools.
Quoted from https://en.wikipedia.org/wiki/Computer_accessibility#Open_Accessibility_Framework
The “use” steps describe what is necessary in the computing environment in which these accessible applications will run. They are:
Provide platform support: Computing platforms must properly implement the accessibility features that are specified in their accessibility definition. For example, the accessibility API definitions must, in fact, be implemented correctly in the program code.
Provide accessible application software: Accessible applications must actually be available for the platform. These applications must support the accessibility features of the platform. This may have been achieved using the accessible stock elements and authoring tools that support accessibility.
Provide assistive technologies: Assistive technologies (e.g. screen readers, screen magnifiers, voice input, adapted keyboards) must actually be available for the platform.