Before you buy an accessibility audit

(Loaded 637 times)

Save yourself time and resources and prepare before you buy an accessibility audit with these tips.

European Accessibility Act (EAA) is nearby and I see that almost all accessibility agencies are fully booked, mostly with accessibility trainings, audits and remediation services.

Some organizations finally discovered the need for accessibility and ordering an audit seems as the best first step. It usually can be – especially for organizations that are still early on their accessibility journey – but I see a lot of potentials to save resources before just ordering an accessibility audit and thinking we did the most out of the situation.

Inventory is a start, but don’t stop there

Before we order an audit we need to know what needs auditing. Is it just the “main” website or do we also need to consider self-care portal? What about our app? Both Android and iOS ones? What about or automatically generated contracts in PDF? And emails? And customer facing ticketing system? Is business to business portal included?

The answer depends on a lot of things, but make sure you start with the critical user journeys – ideally the whole journeys. On-boarding, account creation, authentication, basically every step that matters for your end users and beyond. Don’t leave this decision to the people that will do the audit, as they may miss some parts that can be essential. You have the best overview and you need to define what parts are essential and needs to be tested. Auditors usually use Web Content Accessibility Guidelines Evaluation Methodology (WCAG-EM) and some random sampling, ideally ask for design system and representative samples of components and page templates, but even that is often not enough. Providing test accounts that have production like data can be essential as well. It does not help to cover just a single service or product if you know they can be complex and combined.

Also make sure you can provide accesses to test environments that can really be tested end-to-end, for example account creation, authentication, self-care with full access and all products or services that you offer and even payment flows.

Define also known third parties and consider if they are in the scope of the audit or not. Third parties that are not accessible can sometimes represent huge barriers for people with disabilities. Check with them if they are accessible or at least what is the status. You are responsible for the accessibility of the whole journey, even if perhaps legally you are not. Does it really matter to your users if you use third parties or not when they can’t use your products or services?

Check also with your vendors if you have them. They need to contribute as well. Some of them may even help you take some parts out of scope and save time.

I always suggest that organizations also check if they already have any information about user feedback that is relevant for accessibility and usability. Sometimes I stumble upon years old user feedback on inaccessibility that is still extremely relevant, and could be fixed long before I need to document it again.

Sometimes your teams wanted to fix things but was not allowed to

Accessibility guidelines are not something new. Web Content Accessibility Guidelines (WCAG) are more than a quarter of century old and chances are that somebody in your team already stumbled upon them, but didn’t act on them. Perhaps they got an error in their developer tools and didn’t have the time to investigate. Or they checked the webpage with Google Lighthouse or any other similar tool and discovered a very poor accessibility score and didn’t mind checking that out. That may be a sign of poor or non-existing accessibility culture or many different things. But I am certain that sometimes in some organizations accessibility was ignored for years, intentionally or non-intentionally.

This may also mean that some people wanted to do something about it but didn’t have the support. Or enough knowledge. Usually both. Perhaps they even got leadership orders to not do anything about it. When we try to finally change the culture for the better – I strongly suggest finding internal potentials.

Accessibility culture is enabled from top to bottom, from management to delivery, but it helps a lot if it is also supported from bottom to top – from delivery upwards.

So – perhaps your own people can fix some obvious things – that are maybe documented in the back-logs, just never prioritized. Some accessibility issues are quite simple to fix and when we use design systems we can even fix thousands of issues by fixing a single components (think of a button that has an error and is found on all pages).

Dedicate time for basic accessibility trainings

There are lots of free and valuable resources about digital accessibility out there and management needs to dedicate some time systematically for accessibility training. I suggest starting with official online accessibility course from Web Accessibility Initiative (WAI, opens in new window). It provides some common ground and understanding about the why of accessibility – starting with the people. People with disabilities. And then how they operate digitally and continue with the technical details.

Sure, best trainings cost money, but for a quick and free introduction it helps to have an official course that is there all the time and we only need to allow people to take the time for it.

Even when we have people that have some experience – it is always good to remind them of the basics. And please make sure that you are not only training developers and designers. Accessibility is a common responsibility and managers, customer support, product and project managers, procurement and other parts of organization also needs to be aware of it to make it a common goal and a part of the culture.

Use automatic testing tools, but be aware of their limitations

There are a lot of accessibility testing tools out there, some are even open source. Some are perhaps even a part of your testing tools already, but nobody checked them before. Nevertheless – you can get a quick overview of accessibility issues on a large scale and quickly. Are the tools enough – not by far. Automatic accessibility testing tools have their limitations. Tools are mainly just analyzing code patterns and finding known issues, sometimes just marking some patterns as potential issues. And sometimes tools even find issues where there are no issues (false positives).

But often they do find obvious accessibility issues that need fixing. And when nobody had focus on accessibility before – tools often expose a lot of issues that can be fixed quickly and on a large scale. Typical examples are buttons and links with icons missing alternative text, duplicate id values that are used as references, tools are quite good at finding poor contrasts in simple markup and style combinations and can also find many other code-based issues.

Knowing about issues that can be discovered by automatic tools means that your teams can use some time and fix at least the critical ones that are simple to fix. Most of tools include some help and examples on how to fix the discovered issues and it often makes sense to fix obvious issues before doing an audit that will require the auditors to document the same issues and use the time that could have been used more efficiently elsewhere.

We should also point out to the auditors before the audit which tools we used, what we found and what we fixed, so that we get a conformation for fixes where we were perhaps not confident.

Choose accessibility partner that has the experience

Sometimes it’s not so easy to find an accessibility auditing partner that provides real value. I’ve seen some audit reports that were even based on automatic tools alone. And sometimes I’ve seen audit reports that were not providing any real remediation suggestions. So – before ordering an audit – make sure that the auditor can provide references and example audit or two. When I help organizations with accessibility, I always try to provide relevant documentation before we go further with activities and sometimes I even don’t take the assignment if I see that I will not be the best fit.

You will not want to spend money and time on an audit that will just report what are the issues. It may be OK to generate an accessibility statement, but if it can only be used for that then you lost a lot of time and money. As you should also get proper descriptions on how to fix the issues discovered.

Website accessibility audits are often quite good with the remediation suggestions, but it’s not so easy for native mobile applications. WCAG tries to be technologically agnostic – and it often is – but sometimes you can’t resolve issues without more information that is tailored to your platform. Native mobile application accessibility is sometimes directly reflecting the used platform. This can sometimes mean that audit can be too general in the remediation suggestions and your team needs way more information on how to fix issues. At the same time we also can’t expect that all accessibility auditors know all the details of the platform you are using.

My suggestion here is to make the cooperation last longer than just for the audit. When your teams will start with the remediation it will be most efficient to work together with accessibility specialists, so that you will have both platform and accessibility experts fixing and verifying the problems. This kind of cooperation will also help your teams to learn more about accessibility from the practical point of view.

Go for accessibility culture, not just audits

You can call me an idealist, but just doing audits is not a sustainable way to make your products and services accessible. Integrating accessibility into culture is the only way if we don’t want to spend a lot of money on never ending cycles of audits and remediations. Internal centers of competence, management support and dedication, awareness and systematized trainings should be the goal. If you don’t believe me, please check the EN 17161 Design for All standard. It’s basically defining the same things, only by using a system and scientific approach.

Accessibility is continuous and is a journey, not a project.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me:

Leave a Reply

Your email address will not be published. Required fields are marked *