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).
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- RSS Feeds
- It is quiet helping
52 min 44 sec ago
1 hour 9 min ago
- Reachli - Amplifying your
2 hours 26 min ago
3 hours 14 min ago
- good point!
3 hours 17 min ago
- Varnish works!
3 hours 26 min ago
- Reply to comment | Linux Journal
3 hours 56 min ago
- Reply to comment | Linux Journal
6 hours 22 min ago
- Reply to comment | Linux Journal
10 hours 22 min ago
- Yeah, user namespaces are
11 hours 38 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?