WCAG 2.1 AA is the web accessibility standard government agencies use to make digital services perceivable, operable, understandable, and robust under ADA Title II.
If you have spent any time in an ADA Title II compliance conversation, you have heard the acronym. WCAG. Web Content Accessibility Guidelines. The technical standard your agency is expected to meet. The benchmark enforcement bodies use when evaluating whether your digital services are accessible.
What you may not have heard is a clear, plain-language explanation of what WCAG 2.1 AA actually requires in terms of the work your team does every day.
Most explanations of WCAG fall into one of two categories. Either they are written for developers — full of technical specification language that means nothing to a department coordinator uploading board agendas — or they are written at such a high level of abstraction that they tell you nothing useful about what you are actually supposed to do differently.
This is neither of those. This is WCAG 2.1 AA explained for the people who run public agency digital services: IT directors, web managers, communications staff, department coordinators, and the leadership responsible for understanding what compliance actually requires.
What WCAG Is and Where It Comes From
WCAG stands for Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium, an international standards body that develops technical specifications for the web. The current required version for ADA Title II compliance is WCAG 2.1 at Level AA.
The "2.1" refers to the version. WCAG 2.1 was published in 2018 and builds on the prior version, WCAG 2.0, adding requirements that specifically address mobile accessibility and users with cognitive and low vision disabilities.
The "AA" refers to the conformance level. WCAG has three levels: A, AA, and AAA. Level A is the minimum — the most basic accessibility requirements. Level AA is the standard required by ADA Title II and most federal accessibility mandates. Level AAA is the highest level, with requirements that are not feasible to meet for all content types, which is why it is not required as a blanket standard.
When your agency is evaluating its ADA Title II compliance posture, WCAG 2.1 Level AA is the benchmark. Every success criterion at Level A and Level AA must be satisfied for a digital property to be considered conformant.
The Four WCAG 2.1 AA Principles: POUR
WCAG 2.1 is organized around four principles that define what it means for digital content to be accessible. The principles spell out POUR: Perceivable, Operable, Understandable, and Robust.
Every WCAG success criterion falls under one of these four principles. Understanding what each principle is asking for is the fastest way to build an intuition for accessibility requirements without needing to read the full technical specification.
Perceivable: Can Everyone Access the Information?
The Perceivable principle requires that information and interface components be presented in ways that users can perceive regardless of sensory ability. In practical terms, this means that content cannot rely exclusively on a single sense — like sight — to be accessed and understood.
What this looks like in public agency work:
Images need alternative text. Every image on your website that conveys information — a photo of a construction detour, a chart showing budget allocations, an infographic summarizing a public health initiative — needs a text description that a screen reader can read aloud to a blind user. The alternative text should describe what the image communicates, not just what it depicts. An image of a flood zone map needs alt text that conveys the relevant information the map is communicating, not just "map of flood zones."
Decorative images — images that are purely visual and convey no information — should have empty alt text so screen readers skip them rather than reading out unhelpful descriptions.
Videos need captions. Any video published on your agency website needs accurate closed captions. This includes council meeting recordings, public safety announcements, instructional content, and recruitment videos. Auto-generated captions from video platforms are not sufficient — accuracy requirements for WCAG conformance are higher than what automated captioning typically produces, particularly for specialized government terminology.
Audio content needs transcripts. If your agency publishes audio-only content — recorded public hearings, podcast-style communications, audio announcements — that content needs a text transcript so users who are deaf or hard of hearing can access it.
Color cannot be the only way information is conveyed. If your agency's website uses a red asterisk to mark required form fields, that indicator is invisible to users with color vision deficiencies unless it is accompanied by a text label. If your budget charts differentiate between departments only through color coding, users who cannot distinguish those colors receive no information about the data. Color can be used as an additional indicator, but it cannot be the sole indicator.
Color contrast must meet minimum ratios. The text on your agency website must meet minimum contrast ratios against its background to be readable by users with low vision. The standard for normal-sized text is a ratio of 4.5 to 1. Large text has a slightly lower threshold of 3 to 1. This applies to text in images, text in buttons and form elements, and any text overlaid on photographs or graphic backgrounds.
Documents must have accessible structure. PDFs and other downloadable documents are covered under the Perceivable principle. A document that has been scanned to PDF is a flat image — it has no text layer, no structural information, and nothing a screen reader can interpret. Every word on the page is invisible to assistive technology. This is one of the most widespread and highest-risk accessibility failures in public sector environments. Board agendas, meeting minutes, public notices, permit forms, and annual reports all need to be properly tagged with reading order, heading structure, and alternative text for any embedded images or charts.
Operable: Can Everyone Navigate and Interact?
The Operable principle requires that interface components and navigation be usable by everyone, including people who cannot use a mouse and people who rely on alternative input methods like keyboards, switch devices, or voice control software.
Keyboard accessibility is the primary benchmark. If a user cannot complete every action on your website using only a keyboard — no mouse, no touchscreen, just the Tab key, arrow keys, Enter, and Space — the content fails the Operable principle.
What this looks like in public agency work:
Every interactive element must be keyboard accessible. Links, buttons, form fields, dropdown menus, date pickers, modal windows, file upload tools, map controls, accordion panels — every element a user can interact with must be reachable and operable via keyboard. This is not an edge case accommodation. This is the baseline requirement for operability.
Focus must be visible. When a keyboard user tabs through a page, there must be a clearly visible indicator showing which element currently has focus. Many agency websites suppress the default browser focus outline for aesthetic reasons without replacing it with a custom indicator. The result is an invisible cursor — a keyboard user navigating the page with no visual feedback about where they are. This is a complete operability failure for sighted keyboard users.
Tab order must be logical. The sequence in which focus moves through a page as a user presses Tab should follow the visual and content hierarchy. A tab order that jumps around the page in an illogical sequence disorients keyboard users and makes navigation unpredictable.
No keyboard traps. If keyboard focus enters a component — a modal window, a date picker, a video player — the user must be able to exit that component using the keyboard. A keyboard trap occurs when focus enters a component and cannot leave, effectively locking the user in place. This is one of the most severe operability failures because it stops navigation entirely.
Skip navigation links. Every page should include a skip navigation link as the first focusable element. This is a link that allows keyboard users to bypass the global navigation and jump directly to the main content. Without it, a keyboard user must tab through every item in the navigation menu on every page before reaching the content they came to access.
Time limits must be controllable. If your transactional workflows — permit applications, payment systems, scheduling tools — include session timeouts, users must be warned before the session expires and given the ability to extend it using keyboard only. A session that expires silently while a user is completing a transaction, or that cannot be extended without mouse interaction, is an operability failure.
No content that seizure or vestibular disorders. Nothing on your agency website should flash more than three times per second. Flashing content can trigger photosensitive seizures. Content with significant motion can cause distress for users with vestibular disorders. If you are using animated banners, auto-playing video, or attention-grabbing motion effects, they need to be evaluated against these requirements.
Understandable: Is the Content and Behavior Clear?
The Understandable principle requires that content be readable and that interface behavior be predictable. This is the principle that most directly reflects the quality of the experience for users with cognitive disabilities, users who are new to digital interfaces, and users navigating unfamiliar systems under stress.
What this looks like in public agency work:
Form fields need visible, programmatically associated labels. Every field in every form on your agency website needs a visible label that is programmatically associated with the field so that assistive technology can announce what the field is asking for when a user focuses on it. Placeholder text — the grey text that appears inside a field and disappears when the user starts typing — is not a label. It is not visible when the user is filling in the field, and it is not reliably announced by screen readers. It cannot substitute for a proper label.
Error messages must be specific and actionable. When a form submission fails, the error message must identify which field failed, what the problem is, and specifically how to correct it. "Error" displayed in red text is not a useful error message. "Please enter your phone number in the format 555-555-5555" is. Error messages that rely on color alone — a red border around a field, a red icon — fail users with color vision deficiencies and fail users whose screen readers do not announce visual state changes.
Navigation must be consistent. Navigation that changes structure, labeling, or order across different pages creates orientation failures for screen reader users and cognitive load for all users. A user who learns to navigate your website on the homepage should not need to re-learn it on the permit application page. Consistency is an understandability requirement, not just a design preference.
Language must be specified. The language of each page and each document must be specified in the code so that assistive technology uses the correct voice and pronunciation profile. A French-language document read aloud in English pronunciation is unintelligible. If your agency publishes content in multiple languages, language specification is especially important.
Instructions must not rely on sensory characteristics alone. Instructions that tell users to "click the green button" or "see the form on the right" assume that users can see color and spatial positioning. Instructions must describe what an element does, not just how it looks.
Robust: Is the Content Compatible With Assistive Technologies?
The Robust principle requires that content be compatible with current and future assistive technologies. This is the principle most directly connected to code quality and governance, because it is where technical implementation decisions determine whether the content that looks accessible actually functions accessibly across the range of tools that users with disabilities rely on.
What this looks like in public agency work:
HTML must be valid and semantic. Assistive technologies build a model of each page from its markup. Invalid HTML and incorrect use of semantic elements produce unreliable or misleading models. A page that looks accessible visually may be completely disorganized from the perspective of a screen reader if the underlying HTML is structurally incorrect.
ARIA must be used correctly. ARIA — Accessible Rich Internet Applications — is a set of attributes that allow developers to communicate roles, states, and properties to assistive technology for dynamic content that standard HTML cannot describe on its own. When ARIA is used correctly, it dramatically improves the accessibility of complex interactive components. When it is used incorrectly — which is common — it actively breaks accessibility by overriding correct semantic information with incorrect information. The first rule of ARIA is not to use it if a native HTML element can do the job instead. ARIA misuse is one of the most common causes of accessibility failures in government websites that have had recent accessibility work done.
Vendor integrations must not override accessibility controls. Many county and agency websites rely on third-party tools — payment processors, scheduling systems, GIS platforms, permit portals — that are integrated into the primary website experience. When these tools update on their own release schedules, they can introduce ARIA conflicts, override keyboard navigation behavior, or introduce focus management failures that break the accessibility of the integrated experience. The Robust principle is where vendor monitoring becomes a technical compliance requirement rather than just a governance best practice.
Content must work across assistive technology combinations. WCAG does not specify a single assistive technology stack for testing. Testing with one screen reader on one browser is not sufficient to validate robustness. Common combinations include NVDA with Chrome and Firefox, JAWS with Edge and Chrome, and VoiceOver with Safari on both macOS and iOS. A page that passes with one combination may fail significantly with another.
The Success Criteria That Matter Most for Public Agencies
WCAG 2.1 AA contains 50 success criteria across Levels A and AA. Not all of them carry equal weight in public sector environments. These are the criteria that appear most frequently in public agency accessibility audits and enforcement proceedings.
1.1.1 Non-text Content (Level A). Alternative text for images. This is the most universally cited WCAG failure in public sector audits. Charts without text alternatives, scanned documents posted without OCR processing, and decorative images with missing or incorrect alt text all fail this criterion.
1.3.1 Info and Relationships (Level A). Information conveyed through visual presentation must be programmatically determinable. This is the criterion governing form label associations, table header relationships, and heading hierarchy. A form field with a visual label that is not programmatically connected to the field fails this criterion even if it looks correct on screen.
1.4.3 Contrast Minimum (Level AA). Text must meet a contrast ratio of 4.5 to 1 against its background for normal text and 3 to 1 for large text. This is the criterion most likely to produce a high volume of findings in an automated scan and one of the most commonly cited in complaints involving agency websites.
1.4.5 Images of Text (Level AA). Text should be presented as actual text rather than as an image of text wherever possible. Images of text cannot be resized, reflowed, or read by screen readers. Public notices and announcements published as image files rather than structured text fail this criterion.
2.1.1 Keyboard (Level A). All functionality must be operable via keyboard. This is the operability baseline and the criterion most directly tested through keyboard-only navigation testing of transactional workflows.
2.4.3 Focus Order (Level A). Focus order must be logical and meaningful. This criterion governs the tab sequence through pages and within interactive components.
2.4.7 Focus Visible (Level AA). Any keyboard-operable interface must have a visible focus indicator. This criterion is the one most commonly violated by agencies that have suppressed default browser focus styles for visual design reasons.
3.3.1 Error Identification (Level A). When an input error is detected, the item that is in error must be identified and the error described in text. This criterion governs error messaging in forms and is one of the most consistently cited failure points in government transactional workflows.
3.3.2 Labels or Instructions (Level A). Labels or instructions must be provided for content that requires user input. This criterion governs form field labeling and the requirement that instructions be provided for formatting requirements like date formats and phone number formats.
4.1.2 Name, Role, Value (Level A). For all user interface components, the name, role, and any state must be programmatically determinable. This criterion governs ARIA implementation and is the technical foundation for screen reader compatibility with interactive components.
What WCAG Conformance Actually Requires
WCAG conformance is binary at the criterion level. A page either satisfies a success criterion or it does not. Partial conformance does not exist within a given criterion — if a form has twenty fields and eighteen of them have proper labels but two do not, the page fails 3.3.2.
Full conformance with WCAG 2.1 AA means satisfying all Level A and Level AA success criteria across every page and every digital property under the agency's obligation. In practice, most organizations work toward conformance rather than claiming it — building a documented program of audit, prioritization, remediation, and monitoring that demonstrates structured progress toward the standard.
What ADA Title II enforcement evaluates is not whether every success criterion has been perfectly satisfied across every page simultaneously. It is whether the agency has a documented, ongoing compliance program built around the standard. That program starts with understanding what the standard actually requires — which is what this guide is for.
WCAG 2.1 vs. WCAG 2.2: What You Need to Know
WCAG 2.2 was published in October 2023 and introduced nine new success criteria. The DOJ's ADA Title II rule references WCAG 2.1 AA as the required standard, not WCAG 2.2.
However, WCAG 2.2 is backwards compatible — every Level A and AA criterion in WCAG 2.1 is carried forward into WCAG 2.2 with one exception (4.1.3 Status Messages was adjusted). Agencies that achieve WCAG 2.1 AA conformance are well-positioned to move toward WCAG 2.2 AA as best practice guidance continues to evolve.
For compliance purposes, WCAG 2.1 Level AA is the standard your program should be built around.
Putting WCAG to Work in Your Agency
Understanding WCAG at the conceptual level is the starting point. The next step is applying it to the specific surfaces where your agency's exposure actually lives — the permit applications, the payment portals, the board documents, the public records systems, the vendor-hosted tools — through an audit that identifies where specific success criteria are not being satisfied and builds the prioritized remediation roadmap that drives the work forward.
WCAG is not a pass/fail exam you take once. It is the technical standard that governs an ongoing compliance program. The program is built on the standard. The standard does not build the program for you.
Learn about how to conduct a WCAG 2.1 AA audit now: How to Conduct a WCAG 2.1 AA Audit for a Public Agency
Learn more about what ADA Title II requires for public agencies: What ADA Title II Requires for Public Agencies by April 24th, 2026
FAQ: WCAG 2.1 AA for Government Teams
What does WCAG 2.1 AA stand for? WCAG stands for Web Content Accessibility Guidelines, a technical standard published by the World Wide Web Consortium. The "2.1" refers to the version, published in 2018. The "AA" refers to the conformance level — the middle tier of three levels (A, AA, and AAA) and the standard most public agencies are required to meet under ADA Title II. Level AA builds on Level A by adding requirements that address a broader range of disabilities and use cases, including low vision, cognitive disabilities, and mobile accessibility.
Is WCAG 2.1 AA required for public agencies? Yes. The Department of Justice's final ADA Title II rule, published in 2024, establishes WCAG 2.1 Level AA as the technical standard for digital accessibility compliance for state and local government entities. Public agencies must meet all Level A and Level AA success criteria across their websites, portals, online forms, downloadable documents, and embedded third-party tools. Compliance deadlines vary by jurisdiction size, but the standard itself applies universally to public entities covered under Title II.
What are the four principles of WCAG? The four principles of WCAG are Perceivable, Operable, Understandable, and Robust — often abbreviated as POUR. Perceivable means information must be presentable in ways all users can access regardless of sensory ability. Operable means all functionality must be navigable and usable without a mouse. Understandable means content and interface behavior must be clear and predictable. Robust means content must be compatible with current and future assistive technologies. Every WCAG success criterion falls under one of these four principles.
How many success criteria does WCAG 2.1 AA include? WCAG 2.1 AA includes 50 success criteria across Level A and Level AA. Level A contains 30 criteria covering the most fundamental accessibility requirements. Level AA adds 20 additional criteria addressing color contrast, captions for live video, resize text behavior, focus visibility, and other requirements that extend accessibility to a broader range of users and disability types. All 50 criteria must be satisfied for a digital property to be considered WCAG 2.1 AA conformant.
What is the difference between WCAG 2.1 and WCAG 2.2? WCAG 2.2 was published in October 2023 and introduced nine new success criteria, with a focus on users with cognitive disabilities and mobile users. The DOJ's ADA Title II rule references WCAG 2.1 AA as the required standard, not WCAG 2.2. However, WCAG 2.2 is backwards compatible with WCAG 2.1, meaning an agency working toward WCAG 2.1 AA conformance is building a program that naturally supports WCAG 2.2 compliance as guidance evolves. For compliance purposes, WCAG 2.1 Level AA is the governing standard public agencies should build their programs around.
What happens if a public agency does not meet WCAG 2.1 AA? Failure to meet WCAG 2.1 AA can result in ADA Title II complaints filed with the Department of Justice or state civil rights authorities, demand letters from private attorneys, civil lawsuits, or formal enforcement proceedings. When agencies cannot demonstrate documented progress toward WCAG 2.1 AA conformance, enforcement outcomes typically include mandatory third-party audits, court-supervised remediation timelines, ongoing monitoring requirements, and multi-year reporting obligations. Agencies with documented compliance programs in place before scrutiny arrives are consistently treated differently than agencies with no formal structure.