Accessibility in Agile Transformational Practices

In a lot of ways, accessibility is talked about and practiced as if it is a hydra dragon. Every time you think you’ve made an improvement, you cut off one head of the accessibility dragon and two heads grow back. In particular, there are a lot of myths out there that you can’t do accessibility in an agile development environment.

A lot of that stems from accessibility being thought of something you do manually, and also often only as user acceptance testing or usability testing. And while that’s an important part of accessibility, there is much more you can do to integrate accessibility into your agile processes to produce accessible products. Below, we will cover these agile accessibility transformational practices.

Agile Transformation

This is a very trendy term in the development communities. A lot of you have been through this or the even more trendy term, “digital transformation.” An organization that has been through an agile transformation will know that it is a change process that needs to be actively managed. The same approach is often not taken with accessibility.

A lot of the times when I talk to people and ask them whether they do accessibility, they will say “yes, we do accessibility”. I then ask them how they manage that and quite often I hear something along the lines of: “oh we have it in our done statement to be WCAG 2.0 A and AA compliant, then we link it to the W3C website.” That’s all they do. The developers are supposed to learn accessibility on their own like they do most other aspects of software development, like React, automated testing or using a continuous integration system. With accessibility, this approach very rarely leads to success.

At the root of it, taking an organization from inaccessible to producing software that is accessible by default, is about managing the change. There is a change in processes, change in practices and change in skills at many levels of the organization.

Why is this change so difficult for organizations without active management? After all, developers don’t wake up in the morning saying “I am going to go to work and build a system that excludes 20% of the population!” Developers and development teams create inaccessible software because they don’t even know that it is something they need to pay attention to.

This is a sweeping generalization, but most developers come from backgrounds that don’t put them in contact with people with disabilities. This has been slowly changing as Google, Microsoft, and other big players start to care and highlight accessibility more, but it is still very common for developers to have zero working knowledge of how people with disabilities can use technology and what they have to do to support that.

Build a System of Empathy

The UX profession has built up a vast store of knowledge, based on experimentation and observation, that serves as a heuristic guide for UX and UI designers to design compelling, understandable applications that convey the information they are intended to convey. Technologies like eye tracking, click tracking and analytics give us all sorts of insight into user behavior. For people with disabilities, this information is largely missing. How does a blind user “scan” the page? How do they navigate? What constitutes “good design” for a screen reader?

Most developers don’t know what a screen reader is or how it is used and as they start to learn about them, the gears in their head start turning. Then when they start to realize that it exists, they need to learn how to design for it and how to implement it. This missing knowledge is the “empathy and skills gaps.”

The first step to motivation is to care. Organizations looking to create a sustainable accessibility program should systematically work to close this empathy gap as this will fuel the desire to close the skills gap.

At Deque, there are two things that we do quite often to promote empathy. The first thing is called an empathy lab. An empathy lab is a series of activities that simulate various types of disabilities. Once people go through these hands-on activities, designed to help them experience situations, somewhat akin to the result of a disability, they start to empathize and understand.

The second activity is to have a developer watch a user with a disability (for example a screen reader user with no mouse) use the software that the developer wrote. In my experience, there is nothing more powerful than watching someone struggle to use the system that you have invested countless hours, weeks and months creating. I have seen developers, march straight back to their work areas and start to fix some of the issues immediately.

If your organization institutes a program whereby activities like this are regularly scheduled as part of a regular empathy campaign, you’ll create a culture of caring about accessibility throughout the entire organization. Make sure to include executives in these events to reinforce management buy-in at all levels.

Accessibility Coaches

Why do professional athletes at the top of their games still have coaches? Roger Federer is arguably the best tennis player of all time, and yet he still has a coach. One reason athletes at the highest level have coaches and can profit from coaches is that the coach offers a different perspective that reveals blind-spots in the athlete’s own ability to see what is going on. If the coach also happens to be a really good tennis player, he/she can also help Roger improve his skills. So why don’t we have accessibility coaches for developers? At Deque, we think that you should. Accessibility coaches should be used while building the accessibility program, in a very similar way to how agile coaches are used during an agile transformation.

Accessibility coaches should work with the organization to set achievable milestones so teams can celebrate their successes while they work towards full accessibility. These milestones should be consistent across teams so they can compare against each other, creating some healthy competition. For example, Microsoft uses a term called “axe clean” as one milestone in the development of UI code. What this means is that the new UI code needs to have zero issues that can be found with the axe analysis engine. Setting a milestone of ensuring that all new UI code be axe-clean is a great first milestone on the journey to full accessibility. Once a team has achieved this for some period of time, celebrate! Then set the next milestone to build on top of that. A good next milestone might be full automated keyboard testing for all interactive functionality. Publish the milestones in advance so teams have the ability to over-achieve. The accessibility coach should also help to create a dashboard to measure the accessibility transformation.

Accessibility coaches can also performing accessibility spot checks on new UI functionality with the purpose of bringing these results back to the team to help identify areas of improvement. Sprint retrospectives are a good time to do this as it gives the team an opportunity to talk about the issues that were found, how they’re going to get better, look at their own metrics, and make changes in their processes and skills (an essential part of agile). These metrics and retrospectives are not intended to be a means of punishment and enforcement, rather, they should be used as a benchmarking tool to track progress and provide insight for improvement, which is key to agile philosophy.

TLDR: Summary of Accessibility Transformation Practices

By implementing these accessibility practices into your agile processes, agile teams can sustainably defeat the accessibility hydra dragon. Keep an eye out for a follow-up accessibility post, where we will cover accessibility as it relates to agile team practices.

Finally, let’s reiterate the agile transformational practices one last time:

1. Create a central team to manage the agile transformation and execute the remaining practices in this list
2. Execute an ongoing empathy program to drive and sustain motivation.
3. Curate and make available a set of high-quality learning resources and integrate some of these into standard onboarding.
4. Form a team of accessibility coaches to coach agile teams.
5. Create an accessibility dashboard to measure the progress of change and report to teams and executives