Define the Outcome Before Requesting Quotations

Start with the decision the audit must support. Are you preparing to launch a new portal, investigating barriers in an existing service, reviewing a supplier’s delivery or establishing a baseline for an improvement programme? Each purpose changes the work that should be included.

For example, a government entity preparing an online permit service needs to understand whether applicants can complete the application. Reviewing the homepage and a few information pages will not answer that question. The brief should include sign-in, form validation, supporting-document upload and confirmation, including unsuccessful attempts where users must recover from errors.

Name the internal owner of the findings and the team expected to implement changes. An audit is more useful when procurement, the digital service owner and the development supplier agree how the results will be handled. Set aside time for reviewing the report and clarifying findings before treating delivery as complete.

Agree the Standard and Audit Scope

Avoid briefs that request only “an accessibility audit” or “WCAG compliance.” Specify the WCAG version and conformance level to be assessed, then identify any additional policy or contractual requirements. WCAG 2.2 defines testable accessibility criteria, but the applicable project requirements should be established rather than assumed.

In the GCC, do not assume that every government entity or enterprise follows an identical requirement. Ask the responsible team to confirm the relevant framework. VisiAble’s overview of digital accessibility in the GCC provides regional context, while the procurement brief should state the specific requirement for the service being evaluated.

A useful scope identifies websites or applications, language versions, shared components, page templates, authenticated areas and critical tasks. Include downloadable documents and media where they are part of the service, or explicitly commission them separately. State whether mobile applications are included; a website quotation should not silently be treated as a native app assessment.

Ask the provider to explain how its sample covers the service. W3C’s conformance evaluation guidance describes an evaluation process that includes defining scope, exploring the website, selecting a representative sample, evaluating it and reporting findings. A large page count alone does not explain whether the important interactions have been assessed.

Evaluate the Testing Methodology

When comparing website accessibility audit services, ask which accessibility audit tools the provider uses and what qualified evaluators will test manually. The proposal should explain the pages, states and user journeys covered by each method. W3C’s guidance on selecting accessibility evaluation tools helps clarify why software output must be reviewed within a broader assessment, rather than accepted as a complete conformance result.

Ask for examples of how the provider will evaluate keyboard operation, focus behaviour, form feedback, content structure and assistive technology interaction. Request an explanation in service terms. Can a user open a menu, dismiss a dialog, understand a validation error and continue the task without a mouse?

Confirm how the team handles issues that need judgement. A detected alternative-text attribute does not establish that its wording describes the image appropriately. Similarly, finding a form label does not establish that instructions and error messages make the task understandable.

The provider should also explain how duplicate findings are grouped. Repeating one shared navigation defect across hundreds of URLs can make a report look comprehensive while obscuring the fix. Our article on automated and manual accessibility testing explains why the methods serve different purposes.

Check Bilingual and Assistive Technology Expertise

For an Arabic and English service, ask whether both versions will be evaluated and how the findings will distinguish them. Translation can change labels, instructions and error messages. Right-to-left layouts and mixed Arabic and English content also deserve attention during task testing.

A provider should be able to discuss a bilingual example rather than simply promise “Arabic support.” Ask how it tests focus order, page language, control names and mixed-direction inputs such as email addresses and reference numbers. Agree the language of the report and whether developers need bilingual findings.

Assistive technology testing should name the environments used, such as a particular screen reader, operating system and browser combination. Ask why those environments suit your audience and which interactions will be exercised. Listing NVDA, JAWS or VoiceOver in a proposal is not sufficient evidence of a testing method.

Where user research is included, ask about participant needs, tasks and how the results will be recorded. W3C’s guidance on involving users in accessibility evaluation explains the value of user involvement alongside standards evaluation. A small user study should not be presented as proof that all requirements have been met.

Request a Sample Report from Your Digital Accessibility Audit Provider

Request an anonymised report or a demonstration issue before appointment. Review it with someone who will implement the recommendations. Could that person reproduce the problem, identify the component and understand the expected behaviour without arranging a separate meeting?

For each issue, ask for the affected page or component, the testing environment, reproduction steps, observed behaviour, user impact, relevant criterion and a proposed remedy. Evidence may include screenshots or a short recording where useful, but it should be accompanied by a written explanation.

An executive summary should help service owners decide what to address first. The technical detail should help developers make the correction. W3C’s accessibility evaluation report template is a useful reference for considering report scope, results and recommendations.

Agree a severity model rather than relying on labels whose meaning is unclear. A barrier preventing application submission may warrant immediate attention even if it appears on one screen. Repeated lower-impact issues may be better addressed through a shared component or content process. Ask the provider to explain both the user impact and the reasoning behind priority.

Separate an Audit from Remediation and Conformance Documentation

An audit identifies and documents barriers. Remediation changes the product. Retesting evaluates the changes. These activities may be offered by one provider, but they should have separate responsibilities and deliverables in the agreement.

Clarify whether remediation guidance means suggested fixes, implementation by the provider or workshops with your development supplier. Likewise, define whether the engagement includes only an issue report or additional conformance documentation. If an Accessibility Conformance Report based on a VPAT template is required, request it explicitly and agree its coverage and evidence basis.

Treat broad promises of guaranteed compliance with caution. A report relates to a defined product version, scope and testing date. WCAG conformance requirements include full pages and complete processes; the boundaries of a sampled assessment should be disclosed rather than converted into an unsupported claim about every part of a service.