Creating accessibility systems to fix accessibility issues

When we first start to tackle accessibility work, it usually feels very urgent. It often happens because of a lawsuit, a legal ruling, or an industry trend. Teams get served a long list of accessibility issues, with or without guidance on how to fix them. And if they do fix the issues, what happens next? Do they wait for the next audit and do it all again?

This urgency tends to make accessibility work reactive instead of proactive. It’s suddenly an emergency—even if it’s actually been a problem forever.

This emergency approach isn’t sustainable for anyone, including accessibility specialists, product teams, and organizations as a whole. One common refrain to make this work easier is to start from scratch, when a new product is in development. But, this ideal state isn’t realistic for most organizations. Most aren’t starting from zero when it comes to doing accessibility work. They really do need to figure out how to test and address issues for products they’ve already released, while starting to do accessibility work for new products.

So what do we do? How do we make impactful accessibility change that better integrates into what we’re already doing? The answer is to create systems around accessibility work, instead of treating it like a barrier or a checkmark. Those systems will vary based on your organization, but one way to see if you’re moving in the right direction is to consider what types of activities you’re doing around accessibility work.

Continuous and episodic activities

Before we get into the weeds, let’s zoom out to talk about two types of change and the activities that go with them. Change and activities both tend to be mostly continuous or mostly episodic. The idea of activities being largely either continuous or episodic comes from organizational psychology and can help us think about where we are in our accessibility journey.

So what do “continuous” and “episodic” mean in this situation? The easiest way to talk about this is to talk about how these different types of activities impact us.

Continuous activities are part of a regular process or workflow. Since they smoothly fit into other things we do, they’re less disruptive to our work. For example, “continuous improvement” and “continuous integration” are both ideas a lot of organizations try to embrace. Instead of introducing one big change all at once, they introduce many small, iterative changes that add up over time. These little steps are all activities within that continuous change.

Episodic activities, on the other hand, are bigger changes that (hopefully) don’t happen too often. Since they aren’t part of our normal activities, they tend to interrupt and disrupt our usual workflows and processes. Episodic activities can be small things, like a one-off meeting you weren’t expecting that throws off your day.

Continuous activities are better for any work we do.

They also might be big things. A positive example of an episodic activity is a brand new product launch, or another expected interruption to your workflows. A negative example is a “code red” event that freezes your codebase. This often-unexpected event might grind all of your work to a halt and throw off your sprint, your month, or even your year.

In general, continuous activities are better for any work we do. They’re anticipated, easier to handle, and we usually have guidelines or rules for addressing them. Episodic activities that drag on and on, on the other hand, are often frustrating at best and can be disastrous at worst.

How this applies to accessibility work

So how do continuous and episodic change and activities apply to accessibility work? Well, the truth is that a lot of accessibility work is still episodic. It starts with an organization getting an (episodic) accessibility audit done because there’s a lawsuit (which is also episodic). It follows that the audit drops a ton of accessibility issues on teams (also episodic!). Teams often lack the training and time to address these issues properly and holistically, which in turn creates more friction, which creates more resistance, and so on, and so forth. Even if people do want to do the right thing and make their product more accessible (which is often the case!) this is an excruciating way to go about it.

What we want to do instead is to do accessibility work that integrates into our everyday work. Doing accessibility work, whether it’s fixing bugs or designing a new feature, needs to be just another part of what we do instead of a hurdle. To create this kind of continuous change, we have to create and maintain systems that support and enforce those changes. We have to ramp up accessibility activities so teams are able to learn and practice by making many small changes over time before it’s “too late” and we begin accessibility work under duress.

From “The Accessibility Operations Guidebook”

Making a system

How do we make a system? It might sound scary, but systems are just ways to make it easier for us to do things. You use systems all the time even if you don’t think about it that way. You probably have a system for managing your to-do list, for example, or telling the difference between which of your clothes are dirty, which ones are clean, and which ones are kind of in the middle. In the best case scenario, systems can contribute to habits, where we actually make it easier to do something than to not do it at all.

