Web accessibility agency

A web accessibility agency should help people use your website, not simply help you pass an automated scan. The work needs standards knowledge, manual testing, clear remediation and evidence that the important journeys work for disabled users.

No single tool can prove that a website is accessible. W3C’s evaluation guidance is explicit: automated tools help, but knowledgeable human evaluation is still required.

When to bring in a specialist agency

Specialist support is useful when you are:

• designing or rebuilding a website or digital service;
• responding to customer complaints or known barriers;
• preparing for procurement, investment or a formal compliance review;
• trying to fix a long backlog across templates and components;
• introducing a design system or new content workflow;
• lacking internal accessibility experience.

Bring the agency in early if a rebuild is planned. Fixing a heading structure, form pattern or component once is cheaper than repairing the same fault across dozens of finished pages.

What an accessibility audit should cover

A serious audit tests a representative sample, not only the homepage. The sample should include templates, high-value journeys, forms, account states, errors, documents, video and any third-party tools customers must use.

The review should combine:

1. automated checks for detectable code and contrast issues;
2. keyboard-only testing;
3. screen-reader testing on agreed browser and assistive-technology combinations;
4. zoom, reflow and text-spacing checks;
5. form labels, instructions, validation and error recovery;
6. content structure, link purpose and alternative text;
7. motion, focus and interaction behaviour;
8. manual review against the agreed standard.

For most modern projects, that standard will be WCAG 2.2, normally with a defined conformance target such as Level AA. The target, scope and exceptions should be written down before testing starts.

The agency process

Establish scope and risk

The agency should identify the site’s main audiences, critical tasks, technology and legal or contractual context. A small marketing site and a complex account service need different samples and test depth.

Test the real journeys

Accessibility is experienced across a task. A form can use valid labels and still fail because focus jumps after an error, instructions arrive too late or a time limit cannot be extended.

Ask the agency to test complete journeys such as finding a service, comparing options, submitting an enquiry or completing checkout.

Report issues developers can act on

Each finding should include the affected URL or component, steps to reproduce, user impact, relevant success criterion, severity, evidence and a clear recommendation.

“Improve accessibility” is not a fix. “Associate the visible label with the input and move keyboard focus to the error summary after submission” is.

Support remediation

The best report is not necessarily the longest. A prioritised backlog, developer discussion and component-level fixes are more useful than a large document passed between teams.

Retest the changes

Closing a ticket is not proof. The agency should retest the original issue and check that the fix has not created a new barrier elsewhere.

Audit only or audit plus disabled-user research?

A technical audit checks the implementation against a standard. It is efficient and repeatable, but it cannot show every difficulty people will encounter.

Research with disabled participants shows how real users complete tasks with their preferred technology and strategies. It can reveal problems that are technically conformant but still confusing.

These methods answer different questions. Use both for important services. GOV.UK also recommends researching with disabled people as part of inclusive user research, not as a final approval exercise.

What to ask a web accessibility agency

Ask prospective suppliers:

• Which standard and conformance level will you test against?
• How will you choose the sample?
• Which manual and assistive-technology checks are included?
• Will you test complete tasks and error states?
• How do you rank severity and user impact?
• Will you explain fixes to designers, developers and editors?
• Is retesting included?
• What evidence will we receive?
• How will you handle third-party systems outside our control?

Be cautious about guarantees that a site will be “100% compliant”. Accessibility depends on content, code, integrations and future changes. A credible agency defines the evidence it can provide and the limits of that evidence.

Keep accessibility working after the audit

An audit is a snapshot. New content, plugin updates and design changes can reintroduce barriers immediately.

Build accessibility into:

• component acceptance criteria;
• content templates and editor guidance;
• code review and automated checks;
• release testing;
• procurement requirements;
• customer feedback routes;
• periodic manual audits and user research.

W3C recommends evaluating accessibility early and throughout development. That is the operating model to aim for.

DreamWeb treats accessibility as part of performance, content and customer journeys rather than a separate badge. Start with a clear scope and definition of done using our website redesign brief, or ask DreamWeb to review the current barriers.

Related reading: UX audit services.