in your distribution
Some feedback from Debian
Slides & stuff on http://brl.thefreecat.org/
● Introduction to accessibility
● Software interfaces
Color blindness: 8
% male, 0.5% female
Color blindness: 8
% male, 0.5% female
What is accessibility?
Usable by people with specific needs
● Cognition (dyslexia, attention
● Low vision
disorder, memory, ...)
● Motor disability (Parkinson, ...)
See Accessibility HOWTOs
“Handicap” depends on the situation
and is not necessarily permanent
10% handicapped – 20% limited
● Braille input/output
● Speech synthesis
– Basically replace mouse
● Press button
– On-screen virtual keyboard
Don't focus on one technology
Even for a given disability
● Braille is not perfect
– A lot of blind people can't read brail e
– Braille devices are very expensive (several k€)
● Speech synthesis is not perfect
– Noisy environments
– Tedious for spelling issues
Piezo braille cell
● Usually 8 dots ~= one character
● Piezoelectric effect to move up/down
● Serial, USB, bluetooth connection
● 12 / 20 / 40 / 80 cells, price ~= 150*n €
Why making GUI accessible?
(when textmode seems so easier to make
● A lot of stuff is not available in textmode
● Business applications
● Non-tech people need to get help from non-
tech people around
● e.g. edbrowse, a blind-oriented editor/browser
● Generally a bad idea!
– Oriented to just one disability
– Lack of manpower
● e.g. Web browser
● e.g. An office suite
– MSOffice/OpenOffice compatibility?
– Disabled & non-disabled working together
● Better use the same software
➔ Better make existing applications accessible
● Same software, made accessible
– Understand each other, get help, etc.
● Synchronized work
– Just alternate input/output
– Being able to work together
– Shouldn't have to ask for software installation /
Status in a few words
● Text mode is generally quite well accessible
– But not so well suited to beginners
● Gnome quite accessible
– Gnome 3 was however almost a restart-from-
● We're late compared to the Windows world
– We started less than a dozen years ago
– They started a couple of decades ago
● We're Stone Age compared to the Apple world
– Really good and integrated support
X accessibility, AT-SPI
braille, speech, ...
– Vertical container
● Menu bar
– File Menu
Open Menu Item
● Horizontal container
– Text area
– Ok button
● A lot of applications are already technically
– KDE-Qt4/5 (“Real Soon Now”)
– Acrobat Reader
● A lot are not
– Self-drawn (e.g. xpdf)
● Usually work really great for braille output
● Always provide such equivalent of graphical
applications, e.g. based on same shared lib
– Useful for servers via ssh too!
● The default output of screen readers is what the
cursor is on
– Works great with shell, editor, etc.
– Doesn't work so great with semigraphical apps
➔ Put the cursor appropriately!
– Even when invisible, e.g. mutt, aumix
● Design your application without gui in mind first
– Logical order, just like CSS ☺
● Use standard widgets
– e.g. labeled text fields
– Avoid homemade widgets, or else implement atk
yourself for them
– Always provide alternative textual content for
● Keep it simple!
– Not only to make s
creen reading easier, but to 60
make life easier for all users too!
This is all about freedom #0
“The freedom to run the program, for any
What about being able to use the program?
● RMS said a11y was just a “desirable feature”.
– “Desirable” only, really?
● RMS said “this is free software, you can modify
it” (freedom #1)
– Can. Not. Happen.
Why is accessibility so hard?
● Vint Cerf asked in Communications of the ACM
“Why is accessibility so hard?”
Issues are mostly not technical, actually
A question of priority
● Should be prioritized
– Just like internationalization
A question of who doing it
● Concerns only a small fraction of population
– Already a hard time using computers...
– Almost nobody with both disabilities and
programming skil s
– Almost nobody with awareness and
programming skil s either
→ “This is free software, you can modify it”
can not work.
● Support has to be integrated
– Distributed among maintainers themselves
– Not borne by the tiny a11y community
specialized distribution trap
There shouldn't be specialized distributions
● Accessibility is orthogonal to any other concern
– It's orthogonal to blends and tasks
– Users should be able to choose blend&task
● All (music, medecine, teaching, …) distributions
should be accessible
● Specialized distros tend to be specific
● Specialized distros are interesting testbeds,
● Using a computer at the library, the airport, the
university practice room, etc.
– First ask admin to install & configure
→ Installed by default, ready for use
– Requires very close integration
– E.g. support in Debian Installer
So, what to do?
Installation, configuration, ...
A plethora of software, often text equivalents
ogg123, mc, o3tohtml...
Please continue packaging those!
Brltty, AT-SPI, Orca, ...
Make sure that it works
● In textmode
– readers access VT & soundcard, before login
– they simulate keypresses
In both dm then “joe” user GUI session
● at-spi-bus-launcher, at-spi2-registryd running as
the proper user (dm then joe)
● session dbus gives user's AT-SPI bus address:
dbussend session dest=org.a11y.Bus printreply
● and xprop root AT_SPI_BUS returns it
● “accerciser” tool seeing applications
● Orca runs and speaks
It needs to be enabled!
● GTK3 schema
gsettings get org.gnome.desktop.a11y.applications screen
gsettings get org.mate.interface accessibility
Xfconfquery c xfce4session p StartAssistiveTechnologies
Some applications need more
● GTK2: libgail module
● KDE4: qt-at-spi plugin
● Open/LibreOffice: GTK frontend
● Java: Java-atk-wrapper
– problem with multi-threading :(
● Typing from braille device: xbrlapi
● 32bit apps: 32bit equivalents!
How to bootstrap?
How to bootstrap?
Entering a cyber café, how to access computers?
– USB braille devices
– Existing: XAccess (standard shortcut), Compiz
– Speech synthesis?
● Accessibility panel
– Needs to be accessible itself!
How to bootstrap? (2)
Accessibility installed by default
● You never know who will need it
– At home
– At workplace
– At library
● Ready to be easily enabled
● GPII: e.g. a USB key with a config file
How to bootstrap? (3)
Brand new computer, let's install Linux!
● Same issues and potential solutions
● Nowadays: “accessible” installation CDs
– e.g. start speech synthesis by default
● But all installation CDs should be accessible!
– Including e.g. all Debian forks for various uses
● Debian installer
– USB braille auto-detection
– High contrast or hardware speech by hand
– Software speech synthesis (s <enter>)
Details available on http://brl.thefreecat.org/
● Switch to text mode
– and run brltty (udev script) or speakup
● Graphical accessibility
– AT-SPI & Orca
● Color themes
● Enable same accessibility features at reboot!
● Being able to pass parameters for tuning them
– Kernel cmdline or preseed
Has to be testable
By all maintainers
● Debian installer: wiki page documents testing
● Part of the regression tests
● No need for specific hardware
– Qemu has virtual braille device
What about the bootloader?
Mostly not accessible nowadays, but improving
● Beep to tell that the menu is shown (done)
● Keyboard shortcuts (done)
● Beep to tell which item is selected
● Pre-synthesized ogg files saying entries
– Sound drivers in the bootloader!?
● Screen reader
– For the core, just another alternative terminal
● Take users suggestions into consideration
– E.g. bracketed links in text web browsers
● Be patient with disabled people
– It's not easy for them to use your software
– It's even more difficult for them to explain their
problems in an understandable way
● e.g. “brail e doesn't fol ow”
About bugs (2)
● Try to keep in mind their disability and their
– Yes, blind users don't care that the framebuffer
doesn't show up properly!
● You could even contact your local institutes for
disabled people, to discuss directly with users
More general ideas
Getting people involved
Subscribe to foo-accessibility
Make sure yourdistrib.org is accessible
Add an “accessibility” chapter to the installation
Add an “accessibility” chapter the Maintainers'
Add an “accessibility” tag to bugs
Cc-ed to foo-accessibility
Foo-accessibility mailing list
● Good to centralize user knowledge
● Shouldn't become a “side-park”
– Discussions should happen on main lists
– Cc foo-accessibility
Discussing is essential
● Find compromises so it can be mainstream
● Involve other maintainers
● Quite a few of your distribution users need
● Right from the start
– Yes, blind people do reinstall their PC at 2am
– No, they don't necessarily have a sighted
sibling near them at 2am either :)
● In any situation
– Library, practice rooms, etc.
● Please help us making accessibility