What is accessibility decay?
You’ve done everything right when it comes to accessibility. You prioritized accessibility as a quality gate in design and built everything according to specifications. Or you have completed an intensive accessibility testing phase and addressed all outstanding issues. Does that mean you’re done for good?
It certainly means that it will be easier to keep your site accessible if it remains a priority for you. However, accessibility is similar to security, SEO, and other such areas that require some routine maintenance and vigilance. In other words, your level of accessibility can decay without some discipline to maintain it at the required level.
Brushing is necessary but not sufficient
I was at the dentist last week suffering through the semi-annual cleaning and it struck me that it is a great metaphor for how to think about accessibility decay. The cleaning is not the most pleasant way to spend a half hour but if you brush and floss regularly, it’s not too bad. And if you don’t take care of your teeth, the checkup is only the beginning. You may have to come back for more intensive work like a cavity filling or worse.
Subscribe to our Newsletter
What causes accessibility decay?
Assuming that your site starts out accessible and can’t be frozen in amber, what causes accessibility decay?
The answer is simple: change.
Any changes you make to the site are opportunities for new accessibility bugs to be introduced. And to be more specific, we see three types of changes where accessibility is often not taken into consideration:
- Content creation and updates
- Routine maintenance and updates
- Time sensitive requests and projects
Content creation and updates
You can have the most accessible design system and well-optimized code, but in the end of the day, the actual content of the site is made by people. For example, in the course of creating a new page or post, marketing and editorial teams can encounter multiple content accessibility considerations including:
- Including descriptive alt text for images and media when appropriate
- Organization of the page hierarchy using the correct heading levels
- Avoiding generic link labels
- Building PDF content that is accessible and screen reader friendly
In addition, for most sites that operate at any sort of scale, it’s not feasible to review these in bulk for a manual audit. Even after addressing all technical issues identified in an audit, it’s almost a certainty that you’ll have a lot of content accessibility remediation ahead of you.
And that applies even when you are starting from an entirely clean slate. As new content is created and evergreen content is updated, it’s very easy for new accessibility issues to be introduced in the process.
Our recommendation
- As a first step, educate the teams responsible for content creation. Setting up a content accessibility training program and approval workflows for new content can help set a strong baseline of knowledge and expectations. In most sites, the pace of content creation is such that it should be possible to create a review process that incorporates accessibility checks before new content is published.
- But at scale, it is also helpful to set up sitewide monitoring and scans that can flag at least some issues as they arise and allow you to identify larger patterns that would benefit from further training.
- And finally, it’s always easier to find and address issues in smaller batches. Set up routine reviews monthly or quarterly to review, test, and remediate recent content batches.
Routine maintenance and updates
In the lifetime of a site, there are all sorts of small fixes and updates. Most of these are self-contained. But anyone with development experience knows that changes can introduce regressions and other unintended consequences when you least expect it. And that applies just as much to accessibility.
For example, a routine WordPress or plugin update can occasionally break your design or functionality. On our own site, we recently caught an issue associated with our forms plugin update that both broke the design and introduced a serious accessibility bug that needed to be resolved before we could deploy. For those using builder plugins or similar systems, updates can have a much wider impact.
Our recommendation
- Introduce manual regression testing in the areas where you expect an update might affect the accessibility or usability of a feature or component.
- When possible, it is also helpful to introduce automated regression testing including visual diffs, automatable accessibility scans, and accessibility testing as part of the continuous integration workflow (when relevant).
- Use passive sitewide monitoring and scans to flag potential issues that make it through
Time sensitive requests and projects
Every developer has had the experience of performing triage while working on a tight deadline. (Some would even refer to this system as a form of agile development!)
These scenarios can range from performing hotfixes to address newly discovered bugs after a release to hustling on a new feature or section to align with an immovable product launch or event. Sometimes this even happens when falling behind schedule on a regular project. And it’s not surprising that accessibility can be one of the things that slips or gets deprioritized.
To be clear, this is bad!
Accessibility should be baked into your processes from planning to launch for just this reason. When building to quality (including accessibility) becomes second nature, it need not add significant time to development. But when you are operating on a tight timeline, there are a lot of things that may not be ideal.
Our recommendation
- Just as with routine maintenance, introducing automated testing as part of your workflows can help flag at least some issues as they are introduced.
- If manual QA testing does get deprioritized for whatever reason, it is important to flag it for later. When the emergency is over, you can and should come back to clean things up. Knowing that a specific feature or section has not yet been tested for accessibility bugs means that you can schedule it as part of post-launch fixes or for an upcoming sprint.
You control whether decay builds up
One recurring theme in this essay is that accessibility testing and remediation is a form of quality assurance. It is rare for a website or piece of software to be completely bug free. There are steps that you can take to train teams and improve your processes to prevent or catch these issues at the source. But especially at scale, bugs will happen and some form of accessibility decay is likely. The strategies we discussed above should help with these specific scenarios but we can sum up our advice overall as follows:
- Automate as much as you can. Incorporating accessibility into existing automated testing can help find issues at the source and setting up automated sitewide scanning can ensure wider coverage at scale.
- Make time for accessibility on a routine basis. Automation won’t catch everything and you may need time to address the issues it does find. Set up time on a regular basis for more intensive and remediation of recent work.
- Checkups are still necessary. We can prevent and slow accessibility decay but regular checkups are necessary to verify a clean bill of health. Ideally you’ll find very few issues to address but it’s a best practice to schedule annual (or even biennial) reviews to update your VPAT or conformance report (however formally defined).
