For software to be considered open source, it must not discriminate against any people, groups, or fields of endeavor. In other words, open source software must be available and accessible to all users, which includes people living with disabilities. In many ways, the open source community and technologists focused on accessibility are a natural pairing: The more accessible the product, the greater number of users benefit, and input from a diverse group of users is necessary to build a product that is truly accessible.
"A distinguishing feature of open source software versus proprietary software is that open source software tends to be used by a diverse community of users with different priorities, needs, use cases," says Greg Myers, support engineer at GitLab. "I personally feel the more diverse and inclusive that community is, the better the end product is."
Engineers that draw from the insights of the open source community when developing their software benefit from a broader set of inputs than those that work with a proprietary codebase. In many ways, the standards that define open source software overlap with the process of accessibility in software development.
"Accessibility aims to do the same thing, right? We want to make sure that as we're building software, we're building it with a diverse set of folks that are going to use it, and might want or need to use the technology in different ways," says Brendan O’Leary, senior developer evangelist at GitLab.
Everyone can contribute to open source software
The greatest strength of the open source software community is the level of collaboration among a global set of users. GitLab is an example of an open source software (OSS) product that is continually fortified by the contributions of our community. Since everyone can contribute to improving our product, our team is exposed to many different ideas and perspectives.
"We're doing well because everybody can contribute to our mission," says Greg. "If somebody has a feature request, a problem, or they find a bug – including if something's not accessible on our website, our documentation, or our software – they're invited to create an issue which will actually get passed along to our product team and get prioritized and acknowledged. Whereas that's not easily available in a lot of other companies and products."
Jeremy Elder says that his work as a senior product desiger on the UX team at GitLab has benefitted from community contributions aimed at making GitLab features more accessible.
At GitLab, we have a few different open source accessibility testing tools. We use Pa11y, an open source accessibility tool, to measure the accessibility of our website. We also built a simple CI job template that shares accessibility violations, warnings, and notices. One of the projects Brendan worked on before moving to the developer evangelist team was building the accessibility merge request widget, which creates an accessibility report.
"There's a lot that you can do with automated testing and there's a limit, but it's by examining those limits that I think we can continue to get better and improve," says Brendan. We will discuss accessibility testing more in an upcoming blog post.
How the OSS community can improve accessibility in software development
Despite these good intentions, when it comes to building technology that is accessible to all, the open source community sometimes falls short.
"We've been painting a pretty nice picture of the open source community, and having folks involved and contributing to accessibility," says Brendan. "But I also think that the inverse happens a lot in open source when a project is maybe not as mature or it's just starting out. And accessibility is one of many things that gets put on the backburner as an afterthought."
Accessibility is not an unsolved problem in software engineering. There are plenty of open source accessibility solutions out there, it’s just a matter of making accessibility a priority.
Jeremy mentions two ways the open source community can make accessibility more of a priority: prioritizing user experience and shifting accessibility left.
"I don't feel like there's enough visibility from a design and UX standpoint in open source," says Jeremy. One thing that is unique about GitLab is that design and code work closely together, he says, although this is not typical in many open source communities that are more focused on code than UX.
Oftentimes, when open source communities are building developer tools, they will focus less on user experience and more on code. The number of users that are able to access the software will be limited if accessible design is not prioritized.
"You still want to be thinking through, 'how is this going to be usable by people that may come at the problem differently', or have a different set of needs when they're using the tool," says Brendan.
Another opportunity for developers is to bring accessibility into the DevOps process early. Greg notes that the Linux community does a good job of ensuring accessibility features are available for all users.
"It doesn't seem to matter what distribution you run, there is a screen reader built-in and there are accessibility features included in Linux," says Greg.
In a popular blog post on Opensource.com, Linux user Spencer Hunley shares six reasons why people with disabilities should use Linux. One of those reasons is the ability to customize and modify Linux software to meet the needs of the user.
"Being able to take existing technology and adapt it to suit one's needs—rather than forcing a person to adapt to the device and/or software—is a strength of open source software and Linux, and is extremely important for those who rely on a device to accomplish what others take for granted every day," says Spencer.
The reality is, if accessibility testing were to be an assumed and automated component of the DevOps pipeline, it would be much easier to fix fundamental accessibility problems earlier in the development process.
Accessibility benefits everyone
One of the common misconceptions about accessibility is that it primarily benefits people with disabilities. In the United States, the 1990 Americans with Disability Act (ADA) lead to innovations like curb cuts, wheelchair ramps, and automatic doors, which were designed to help people with mobility issues navigate the physical world, but benefits everyone. Similarly, accessible software benefits users with different abilities as well as non-disabled users. While building software that complies with laws like the ADA for Accessible Design is legally mandated, accessibility is also about making software adaptable to meet the preferences of different users. For example, some users might prefer to use keyboard enhancements so they can work faster, or they prefer to use different shortcuts or quick actions to develop in Web IDE.
In the context of software, inclusive design is really all about intentionally considering and meeting the needs of people with different abilities and workflow preferences — which results in a more accessible product. For software to be truly open source, it ought to be built with accessibility in mind so everyone can contribute.
Watch the video below to see our conversation about the overlap between the open source community and accessibility, and check back in with the blog to read more about accessibility.
"I'd love to hear more from anyone who's using open source web accessibility tooling," says Brendan. He invites GitLab users to share their ideas for improving accessibility features for our product by opening an issue in the www-gitlab-com project, and adding the accessibility label. Tag any one of the GitLab team members mentioned in this article and they will help triage the issue. If you have ideas for how to make GitLab more inclusive, open an issue today, and check out the resources Jeremy compiled to learn more about accessibility.
