Automated checks catch a useful slice of accessibility issues quickly. Manual testing with assistive technologies catches the rest — the flows, the judgment calls, and the failures that only show up when a real person tries to use the product.

Most engagements need both. We start with automation to map the surface, then spend the bulk of the audit where people actually get stuck.

What the scanners actually see

Scanners are excellent at spotting missing alt text, empty links, low-contrast hex values, and a long list of other deterministic failures. They run fast, they do not get tired, and they give you a backlog you can triage on day one.

What they cannot see is whether a custom date picker is usable with VoiceOver, whether a modal traps focus in a way that makes sense, or whether the error message next to a form field is announced when it appears. Those are judgment calls, and judgment is still a human job.

The quarter that matters

On a typical product surface, automation might surface roughly three-quarters of the issues that show up in a full audit — the easy quarter for machines. The remaining quarter is where real users get stuck: keyboard traps, broken focus order, unlabeled controls that look fine in the DOM until a screen reader hits them.

That last quarter is also where procurement conversations get serious. Buyers do not ask whether you ran a scanner; they ask whether someone who uses assistive technology can complete the critical paths.

Where a person is irreplaceable

We test with the same tools your users rely on — VoiceOver, TalkBack, JAWS, ZoomText, braille displays — because those sessions surface failures no rule engine has encoded yet. A person notices when a flow is merely “technically accessible” but still exhausting.

So we keep the scanners. We just refuse to let them be the whole story. Automation maps the surface; people find the places that matter.

A Voluntary Product Accessibility Template (VPAT) is a structured report of how a product conforms to accessibility standards such as WCAG. Buyers use it to compare vendors and to document due diligence in procurement.

A useful VPAT is specific: criteria mapped to evidence, not marketing language. We write them from the same audit work that produces the findings — no separate theater track.

What buyers actually read

Procurement teams skim for coverage of the standards they care about, then dig into remarks where conformance is partial or not supported. Vague language (“supports with exceptions”) without evidence is a red flag; concrete remarks with methods and versions build trust.

How we put one together

We start from a real audit: automated scans plus manual testing with assistive technologies on the critical paths. Findings map to VPAT rows so every claim has a trail. If a criterion is not supported, we say so — and we say what would change that answer.

When you need one

You need a VPAT when a buyer, agency, or RFP asks for documented accessibility conformance. You also need one when your sales cycle keeps stalling on “send us your accessibility paperwork.” A clear VPAT shortens that conversation because it answers the question once, with evidence.