Accessibility and Open Source

Open Source projects can improve adoption and spread the “accessibility love” if they make their base code work for people with disabilities. Contributors can help.

More and more companies are either consuming or producing open source software. However, very few of them are thinking about accessibility. That creates a problem for both the producers (people making open source) and consumers (people using open source)

Of the five most commonly cited issues associated with open source, two of them are directly related to accessibility:

• Underestimating cost of open source software
• Skimping on usability

Open Source Problem #1: Underestimating the cost

If your organization:

• wants a particular piece of open source software
• and the software isn’t accessible
• and your organization has accessibility obligations

THEN your organization’s only choice may be adapting the open source version to be accessible. That is the position that PayPal found themselves in with Bootstrap about five years ago. Paypal decided to make Bootstrap v3 accessible, then distributed their Bootstrap accessibility modifications back to the Bootstrap community to improve the experience for everyone. OK, so they did make it obvious that the Bootstrap accessibility additions were created by Paypal, rather than forking straight from the main Bootstrap project in Github. So, maybe there was a little bit of free advertising that motivated this decision. Regardless of the reasoning, it was in the spirit of open source for Paypal to make their accessibility changes available for the good of everyone. A lot of organizations that I have worked with (and those organization’s customers) have benefited from those extensions.

Open Source Problem #2 — Skimping on usability

Open Source folks are frequently creating stuff on a shoestring budget.

• Many open source contributors are students or have day jobs, increasing the chance that they don’t themselves have a significant disability.
• Lack of financial resources means chances of any significant level of rigorous, independent user research done is vanishingly close to zero.

and finally, if your open source project isn’t very usable, it is probably not very accessible either. Better usability generally makes for better accessibility as well.

Successful, Accessible Open Source Products

MySQL

MySQL has been accessible open source since early on in the days of Sun Microsystems. Now maintained by Oracle as part of the Sun acquisition, Oracle keeps the VPATs for all the different pieces of MySQL

Sakai

Sakai may be the most successful Open Source Learning Management System (LMS) that you have never heard of. It is used by 100,000 students at the University of Hawaii, as well as Duke, and Notre Dame.

OpenStack

Many large companies have integrated RedHat OpenStack into their products with accessibility obligations. RedHat even went through the expense of producing a Open Stack VPAT proving that it is Section 508 Compliant as of June 2018.

Design Systems (examples: Clarity, Lightning, Carbon)

VMware’s Clarity Design system, Salesforce Lightning design system and IBM’s Carbon design system have all been built with accessibility in mind.

Because design systems provide building blocks that are consumed by other systems, it is even more important that design systems provide accessibility-friendly components.

• If a component in a design system is inaccessible, that inaccessible behavior is likely to be carried into every system built using that component.
• If an accessible design system component is implemented in an accessible manner, that implemented component is much more likely to be accessible.

“Implemented in an accessible manner” is key to having an accessible end result. Design systems don’t know how any of their components will be used. Design systems can only provide the ability for the developer to specify the accessibility information. If the developers provide accessible information, then the end result should be good (but still should be tested).