Accessibility in Agile Team Practices

Pause: Before we dive into the content, you may want to check out my first blog post on accessibility in agile transformational practices. In this post, we covered cultural accessibility practices that will lead your agile teams to create accessible content and applications in a sustainable way.

In this post, we’ll be diving into accessibility for agile team practices that will promote sustainable and effective accessibility throughout your software development lifecycle.

Accessibility Ultimately Starts with Design

Accessibility starts with design. One way design teams can achieve accessible designs is by using personas that have qualities of disabilities embedded into them. It is important to avoid creating personas that are just people with disabilities, instead, you should integrate disabilities into the personas you already have. When designers are creating designs and wireframes, they can then think about the possible additional steps the persona must take if an app or website is inaccessible.

Accessibility often creates a usability focal point that can lead to better designs for everyone, not just people with disabilities. For example, the City of Ottawa built an online map to illustrate the new boundaries of the city. They performed user research that included people who were blind and asked them why they wanted to use this map.

Their response was that they wanted to be able to search an address and determine whether it was within the confines of the new boundaries. The City then updated the map with this search function, making it more usable so that those who could view the map didn’t have to manually zoom in and struggle to determine what is and isn’t within the newly-proposed boundaries.

Once designers create an accessible design, they have done a lot of thinking about usability and accessibility. It is crucial that designers effectively communicate the intent of that design to the developers. Agile teams communicate in many different ways. Some teams use whiteboards with annotations and some teams do high fidelity design comps with annotations.

It doesn’t matter how you do it, but communicating the intent via annotations is very important. For example, below are widget annotations for a media player design:

Something as simple as a media toolbar can have many different interactions, alternative state interactions, and minimal control size annotations. These annotations should communicate what should be read out to a screen reader, how screen readers should control the widgets, how the role should be coded for in ARIA, etc.

There are many other accessibility annotations to consider, but what is most important is that the communication and intent are passed on from designer to developer because accessibility ultimately starts in design.

Debunking Accessibility Myths

Forming a culture around accessibility in agile teams requires debunking some myths around accessibility. Firstly, agile teams believe that accessibility testing cannot be automated. Secondly, agile teams believe that accessibility testing is usability testing.

At Deque, we know both of these myths to be untrue. Accessibility testing isn’t all manual, in fact, earlier in the post we touched on “axe clean” automated testing for agile teams. Running a browser extension or integrating this tool in an automated test is an easy step.

In fact, it’s a best practice that teams should not commit any code to a repo or complete pull requests for things that aren’t axe clean. Through our extensive research via audits, we have determined that automated accessibility covers about 25% of success criteria by WCAG and about 50% of accessibility issues by volume.

Although some things around accessibility must be validated manually, such as alt text, you can still write a simple unit or integration tests to check for alt text to serve as a reminder for developers. Furthermore, if you have the design information like we previously discussed, it’s easy to put accessibility requirements into a test. For example, the code below is testing the Deque logo and alt attribute associated with it:

<// Check the Deque Logo
ok(img.src.indexOf('logo.png' !== -1, 'image is the Deque logo image'));
equal(img.getAttribute('alt'), 'Deque Logo');>

Testing is ultimately about risk mitigation, so you need to figure out how often you want to retest things. Usually, this is when there is a major update released for screen readers.

Accessible Pattern Libraries

Using a pattern library may seem like an anti-agile methodology, in that you are designing code before you actually need it. However, there are different levels to how a pattern library can actually help you. Having a library that shows what an accessible component or widget looks like in various states is very valuable. These are things you can reuse regardless of which framework you are using. If you’d like to see what an accessibility pattern library looks like, checkout Cauldron, Deque’s accessible pattern library.

TLDR: Summary of Accessibility in Agile Team Practices

Agile and accessibility are not mutually exclusive terms. If your agile teams implement the practices above, they can continue their usual practices while also creating accessible and compliant software and websites, which will ultimately be more usable to all users. To reiterate, these team practices are:

• Breaking down the accessibility myths that accessibility cannot be automated and that accessibility only applies to usability.
• Knowing that accessibility starts in design; designers need to be intentional in their accessibility annotations.
• Reusing an accessible pattern library that is framework agnostic.