Trust me — I'm the DHS Trusted Tester
Good news and a life update: I’m officially a DHS Trusted Tester now!
I’m so happy about it because it was a really time-consuming process that took a lot of effort. It started with many theory tests, then a practice exam (about 4 hours testing 100 web pages), followed by the final exam (which took me 3.5 hours of almost non-stop testing on another 100 web pages).
I wanted to get this official certification mostly to see the whole picture from the other side of the table: how big organizations actually check whether a product or service is accessible, and how that influences procurement decisions.
I’ve spent many years developing, testing, and code-reviewing UX/UI for accessibility as a Frontend Engineer, but I knew very little about the official process of reporting accessibility conformance and Section 508 requirements (specific to the U.S.). Now I know that side of the work too, and I can help others with it.
What is a DHS Trusted Tester?
The Trusted Tester Program is run by the U.S. Department of Homeland Security (DHS), through its Office of Accessible Systems & Technology (OAST).
It certifies individuals to test web content against Section 508 (which includes testing against WCAG) using a single, standardized manual testing process. The point is repeatability: two certified testers following the process on the same page should get the same result. That consistency is exactly what federal agencies need when they have to defend a conformance claim (that’s why they have the testing done by someone with a Trusted Tester ID).
From “is it accessible?” to “prove it”
Here’s the situation that makes all of this matter. Let’s use the U.S. market as the example:
If you’re a government agency with a procurement process to buy a new tool, product, or service, by law you must choose the most accessible option that meets your needs (I simplified a bit).
How do you actually compare two products on accessibility? The answer is an ACR. And an ACR is the output of a VPAT®.
…
VPAT/ACR — WHAT??
A VPAT® (Voluntary Product Accessibility Template) is a standardized document, maintained by the Information Technology Industry Council (ITI), used to describe how a product or service meets accessibility guidelines. Once you fill it out for a specific product, the result (the actual evidence) is the ACR (Accessibility Conformance Report).
The VPAT is the template you fill out, and the ACR is the completed report you submit.
VPAT® is a registered trademark of the Information Technology Industry Council (ITI).
ACRs are common in both the public and private sectors. Some companies require vendors to submit one as part of procurement. If you’re selling to a government agency, you may be required to provide an ACR as proof of your product’s accessibility.
Which standards does a VPAT cover?
A VPAT comes in editions, so the ACR can report conformance against one standard or several at once — WCAG, Section 508, EN 301 549, or all three (the “INT” edition).
| Standard | Where it applies | What it covers |
|---|---|---|
| WCAG 2.2 | International (W3C) | The technical baseline for web content. The other two standards build on it. |
| Section 508 | United States | Federal agencies and the vendors who sell to them. References WCAG. |
| EN 301 549 | European Union | Public-sector ICT procurement standard. Supports compliance with the European Accessibility Act (EAA) and references WCAG as well. |
Why an ACR is worth having even when nobody asks (right now)
Even when it isn’t required, an ACR is a useful snapshot of how accessible your product is at a specific point in time.
I ran into this in a previous role: a few days before a rollout, we were asked to prove that the app’s new front end was more accessible than the previous one. We didn’t have an ACR, so we had to improvise something similar from scratch. It was a lot of work, and it could have been avoided if we’d had one ready.
And beyond moments like that, these are the reasons I think an ACR is worth having:
- It shows an honest picture of where your accessibility issues are right now.
- It marks progress in your accessibility journey when you compare it against an earlier report.
- It helps prioritize roadmap work based on the issues found.
In other words, an ACR is not just for procurement. It also helps your team know what to improve.
Where I can help
Whether you’re building a product or buying one, these are the things I can help your team with:
- VPAT / ACR documentation built to survive procurement — U.S. Section 508 and EU EN 301 549 / EAA.
- Vendor ACR review for buyers — evaluating the ACR a vendor hands you before you buy, so you’re comparing real conformance, not optimistic paperwork from their marketing department.
- Manual + automated audits — keyboard, screen reader, and the task flows people actually use.
- Remediation — as a Frontend Engineer, I can implement the fixes too, if you need someone to do the work.
- New feature reviews and design reviews for accessibility — I can add annotations to Figma/design files with accessibility-focused HTML tagging and notes, making sure accessibility is baked in from the start.
- Design System accessibility audits or Design System development from scratch — making sure your components are accessible.
- Automating accessibility checks in CI pipelines — catching issues before they become compliance, sales, or legal problems.
- Training — for your team, on accessibility testing and the best frontend practices for common scenarios.
- Accessibility program management — owning the strategy, governance, and processes so accessibility scales across teams and ships reliably, not just on one project.
FAQ
Why is the Trusted Tester program run by the Department of Homeland Security?
There is no single federal “accessibility agency” in the U.S. Section 508 requires each federal agency to make its own technology accessible, and each agency is responsible for testing its own systems.
DHS is one of the largest agencies, and its Office of Accessible Systems & Technology (OAST) created a structured, repeatable manual test process. Instead of building their own, other agencies adopted it.
That process is now used across the federal government as the Trusted Tester standard, currently version 5.
What does a real ACR look like?
The easiest way to get a feel for one is to read published examples. Large vendors keep public libraries of their ACRs, one per product — see Google’s accessibility conformance reports and Microsoft’s conformance reports. Each report works through the standard criterion by criterion, marking every one as Supports, Partially Supports, Does Not Support, or Not Applicable, with notes explaining the gaps.
Sources
- VPAT — Information Technology Industry Council (ITI)
- DHS Trusted Tester training course — Section508.gov
See also:
- ACR/VPAT FAQ — Section508.gov
- How I Evaluate an ACR / VPAT by Adrian Roselli
- Voluntary Product Accessibility Templates — Applause
- Practical accessibility testing — the full testing process