2026-05-17 · 5 min read

How to Choose a WCAG Auditor: Questions Every Government IT Director Should Ask

# How to Choose a WCAG Auditor: Questions Every Government IT Director Should Ask

The market for WCAG accessibility auditing spans a wide range — from automated scanner vendors repackaging monthly reports as "audits" to large enterprise consultancies charging six figures for services that may be redundant to what your development team already knows. For government IT directors writing an RFP or evaluating proposals, the challenge is knowing what to require.

This post gives you the evaluation framework. Not vendor names, but the specific methodology questions, deliverable requirements, and red flags that distinguish a defensible compliance audit from a report that leaves you exposed.

The fundamental question: automated or manual?

The first thing to establish with any prospective auditor is what percentage of their testing is automated versus manual.

Automated tools — axe-core, Lighthouse, WAVE — are valuable and fast. They consistently identify specific failure categories: missing alt text, contrast ratio failures, missing form labels, missing document language declarations. But automated tools detect approximately 57% of WCAG failures. The remaining 43% require human judgment and manual testing: keyboard navigation testing, screen reader output verification, focus management evaluation, and assessment of whether content makes cognitive sense to users with disabilities.

An "audit" that consists entirely of automated scanner output is not a WCAG 2.1 Level AA audit. It is a subset of one. A court or DOJ investigator evaluating your compliance documentation will recognize the difference.

Ask: "What percentage of your assessment is automated versus manual? How do you test WCAG criteria that automated tools cannot evaluate, such as 2.4.4 (Link Purpose in Context) or 3.3.2 (Labels or Instructions)?"

What testing tools and assistive technology do they use?

A credible WCAG audit includes testing with actual assistive technology. The two screen readers that matter most for government site compliance are NVDA (Windows, free) and JAWS (Windows, commercial). VoiceOver on macOS/iOS is also relevant. An auditor who can only run axe-core in a browser extension but has no assistive technology testing capacity cannot evaluate how your site actually behaves for screen reader users.

Ask: "Which screen readers do you use in your evaluation? Which browser/screen reader combinations do you test?"

What pages do they test?

The scope of a WCAG audit matters as much as the methodology. An audit that evaluates only your homepage is not useful for compliance documentation — and it may not be representative of your site's most critical accessibility failures, which often occur on forms, search results, and service delivery pages.

For government sites, the pages that matter most for compliance are:

• Public service application forms
• Public meeting notices and agendas
• Online payment interfaces
• Job listings and HR portals
• Search results pages
• Document libraries (where PDFs are served)

Ask for a representative page sample. For typical government websites, 150–200 representative pages is a reasonable audit scope. Some auditors charge by the page; others audit a representative sample and note the methodology clearly.

Ask: "How do you determine which pages to include in the audit scope? What is the minimum and maximum page count included in your proposal?"

What deliverables do you receive?

The deliverable is where most audits fall short. The output must be actionable for developers, documentable for legal purposes, and accurate enough to serve as the basis for your accessibility statement.

A complete WCAG 2.1 audit deliverable should include:

1. A findings report organized by WCAG success criterion. Each finding should include: the criterion number and name, the failure description, the affected URL(s), the severity, a code example or screenshot of the issue, the estimated remediation effort, and a recommended fix. A report that lists findings without these elements forces your development team to re-investigate each item.

2. A remediation roadmap. The findings should be prioritized so your development team has a clear sequencing: fix critical failures first, then major findings, then minor. The roadmap should be organized in a way that allows you to show progress against specific criteria over time.

3. An accessibility statement draft. The accessibility statement you are required to publish under the Title II Final Rule should name the auditor and reflect the findings from the audit. If the auditor doesn't deliver a statement draft, you're left writing one yourself — which means interpreting the findings, choosing the right conformance language, and hoping you've selected accurately.

4. A testing methodology note. The audit report should document which tools were used, which assistive technology configurations were tested, when the testing occurred, and which page template types were included. This is the documentation you produce if a DOJ investigator asks how you determined your conformance status.

Ask: "Can you provide a sample audit report? Does your deliverable include an accessibility statement draft? How are findings organized and prioritized?"

Red flags to watch for

"WCAG compliant" as a deliverable. An auditor that promises to make your site "WCAG compliant" is selling remediation services, not an audit. An audit identifies what's wrong; remediation fixes it. Both may be valuable, but conflating them obscures which you're paying for.

Automated-only reports presented as full audits. If a vendor's sample report is a Lighthouse or axe-core output with a company header, they're repackaging a tool output, not conducting an audit.

Overlays included as part of the service. Some accessibility vendors bundle an overlay product with their audit service, positioning the overlay as the remediation solution. As covered in an earlier post on overlays and the DOJ Title II rule, overlays don't fix the underlying conformance failures and won't satisfy the rule.

No manual testing disclosed. If a vendor doesn't clearly describe their manual testing methodology in their proposal, assume they don't have one.

No references from government clients. Government websites have specific patterns — complex navigation, document libraries, form-heavy service pages — that require auditors with experience in the sector. Ask for references from comparable government agencies.

What good government auditing looks like in practice

The Parallax WCAG audit from Morton Technology Consulting was built specifically for Florida government agencies facing the April 2027 deadline. The audit covers 200 representative pages, uses both automated tools and manual testing with NVDA and VoiceOver, and delivers a full findings report, prioritized remediation roadmap, and a completed accessibility statement draft.

The sample report for a fictional Florida city government — showing the format, finding structure, severity ratings, and code examples — is available at morton-digital.com/parallax-sample-audit.

If you're still building your baseline before engaging an auditor, the quick self-assessment guide gives you a 10-minute pre-audit using free tools. And the WCAG Pre-Audit Readiness Kit ($149) includes a 49-criterion testing checklist, a remediation tracker, and a procurement guide specifically written for Florida agencies writing RFPs for WCAG auditors — including the specific scope and deliverable requirements to write into your RFP language.

---

*Morton Technology Consulting LLC, Tallahassee, FL. Questions about WCAG auditing or vendor evaluation: [email protected].*

Morton Technology Consulting LLC — WCAG 2.1 AA audits for Florida government agencies. Parallax audit → · WCAG Readiness Kit → · All posts →