Sweent Earns U.S. Department of Homeland Security Trusted Tester Certification

We passed the exam. As of this month, Sweent team holds the U.S. Department of Homeland Security (DHS) Trusted Tester for Web certification, earned the exam against the current test process (version 5.1.3). It's a credential we've wanted on the team for a while, and getting it changes how we can talk about accessibility work with the agencies and companies we serve. But the certification itself is widely misunderstood, so it's worth explaining what it is and what it isn't.

There is no such thing as a "508 certified company"

Start here, because it's the source of most of the confusion in this market. Plenty of vendors advertise that they are "Section 508 certified." No government body issues that. There is no company-level certification for Section 508 conformance, and anyone claiming otherwise is either being loose with language or hoping you won't check.

What actually exists is the Trusted Tester program run by the U.S. Department of Homeland Security’s Office of Accessible Systems and Technology (OAST), the federal office responsible for accessibility across the government. It certifies individual people, not organizations. A tester studies the methodology, passes a practical exam, and earns the credential. So the honest, defensible claim is the one we're making: a Sweent engineer is a certified Trusted Tester, which means we can apply the federal government's official testing process in-house rather than outsourcing it or approximating it.

If you're evaluating any accessibility vendor, that distinction is a useful filter. Ask who on their staff holds the certification and what version of the process they used. A real answer is a good sign.

What the Trusted Tester process actually is

Trusted Tester is a standardized, manual methodology for checking whether a web page conforms to the Revised Section 508 standards. Those standards, in turn, incorporate the WCAG 2.0 Level A and AA success criteria, so in practice the process is testing against the same accessibility requirements most people already know from WCAG.

The word that matters is standardized. The process walks a tester through each page and component with a fixed sequence of checks: keyboard operability, focus order, ARIA roles and states, form labeling and error handling, contrast, reading order, and so on. Because every certified tester follows the same script, two different testers evaluating the same page should reach the same result. That repeatability is the whole point. It's what makes a conformance claim defensible when a procurement office, a legal team, or an agency reviewer asks how you know the software is accessible.

Why we didn't just rely on automated scans

Automated accessibility scanners are genuinely useful, and we run them. Point one at a production site and within a couple of minutes you'll get a list of missing alt attributes, low-contrast text, and some malformed ARIA. That's real value for almost no effort.

But it's a slice of the picture. Industry testing consistently shows automated tools catch somewhere in the range of 30 to 40 percent of WCAG issues. They are blind to the things that most affect real users:

• Whether you can operate the entire interface with a keyboard, and whether the focus lands somewhere sensible when a menu or modal opens

• Whether focus is trapped correctly inside a dialog, and released correctly when it closes

• Whether a screen reader announces which field an error message belongs to

• Whether the reading order a screen reader follows matches the visual order a sighted user sees

None of those can be verified by a script parsing the DOM. They require a person operating the page the way an assistive-technology user would. The Trusted Tester process exists precisely because the automated layer stops well short of a real conformance answer.

What this means if you're buying software

For our federal and state clients, the practical upshot is straightforward: we can produce conformance testing that stands up to review, and document it in a VPAT, the Voluntary Product Accessibility Template that most public-sector procurement requires before they'll consider a product. Having a certified Trusted Tester in-house means that testing and the documentation behind it come from the same team that understands your codebase, not a separate vendor stitched into the process.

For commercial clients, the value is less about the acronym and more about the discipline it represents. A team that tests to the Trusted Tester standard is a team that has thought hard about keyboard users, screen reader users, and the failure modes an automated tool never sees. If you've received an ADA demand letter, or you just want your product to work for everyone who tries to use it, that discipline is what you're actually paying for.

Where this fits with the rest of our work

This isn't a pivot into a new service line. Accessibility has been part of how we build software from the start, and we've done remediation work that involved real screen-reader testing on live applications rather than checklist review. The certification formalizes something the team was already doing, and it raises the ceiling on what we can promise: not "we ran a scanner and it looked clean," but "a certified tester walked the application through the federal conformance process, and here is the documented result."

If accessibility is on your roadmap, or landed on your desk as a requirement you now have to satisfy, that's the conversation we're equipped to have.