28
Accessible Code Reviews
In the agile world that we live in, especially in web development, the race to get the latest design and new functionality out the door has historically left accessibility in the rearview mirror.
However, over the last few years there has been a major shift of getting accessibility as part of the day to day development process. Even though this trend is fantastic, it is still a rather new concept and one that can always be improved.
One way in which accessibility in the development process can be improved is through code reviews. A lot of development teams currently have an "honor system" for automated tests or manual accessibility testing, in which the developer claims they did those steps. Which is why they tend to continue to have issues and not see a downward trend.
Adding accessibility to a code review of any pull request that your development team creates has great benefits. But what makes an accessible code review? Let's go through some tips and tricks to add accessibility into your code reviews.
Automated testing has become one of the staples of shifting accessibility left in development process. Automated testing is most popular with axe-core in developers unit or integration test cases.
When a developer creates a new component, they then add a test case that checks if the component is accessible. If it comes back with any issues, they go back and fix them and look for green light on the test case.
This is great, however automated accessibility testing with axe-core can only catch around 40% of accessibility violations. This leaves a lot of room for the possibility of "tricking" automation into thinking the content is accessible. It also is only checking the HTML as is, and won't suggest changes to semantic HTML or enforce accessible coding patterns.
Speaking of semantic HTML, accessible code reviews can enforce the use of it!
Lets say a developer checks in code like this:
<div role="button" onClick={this.handleClick}
onKeyPress={this.handleClick} tabindex="0">Click me!</div>Is there anything wrong with this? Technically it is accessible. However, the use of non semantic HTML here makes it so the developer has written extra code to include both click AND keyboard event. Also, anytime role and tabindex are used, there comes the risk that a future developer may not be accessibility aware and remove them, and then keyboard functionality is totally lost.
This is where the enforcement of semantic HTML could explain the above, and suggest using a button like so:
<button onClick={this.handleClick}>Click me!</button>Any time you get the chance to use semantic HTML and enforce it the better. It reduces the risk of misused ARIA and cuts down on the creation of extra code.
Sometimes semantic HTML is not possible, and ARIA is required to make HTML widgets fully accessible. ARIA is widely used, but often time implemented incorrectly. The best time to ensure that ARIA is properly used is in a code review.
One ARIA issue that could easily be caught in a code review would be an incorrect or unnecessary value. Let's say code is checked in that has an aria-live value that is variable. The default of this variable is "off" when there is no text and then "assertive" when text appears. A code review could catch this and tell the developer it does this by default already, so they could have just used assertive.
<span aria-live="{{currentState}}">{{announcemetText}}</span>Another example would be using the same aria-labelledby id for a component that is used multiple times on a page.
<Fragment>
<label id="dataInputLabel" >{this.props.inputLabel}</label>
<input aria-labelledby="dataInputLabel"
className="form-control" id="dataInput"/>
</Fragment>These are just a couple of examples, in the literally hundreds of different ARIA misuses that could be caught in a code review.
Last but not least, code reviews can be used to enforce accessible coding patterns.
This sounds pretty self explanatory, however when I say to enforce accessible coding patterns I mean your development teams or companies coding patterns.
Let's take a modals focus management as an example. 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 now a days has multiple different ways to do this.
If you have an accessible coding pattern that is consistent, this can help make your site easier to navigate and understand for those with disabilities. This pattern can be easily enforced when looking at another developers pull request.
Now instead of having 3 different ways that modals could potentially deal with focus. You simply have one consistently across your entire site.
Accessible code reviews can greatly improve the accessibility of your web content. By following the simple steps laid out in this article, you can help make developers that are not only accessibility aware, but that actually care about the content they are creating. At the end of the day, that is the goal.
To create developers that give a damn about accessibility, and to do that it requires enforcement and proper accessible coding reviews!
28