WCAG in the United States: What it means, where it applies, and how to get started

A plain-language guide to how WCAG shows up in U.S. accessibility expectations—plus practical steps to reduce risk and improve customer experience.

Who this is for: U.S. organizations (and global organizations serving U.S. customers) that own or manage public websites, web apps, mobile apps, customer portals, or digital documents—and need to understand what “WCAG compliance” usually means in a U.S. context.

Important: This page is informational and not legal advice. U.S. accessibility obligations can depend on your industry, whether you receive federal funding, whether you sell to the public, and (in some cases) state/local requirements. If you’re looking for a general WCAG overview, start with Understanding WCAG. If you need the Canada angle, see WCAG in Canada.

How WCAG fits into the U.S. landscape

WCAG (Web Content Accessibility Guidelines) is an international standard used to make digital experiences more usable for people with disabilities. In the United States, WCAG is frequently used as the practical benchmark for accessible websites and apps—especially when legal or policy requirements are written at a higher level (for example, requiring “effective communication” or “accessible technology” rather than naming specific technical criteria).

What “meeting WCAG” usually means in the United States

Level AA is the practical baseline: For most public-facing websites and apps, WCAG Level AA is the most common target used in policies, settlement agreements, and accessibility programs.
Version matters (2.0 vs 2.1 vs 2.2): You’ll still see WCAG 2.0 referenced in some older requirements, while many organizations now target WCAG 2.1 AA to better cover mobile and modern UI patterns. WCAG 2.2 is newer and adoption is evolving—your risk profile, contracts, and internal standards often drive what you choose.
It’s about journeys—not just pages: Registration, sign-in, account management, payments, customer support, appointment/booking, and “download this PDF” moments are common hotspots for accessibility barriers (and complaints).
Third-party tools still count: Embedded widgets, identity providers, chat tools, booking systems, maps, and consent banners can create barriers. Even if you don’t build them, they can affect your customers—and your overall accessibility posture.
Accessibility is ongoing: New releases, marketing campaigns, and content updates can introduce regressions unless accessibility is built into design, development, and publishing workflows.

Where accessibility requirements come from in the U.S.

Start by identifying which expectations apply to you

In the U.S., digital accessibility expectations typically come from a mix of civil rights law, government standards, and procurement requirements. A practical starting point is to answer:

Do you serve the public (customers, patients, students, members, etc.)? Public-facing websites and apps are where most expectations—and complaints—show up.

Are you a public entity or a recipient of public funding? State/local governments and many education/public programs have explicit obligations around accessible communication and technology.

Are you part of the federal ecosystem? If you’re a U.S. federal agency—or you sell digital products/services to one—Section 508 accessibility requirements are often a direct driver.

Are you in a regulated or high-scrutiny industry? Healthcare, financial services, transportation, education, and retail/e-commerce often see stronger accessibility expectations due to customer impact and risk.

Do you have contractual accessibility commitments? Enterprise customers, partners, and RFPs frequently require WCAG conformance (commonly 2.1 AA) plus documentation like an accessibility statement or VPAT/ACR-style reporting.

What standards and terms you’ll commonly see

In U.S. digital accessibility work, WCAG is the most common technical benchmark teams use to design, build, test, and report on accessibility. You’ll also hear about:

ADA (Americans with Disabilities Act): A U.S. civil rights law. While it doesn’t list WCAG success criteria, WCAG is frequently used as the practical yardstick for whether digital experiences provide equitable access.

Section 508: A U.S. federal standard for accessible information and communication technology (ICT). It’s a common driver in federal procurement and vendor requirements.

VPAT / ACR: Common procurement formats used to document accessibility support and conformance claims for software, websites, and digital products.

Choosing a target: version + level + scope

To make accessibility requirements actionable, define three things up front: (1) the WCAG version, (2) the conformance level (usually AA), and (3) what’s in scope (web, mobile, PDFs, portals, third-party tools). In U.S. contexts, it’s also common to pair this with a plan for how you’ll document and communicate accessibility (for example, an accessibility statement and, when procurement requires it, VPAT/ACR reporting).

Level A: Covers the most basic requirements and prevents major blockers, but usually isn’t enough for real customer usability.

Level AA: The most common target for public-facing experiences in United States. It addresses many frequent barriers (contrast, keyboard access, form errors, focus, etc.).

Level AAA: The highest level. It’s rarely required end-to-end, but selected AAA criteria can be excellent goals for specific content or audiences.

In the U.S., “being accessible” is often evaluated based on what users can actually do: complete tasks, understand content, and access support without barriers. Many organizations formalize this with an accessibility statement, an assessment report, and an internal plan to prevent regressions.

What to focus on first (practical priorities)

