The number of people with disabilities is about 16% of the overall population. This is a billion-customer opportunity. Software that is not written with the needs of people with visual, auditory, motor, and cognitive disabilities in mind blocks potential and current customers from using your products and services. Imagine what you would do to get 1.3 billion more customers … and if that’s not a compelling reason, how about the fact that, as of June 2025 under the European Accessibility Act, the EU will require covered software to be compliant with the EN 301 549 standard or face fines. This is a moment similar to when GDPR arrived, only aimed this time at ensuring that all people can access software in an accommodating manner.

Accessibility In Software Is A Repeat Of DevSecOps

Most development shops think about accessibility later in the development process — for example, by requesting an audit after the product is complete and in production. Sound familiar? It should, because it’s the same broken process that most DevOps shops went through when they began facing security requirements. Developers would write insecure code, they would send it to a security expert, that security expert would review and send back suggestions, the developer would rewrite the code, and the endless loop would carry all the way into production (where the very last stage was penetration testing). Most DevOps shops have moved on from those dark days and now embrace DevSecOps, the practice of developers writing secure code from the beginning, bolstered by static code analysis tools that can uncover security issues as soon as code is written. Accessibility testing offers the same potential for saving development time, improving time to market, and reducing the overall cost of delivering quality software that is accessible to all.

Accessibility Testing Is Just Another Form Of Shift-Left In The DevOps Lifecycle

Several vendors support static code analysis tools for accessibility. These tools can help developers uncover and fix accessibility issues early in the coding phase. It’s the same form of shift-left that DevOps engineers have been practicing with unit testing, functional testing, security testing, and performance testing. Accessibility testing is just another form of quality that fits directly into the shift-left paradigm. Shifting-left accessibility encourages you to:

  • Establish a foundation of awareness and empathy. Make the business case for accessibility so that IT leadership and all developers understand why it’s imperative for the organization to create accessible experiences. At the same time, bring accessibility to life by highlighting the human impact. Bring forward stories of customers who have been shut out by inaccessible experiences. Demonstrate what it’s like to use your software today with assistive technologies like screen readers. Once developers understand that the software is essentially “broken” for those users, it’s hard to unsee that.
  • Embed accessibility into component libraires. Make it easier for developers to build accessible experiences by ensuring that they’re working from accessible-ready building blocks. Double-check that components adhere to the Web Content Accessibility Guidelines (WCAG).
  • Enable developers with tools to test for accessibility. Teach developers how to test their code for common accessibility barriers using free tools such as the axe DevTools Chrome extension. Longer term, invest in a digital accessibility platform with deeper capabilities for embedding accessibility into each phase of development and make it part of your everyday development process by building automated linkages between DevOps tool chains and internal developer portals.

Let’s Connect

If you’re a client and would like to ask us questions or discuss how to embed accessibility into development at your organization, set up a conversation with us.