I have been developing open-source software now for over a decade and feel that community software is a really important concept for inclusive technology. With the rise of the Linux operating system and more importantly with the growth of the Internet, more people and companies have embraced a collaborative culture. The growth of do-it-yourself initiatives that allow creators to use, modify and distribute ideas is key to making technology fit a wider range of humanity.

My company, OpenConcept, has been developing open-source solutions for the Web for the last 15 years. We develop with a popular Content Management System (CMS) called Drupal. We decided to focus exclusively on Drupal development because of the increasing complexity in these tools and because we wanted to be able to contribute back to it. We have have made a number of significant improvements, but most importantly we were able to spearhead most of the accessibility improvements which Drupal has become known for.  

We saw an opportunity where we could help shape a corner of the Internet to make it more accessible by default. It has been a long-term investment in improving the technology that we use, but also an opportunity to gain a global reputation for our work to improve this CMS.

We learned about web accessibility as we went along and leveraged our knowledge of open-source communities to help shape Drupal 6, 7 and 8. As OpenConcept has become more involved in the world of web accessibility, it has become clear to me that there is a huge opportunity for people with interests in this area to more effectively shape the accessibility of the open-source software that they use and reduce the barriers faced by many users.

We have to remember that many aspects of Web Accessibility are complicated.  It is a constantly changing landscape which requires an ongoing effort to maintain. By educating the maintainers of the code about accessibility and bringing them onside about universal access we also help to create a culture that better understands and appreciates the challenges of web accessibility.

One of the first concepts to grapple with for non-techies is that most software is built with libraries of code. These software libraries are a collection of reusable components that help programmers build the required functionality (configuration data, documentation, pre-written code, etc.). Many of these libraries have not been evaluated for accessibility and when they are used, they cause problems. Users often do not know or care that a common code base is being used, they just care there is yet another website that does not allow them to access their content.

Drupal, WordPress, Joomla, jQuery, Bootstrap, AngularJS, Select2, Chosen and Suckerfish are just some examples of some of the common software libraries that have been used in websites you have visited.

With these libraries and thousands of others, if we can fix the problems at the source library, the results will spiral down, sometimes to millions of websites. Popular libraries are updated regularly, so there is an opportunity to fix not only new sites that are being built, but also sites that are being responsibly maintained.

With the growth of open-source tools on sites like GitHub, there is a real opportunity to identify bugs, educate the developers and find solutions that work better for everyone. In general, open-source communities are very receptive to ideas to improve their code base. The more popular something is, the more competing demands there are, but as is often the case, a small group of dedicated individuals can create a big change.

Open-source communities generally have open “issue queues” where people can identify bugs and also provide requests for improvements or new features. This element of transparency is really important, partly because you can usually search it to find out if the problem or idea has been submitted previously.  This goes a long ways in reducing the unknown unknowns that need to be managed.

This is important because it allows people to nudge issues.  Simply taking the time to say “yes, I experienced this too”, can have a real impact. The more people who speak out on an issue, the more likely it is to be addressed.

Most proprietary tools including screen readers like JAWS and VoiceOver, browsers like Internet Explorer or web collaboration tools like SharePoint do not have issue queues that are open to the public. Without this transparency it is hard to know if you are one of many with a problem or who would benefit from an improvement or new feature.

Ultimately though, words only go so far. Developers of all stripes want code that will help them quickly develop their projects. If people conscious of accessibility issues can write the code and create a patch to improve the library it can be much more easily incorporated by the project’s maintainers. Tools are available which allow people of most abilities to learn how to code, but it isn’t something that everyone will be good at. Learning to program takes time and learning to do so in a way which is universally accessible takes even more time. For some people it may be more effective to find people or organizations to partner with to build these patches and contribute them back.

Since these libraries have a very wide user base, responsible maintainers will want to have any contributed code reviewed to see that it does not introduce any bugs and also does what is intended. Most code maintainers will not have the skills to evaluate the patches as very few schools educate programmers about accessibility or usability issues. Having this new code tested by independent people who use Assistive Technology will provide more confidence for the maintainer that this change is indeed an improvement.  

Any change takes time. To influence a library will take a sustained effort.  Use of credible external resources like the World Wide Web Consortium (W3C) can help others understand that this is an industry best practice. In general if you can provide respected references to back up your position you are more likely to get people on board. Furthermore, if the competition is doing it, it can be a great incentive within a community.

As with any community, it is useful to nurture allies. Accessibility is an issue that everyone can get behind, but there are also going to be costs for the project team. Accessibility isn’t sexy, so it requires ongoing advocacy as it is inevitably adds complexity. It is common knowledge that the more accessibility issues included in the design stage, less remediation will be required after the development. Furthermore, if you know that the libraries you are using have already had extensive accessibility testing, then you can be more confident that an accessible implementation will be achievable within your budget.

There are subjective elements of web accessibility, but the vast majority of concerns are pretty definitive. There are hundreds, if not thousands of outdated guides on the Internet about web accessibility. Trying to find resources that address today’s technology is often a challenge.

I do hope that this introduction to how open-source software is developed is useful for whatever open-source tools you use in your life. Although we are always looking for more people in the Drupal Community who have experience with web accessibility, it is probably more useful to start with the open-source software libraries you presently use.