Open Source is Good for Web Accessibility

The culture of IT organizations has profound effects on the quality of of software deployed and services delivered. Even problems that have clear technical solutions, like web accessibility are strongly affected by social characteristics of the organization. Open source communities provide a model for improving the quality of Web applications.


At the Illinois Web Accessibility Conference (http://webaccessibilityconference.illinois.edu/) I presented the idea that open source projects are good for web accessibility. I was not arguing the technical advantages of open source, rather that the shared attitudes and practices within successful open source projects, like Linux and Apache, are good models for how to iterate towards improved Web accessibility. OS community dynamics enable open discussion of software quality and interface design, among other topics, and eventually, someone with an interest or stake in accessibility will start the discussion and lead efforts towards solutions that eventually find their way into the core code.

So, my goal was to make the point that fixing Web accessibility is equal parts technology and culture. The cultural effects are often not an agenda item at gathering of developers, so this was a rare opportunity to inject a little surprise into a technology-focused conference.

I hit the target. The importance of the developer/integrator communities participating in these large and successful open source projects is underappreciated. That's amazing to me, since engaged communities are the very reason open source is successful. It's the same in our institutions. Deeper engagement of creative and development staff will not only improve chances of project success, but will ultimately contribute to improving the user experience - including accessibility. I know this from my own work with WebLion and Plone.

Here's how it works: Say developers in a university software shop are customizing and deploying an open source Web application. One of their requirements is they want to add ARIA landmark data to the template markup to support staff and students using screen readers. The team is routinely collaborating with the open source community and follows OS development good practices for sharing code. Changes are stored the their code repository and documented in the project's ticketing system. The project team and open source community discuss implementation, code and the user interface. A champion of the ARIA implementation emerges from the open source community, the changes enter into new releases, and thereby are deployed to the worldwide user base. Mission complete; the developers have integrated new accessibility features in a software product that is used worldwide.

But here's how it's more often done: The Department of Old Patterns has some developers that decided to replace their home-rolled CMS in favor of a popular open source CMS. They know they can customize the code to suit their special needs, including adding a roughly similar ARIA implementation in the templates. In a building on the other side of the street, developers in Another Department decide to use the same CMS, and apply similar modifications. Sadly, their duplicate efforts will waste resources, the modified (and probably flawed) code is landlocked on developer hard drives, never to be shared.

That was the message that resonated with the conference attendees. Not only is a siloed organization inefficient, but they are a real barrier to progress. Web accessibility is a social problem as well as a technical problem. Look to the collaborative development model of open source for real progress.