What Section 508 VPAT Means and How Organizations Use It

"Make the website ADA compliant." If that directive just hits your inbox, take a breath. You're not the first. It's tempting to think of it as a single toggle to flip. But anyone who's been through the process will tell you: it's more like navigating a code with real consequences for real people.

Consider this guide your first toolkit. We'll translate the legal expectations into plain English for 2026. You'll get clarity on which standards actually matter for an audit, and a prioritized list of where to look first.

The 60-second answer

• The ADA applies to websites and mobile apps when they’re part of how the public accesses your services. The Department of Justice has been clear that businesses open to the public and state/local governments must make web content accessible.
• If you’re a state or local government (ADA Title II), there’s now a DOJ rule that requires WCAG 2.1 Level AA for web content and mobile apps, with compliance timelines tied to entity size.
• If you’re a business (ADA Title III), there isn’t one single “ADA web standard” written into a Title III regulation, but WCAG Level AA is the most common benchmark used in audits, procurement, and risk discussions.
• Automated scanners don’t prove compliance. They catch a slice of issues, but the stuff that blocks real users often shows up only in manual testing (keyboard, screen readers, focus behavior, forms, PDFs, modals). That’s why serious programs start with a human-led audit.

ADA vs. WCAG vs. Section 508 (and why people mix them up)

These terms get used interchangeably. They shouldn’t.

ADA (the law)

The Americans with Disabilities Act (ADA) is a civil rights law. For websites, the key idea is equal access. The ADA doesn’t read like a technical spec. It doesn’t tell a developer exactly how to label a form field. It sets the obligation, then you use a technical standard to meet it.

Two ADA buckets matter most for websites:

• Title II: state and local government entities (public sector).
• Title III: businesses open to the public (private sector).

WCAG (the technical benchmark)

WCAG is the set of technical requirements most organizations use to design, audit, and remediate accessibility. WCAG 2.2 is the current major version, and it builds on WCAG 2.1 with additional success criteria.

In real projects, you’ll usually hear:

• WCAG Level A: minimum baseline.
• WCAG Level AA: practical target for most public-facing sites.
• WCAG Level AAA: rarely feasible across full sites (and often not expected).

Section 508 (the procurement requirement)

Section 508 applies to U.S. federal agencies and frequently shows up in procurement requirements for vendors. The Revised 508 Standards incorporate WCAG 2.0 Level AA by reference.

This matters even if you’re not a federal agency, because enterprise buyers often ask for accessibility documentation as part of security and compliance reviews.

What changed that matters in 2026

Title II now has a clear rule (public sector)

For state and local governments, the DOJ published a rule that requires web content and mobile apps to meet WCAG 2.1 Level AA, with compliance timelines based on population size.

If you sell to the government, build government portals, run a municipality site, or manage public services online, this is not theoretical. It’s operational.

WCAG 2.2 is now the “current language”

WCAG 2.2 is published as a W3C Recommendation and adds new success criteria beyond WCAG 2.1. Even when an org is anchored to 2.1 AA for a specific regulatory reason, many teams aim to be “2.2-ready” so they’re not rebuilding the same components again later.

What “ADA compliant website” actually means in practice

A compliant site isn’t one where a scanner gives you a green score. It’s one where users can complete your real tasks without getting blocked.

Think in journeys, not checklists:

• Can someone find your services, navigate menus, and understand headings using a screen reader?
• Can they book, apply, pay, contact, or submit forms using only a keyboard?
• Can they recover from form errors without guessing?
• Can they read key documents (PDFs, policy docs, invoices) with assistive technology?
• Can they use the site when zoomed to 200% on a laptop or on a phone?

If you can’t confidently answer those, you don’t have “ADA compliance.” You have hope.

Why automated tests aren’t enough (and what a real audit looks like)

Automated tools are fine as a smoke alarm. They’re not the fire marshal.

Scanners are good at catching things like missing alt attributes or obvious contrast failures. They’re bad at the issues that trigger real user complaints and lawsuits:

• broken keyboard focus order
• dropdowns and modals that trap focus
• “Submit” buttons that don’t announce errors
• dynamic content that changes without being announced
• PDFs that look fine but aren’t readable by assistive tech

That’s why ADA Compliance Professionals’s approach should lead with manual testing, supported by tooling, not replaced by it. A proper audit typically includes:

• keyboard-only navigation testing (including focus visibility and order)
• screen reader testing on the key templates and flows
• review of interactive components (menus, modals, carousels, forms)
• document accessibility review (often where risk hides)
• a prioritised remediation plan that maps issues to WCAG criteria and user impact

The checklist that actually matters

Most ADA checklists look official but don’t help. They list rules without explaining where things actually break. This section focuses on the problems that cause complaints, lost users, and legal risk. Start here.

1) Keyboard access and navigation

If someone can’t use your site with a keyboard, the site is not accessible. Here’s what to check and what usually goes wrong:

All links and buttons work with the Tab key

Every interactive element must receive focus.

Common problem: clickable elements that never receive focus, even though they look interactive.

Focus moves in a logical order

Tabbing should follow a predictable visual and structural flow.

Common problem: focus jumps to hidden or random elements, confusing users.

Skip to main content is available

Users should be able to bypass repeated navigation.

Common problem: users must tab through the full header every single time.

Menus work without a mouse

All navigation must function via keyboard only.

Common problem: hover-only dropdown menus that can’t be accessed without a mouse.

Sticky banners don’t trap focus

Persistent UI elements must not block keyboard navigation.

Common problem: cookie banners or chat widgets that trap focus or block progression.

2) Focus visibility and behavior

Keyboard support means nothing if users can’t see where they are. Here’s what to check and where things usually fail:

Focus indicator is clearly visible

There must be a clear visual outline or highlight.

Common problem: designers remove the focus outline “for aesthetics.”

Focus works on all backgrounds

The focus style must be visible across light, dark, and image backgrounds.

Common problem: low-contrast focus styles that disappear in real usage.

Focus moves into modals when they open

When a dialog appears, focus should move inside it.

Common problem: focus remains behind the modal, making interaction impossible.

Focus returns after closing modals

After closing, focus should return to the triggering element.

Common problem: focus gets lost, leaving keyboard users stranded.

Modals can be closed with a keyboard

Users must be able to close dialogs without a mouse.

Common problem: the close button isn’t reachable via keyboard.

3) Forms and error handling

Forms are where accessibility issues turn into lost leads and abandoned checkouts. This is where compliance directly affects revenue. Here’s what to check and what typically goes wrong:

Every field has a real label

Each input must have a properly associated, programmatic label.

Common problem: placeholder text is used instead of a real label. It disappears when users type and often isn’t announced correctly by assistive technology.

Required fields are clearly identified

Users need to know what’s required before they submit.

Common problem: required fields are only indicated visually or not announced to screen readers.

Error messages clearly explain the issue

Error feedback should state what went wrong and how to fix it.

Common problem: vague messages like “Something went wrong,” which provide no actionable guidance.

Errors are announced to screen readers

Validation errors must be programmatically exposed so assistive tech can detect them.

Common problem: errors appear visually but are never announced, leaving non-visual users unaware that submission failed.

Forms work fully with a keyboard

All fields, controls, and submission actions must be usable without a mouse.

Common problem: CAPTCHA or interactive widgets block keyboard-only users.

4) Headings, structure, and readable content

Strong structure benefits both screen reader users and search engines. Weak structure confuses both. Here’s what to check and what frequently fails:

One clear main heading per page

Each page should have a single primary heading that defines its purpose.

Common problem: multiple main headings used for visual layout instead of document structure.

Headings follow a logical order

Heading levels should reflect hierarchy, not just styling.

Common problem: skipped heading levels that break the content outline.

Lists use proper semantic markup

Bulleted or numbered content should use real list elements.

Common problem: lists created from styled paragraphs instead of semantic list markup.

Links describe their destination

Link text should clearly indicate where it leads.

Common problem: repeated “Learn more” links that provide no context when read out of order.

Page language is correctly defined

The HTML language attribute must accurately reflect the page language.

Common problem: missing or incorrect language attributes, which affect pronunciation and comprehension in screen readers.

5) Color contrast and visual cues

Low contrast is one of the most common accessibility failures. And one of the easiest to avoid. Here’s what to check and what typically fails:

Text is easy to read

Text must have sufficient contrast against its background.

Common problem: light gray text on a white background that looks stylish but fails readability standards.

Links are not identified by color alone

Links should have more than just a color difference.

Common problem: links distinguished only by color, with no underline or additional visual cue.

Errors don’t rely only on red

Error states must include text or icons in addition to color.