There are lots of tools designed to help us with managing systems and habits, too. For example, you might have an app on your phone that you use for your to-do list, and a certain chair that holds your designated “not clean enough or dirty enough” clothing pile. Systems don’t just come down to tools, though. Any system, including an accessibility system, isn’t just about tools, but about people. And people stuff is always going to be harder than tool stuff.

For a very concrete example, accessibility touches every role of a product team, and we can’t just rely on tools or checklists to do that work for us. Everyone needs to know a little and also understand how their responsibilities are all interconnected with others’.

• Program and project managers can set accessibility as a requirement to ship or integrate. But this isn’t effective unless the team is on board and prepared to do accessibility work on the regular.
• Designers can design for and document accessible interactions. But this won’t be effective if engineers don’t know what to do with that documentation.
• Engineers can use best practices for coding and do end-to-end accessibility testing. But this won’t be effective if they’re being given designs that are hard or impossible to make accessible.
• QA testers can use test cases and assistive tools that humans actually use in the wild. But this won’t be effective if engineers or designers don’t understand those tools or why they’re used, and by whom.

At the same time, accessibility work often reveals strengths and weaknesses in teams’ existing processes and workflows. For example, teams that struggle with using automated accessibility tools can be ones that already struggle with automated tooling. Teams that struggle to talk about accessibility across roles can often struggle to communicate in general. Accessibility work usually finds the cracks in systems, so we often end up doing accessibility work and also work to shore up or change those systems.

No matter what we’re doing, our goal (and the goal of our systems) should be to help us move from having mostly episodic activities to mostly continuous activities in our work.

Where to start

This all sounds complicated, because it is! But “complicated” doesn’t have to be “hard.” Here are some principles I’ve found useful for creating this type of change in accessibility work, along with systems to support that change. Remember, the goal here is to move from episodic (one-off) activities to continuous (consistent) activities, to build habits.

Take small steps and grow complexity gradually.

Adapt automation to fit

Use automated tooling first, but know what you’re going to do with the information it gives you. Automated tools can identify a lot of the accessibility errors that are easiest to correct. But they also might drown a team in a ton of tiny, minor, duplicate issues. Just as important as setting up a tool is having a process for dealing with what the tool finds. Do you want to fix every bug the tool detects? Or do you want to use it to identify hot spots or follow trends over time? Starting with many types of testing on day one is going to overwhelm and stress out everybody, so take small steps and grow complexity gradually.

For example, if you have a long list of audit issues and you’ve just set up a new automated tool, it can produce test results that match up to an audit issue and results that don’t (note that traditional accessibility tools usually only match up to a fraction of audit issues, you’ll need end-to-end tooling to change that). These new results usually represent new bugs that were missed in the audit. It’s tempting to add the new bugs to your list, but that may risk dragging out an already large episodic activity. Instead, you could temporarily silence the new bugs and use the tool to monitor progress on the audit issues. This also allows you to set a benchmark and introduce a continuous system to prevent backsliding, which happens when teams unintentionally create more bugs, even while fixing others. If, after a month of running the tool it detects a new bug, that can kick off a small iteration to immediately fix it. Over time, you can chip away at the temporarily silenced bugs to reduce disruption, and eventually reach a clean slate.

This will, of course, cause some friction up front as teams think through these issues. A new tool will always cause some resistance, but making sure the tool is easy to use and easy to interpret goes a long way. So be deliberate about what you test and when.

Make learning easy to apply in context

Make information relevant. Teaching to what teams are actually doing is way less disruptive than teaching in a vacuum. This does mean being thoughtful about how you’re teaching about accessibility. For example, if a team is working in React, your technical examples and recommendations should use React. If a team primarily works on forms, prioritize learning around form design, usability, and implementation.

Relevance also depends on what people might already know. It’s always best to start with accessibility basics that everyone on the team should know, and work up to more advanced learning that’s aimed at specific roles. This includes teaching the basics before sharing audit results. It’s much easier, and much less disruptive, to build on knowledge that everyone has when you’re working with ICs to fix specific problems.

