EOF - Consider Accessibility

How does Linux measure up for users with disabilities?

Is Linux accessible? In other words, how well does Linux work for persons with disabilities? The answer today depends, in great degree, on which disability we're talking about. However, several factors have begun driving Linux to become a friendlier environment for users who are persons with disabilities.

Perhaps the most fundamental factor spurring Linux toward a more cohesive response to the accessibility challenge is the Linux ethos itself. The communitarian values that undergird free and open-source software simply cannot tolerate the notion that Linux should exclude anyone. Doesn't everyone have the right to run the program? Isn't everyone free to study and improve the source? It goes against the grain to leave anyone out simply because they can't read text on a video display or press both the meta key and F1 simultaneously. Linux always has valued and encouraged active participation from its community of users. We pride ourselves that quality contributions, whether code or documentation, float to the top and become incorporated in the next release. And, indeed, much in Linux exemplifies accessibility. Unfortunately, it is generally incidental accessibility—a by-product of the fact that Linux is deeply rooted in ASCII on the one hand, and on Linux's stellar ability to accept input from most any kind of device on the other. Not that developers intentionally would exclude support for accessibility—it just hasn't been a design criterion in the code review process.

Another potent contributory factor is the emergence of laws and policies giving preferences to software and systems that are accessible. Chief among the examples of such factors is the legal mandate in the US government procurement known as Section 508. This recently strengthened US law requires the US government to procure accessible “electronic and information technology” for use in the federal workplace and in systems that provide information and services electronically to the public if accessible technology is commercially available. Section 508 has expanded interest in accessibility greatly simply because the US government is a big IT customer, currently spending about $40 billion annually on technology—a number expected to grow by 50% in merely five years. Clearly, most vendors that bundle Linux products and services might find Uncle Sam a customer to court. Coupled with the high esteem Linux people have for Linux communitarian values, it rankles one to think that Linux itself might, just might, not measure up against this social performance yardstick.

Over the past few years several developers, funded principally by Sun Microsystems, but also by IBM, Red Hat and Ximian, among others, systematically have been putting the new GNOME 2.0 desktop accessibility framework together. Frankly, it is hard to believe this would have happened had it not been for Section 508, but the benefits of these efforts will extend well beyond the US. The GNOME Accessibility web page (developer.gnome.org/projects/gap) is possibly the best current source of information, in a Linux context, of what constitutes accessibility and how it can be achieved.

However, we might summarize accessibility as an I/O issue. The fundamental problem, though varied and complex in its myriad permutations, is simple. For every way by which a computer can accept input from a human user, there is someone who can't do things that way. Likewise, for every output modality intended for human consumption, there are users who cannot accept that particular medium as input. So, the challenge, the subject of articles to come, is simply how we get this intrinsically binary instrument to accept input from whatever device might be needed. And, how do we reformat and re-purpose output to encompass the rest of the user base?

The ethical imperative is clear. The software commons must be for everyone if it is to be a true commons. Even those whose software isn't directly related to providing interface support to users with disabilities must help, at some point and in some manner, to make their applications work for the widest possible user base. It is indeed possible this demand will prove disruptive in some areas. For the most part, however, it should prove minimally invasive, simply because of the socketed nature of Linux. Clearly, much of the work will be performed by specialists, because there is a good deal of specialized knowledge involved in getting solutions that work well. Ultimately, of course, the various communities of users with disabilities will determine for themselves how to do things. But, what they will want to do are the same things the rest of us want to do—which takes us back full circle to the communitarian ethos.

Janina Sajka is the director of Technology Research and Development, at the American Foundation for the Blind (AFB).



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I wish contact Janina

Toni from FOCUS's picture

Hi, Janina, I met you in open source world conference in Málaga, Spain. Do you remember me? I took every morning early to the conference, I was very pleased to met a woman like you.
Then, I has no time to attend you as I wanted, cause I has to attend voluntiers. Now I,m the president of Focus, do you remember? I gave you a T-shirt with our name :-)
In this summer, we have a conference at Sevilla's University Pablo de Olavide, I would be very happy having you in Spain this days, so I expect you to be here. It would be very interesting for Spanish woman, and blinds, and everybody else.
Thank you very much, Janina.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot