This Is The Way: A Phased Approach to Accessibility in the Development Lifecycle

In the web development community, accessibility has a bad reputation for adding more overhead and time to the development process. With almost all the development world being agile, this has left accessibility out of the “Minimum Viable Product” (MVP), and left it behind as “defects” or a “nice to have”.  Some companies have even turned to the fact that accessibility will NEVER be a part of their development process and decided to use an overlay to try and make their site “accessible”.

In the words of Obi-Wan Kenobi, “Only a Sith deals in absolutes”. The same goes with development teams and accessibility. There is no absolute solution that will add accessibility into the development process in one sprint. There is not one single line of code that will fix all your accessibility issues. However, you can add accessibility as part of the development process in small increments, which will eventually create a well-oiled and agile accessibility process within your development team!

Adding Accessibility into the Development Process

Accessibility is a journey. Including it into the daily development activity takes time and effort but will ultimately be the most effective way to build an accessible UI.

The best way to get accessibility fully shifted left into the web development process is to take a phased approach. By phasing in accessibility, you will slowly but surely be able to efficiently and effectively add the proper automation, training, and accessible coding standards needed to ensure your content is accessible when it is released to a test environment or production.

Phase One: Start Small with Automation

One easy way to start to get results daily from an accessibility standpoint is to use automation. It is true that while automation will catch around 57% of your total accessibility issues, it is also a great way to get your web developers thinking about accessibility in the content they create.

Using the free axe-Linter for VS Code in tandem with axe-core and axe-core powered tools, like the axe DevTools browser extension for testing allows your developers to get instant accessibility feedback as they develop, as well as after the content is fully rendered (unit testing, or integration testing). Axe-linter and axe-core’s goal is to not only give developers the means to identify the issues, but also to give guidance on how to fix the issues and teach them how to prevent it going forward. This creates accessibility-aware developers.

Developers can use axe-linter to catch accessibility bugs as they develop in Visual Studio Code. The axe-Linter will catch the most simple accessibility issues and give instant feedback as to how to fix it within the Integrated Development Environment (IDE). No rendered-out content needed– it just needs to be a JSX, HTML, Vue file and you can have it fully linted for accessibility issues.

On top of linting, you can use an axe-core integration in your UI automated tests or the axe DevTools browser extension. This allows you to fully bake out a test environment and test the content for accessibility issues. Both of these can catch up to 57.6% of accessibility issues by volume (SEE STUDY) and takes you above and beyond just linting the content. Now, a developer can create new content and check in their code. Then their teammate can come and pull down the latest changes, run the UI test cases on build (or scan the content using axe devtools extension), and get accessibility results as part of the testing.

This phase may take a sprint or two to get set up and fully working. However, once you have these items in place, your development team will begin to get accessibility results quickly and efficiently, while also learning about how to make their content accessible!

Phase Two: Accessibility Training

Once you have automation set up and being used successfully and your developers are starting to see the very simple accessibility issues they are catching, you can now begin to add in some training.

Accessibility training is needed so that developers and testers can get a better grasp of digital accessibility. Automation only goes so far, and there is so much more that goes into making accessible content.

Web accessibility training can help you develop a deeper understanding of how people with disabilities use and interact with your web application, as well as a better understanding of the standards for digital accessibility. Having the proper training can give your developers a wider viewport into why we need to make content accessible, different patterns for creating accessible widgets, and also how to use different assistive technologies in their daily development.

This training does not need to be hours a day or even hours a week. Simply setting 30 minutes a day for developers and testers to go through a couple of segments of training will vastly improve their knowledge base, without adding a lot of extra overhead to their daily work! Even the smallest amount of coursework daily can pay big dividends in the end.

Deque offers a wide variety of self-paced, online courses through Deque University which you can check out here: https://dequeuniversity.com/.

Phase Three: Add Accessible Coding Standards

One way to enforce the training your development teams have had is through setting accessible coding standards. These coding standards will help ensure that content created in pull requests and seen in code reviews meets the criteria set by your team for your web components or pages.

A lot of development teams currently have an “honor system” for automated tests and manual accessibility testing, in which the developer claims they completed the necessary steps to make their code accessible. However, that developer may have used ARIA incorrectly on their widget, when simple semantic HTML would have fixed the problem. This a recurring example of  why developers tend to continue to have issues and not see a downward trend in overall accessibility issues.

An example of an accessible coding standard would be simply instead of creating a button with <div> and <span>, making it required that they use a semantic <button>.

Example using ARIA and <div>:

<div role="button" onClick={this.handleClick}

onKeyPress={this.handleClick} tabindex="0">Click me!</div>

Example using semantic HTML <button>

<button onClick={this.handleClick}>Click me!</button>

Another example is modal focus management. When a modal opens up, where does focus go? The body of the modal, the heading text, the button? Seems like every site you go to nowadays has multiple different ways to do this. Creating a uniform pattern for your components can help maintain the same level of accessible content across your application.

Phase Four: Add Keyboard and Screen Reader Testing

The final phase is adding in keyboard and screen reader testing for each web component or page that your development team creates. Adding in proper keyboard and screen reader testing can help your team know that your content is as accessible as it potentially can be.

Yes, this will take more time than you want initially. This is why I always recommend this being last in the phase of adding accessibility into your development process. Proper keyboard and screen reader testing can take time to perfect, and usually requires more time to perform at first. However, if your goal as a development team is to ensure that your content is as accessible as it can be, then this phase is a must!

The ideal scenario for adding in keyboard and screen reader testing is to create a checklist of types of tests that the team must complete for their content before it can be merged and a Pull Request created. I have also seen the checks be completed by the team lead at the PR/Code Review, however, this is a little less efficient than having a developer do it as they create content.

Creating a list of checks can help alleviate the pain of trying to figure out what all to test for each page or component the developer is creating, and in turn helps speed up the process as well!

For more information on screen reader testing see the following:

• https://dequeuniversity.com/curriculum/courses/screenreaders
• https://accessibility.deque.com/live-webinar-introduction-to-screen-readers

For more information on keyboard testing see the following:

• https://dequeuniversity.com/tips/keyboard-accessible
• https://dequeuniversity.com/mac/keyboard-access-mac
• https://accessibility.deque.com/website-accessibility-checklist-download

In Summary

Adding accessibility into the development process isn’t an all-or-nothing flip of the switch. It simply has to be added in phases in order to ensure your development team can properly have accessibility as part of the development life cycle, and so that it isn’t overwhelming to them.

Does it take time and patience? In the words of Master Yoda, “Patience you must have, my young padawan”. Does it have to be in this order above? No way! You and your development team can pick the phases in the order that best fits your development team. But the payoff for practicing the above is developers who now can see the value of accessibility, ensure better HTML coding, and actually give a damn about the content they create!