Accessibility and Open Source
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 to adapt the open-source version to be accessible. That is the position that PayPal found itself 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.
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 ever 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 an 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).