Procurement Guide: What to Ask When Buying a Government Website Compliance Tool

TL;DR: Not all “website compliance” tools do the same job — some only check accessibility, some only run point-in-time scans, and few cover privacy, security, and performance together. Before you buy, pin vendors down on coverage breadth, which WCAG version they test, whether monitoring is continuous or one-time, multi-site support, finding ownership and remediation workflow, false-positive rates, reporting, and data handling. Demand a trial run against your own sites so you can verify accuracy claims with your own eyes. This guide gives you a categorized list of RFP questions you can drop straight into a solicitation.

Buying a government website compliance tool looks simple until you compare two demos and realize the vendors are describing completely different products. One scans for accessibility once and hands you a PDF. Another monitors continuously across hundreds of sites and tracks privacy, security, and performance alongside accessibility. Both call themselves “compliance tools.” With the ADA Title II WCAG 2.1 AA deadlines now in force — April 2026 for entities serving 50,000+ residents, April 2027 for smaller ones — agencies are buying fast, and a tool that checks the wrong things, or checks them once, can leave you exposed while feeling protected.

This guide gives you the questions to ask before you sign. It’s organized so you can lift the questions directly into an RFP or vendor evaluation, and it ends with a consolidated checklist. The goal is to make vendors prove their claims against your sites, not their curated demo.

Before You Talk to Vendors: Define the Job

Procurement goes badly when the buyer hasn’t decided what the tool is for. Settle these first:

• Scope of properties. One site, or a whole portfolio of agency sites and subdomains? This single answer eliminates half the market — many tools aren’t built for multi-site governance. (If you’re a state IT shop, see managing compliance across multiple agencies.)
• Which compliance domains. Accessibility only, or also privacy, security, and performance? Government compliance is broader than WCAG — the government website compliance checklist shows the full surface.
• Who acts on findings. Developers? Content editors? A central team handing tickets to agencies? The tool has to fit that workflow.
• Point-in-time vs. ongoing. Are you buying a one-time audit to hit a deadline, or an always-on system to stay compliant after it? These are different purchases.

With the job defined, here are the questions that separate the tools.

Coverage: What Does the Tool Actually Check?

The first and biggest differentiator. “Compliance” is a broad word, and many tools quietly cover only a slice.

Questions to ask:

• Does the tool check accessibility, privacy, security, and performance — or only one of these? Government compliance spans all four.
• For accessibility, which WCAG version and conformance level do you test against? You need 2.1 AA (the ADA Title II legal floor) at minimum; 2.2 AA is better since it’s backward-compatible and future-proofs you. Be wary of any tool still anchored to WCAG 2.0. See what changed from 2.1 to 2.2.
• Do you also map findings to Section 508? Relevant if any of your systems are federally funded. See Section 508 vs. ADA Title II.
• For privacy, do you detect third-party trackers, cookies set before consent, missing privacy policies, and risky data flows? This matters under state privacy laws and for cookie banner requirements.
• For security, do you check security headers, TLS configuration, and mixed content?
• For performance, do you measure Core Web Vitals?
• Do you test PDFs and other documents, or only HTML pages? Government sites are full of PDFs, a notorious accessibility gap. See PDF accessibility.
• How do you handle authenticated pages and forms behind logins (permit portals, benefits applications)? Much of the highest-stakes content lives behind authentication.

A tool that only does HTML accessibility scanning may be perfectly good — but you should know that’s what you’re buying, and plan to cover privacy, security, and PDFs another way.

Continuous vs. Point-in-Time Monitoring

This is the question that most affects whether the tool keeps you compliant or just tells you that you were compliant last March.

Questions to ask:

• Is this a one-time scan, a scheduled re-scan, or continuous monitoring?
• How often do you re-crawl, and can I control the frequency?
• Do you detect regressions — alert me when a newly published page or a site change introduces a new failure?
• Can you alert me when a third-party script or tracker changes on my site?

Why this matters: a government website is not static. Content editors publish daily, vendors push platform updates, and a site that passed an audit in March can fail by June after a few hundred new pages and a CMS upgrade. Compliance under Title II is an ongoing state, not a one-time certificate. A point-in-time audit is a snapshot; continuous monitoring is the movie. For deadline crunch a one-time audit has its place, but for sustained conformance you want monitoring that catches drift. (For the full audit-vs-monitoring distinction, our accessibility audit guide is a good primer.)

Multi-Site and Portfolio Management

Critical if you govern more than one site — a county with departmental sites, a university with many subdomains, a state with dozens of agencies.

Questions to ask:

• Can the tool manage many sites and subdomains under one account, with per-site and rolled-up views?
• Do you support role-based access so each agency or department sees its own results while a central team sees everything?
• Can you produce comparative scorecards ranking sites or agencies?
• How is pricing structured for many sites — per site, per page, per scan, per seat? (See pricing below; multi-site pricing models vary enormously.)
• Can you scope crawls (include/exclude paths, set crawl depth, respect rate limits) so we don’t hammer fragile legacy systems?

A tool priced and architected for a single site rarely scales gracefully to a portfolio. If you’re managing an estate, make portfolio support a hard requirement, not a nice-to-have.

Ownership, Workflow, and Remediation

A list of problems isn’t worth much if nobody can act on it. The best tools fit into how your teams actually work.

Questions to ask:

• How are findings assigned and tracked to resolution? Is there a workflow, or just a report?
• Do you integrate with our issue tracker (Jira, ServiceNow, GitHub, Azure DevOps)?
• Do findings include specific remediation guidance — the element, the code, and how to fix it — or just “fails SC 1.4.3”?
• Can findings be routed to the right owner: developers for code, content editors for alt text and headings, a central team for vendor issues?
• Can we suppress or annotate known false positives and accepted risks so they don’t keep resurfacing?
• Is there a way to track trend over time and show progress to leadership?

