Is WCAG 2.1 AA a legal requirement?

It depends on jurisdiction and sector. It’s the technical standard referenced by regulations like the ADA (through case law in the US), Section 508 for US federal procurement, and the EN 301 549 standard in the EU. Many enterprise and government buyers also require a current VPAT as part of procurement regardless of whether a specific law mandates it for your product directly.

Can automated tools alone produce a valid VPAT?

We don’t recommend it, and most experienced procurement reviewers can tell the difference. Automated scanners reliably catch structural issues like missing alt text or insufficient color contrast, but structurally cannot evaluate things like whether a screen reader user can actually complete a checkout flow. A defensible ACR requires manual testing with real assistive technology.

How long does a full audit and VPAT take?

For a typical web application, a full WCAG 2.1 AA audit with manual assistive-technology testing and a completed VPAT usually takes two to four weeks, depending on the number of user flows and templates involved. Remediation timelines depend on the number and severity of findings.

Do you only test websites, or also native apps and documents?

We audit web applications, native mobile apps, and PDF or document-based content — each has its own applicable success criteria and testing approach, and we scope the engagement to match what you actually need conformance for.

VPAT & ACCESSIBILITY

Accessible enough to passa screen reader, not just a scanner.

A VPAT is only as trustworthy as the testing behind it. We audit against WCAG 2.1/2.2 AA with real assistive technology — screen readers, keyboard-only navigation, voice control — and produce the Accessibility Conformance Report procurement teams actually rely on.

Request an accessibility audit

HOW WE TEST

A conformance report is only as credible as the testing behind it.

WCAG 2.1 AAbaseline standardThe conformance level we test against by default, extending to 2.2 and AAA criteria on request.

Manual +assistive tech testingReal screen reader, keyboard-only, and voice-control testing — automated scanners catch roughly a third of issues at most.

Section 508& EN 301 549 mappedEvery finding is mapped to the US and EU regulatory frameworks your VPAT needs to reference.

ACRready for procurementA completed Accessibility Conformance Report your sales and legal teams can hand to enterprise buyers directly.

WHAT WE DO

What our accessibility audit covers.

Structured around WCAG’s own four principles.

Every audit finding is organized under the POUR framework WCAG itself is built on, so the report maps directly to the standard your VPAT will cite.

Perceivable

Text alternatives for non-text content
Captions & audio descriptions
Color contrast & use of color alone
Content adaptable & distinguishable

Operable

Full keyboard accessibility
No keyboard traps
Enough time & no seizure-inducing content
Clear navigation & focus order

Understandable & Robust

Readable, predictable interfaces
Input assistance & error identification
Valid, semantic markup
Compatibility with assistive technologies

A DISTINCTION WORTH MAKING

Passing a scanner isn’t the same as passing a screen reader.

An automated tool can confirm an image has an alt attribute. It can’t tell you the alt text reads "image047.png" to someone who can’t see the image itself.

It can flag a contrast ratio. It can’t tell you a custom dropdown is completely invisible to a screen reader, or that a modal traps keyboard focus with no way out.

A conformance report built on scanner output alone tends to fall apart the moment a real assistive-technology user — or a skeptical procurement reviewer — actually tries the product.

Passing a scanner isn’t the same as passing a screen reader.

ENGINEERING PRACTICE

Accessibility fixes that hold up, not just pass a re-scan.

It’s possible to satisfy an automated checker without actually fixing the experience for someone using a screen reader. We build fixes that address the underlying markup and interaction pattern, not just the flagged attribute.

Semantic HTML first

Native elements and landmarks over ARIA patches wherever possible — the most reliable accessibility is the kind the browser and assistive tech already understand.

Focus management that makes sense

Modals, menus, and dynamic content manage keyboard focus predictably, so navigation never gets silently trapped or lost.

Meaningful alternative text

Alt text and ARIA labels describe function and content, not just satisfy a linter — the difference between "image" and something a screen reader user can actually act on.

Contrast & scalability by design

Color contrast and text-resize behavior are checked against real WCAG thresholds during design review, not discovered during a pre-launch audit.

Accessibility fixes that hold up, not just pass a re-scan.

ENGAGEMENT

How an accessibility engagement runs.

Automated + manual audit

Automated scanning establishes baseline coverage, followed by manual testing with real assistive technology across your key user flows.

Findings mapped to WCAG

Every issue is documented against the specific WCAG success criterion it violates, with severity and user-impact context — not a raw tool export.

Remediation support

We provide implementation guidance or work directly in your codebase to fix confirmed issues, prioritized by user impact.

VPAT / ACR delivery

You receive a completed Accessibility Conformance Report mapped to WCAG, Section 508, and EN 301 549 — ready to hand to a customer or procurement team.

FAQ

Common questions on VPAT & accessibility engagements.

Can't find what you're looking for? Reach out to our engineering team directly.

A VPAT (Voluntary Product Accessibility Template) is a standardized document format, published by the IT Industry Council, used to report how a product conforms to accessibility standards. The completed document is called an Accessibility Conformance Report (ACR). The audit is the testing work that determines what actually goes in it — a VPAT is only as credible as the testing behind it.

Can't find what you're looking for? Reach out to our engineering team directly.

Get an ACR you can actually stand behind.

Whether you need a first VPAT for a procurement deal or a full remediation program, we’ll test it the way your users — and their assistive technology — actually experience it.

Request an accessibility audit

Accessible enough to passa screen reader, not just a scanner.

Passing a scanner isn’t the same as passing a screen reader.

An automated tool can confirm an image has an alt attribute. It can’t tell you the alt text reads "image047.png" to someone who can’t see the image itself.

It can flag a contrast ratio. It can’t tell you a custom dropdown is completely invisible to a screen reader, or that a modal traps keyboard focus with no way out.

A conformance report built on scanner output alone tends to fall apart the moment a real assistive-technology user — or a skeptical procurement reviewer — actually tries the product.

Accessibility fixes that hold up, not just pass a re-scan.

Semantic HTML first

Native elements and landmarks over ARIA patches wherever possible — the most reliable accessibility is the kind the browser and assistive tech already understand.

Focus management that makes sense

Modals, menus, and dynamic content manage keyboard focus predictably, so navigation never gets silently trapped or lost.

Meaningful alternative text

Alt text and ARIA labels describe function and content, not just satisfy a linter — the difference between "image" and something a screen reader user can actually act on.

Contrast & scalability by design

Color contrast and text-resize behavior are checked against real WCAG thresholds during design review, not discovered during a pre-launch audit.

Accessible enough to passa screen reader, not just a scanner.

A conformance report is only as credible as the testing behind it.

What our accessibility audit covers.

WCAG conformance audit

Assistive technology testing

VPAT & ACR documentation

Remediation engineering