Procuring a web accessibility audit

Things to consider when buying a web accessibility audit.

What is a web accessibility audit?

A web accessibility audit is a systematic assessment of a website’s compliance with a web accessibility standard or set of guidelines. An audit’s main goal is to identify barriers that might prevent disabled people using the website.

A web accessibility audit typically uses automated and manual methods to test a sample of pages from a website. From this, a report is generated listing all the accessibility issues discovered.

Ideally, the report will also:

Note: Instead of waiting until the end of a project to test for and fix web accessibility issues, integrate accessibility into the project from the beginning.

Engage an accessibility advisor on the project, or at least have one available to review designs, prototypes, and finished work as they are created, and to quickly answer any designer or developer questions as they come up.

This will lead to:

  • accessibility issues being fixed when they first come up, when it’s easiest and cheapest to do so
  • a lower chance of finding major accessibility issues just before or after the website is launched
  • the team getting familiar with accessibility best practices and creating accessible content from the start.

Before buying a web accessibility audit

The number of suppliers offering web accessibility auditing services is increasing. As websites and web technologies get more complex, the effort and cost involved in an accessibility audit are also going up.

To get a cost-effective accessible audit that will be useful to you, it’s critical to know beforehand exactly what you need from an audit and what to ask for. See below for some questions to ask before going to market.

For a good overview of what to consider, see 5 things you should know before buying accessibility audit and accreditation services — Hassell Inclusion.

What budget is available?

How much money is there to spend on an audit? This will impact things like how much web content can be tested, the level of detail in the report, and whether solutions are recommended.

In some cases, this amount will already be set. In others, the amount available might be open to negotiation. In that case, there might be arguments for increasing the budget depending on things like:

Why are you auditing?

It’s assumed that website owners want to fix accessibility issues with their websites and that’s why they get an accessibility audit. But there are different situations in which an audit might be called for. For example, some audits:

It is also important to consider the website’s future and the likelihood that accessibility issues raised in an audit will be addressed. If the website is going to be replaced in a year, or there will be little budget or capacity to fix issues found, this should inform the decision to audit.

How many and which pages to test?

Figuring out what to include in the sample of pages to be audited can be tricky. It’s also one of the major contributors to an audit’s cost: The more pages to audit, the higher the price.

Reducing the number of pages and other features to be tested is the easiest way to reduce the cost of the audit. But it also increases the chance that accessibility issues will go undiscovered. To address the risk associated with an inaccessible website, it’s important to show that a reasonably comprehensive audit was procured and sufficient to find most issues.

Accessibility was embedded

If accessibility was considered throughout a site’s design and development, a less comprehensive — and less costly — audit is reasonable. In this situation, an accessibility review of the critical user journeys and most common template-level features could be all that’s needed. The attention paid to accessibility during the project means it’s unlikely there are many unknown accessibility issues across the site overall.

Accessibility was not a concern

If accessibility was not part of a website’s design and development, the site’s actual accessibility is possibly unknown. In this scenario, a reasonably representative sample of pages will need to be tested to ensure that the audit finds most of the issues in the site. A sampling methodology for a more comprehensive audit like this can be found in Step 3 of the W3C’s Website Accessibility Conformance Evaluation Methodology (WCAG-EM).

What standard to test against?

The NZ Government Web Accessibility Standard requires that web pages conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, with a few minor exceptions.

If non-web documents like PDFs or Microsoft 365 Office documents are being included, they should be tested against EN 301 549 Section 10 Non-web documents. For more information, see the requirements for Publishing PDF and office documents — Knowledge Area: PDF and office documents.

Does this include best practices?

Some auditors will identify failures of accessibility best practices. These are not failures of WCAG or a formal standard, but of commonly known principles and practices for designing and developing accessible web content. Based on their knowledge and experience, some auditors will recommend other accessibility improvements.

The more accessibility issues found, the better. However, there’s a formal requirement to meet WCAG, and so it’s important that auditors distinguish the WCAG failures they find from any best practice or other recommendations.

Which browsers, devices, and assistive technologies to target?

The supplier chosen to perform the audit will be able to advise on this question. Visitor statistics, if available for the website, can also help decide which web browsers, operating systems and devices should be considered during the audit.

Depending on the situation, some amount of screen reader testing is recommended. Discuss with the auditor how many screen readers and which user journeys or widgets to test with. However, note that this can add cost to the audit.

What kind of report is needed?

The content and level of detail included in the report contributes to the supplier’s work and so increases the overall cost of the audit.

The best audit reports have the following characteristics:

If the team that built or is maintaining the website is well-versed in accessibility and technical solutions, then a report that simply lists the issues might be all that’s needed.

If the team is not as familiar with accessibility best practices and techniques, or easily reporting audit details to management is important, a more detailed audit report with solutions and charts will be worth it.

Ask for a sample report

If your team needs a more detailed report, make sure you ask for a sample of the type of report you can expect from the auditor.

You’re not paying for a list of problems. You’re paying for detailed guidance on how to make those problems go away. So before buying an accessibility audit, ask to see a sample deliverable. If they don’t have one, run away. If they do have one, read through it and ask yourself: “Can I understand exactly what work is needed to fix the issues in this audit?”. If you cannot answer in the affirmative, find another vendor.
How long until your website is accessible? — Karl Groves

Procuring the audit

NZ Government organisations can procure a web accessibility audit through the Marketplace from any of the approved suppliers of Web Accessibility services.

It’s recommended that you email at least a few, if not all, of the suppliers with a description of what you are looking for in an audit, then compare the responses and follow up directly for more details with the suppliers as necessary.

Auditor credentials

Web accessibility auditors have various levels of knowledge, experience and skill. An experienced auditor might cost more, but they’ll also be quicker and have more experience finding issues and recommending known solutions.

When comparing providers, ask them about:

After the audit

Once the audit results are received, they need to be reviewed and actioned. The auditors will typically offer to take you through and explain the results.

If the accessibility issues identified have been prioritised, this makes it much easier to action them, as the high impact issues can be addressed first to remove the most significant accessibility barriers.

Template-level issues are also good to prioritise. A common accessibility issue that appears throughout the website can often be fixed with just one or two simple corrections. Since template-level issues are so often repeated, fixing them also tends to significantly reduce the total number of issues left to address.

At the same time, it’s important to consider how much effort is involved to fix each issue. There might be a number of accessibility problems that are simple to fix and could be addressed right away with little effort. Even if they don’t represent serious accessibility barriers, they could be easily fixed while the more complex accessibility issues are scoped and sized.

Integrate accessibility

If you haven’t already, consider embedding accessibility into all of your web design and development work.

For instance, integrate automated accessibility testing into the web development work that your team does. For more information, see A Practical Approach to Automated Accessibility — DEV Community.

But designers, user experience (UX) researchers, and others on the team can also integrate accessibility considerations, review and testing into their work as well.

For example, designers should be annotating their wireframes and mockups. For more, see A Designer’s Guide to Documenting Accessibility & User Interaction — Stéphanie Walter.

UX researchers should be testing new ideas, features and functionality with users including disabled people. For more information, see Getting started with accessibility UX Research — Assistiv Labs.

For a breakdown of the typical roles or functions on a web team and how they can directly impact or influence the accessibility of web content, see the Roles section of this website.