This is where tools built for developers and tools built for content teams diverge. Government sites are mostly maintained by non-technical content staff, so workflow that routes a missing-alt-text finding to the person who published the image — not to a developer — is a major practical advantage.

Accuracy and False Positives

Automated tools find only part of the picture, and they sometimes cry wolf. Both facts matter for buying.

Questions to ask:

• What percentage of WCAG criteria can your automated checks detect? (Honest vendors acknowledge automation catches roughly 30–50% of issues; the rest need human testing. A vendor claiming “100% automated WCAG coverage” is overselling.)
• What is your approach to false positives, and what’s a typical rate?
• Do you offer or recommend manual/human testing to cover what automation can’t — screen-reader testing, keyboard navigation, cognitive flows?
• How do you keep your rules current with WCAG and DOJ guidance updates?
• Can I see the raw evidence behind each finding so my team can verify it?

The danger isn’t just missing issues — it’s false confidence. A tool that reports “no issues found” while real barriers exist is worse than no tool, because it tells leadership the job is done. Insist that the vendor be candid about automation’s limits and offer a path to cover the manual remainder.

Reporting and Evidence

If you face a complaint or an audit, you’ll need documentation. Reporting also drives internal accountability.

Questions to ask:

• Can you produce reports for different audiences — an executive summary for leadership, technical detail for developers, an evidence trail for legal?
• Do reports timestamp findings and remediation, creating a record of good-faith, ongoing effort?
• Can we export data (PDF, CSV, API) for our own dashboards and records?
• Do you map findings to specific WCAG success criteria so they’re defensible and traceable?
• Can the tool help demonstrate the history of conformance, not just current state? A documented record of continuous effort is valuable if a complaint arises. See what happens in a DOJ complaint.

Data Handling and Security

You’re pointing a third-party tool at government web properties — sometimes including authenticated areas. Treat the vendor as you would any system handling government data.

Questions to ask:

• Where is data hosted and stored (US data centers, data residency)?
• What security certifications or authorizations do you hold — SOC 2, ISO 27001, FedRAMP or StateRAMP, or an equivalent? (Full FedRAMP authorization is uncommon for monitoring tools, so ask what bar they actually meet and whether it satisfies your agency’s requirements.)
• How do you handle any personal or sensitive data encountered while crawling, especially on authenticated or form pages?
• Do you sign a data processing agreement / data security addendum consistent with our state requirements?
• What is your subprocessor list and breach-notification commitment?
• Can the tool crawl without storing the full content of sensitive pages?

For state-level buyers, align these questions with your existing IT security review and procurement security clauses. The CISA cybersecurity guidance for government websites is a useful reference for the security posture you should expect.

Pricing and Contract Terms

Finally, the commercial questions — and the ones most likely to surprise you later.

Questions to ask:

• How is pricing structured — per site, per page, per scan, per seat, or flat? Page-based pricing can balloon on large government sites with thousands of PDFs.
• Are all compliance domains included, or are privacy/security/performance priced as add-ons?
• Is continuous monitoring included, or only periodic scans at the base tier?
• What are the contract length and renewal terms, and is there a usable trial or pilot?
• Are onboarding, training, and support included or extra?
• Does the contract include accessibility and security commitments from the vendor’s own product (ironically, some compliance tools aren’t accessible)? Request the vendor’s own VPAT — see VPATs in procurement.

The RFP Question Checklist

Drop these straight into a solicitation or scoring matrix.

Coverage

• Covers accessibility, privacy, security, and performance — or which subset?
• Tests against WCAG 2.1 AA at minimum; 2.2 AA available?
• Maps to Section 508 where needed?
• Scans PDFs and documents, not just HTML?
• Handles authenticated pages and forms?

Monitoring model

• Continuous monitoring vs. point-in-time?
• Configurable re-crawl frequency?
• Regression and tracker-change alerts?

Multi-site

• Many sites/subdomains under one account?
• Role-based access (per-agency + central rollup)?
• Comparative scorecards?
• Crawl scoping and rate limiting?

Workflow

• Findings assignable and trackable to resolution?
• Issue-tracker integrations?
• Element-level remediation guidance?
• Routing to content editors vs. developers?
• Suppress/annotate false positives?

Accuracy

• Honest statement of automated coverage (~30–50%)?
• False-positive approach and rate?
• Manual testing offered or recommended?
• Raw evidence for each finding?

Reporting

• Audience-specific reports (exec, dev, legal)?
• Timestamped history of conformance?
• Export via PDF/CSV/API?
• Findings mapped to specific success criteria?

Data handling

• US hosting / data residency?
• SOC 2 / ISO 27001 / FedRAMP or StateRAMP — or equivalent?
• DPA / data security addendum available?
• Subprocessor list and breach notification?

Commercial

• Pricing model (site/page/scan/seat/flat)?
• All domains included vs. add-ons?
• Continuous monitoring included at base tier?
• Pilot/trial available?
• Vendor’s own product VPAT provided?

The biggest mistake in buying a compliance tool isn’t picking the wrong vendor — it’s buying a point-in-time scanner when you needed continuous, portfolio-wide monitoring, and discovering the gap only after a complaint lands. Define the job, ask the hard questions, and insist on a pilot against your own sites so accuracy claims survive contact with reality. Govzu was built for government buyers running exactly this evaluation: continuous monitoring across accessibility, privacy, security, and performance, multi-site management with per-agency and rollup views, and reporting designed to stand up to a DOJ inquiry. Run it against your own sites during procurement and let the evidence make the case.