Most public agencies are not exposed under ADA Title II because they don't care about accessibility.
They're exposed because accessibility risk hides in places no one owns, compounds in places no one monitors, and surfaces at the worst possible moment — when a complaint has already been filed and the documentation doesn't exist to defend the work that was done.
Title II risk is rarely about one dramatic, obvious failure. It's almost never the homepage. It's almost never the thing your web team is actively thinking about.
It's the permit application that traps keyboard users in a date picker loop. It's the 4,000 scanned PDFs sitting in your document library that no screen reader has ever successfully read. It's the payment portal your vendor built three years ago that failed its last accessibility test and nobody knew. It's the six departments publishing content independently with zero accessible publishing standards and no one checking.
That's where the exposure lives. Not in neglect. In structure. Or the absence of it.
This is a breakdown of the eight areas where public agency ADA Title II exposure most commonly concentrates: what causes it, why it persists, and what actually reduces it.
1. Forms and Transactional Workflows
If you want to understand where ADA Title II enforcement pays the most attention, start here.
Public agencies exist to process transactions. Residents don't visit your website to read about your agency. They visit to do something: apply for a permit, pay a tax bill, request a public record, schedule an inspection, register for an event, renew a license. These are the workflows that matter most to the people you serve. And they are the workflows that receive heightened scrutiny in enforcement proceedings because they represent the core function of government digital services.
When a transactional workflow is inaccessible, it is not a usability inconvenience. It is a denial of access to a government service. That distinction matters legally, and enforcement bodies treat it accordingly.
The most common transactional failure patterns:
- Form fields without programmatic labels, meaning a screen reader user has no way to know what information a field is asking for
- Error messages that communicate failure only through color — a red border, a red icon — with no text explanation, blocking users with color vision deficiencies entirely
- Required field indicators that are visually obvious but not announced to assistive technology, causing form submissions to fail without the user understanding why
- Date pickers built with custom JavaScript components that cannot be operated via keyboard, locking out users who cannot use a mouse
- CAPTCHA systems on public service portals with no audio alternative, functioning as a complete barrier for screen reader users
- Multi-step application flows where dynamic content updates — "step 2 of 4," error states, confirmation messages — are not announced to assistive technology
- Session timeout warnings that cannot be dismissed or extended via keyboard before the session expires and all entered data is lost
The enforcement pattern here is consistent: agencies fix homepage contrast ratios and navigation structure, then leave their permit applications, payment portals, and public records systems entirely unaddressed. That is fundamentally misaligned prioritization. The homepage is not where residents get blocked from accessing government services. The application system is.
If your agency has not specifically tested its transactional workflows for keyboard navigation, screen reader compatibility, and error handling, your highest-risk surfaces have not been evaluated.
2. PDFs and the Public Document Library
For most public agencies, the PDF library is the real accessibility battleground. It is also the most underestimated.
Agencies frequently think of their website when they think of accessibility. But the volume of accessibility exposure sitting in their document library often dwarfs what's on the site itself. Board agendas. Meeting minutes. Budget documents. Environmental studies. Permit applications. Public notices. Policy manuals. Annual reports. Each one is a potential accessibility failure. And most agencies have hundreds, sometimes thousands, of them publicly accessible on their domain.
The most common document failure patterns:
- Scanned documents posted as flat image PDFs — the most pervasive issue in local government. A scanned board agenda is an image. A screen reader sees nothing. Residents who are blind or have low vision receive zero information from that document regardless of how critical it is.
- PDFs exported from Word, PowerPoint, or InDesign without accessibility structure — no tagged headings, no defined reading order, no alt text on charts or figures. These documents may look fine visually. They are navigated in random order by assistive technology.
- Budget reports and financial documents with complex tables that have no programmatic header structure, making relationships between data cells impossible to interpret without visual context
- Environmental and infrastructure reports with charts, graphs, and maps embedded as images without text alternatives
- Multi-column permit forms without defined reading order, causing screen readers to read across columns rather than down, producing nonsensical output
- Emergency and public safety notices posted as scanned images, denying access to critical information to the residents who may need it most
The scale problem is the governance problem.
An agency that has been publishing PDFs for ten years may be looking at thousands of documents that have never been reviewed for accessibility. Attempting to fix all of them is not realistic. Fixing none of them is not defensible. The answer is prioritization — distinguishing between high-traffic, active service documents that need immediate remediation and archival content that can be addressed on a longer timeline.
A defensible document accessibility program includes: a document inventory, a risk classification that separates active from archival content, prioritized remediation starting with public notices, forms, and meeting documents, and a going-forward standard for all new document uploads.
Without that structure, document risk grows every week. And when complaints cite inaccessible documents — which they frequently do, because documents often contain the information residents most need — the absence of a prioritization framework makes the situation significantly harder to defend.
3. Third-Party Vendors and Embedded Tools
This is the exposure area that surprises agencies most. And it is the one with the most dangerous misconception attached to it.
The misconception: "If the vendor built it, the vendor is responsible for its accessibility."
The reality under ADA Title II: public entities are accountable for the accessibility of services delivered to the public, regardless of who built the underlying system. Vendor contracts may include accessibility language. That language does not transfer liability. If a resident cannot access your online payment portal because your payment vendor's platform fails keyboard navigation, your agency has an accessibility barrier. The fact that a third party created it is a procurement and contract management issue, not a compliance shield.
The most common vendor-related failure patterns:
- Embedded iFrames without accessible labeling, invisible to screen readers navigating by landmark or region
- Third-party permit portals and licensing systems with inconsistent or broken keyboard navigation across their own components
- GIS mapping tools that require precise mouse interaction with no keyboard alternative and no accessible equivalent pathway
- Payment processing systems that fail screen reader testing on critical actions — selecting a payment method, confirming a transaction amount, receiving a confirmation
- Online scheduling and reservation systems with non-navigable calendar components
- Chat and support widgets that trap keyboard focus inside the widget without an escape mechanism
- External login systems with error messages that identify failure without identifying cause or providing actionable guidance
What vendor risk management actually requires:
Accessibility review during procurement — before a vendor is selected, not after they are embedded. Current VPAT documentation (Voluntary Product Accessibility Template) reviewed for WCAG 2.1 AA conformance, not just existence. Accessibility requirements in contract language with defined remediation obligations when issues are identified. Ongoing testing of vendor tools after major updates, because a conformant tool at procurement may not remain conformant through the vendor's own development cycle.
Accessibility governance must extend beyond your CMS and your internal web team. It must extend to every tool a resident interacts with through your digital services.
4. Decentralized Publishing and Content Drift
This is the structural problem that makes accessibility feel impossible to sustain at scale. And it is entirely predictable once you understand how public agencies actually operate.
Most agencies do not have centralized content control. Departments manage their own sections. Communications staff in each division publish independently. Temporary or seasonal staff upload documents during high-volume periods. Updates happen quickly, especially for time-sensitive content like meeting agendas, public notices, and emergency announcements. Web teams are small and cannot review every upload.
The result is a publishing environment where accessibility standards exist on paper but cannot be enforced in practice — because the governance structures that would enforce them do not exist.
What operational drift looks like in practice:
A department publishes a new program page with images and no alt text because the coordinator who created it was never trained on accessibility standards. A seasonal employee uploads fifty event flyers as image-based PDFs because that's the format they received from design. A developer makes a quick template adjustment for a new feature without accessibility review and introduces a keyboard navigation failure that affects every page using that template. A new embedded widget gets added to the events page without any testing. None of this is malicious. All of it is structural.
What actually prevents content drift:
Editor training with documented completion rates — not a one-time onboarding session, a recurring program with standards that are updated as requirements evolve. Accessible content guidelines specific to the tools and workflows your content creators actually use. Pre-publish checklists embedded in the CMS workflow where possible. Template-level controls that make inaccessible publishing harder than accessible publishing. Recurring monitoring that catches what slips through anyway.
Without these structures, drift is not a risk — it is a certainty. Compliance will regress at exactly the rate your organization publishes new content. And in most public agencies, that rate is high.
5. Accessibility Overlays and the False Security They Create
Accessibility overlays are software tools — typically a JavaScript widget added to a website — that claim to improve or remediate accessibility automatically. They are marketed aggressively to public agencies as compliance solutions, often with language suggesting they provide "ADA compliance" or "WCAG conformance."
They do not.
Overlays can provide certain user-facing adjustments: contrast toggles, text resizing, some cursor modifications. Some include automated fixes for specific, detectable issues. They are not without utility as supplemental tools.
What they cannot do is address the categories of accessibility failure that create the most exposure.
- They cannot remediate structural document accessibility. A scanned PDF remains a scanned PDF regardless of what overlay is running on the page where it is linked.
- They cannot fix inaccessible transactional logic. An unlabeled form field, a keyboard trap in a date picker, a CAPTCHA without an audio alternative — these require code-level remediation that no overlay can substitute for.
- They cannot address vendor tool failures. An embedded third-party payment portal with keyboard navigation issues is not corrected by an overlay on your agency's page.
- They cannot create the governance documentation that defensible compliance requires. An overlay produces no audit history, no remediation log, no prioritization framework, no monitoring record.
The core problem with relying on an overlay: agencies that use them often believe they have addressed their compliance obligation. Enforcement bodies and courts have been consistent in rejecting that belief. In multiple cases, agencies and organizations that relied on overlays as their primary accessibility solution found that the presence of an overlay did not constitute defensible compliance when challenged.
Overlays may reduce some visible issues. They do not create defensible infrastructure. And the false confidence they generate can be more dangerous than the issues they partially address, because it delays the structural work that actually reduces exposure.
6. Documentation Gaps
This is the least visible risk category. It is frequently the most consequential.
Here is a scenario that plays out more often than it should: an agency has genuinely been working on accessibility. Their web team has fixed real issues. They've done real work. But when a complaint is filed and an enforcement inquiry opens, they cannot demonstrate what was done, when it was done, who decided to prioritize it, or what timeline exists for remaining items.
The work happened. The evidence does not exist.
In that scenario, even meaningful remediation effort becomes legally indefensible — not because the work was wrong, but because documentation is what transforms effort into evidence. And evidence is what defensibility is built from.
What enforcement bodies need to see:
A dated baseline audit report that identifies issues by WCAG criterion, severity level, and affected surface. A risk-based prioritization framework that explains how the agency decided what to address first. A remediation log with issue IDs, assigned owners, status, and resolution timestamps. A monitoring history showing recurring evaluation, not just a single past event. A documented complaint intake and response process. Executive-level reporting records showing that leadership was informed and engaged. Vendor VPAT review documentation for embedded third-party tools.
The through line in every one of these: documentation is not bureaucracy. It is the structural record that allows an organization to say, credibly and specifically, "here is our process, here is what we found, here is what we fixed, here is what remains, here is how we monitor."
Without that record, even good-faith effort cannot be demonstrated. And the absence of documentation in an enforcement context does not look like good faith. It looks like absence of program.
7. The Compounding Nature of Exposure
ADA Title II risk rarely announces itself. It accumulates.
Each new document added to the library without accessibility review. Each vendor update that introduces a new keyboard navigation failure. Each template modification that no one tested. Each new staff member who publishes content without training. Each third-party tool embedded without a VPAT review.
Individually, these events are minor. Collectively and over time, they build structural exposure that is difficult to quantify and harder to remediate under pressure.
Agencies that manage accessibility reactively — addressing issues only when complaints arrive or enforcement looms — find themselves in a cycle. Emergency remediation. Legal review. Internal scrambling. Costs concentrated at the worst possible moments. And then, six to twelve months later, the same cycle begins again because the structural conditions that created the original exposure were never addressed.
Governance breaks that cycle. Not by achieving perfection — that is not the standard. By creating the monitoring, remediation, documentation, and ownership structures that catch issues before they compound and demonstrate sustained effort before it is demanded.
8. How Public Agencies Actually Reduce Exposure
Reducing ADA Title II exposure does not require a crash remediation sprint or a complete website rebuild. It requires structured, sustained response built around the right priorities.
Effective exposure reduction programs are built in a specific sequence:
Start with a baseline audit across templates and high-impact workflows. Not just the homepage. The permit applications. The payment portals. The public records systems. The document library. The embedded vendor tools. An honest, comprehensive picture of where risk actually lives.
Classify issues by risk and impact. Not everything needs to be fixed immediately. Transactional workflow failures that directly block access to government services come first. Template-level issues that affect hundreds of pages come next. Low-traffic legacy content is a longer-term effort. Prioritization is what makes the program sustainable.
Build a remediation roadmap with defined timelines and ownership. Who is responsible for what. When it will be addressed. What the success criteria are. This is the document that turns a list of issues into a program.
Allocate dedicated remediation capacity. This is where most programs fail. Accessibility competes with other development priorities, and without defined allocation — whether internal hours or an external partner — it consistently loses. Infrastructure means remediation capacity is planned, not improvised.
Implement recurring monitoring. Monthly automated scanning with human review of flagged issues. Quarterly manual QA of key workflows. Annual comprehensive audit updates. The cadence can scale with capacity, but the principle is the same: recurring evaluation, not periodic panic.
Document everything. The audit. The prioritization decisions. Every remediation action with timestamps. Every monitoring scan. Every executive report. The documentation program runs in parallel with the remediation program, because one without the other is incomplete.
Build vendor oversight into procurement. VPAT review before tools are selected. Accessibility requirements in contract language. Ongoing testing of vendor tools after major updates. Accountability frameworks that give the agency recourse when vendor updates create new failures.
Assign clear ownership at every level. Central IT. Department coordinators. Executive leadership. Legal. Everyone has a role. The role needs to be named, documented, and resourced.
Exposure Is Structural. So Is the Solution.
Most accessibility risk in public agencies does not come from bad intent. It comes from complexity. From decentralization. From vendor reliance. From document volume. From content velocity. From the gap between policy and practice.
Those are structural conditions. They require structural solutions.
Monitoring. Remediation. Documentation. Governance. Ownership. These are not abstract commitments. They are operational programs with specific components, defined cadences, and named accountabilities.
The agencies that are managing this well have built those programs. They are not perfect. They do not claim to be. But they can demonstrate structured, sustained effort — and that demonstration is what separates a defensible compliance posture from an exposed one.
If You Need a Clear View of Your Agency's Exposure
If you are not certain where accessibility risk lives inside your digital environment, the first step is not panic and it is not a crash remediation sprint. It is an honest, structured assessment.
A governance-focused ADA risk assessment for public agencies identifies:
- High-risk transactional workflows requiring immediate remediation attention
- Document library scope and prioritization approach
- Third-party vendor exposure and VPAT status
- Content publishing governance gaps
- Documentation completeness and defensibility
- Governance ownership and structural weaknesses
From there, your agency can prioritize intelligently, allocate resources where they create the most risk reduction, and build a compliance program that holds up under scrutiny.