EOF - Consider Accessibility
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).
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- Users, Permissions and Multitenant Sites
- New Products
- diff -u: What's New in Kernel Development