In IT services there is a term for not maintaining your technology and hardware. Eventually, something will break and then you will have to fix it with the additional pressure of it being broken. The industry term for this cycle is Break/Fix. When it breaks then you fix it. The Break/Fix cycle is generally not a good way to live and can be disastrous depending on what is breaking.
IT service professionals often advocate for a managed service where regular preventative maintenance occurs to minimize the risk of things breaking. For software this is technical debt. You are delaying the cost of maintenance now but will have to pay for it later. Think brushing your teeth and flossing vs drilling out cavities and root canals.
So what does this have to do with web accessibility?
Unfortunately, this pattern of ignoring (often unconsciously) web accessibility until there is a crisis is what most organizations do. Most of the time it follows one of two patterns:
- An organization waits to focus on web accessibility until they receive a demand letter, lawsuit, customer complaint, or some outside pressure. Now you have a crisis with extra urgency. Web Accessibility will cost the most under these circumstances.
- A more subtle version of this pattern is waiting to think about web accessibility until a specific point in time by a specific person or team. For example a web accessibility team is responsible for it and the rest of the team ignores it or only thinking about it at the end when things are live on production. It will cost more to fix issues on production than it does on stage and more on stage than it does on dev and more on dev than it does in design and more during design than it does by preventing issues through training.
I once observed a retail client who did both. They ignored web accessibility until they received a demand letter. It was now a top priority for the company. They worked to fix the identified issues and clean up errors detected by automated testing. Once past the crisis they realized they needed to pay attention to web accessibility but they assigned it to one team at one point in time. Each month they would get the automated report and fix the errors but by the next month their fast changing products would have been updated introducing new accessibility errors. They followed this cycle every month. The team fixing the errors were not the same team that added new products.
The desired outcome of being accessible was elusive and the cost to always be fixing errors was much higher than needed.
There is a solution to break out of this pattern.
Web accessibility needs to be a part of your process and culture. It is cheaper and will yield a more accessible website.
Building web accessibility into your process
What does this look like in practice?
When web accessibility is part of your process and culture the following start to sound more familiar:
- Leadership prioritizes web accessibility and talks about it. It is a priority starting at the top.
- Team members are trained on web accessibility as it applies to their roles. Remember not everyone needs to be a web accessibility expert. Many people knowing a few principles will have a significant impact.
- Web accessibility isn’t a separate function but is embedded into each existing process.
- Team members have web accessibility in mind as they work, instead of a one-time checklist completed at the end of a project.
- Web Accessibility becomes a habit. Once team members are trained and aware, it is just as quick to make many things accessible as the old inaccessible way.
- Manual web accessibility testing happens strategically and regularly. For example, a representative sample of pages might be tested each year along with testing on new components and templates.
- Automated testing is used to test a larger sample than possible with manual testing, catch regressions and facilitate an ongoing web accessibility cadence.
Your organization is unique in many ways. Adapt these ideas to fit your situations as you build out your web accessibility strategy. Don’t forget that it is ok to not be perfect, simply picking one or two things you can start doing now can have a big impact.
Breaking the cycle
In the middle of the break/fix web accessibility cycle, it can be challenging to break out. It is easier to spend all of your limited resources on fixing issues rather than preventing them. This keeps you in the cycle going from one issue to the next.
To start preventing issues, think about each of the bullet points above and how you can improve in that area. There will often be some things you can do within your current resources. The current crisis can even bring some opportunities if you look for them.
Can you get more leadership buy-in from the current crisis or urgency?
One of the simplest suggestions is to use the process of fixing current issues as training opportunities. If you get this right you will not only fix an issue but will prevent many more in the future. The best person to fix an issue is the person/team who is most likely to create the same issue in the future unless they are trained. This can be some of the most effective accessibility training.
Anything you can do to build accessibility into your process gives you leverage. You aren’t fixing errors one at a time, you are preventing them.
It may take some effort and strategizing, but if you can shift accessibility from break/fix to being baked into organizational processes and culture it will pay-off in the long run.