Common problem: red borders around fields with no explanatory text.

States are visually clear

Users should be able to clearly distinguish active, disabled, focused, and selected states.

Common problem: active or disabled states that are visually subtle or indistinguishable.

If users struggle to read content or identify actions, accessibility fails. It’s that simple.

6) Images and alternative text

Alt text is about purpose, not decoration. Here’s what to check and what usually goes wrong:

Important images have meaningful alt text

Images that convey information must have descriptive, purpose-driven alt text.

Common problem: the same generic alt text reused everywhere, which adds no value.

Decorative images are properly ignored

Purely decorative visuals should not be announced by screen readers.

Common problem: decorative images are read aloud, adding noise and confusion.

Icon buttons have accessible labels

Icons that perform actions must have programmatic labels.

Common problem: interactive icons that look clear visually but provide no accessible name to assistive technology.

Charts and data visualizations include text explanations

If data is presented visually, it must also be explained in text.

Common problem: critical information shown only through charts or graphics, with no textual equivalent.

7) Video, audio, and motion

Media accessibility is often ignored until it becomes a compliance issue. Here’s what to check and what commonly fails:

Videos include accurate captions

Captions should reflect spoken dialogue and meaningful sounds.

Common problem: captions are missing, auto-generated without review, or inaccurate.

Audio content includes transcripts

Audio-only materials must have a text transcript.

Common problem: podcasts or voice messages published with no text alternative.

Autoplay can be stopped

Users must be able to pause or stop media that starts automatically.

Common problem: audio begins playing without visible controls.

Motion can be reduced or disabled

Users should have control over animations and motion effects.

Common problem: animations that cannot be paused or disabled, creating issues for users with motion sensitivity.

8) PDFs and documents

This is where many sites quietly fail. Here’s what to check and what typically goes wrong:

PDFs are properly tagged

PDF documents must include correct semantic tagging so screen readers can interpret structure and content.

Common problem: PDFs are just scanned images with no readable text layer.

Forms inside PDFs are accessible

Interactive fields in PDFs must be labeled and usable with assistive technology.

Common problem: PDF form fields are not labeled, making them unusable for screen reader users.

Reading order makes sense

Content must follow a logical reading order when accessed by assistive technology.

Common problem: content is read in the wrong order because the document was visually arranged without structural tagging.

Important documents are accessible

Key policies, applications, contracts, and official forms must meet accessibility standards.

Common problem: critical documents are ignored entirely during accessibility reviews.

Fixing the website but ignoring PDFs is a common and costly mistake. If users can’t complete official forms or read required documents, compliance fails.

9) JavaScript components and third-party tools

Modern sites rely heavily on components. Components can break accessibility fast. Here’s what to check and what usually breaks:

Dropdowns and tabs work with a keyboard

Interactive components must support full keyboard navigation.

Common problem: click-only components that cannot be accessed or operated without a mouse.

State changes are announced

Dynamic updates must be communicated to screen readers.

Common problem: content updates visually, but assistive technology is never informed.

Widgets don’t trap focus

Embedded tools must not block or hijack keyboard navigation.

Common problem: chat tools or booking widgets that capture focus and prevent users from moving forward.

Custom components behave consistently

Custom-built UI elements must follow accessible interaction patterns.

Common problem: accessibility breaks because of custom styling or scripts that override default behavior.

What to fix first

Trying to fix everything at once usually fails. Fix what matters most.

First start here:

1. Pages where users contact you, buy, book, or apply
2. Page templates used across the site
3. High-traffic pages
4. PDFs and third-party tools

This is why a human-led audit matters. You don’t need a massive report. You need a clear list of real problems and how to fix them.

Accessibility is not a one-time task

You can fix a site and break it again next week with:

• a new landing page
• a new widget
• a redesign

A realistic approach includes:

• a manual baseline audit
• clear fixes developers can follow
• testing after changes
• regular reviews as the site evolves

If your goal is to reduce risk and make your site usable, start with a professional ADA audit. That’s where ADA Compliance Professionals actually helps: practical testing, clear guidance, and documentation that holds up when someone asks hard questions.

Get help more information or help with VPAT certification

You can call us at (626) 486-2201 for further details or assistance in developing a VPAT for your product, or you can use this link to get in touch with our sales staff. Once we hear from you, we'll be able to schedule a meeting with you to go over your Section 508 VPAT requirements.