This also means making information easy to find in the moment. This usually means not being too precious around where information lives. Find out where people do go as a part of their normal work and put learning materials there. You might want to design an elegant wiki all about accessibility, for example, but what if no one reads it? Maybe a better place for learning material is in a design system’s documentation, or in a handbook aimed at designers or developers. Make the information that people need the most appear in the places they are going to look for it.

Do no harm first

It’s important to remember that our accessibility systems impact users directly. Changes we make to our own processes and workflows should be in service of making our products better for the actual humans who depend on them. From an accessibility standpoint, that means avoiding harm as much as possible. It means prioritizing fixing and preventing accessibility issues that will harm users or block them from using the product. And that means teaching accessibility from the perspective of harm prevention and reduction, not as a zero sum game of passing or failing to meet WCAG 2.1 AA success criteria.

Accessibility work needs to be easier to do than not.

However, this also means doing no harm to the teams or individuals you’re trying to get on board. For example, if a design system team approaches accessibility review as a punishment for inaccessible designs or code, the product team might very well just work around the design system, which brings a whole host of its own problems.

Make it easier to do the work than not

To accomplish all of these other things, accessibility work needs to be easier to do than not. It needs to be embraced and rewarded! That is a lot easier to do if an organization actually prioritizes inclusion and accessibility as values in the first place. But here are some ways to demonstrate those values even if they’re not universal, and ease the way in the process. Think of these as a kind of minimum viable product (MVP) of accessibility systems, or work systems in general. Having these types of practices and strategies in place will make moving from stressful, episodic activities to expected, continuous activities easier.

• Senior individual contributors (ICs) normalize accessibility work by doing it themselves and learning along with everyone else. This means not taking it personally when you learn that you can always learn more!
• Individuals have enough knowledge and understanding to prevent major barriers or harm first. This means things like flashing graphics and autoplaying videos should get as much or more discussion and focus as things that often take up a lot of our time, like discussions about color contrast.
• People who are working at a systems level (like an accessibility team, design system team, or senior ICs who are reviewing work) can identify patterns in what teams are doing and how they are doing it. This means giving these folks enough bandwidth to actually do systems-level work, not just tack it on to the end of their day when they are too fried to think clearly.
• There is a process, workflow, or program in place that actually rewards experimentation and gradual, continuous improvement. This might come through a product health approach or a diversity, equity, and inclusion (DEI) approach, or another strategy that’s important to the organization. It may take the form of teams who are involved in accessibility work sharing what they’ve learned with a wider audience. Getting folks to reflect on and feel confident in their growth creates positive feedback, which further cements the work as just something folks do.

This means investing in three key pillars of this work: people, process, and knowledge. That’s going to look like many different things that depend a lot on your organization and where you are in your accessibility maturity and journey. It might mean working with a team to provide accessibility training, and collaborating with them to pilot changes to tooling, workflows, and documentation. Or it might mean consulting with your knowledge management team to identify the best internal resources to update, while working with your DEI team to develop a series of workshops to hash out issues around inclusivity in general. The specifics will vary based on you and your organization’s needs, but they’ll always impact the systems your organization relies on day in and day out to create any lasting change.

All in all, making accessibility work continuous and easier for everyone means leaning into your organization’s strengths, but also being aware of its weaknesses, and being okay with making many small changes over time, instead of one big change all at once. The result will be a more sustainable system and a healthier approach to accessibility as a whole, which is going to benefit everyone.

And if you liked this take, you might just like my book, The Accessibility Operations Guidebook, which is all about sticky problems like this one.

About the Author

Devon Persing is an accessibility consultant who focuses on accessibility operations and education. Before starting her career in digital accessibility, she worked in academic and research libraries, higher education, and social services. In these roles she focused on user experiences, user interfaces, and user education. She has been working as an accessibility specialist since 2012.

She has a BA in Creative Writing from Susquehanna University in Pennsylvania and an MS in Information from the University of Michigan, with a specialization in Library and Information Services.

You can learn more about her work at dpersing.com.