High-impact areas that commonly drive complaints
(and quick wins)

Page structure and navigation: Headings, landmarks, skip links, and consistent menus that work well with screen readers.
Keyboard accessibility: Everything works without a mouse (menus, modals, carousels, filters, and custom widgets) and focus is visible.
Text alternatives and non-text content: Images, icons, charts, and controls expose meaningful text equivalents.
Color and visual presentation: Sufficient contrast, information not conveyed by color alone, and text that can resize without breaking layouts.
Forms and errors: Labels, instructions, required fields, and error messages are clear and programmatically tied to inputs.
Dynamic content and components: Updates are announced appropriately; dialogs and menus behave predictably; ARIA is used correctly.
Documents and media: PDFs are tagged and readable; video has captions (and transcripts/audio description where needed); players are accessible.

If you’re building an internal standard, a common approach is to set WCAG 2.1 AA as the baseline for public-facing experiences, then add any industry or procurement-specific requirements on top.

What to include when scoping an assessment
(U.S.-friendly checklist)

Core customer journeys: Sign-up, sign-in, onboarding, account setup, checkout/payments, billing, service changes, and cancellations.
Support and issue resolution: Contact flows, troubleshooting content, outage/service notices, complaint paths, and escalation processes.
Templates and shared components: Headers, footers, navigation, search, filters, modals, tables, and design system components used across the site/app.
Documents and downloads: Policies, terms, guides, and PDFs users need to read, understand, or complete (this is a frequent gap).
Third-party tools in key journeys: Chat widgets, identity providers, booking tools, maps, embedded analytics/consent tools, and other integrations.
Language and content variants: If you publish in multiple languages (for example, English and Spanish) or across regional experiences, test each variant—templates and content patterns often differ and issues can be language-specific.
Customer communications: Emails, statements, notifications, and “how to” content that customers rely on to access services (and any alternate format process you offer).

A quick WCAG-aligned self-check (non-exhaustive)

Can you complete your key tasks using keyboard only (including menus, dialogs, and forms)?
Is focus visible at all times, and does it move in a logical order?
Do images and icons that convey meaning have appropriate text alternatives?
Is text readable with sufficient color contrast, and is information never conveyed by color alone?
Do forms have labels, instructions, and clear errors that help users recover?
Are headings used in a clear hierarchy (so screen reader users can scan and jump)?
Do videos include captions (and transcripts where appropriate)?
Are PDFs and downloads either accessible (tagged, structured) or available as accessible web pages?

How teams typically use WCAG

Product & compliance: Use WCAG to define “done” (acceptance criteria) and to set a target level (most commonly WCAG 2.1 AA). If you’re operating in multiple regions, confirm whether a different WCAG version is referenced in your jurisdiction pages.
Design: Apply WCAG to interaction patterns, focus states, error handling, responsive layouts, and color/typography decisions.
Content & marketing: Ensure headings make sense, link text is descriptive, images have appropriate alt text, and PDFs are accessible (or avoided).
Development: Build with semantic structure, keyboard support, and correct ARIA; avoid creating custom controls without accessibility behavior.
QA: Validate with keyboard testing, screen reader spot checks, and targeted automated scans—then confirm fixes didn’t introduce regressions.
Procurement / vendors: Use WCAG requirements in RFPs and acceptance testing for third-party tools and platforms.

A practical way to get
started with WCAG

Pick your scope: Start with the journeys that matter most (sign-up/sign-in, checkout, account, support) and the templates/components they rely on.
Choose a target: Confirm the WCAG version and level you’re aiming for (most commonly WCAG 2.1 AA). If you need a jurisdiction-specific reference, use the Canada/US pages to validate what’s expected for your context.
Assess with the right mix: Combine automated scanning with manual testing (keyboard + screen reader) to catch the issues tools miss.
Prioritize by user impact: Fix blockers first (navigation, keyboard traps, form errors, contrast, missing text alternatives) and then move to deeper usability improvements.
Make it repeatable: Add accessibility checks into design reviews, development workflows, and content publishing so you don’t reintroduce issues with every release.

How 4Point can help

Unsure where to begin?

Start with an accessibility audit. 4Point can run a practical audit to establish a baseline, identify the highest-risk barriers, and give you a prioritized remediation roadmap.

Scoping session: confirm which forms are in scope, the number to be reviewed, and the accessibility standard(s) to assess against.
Forms accessibility audit: review an agreed number of forms and document accessibility gaps.
Conformance report and prioritization: provide conformance findings, severity ratings, and a recommended fix order.
Recommendations and remediation plan: share recommendations for addressing identified gaps and provide a statement of work for remediation of the audited forms (remediation is not included in the audit engagement).

Contact 4Point: Request an accessibility audit

Anchor 2