Making open source software accessible to all
Why open source needs accessibility standards
Image by :
opensource.com
As the user base of open source software continues to grow, developers have the responsibility of making their software accessible to all potential users, including people with disabilities. While programs designed specifically to provide accessibility exist in the development sphere of open source software, most applications have little to no native accessibility support.
A definitive step forward in improving the convenience of open source software is to consider a wider variety of input and output peripherals available to potential users. While developing a program for use with a mouse, keyboard, and computer monitor is an obvious standard, user experience designers need to look at less conventional methods of hardware interaction. Designing an application with the intent of the user employing a screen reader requires an entirely different development procedure and focus.
In Remote usability evaluations with disabled people, Helen Petrie reasons that many developers have little experience with peripherals employed by those who are disabled, and thus do not have a theoretical framework available to assist in developing for such technology. However, with exposure to assistive technologies, it is possible for designers to be more inclusive and aware of issues with the relative technology.
In Reframing accessibility for the web, Anne Gibson suggests software developers and quality assurance teams use a test matrix pertaining to numerous input and output peripherals to help regulate accessibility testing. There are numerous procedures that allow for this.
For example, the guidelines and standards for a quality assurance team's design review can be modified to more broadly encompass accessibility issues. In doing so, usability testing becomes an aspect of ordinary testing practices, which results in consistent scrutiny for accessibility issues (as well as normalizing concepts around computer and web accessibility) at the cost of potentially inhibiting the speed of the overall development.
Another prospective (and less time consuming) approach to testing assistive software is to utilize automated accessibility checking tools. While this reduces pressure on team members to spend excessive time in the testing phase, complications also affect this method of testing.
This approach marginalizes the importance of making familiar and understanding computer accessibility concerns, and also reduces effectiveness of the testing process considerably. In The evaluation of accessibility, usability and user experience, Nigel Bevan writes, "Although [automated accessibility checking tools] are useful for screening for basic problems, they only test a very limited scope of usability issues."
A core tenet of the free software movement is to enable every computer user to cooperate and contribute as equals. Improving the accessibility standards at which open source software is developed not only progresses the fundamental concepts behind this philosophy, it further legitimizes open source developers’ place in the software development community.
Providing users with accessibility options widens the potential audience of the software, and should exist as a common practice in all software design and production.
About the author
15 Comments
Hi Shaun,
Thanks for the great article,
I fully agree with you on the importance of making Accessibility a priority when developing and maintaining open source projects. Making the software accessible to everyone, is not only aligned with the values of the Free and Open Source, it is also a good engineering and business practice.
Thanks for raising awareness about this topic.
Thanks for the comment! I really appreciate the feedback.
I would have to second that comment, making software that is both accessible and meets the needs of the user is not as common place as it should be. Props to you for highlighting this as it relates to Open Source, which will eventually raise awareness as a whole. The issue though isn't limited to application development of client / server or client side applications, it's a fundamental flaw in our thinking. We believe that everyone should do as we do and at deep brain level that can be seen extending to our abilities.
You mention in your article as an example, a Q/A team could increase its scope to test more advanced accessibility requirements, do you have any examples of some of those requirements?
I am aware that groups such as WAI (http://www.w3.org/WAI/) are working hard to create similar standards and objectives from an Internet purview; however I'd be interested in your thoughts from a more localized software perspective.
Thanks for the kind words!
In regards to your question, some accessibility requirements that could be tested for generally include less common hardware, such as eye trackers or Braille embossers. Of course, I recognise this is no easy task, especially when it is uncommon for developers to have access to these devices (outside of them actually requiring the hardware themselves), but as open source development improves, developers should become more aware about improving the accessibility of their software.
The WAI are really forward thinking in regards to their guidelines for accessibility standards. They have awesome pre-existing frameworks for web developers who are interested in making their sites accessible. However, while this information provides a good starting point for software developers, I believe the overall process of producing similarly accessible applications is more difficult. This doesn’t mean it shouldn’t be done though!
Thank you for bringing this up. I have only limited use of one hand and struggled after Ubuntu moved away from the old Gnome - which had an easy to use sticky keys plugin that highlighted when it was in use. Thankfully MATE supports this fully but I worry that as the years pass as new desktop environments evolve I will be left behind again. It seems like a trivial thing to most people, but without it I cannot type very well.
I’m sorry to hear that. It’s a shame to see some of the distributions stepping backwards in terms of accessibility. I think it’s important to expose developers to these ideas in order to encourage more effort by individuals and companies both to create more accessible software.
Thanks for bringing up this issue. I was hoping the article was going to highilght some proposed standards and those working towards this, things like standardised text to speech engines like SpeechHub. There are some accessible computing projects like Sonar linux around - but there is much work to be done. There's a good podcast episode which introduces the topic of accessible computing using linux -- http://goinglinux.com/shownotes.html#glp256 also Episode 259.
Vic
Thanks for the great link! I'll be sure to check it out.
Hi, Shaun.
An excellent brief article, highlighting the issues that need to be addressed. I know this needs a coordinated response to the problem, but I wonder whether it would be a good start, for people to raise a bug against the top distributions? A table of the top distributions can be found at the right of Distrowatch's home page (http://distrowatch.com/).
Perhaps the bug could be something along the lines of 'To be an inclusive distribution, needs to assess whether it meets the needs of users with different abilities'. The detail could then follow, in the main body of the bug.
Cheers,
Chris.
I think reporting accessibility problems as software bugs is an excellent re-framing of the overarching issue. If developers begin to see accessibility failings as bad code instead of an unnecessary hassle they have to deal with, I believe the development sphere could swiftly learn to adopt more progressive policies in regards to these hurdles.
My quote above got stripped of some words; it should have read:
"To be an inclusive distribution, _Insert distro name_ needs to assess whether it meets the needs of users with different abilities"
Fingers crossed, this time.
Chris.
The nice thing about free/open software is that you can add the missing features yourself including accessibility features. That is not possible with proprietary software!
I support adding accessibility features to my code, but I don't feel it is my responsibility to try to add all of those features myself or worse try to anticipate all accessibility issues.
I write free software and I am living with multiple sclerosis so I appreciate accessibility!
I'm glad I came across this article. I've been trying to raise awareness of the issues blind people in particular face when trying to use linux. I've been running into largely the same issues as in this article. Little documentation, developers assuming someone else will do it, or expecting money to fix what they should've done right in the first place. This last one is very much the minority, but it does happen sometimes. I'm a member of this website, so I'm trying to spread the word that accessibility isn't black magic. It's not hard to make something accessible. What we really need are more developers who know how the process works, less whining about how much trouble it is, and more coding. The accessibility community is severely understaffed. The people who keep linux usable are usually so overworked they don't have much time for much else. And I'll just put this out there. Myself, I'm not sure about other people, when I reach outside the linux community for help, I'm apauled at the response from other blind users. It generally boils down to "why do you want to improve that? It'll nver get anywhere, just use xyz" Which is usually one of windows or osx. That's not helping anything. Do others suffer from this indifference as well? A bigger problem is standards for "open access" are often predicated around antiquated technology. To de-geek that, the DAISy, digital accessible information system standard is the best we currently have in the way of accessible books, whether that be newspapers, magazines, etc. The standard is immensely complicated, long, dry, and explicitly specifies non open source friendly i.e patent encumbered audio formats for the only two formats the standard supports. Specifically, mp3 and wav. It also specifies an optional drm mechanism, which is part of the standard just enough so that daisy playback software can recognize a "protected" book, but cannot parse it without the "key" Every blindness company has their own implementation of this scheme, and each is incompatible with the other. It's a mess, and unlikely to get anywhere, so long as blind organizations and agencies assume everyone will just use windows. This is the issue. Any standard that's built around enabling disabled people to better access things almost always ends up including an "optional" drm mechanism. This is done, as far as I can tell, to appease the companies who treat all disabled people as potential criminals. Thing is, the drm mechanism usually ends up getting used, windows only software is written, and once again us linux users are left in the lurch because, why would anyone help support linux? Goes the usual argument Sorry for the rant, but it makes me angry when I try to solve these problems, only to run into the same wall of "there's not enough insentive" and "just use windows".
I don't want to accidentally irritate any interested developers, so I'll expand on my last comment. When I first switched to linux back in august of 2011, I used a distribution called vinux. It was, and still is, a fantastic distribution for anyone who is visually impaired. A few months after I first started, we were preparing for a new release, but there was a problem, Console speech, that is, speech in the text console, rather than xorg graphical sessions, was broken, largely due to pulse audio. One of our developers offered to fix the problem, but at a catch. He wanted $500 total before he'd work on a fix. That, in itself might not have been an issue, but there were some unusual circumstances. The entire vinux community, developers included is blind. Most of us don't have a ton of money to spair. I myself found the prospect a bit of an insult. Pay money to fix an issue you should be willing to fix for free? That was my first experience with that kind of attitude. I've also run into developers who were willing to write special applications for us blind people, including daisy playback software, but at a price. Some of them want to leave it open source, but most of the ones I've come across want me to pay them to write it, and the resulting application will be closed source. The excuse is often, gotta make a living. I find this too, rather insulting. Would you charge a sighted person for the privilage of being able to crack the spine of his/her book or press the "read" button on their book reader? Of course not. That's pretty much what you're doing when you expect money for assistive applications. Should developers get paid for their work? absolutely. I've never said otherwise. This is a messy problem and I don't know how to solve it. The last thing I want is to imply that I expect everything done for free. I do expect that applications written for us are open source, whether that be for the blind, dyslexic, physically handicapped, etc. But I find the attitude of having to insentivize developers to work on applications a bit offputting. It's the equivalent of telling a sighted person, "I'm going to open a document." When they look at the screen, it's black. "huh?" "Oh, right. Forgot to tell you, it'll cost you $50 for me to turn the screen on so you can look at it. Can't help it, gotta make a living." Has anyone else run into this, or am I one of the only ones who seem upset by this?
This is a great reminder Shaun. As a Drupal Core Accessibility Maintainer, I definitely agree that all software need to pay more attention to accessibility. One big difference with open source software is that people with disabilities can be involved in the community and can have an important role in improving the code base. This involvement with people with disabilities probably had the greatest role in changing the culture within the Drupal community to embrace accessibility.