What if you had a limited budget for accessibility?

Imagine you're in charge of making an app accessible, but you have limited time and money. You want to make sure your approach is both smart and efficient.

Extensive testing

Many organizations, especially in the government, start by doing a full audit of their app to see where they stand. In the Netherlands, they use WCAG EM (or Appt EM) to test up to 20 screens. If accessibility wasn’t considered in the app, the audit usually finds 100 to 150 issues. However, repeated issues aren't always listed. This report is then sent to developers to fix the problems. But most developers don’t know much about accessibility, so they either don’t understand what to do or charge too much for the fixes.

That’s why it’s not helpful to just send an audit report if the development team lacks knowledge.

Tip: Help developers by providing training and adding clear instructions in the audit report on how to fix the issues.

Full audit, we know everything!

Now that the development team has the right knowledge, they look at the audit report. The report shows a good summary of the screens that were tested. But we often forget that the same issues can happen on screens that weren’t tested. To make the whole app accessible, all screens need to be fixed, not just the ones in the report. Instead of testing 20 screens, it would have been enough to show a few examples so the developers understand what problems exist throughout the app.

There is no point in testing a lot of screens if basic accessibility is not implemented.

With this knowledge, let's fix all issues!

We tested a small number of screens to find common problems. You can even start with automated testing to catch some issues, but manual testing is still needed because automated tools have limits. After this first round of testing, the developer fixes the problems. This saves a lot of time and effort. However, during the next round of testing, we find that the developer fixed some issues incorrectly, which created new problems. For example, text resizing works now, but it caused text to get cut off and overlap with other elements. Now the development team has to fix these "improvements" across many screens. That’s why we need an interactive approach, not just for testing but for making improvements to the app as well.

There is no point in fixing all screen if you are not certain you fix the issue correctly.

Tip: Check if improvements are actually improvements and reach your goal, make your app accessible.

Now, we focus on testing a few screens and fixing the issues on those screens first. This way, the learning process is faster, and fewer resources are wasted. It’s the best approach for fixing problems. By using this method, we have an effective and efficient way to test and improve the app. We test and improve it step by step, starting with simple tasks that have the biggest impact. This approach saves about 50% of the effort, which can then be used to go beyond just meeting WCAG standards and actually testing with real users.

Lets make a new feature!

While the team is fixing accessibility issues, they’re also working on new features. But many accessibility problems still show up on these new screens. Fixing accessibility after the launch can increase cost 50%-100% of the original development cost.

That’s why it doesn’t make sense to create new features without including accessibility in the development process.

Tip: Review your design system and components, create checklists, and set clear goals for each stage. Test after every step.

By including accessibility in the development process from the start, you can save up to 80% of the effort.

Check out our earlier blog about the maturity of accessibility within apps and if you are interested in the possibilities check out: our recently released product Abra Desktop, it can scan for accessibility issues without access to your source code.