Section 508 Compliance: Complete Guide to Website Accessibility (2026)

If your organization builds, sells, or maintains digital products for the US federal government, Section 508 compliance is not optional — it is a legal requirement that directly impacts your ability to win and retain contracts. Even if you operate entirely in the private sector, understanding Section 508 matters: the standard has become the de facto benchmark for digital accessibility across government at every level, and its influence extends into private-sector procurement and litigation. This guide breaks down what Section 508 actually requires in 2026, how it connects to WCAG, what to test, what happens when organizations fail to comply, and gives you a practical checklist to work through.

What Is Section 508?

Section 508 is an amendment to the Rehabilitation Act of 1973. It was added in 1998 and requires US federal agencies to make their electronic and information technology (ICT) accessible to people with disabilities — both employees using internal tools and members of the public accessing government services online.

The original 1998 standards were written before smartphones existed, before cloud software became the norm, and before most government services moved online. They were outdated almost immediately.

The 2017 Refresh

In January 2018, the US Access Board's "ICT Standards and Guidelines" refresh took effect. This revision did something critical: instead of maintaining a separate set of technical requirements, it incorporated WCAG 2.0 Level AA by reference. That single decision unified Section 508 web requirements with the international accessibility standard used by the EU, Canada, Australia, and most other jurisdictions.

The practical result: if your website meets WCAG 2.0 AA, it meets Section 508's web content requirements. If it meets WCAG 2.1 or 2.2 AA, it exceeds them.

Why Section 508 Still Matters in 2026

Three developments have made Section 508 more relevant than at any point in its history:

• DOJ enforcement escalation — The Department of Justice published explicit web accessibility guidance in 2022, and enforcement actions against both federal agencies and state/local governments have accelerated since then.
• Procurement gatekeeping — Federal procurement officers now routinely require VPATs (Voluntary Product Accessibility Templates) as part of the vendor evaluation process. No VPAT, no contract.
• Spillover into the private sector — Organizations that serve federal agencies, receive federal grants, or operate in regulated industries increasingly face accessibility requirements derived from Section 508.

Section 508 vs WCAG 2.1/2.2: Key Differences and Overlap

The revised Section 508 standards incorporate WCAG 2.0 Level AA by reference. But WCAG has moved forward since then. Here is how the standards relate to each other in 2026:

What Section 508 Covers That WCAG Does Not

WCAG focuses on web content. Section 508 has a broader scope — it also covers:

• Software applications — desktop and mobile apps used by federal employees, including interoperability with assistive technology
• Hardware — physical devices like kiosks, multifunction printers, and self-service terminals
• Telecommunications equipment — phones, video conferencing systems
• Documentation and support — user manuals, help pages, and customer support channels must also be accessible

So while WCAG conformance satisfies the web content portion of Section 508, organizations selling complete ICT solutions to the federal government need to address these additional categories as well.

Which Version Should You Target?

For federal procurement VPATs in 2026, target WCAG 2.1 AA as the minimum. Many agencies are beginning to reference WCAG 2.2 in new RFPs, and testing against 2.2 AA future-proofs your conformance documentation. Our WCAG 2.2 checklist covers all 55 success criteria with implementation guidance.

Who Must Comply with Section 508?

Federal Agencies

All US federal agencies — executive, legislative, judicial, and independent — must ensure their ICT is accessible. This covers public-facing websites, internal tools and intranets, documents published online (PDFs, spreadsheets), multimedia content, mobile applications, and procurement systems. The requirement applies to both new development and existing systems. Agencies cannot claim grandfather exemptions for legacy technology indefinitely — they are expected to remediate or replace inaccessible systems as part of normal technology refresh cycles.

Federal Contractors and Vendors

Any private company selling ICT products or services to the federal government must ensure those products meet Section 508 standards. This is enforced through the procurement process: Federal Acquisition Regulation (FAR) clause 39.2 requires agencies to evaluate ICT purchases for Section 508 conformance. Vendors must provide a VPAT documenting how their product meets (or does not meet) each applicable standard.

Non-compliant products can be — and regularly are — rejected during procurement evaluation. If a vendor's VPAT shows major gaps, the agency will either choose a competing product or require a remediation plan with contractual deadlines.

Organizations Receiving Federal Funding

Universities, research institutions, healthcare organizations, and nonprofits that receive federal grants or funding may be subject to Section 508 requirements for the digital properties associated with that funding. The specifics depend on the grant terms, but the trend since 2022 has been toward broader application of accessibility requirements to grant recipients.

State and Local Governments

Section 508 technically applies only to federal agencies. However, the DOJ's 2024 Title II rule under the ADA requires state and local governments to make their web content and mobile apps conform to WCAG 2.1 AA — creating a parallel obligation that is functionally identical to Section 508 for web content. For private businesses and ADA web compliance, our ADA compliance guide covers those requirements.

Section 508 Technical Requirements

Section 508's technical requirements map directly to the four WCAG principles — Perceivable, Operable, Understandable, and Robust — plus additional requirements for non-web ICT.

Web Content Requirements

These align with WCAG 2.0 AA and are organized by principle:

Perceivable

• All images must have appropriate alt text — informative images need descriptive text, decorative images need empty alt=""
• Video content requires synchronized captions and audio descriptions for pre-recorded media
• Color contrast must meet minimum ratios: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold)
• Content must be readable and functional at 200% browser zoom without loss of information
• Information must not be conveyed by color alone — use text labels, patterns, or icons as well

Operable

• All functionality must be accessible via keyboard alone — no mouse-dependent interactions
• Keyboard focus must be visible at all times during navigation
• Skip navigation links must allow users to bypass repeated header content
• No content may flash more than three times per second
• Users must have enough time to read and interact with content — or be given controls to extend time limits

Understandable

• The page language must be declared via the HTML lang attribute
• Form inputs must have visible, associated labels — placeholder text alone is not sufficient
• Error messages must identify the field in error and suggest corrections in text
• Navigation must be consistent across pages within the same site

Robust

• HTML must be well-formed — no duplicate IDs, proper nesting, valid markup
• All interactive components must expose their name, role, value, and state to assistive technologies via native HTML semantics or ARIA
• Status messages must be programmatically conveyed to assistive technology without receiving focus

Software Application Requirements

Desktop and mobile applications must provide keyboard accessibility, programmatic access to UI elements, compatibility with platform accessibility APIs (UI Automation on Windows, Accessibility API on macOS/iOS), and support for user-selected system settings like high contrast mode and text size.

Hardware Requirements

Physical devices must provide tactile or auditory alternatives to visual-only indicators, accommodate assistive technology connections, and meet reach and operation requirements for users with physical disabilities. Self-service kiosks are a frequent compliance problem area.

Documentation and Support

Product documentation, help systems, and customer support channels must themselves be accessible. If your user manual is a PDF, that PDF must meet accessibility standards. If you offer phone-only support, you must also provide TTY or relay service access.

How to Test for Section 508 Compliance

A persistent misconception: running an automated scan equals testing for compliance. It does not. Automated tools catch between 30% and 40% of WCAG issues. The rest require human judgment — evaluating whether alt text is actually meaningful, whether focus order is logical, whether error messages make sense in context.

A thorough Section 508 evaluation combines three layers.

Layer 1: Automated Scanning

Start with automated tools to identify the obvious violations — missing alt text, contrast failures, missing form labels, invalid ARIA attributes. Run these tools across your entire site, not just the homepage.

Recommended tools:

• Web Accessibility Checker — scans your URL against WCAG 2.1 AA and generates code-level violation reports with fix suggestions
• axe DevTools (browser extension) — the most widely used automated accessibility testing engine, available for Chrome and Firefox
• WebAIM WAVE — provides a visual overlay highlighting errors directly on the rendered page
• Lighthouse (built into Chrome DevTools) — includes an accessibility audit score based on axe-core

Automated scanning is your first pass. Treat it as a floor, not a ceiling.

Layer 2: Manual Testing

Manual testing catches what automation cannot: context-dependent issues, interaction patterns, and content quality problems.

Keyboard testing:

1. Disconnect your mouse. Navigate the entire site using only Tab, Shift+Tab, Enter, Space, Arrow keys, and Escape.
2. Verify that every interactive element receives visible focus.
3. Confirm that focus order follows a logical reading sequence.
4. Check that no keyboard traps exist — especially in modals, dropdown menus, and date pickers.
5. Test skip navigation: the first Tab press on any page should reveal a "Skip to content" link.

Screen reader testing:

1. Test with NVDA + Firefox on Windows (NVDA is free and open source).
2. Test with VoiceOver + Safari on macOS (built-in, activate with Cmd+F5).
3. Verify that all images have meaningful alt text (not "image123.jpg" or "photo").
4. Confirm that form fields announce their labels, required status, and error messages.
5. Check that dynamic content updates (AJAX, live regions) are announced.

Visual testing:

1. Zoom to 400% — content should reflow without horizontal scrolling.
2. Enable Windows High Contrast mode — verify the site remains usable.
3. Disable CSS — confirm the reading order makes sense.
4. Check that focus indicators are clearly visible (not just a faint dotted outline).

Layer 3: VPAT Documentation

For federal procurement, you need a Voluntary Product Accessibility Template (VPAT). The current version is VPAT 2.5, based on the ITI template. A VPAT documents your product's conformance level against each applicable Section 508 standard and WCAG success criterion.

Each criterion receives one of four ratings:

• Supports — functionality fully meets the criterion
• Partially Supports — some functionality meets the criterion, some does not
• Does Not Support — functionality does not meet the criterion
• Not Applicable — the criterion does not apply to this product

VPATs should be written by qualified accessibility professionals who have actually tested the product — not auto-generated from scan results. Procurement officers increasingly verify VPAT claims through their own testing, and inaccurate VPATs create legal and reputational risk.

Penalties for Non-Compliance

Section 508 enforcement has real consequences, though the mechanisms differ depending on who you are.

For Federal Agencies

Federal employees or members of the public can file complaints with an agency's Section 508 coordinator. If the complaint is not resolved, it can be escalated to the US Access Board or the Department of Justice. Sustained non-compliance can trigger:

• Mandatory remediation plans with deadlines and oversight
• Budget impacts — agencies may face scrutiny in their IT spending justifications
• Public reporting — agency compliance is tracked through the Government-wide Section 508 Assessment, published annually since 2023
• Congressional inquiry — persistent accessibility failures at high-profile agencies draw legislative attention

For Federal Contractors

The consequences are more direct and financially impactful:

• Contract loss — non-compliant products can be rejected during procurement, losing the contract to a competitor
• Contract termination — existing contracts may include accessibility warranties; failure to maintain compliance can trigger termination clauses
• Debarment risk — in extreme cases of sustained non-compliance or fraudulent VPAT reporting, vendors can be debarred from future federal contracts
• Reputational damage — federal accessibility audits are sometimes published, and a failed audit becomes a matter of public record

Recent Enforcement Trends

Several developments have increased enforcement pressure since 2022:

• The DOJ's 2022 web accessibility guidance established WCAG 2.1 AA as the expected standard for state and local government websites under ADA Title II
• The DOJ's 2024 final rule formalized WCAG 2.1 AA as the mandatory standard for state and local government web content and mobile apps, with compliance deadlines in 2026-2027
• Federal accessibility lawsuits have averaged over 4,000 per year since 2023, with settlements frequently requiring WCAG 2.1 AA conformance
• The government-wide Section 508 Assessment has created public accountability for agencies, with compliance scores published and compared

For organizations operating in both the US and EU, our guide on European Accessibility Act penalties by country covers the parallel European requirements taking effect in June 2025.

Section 508 Compliance Checklist

Use this checklist to systematically evaluate your website or application against Section 508 requirements. Each item maps to one or more WCAG 2.1 AA success criteria.

1. All images have appropriate alt text — Informative images have descriptive alt text. Decorative images use alt="". Complex images (charts, diagrams) have extended descriptions. (WCAG 1.1.1)
2. Video content has captions and audio descriptions — Pre-recorded video includes synchronized captions. Audio-only content has a text transcript. Video with meaningful visual content includes audio descriptions. (WCAG 1.2.1-1.2.5)
3. Color contrast meets minimum ratios — Normal text: 4.5:1 against its background. Large text (18pt+ or 14pt+ bold): 3:1. UI components and graphical objects: 3:1. (WCAG 1.4.3, 1.4.11)
4. Content does not rely on color alone — Links are distinguished by more than color (underline, icon). Error states use text labels, not just red highlighting. Charts use patterns in addition to colors. (WCAG 1.4.1)
5. All functionality works via keyboard — Every button, link, form field, menu, and interactive widget can be reached and operated using only the keyboard. No keyboard traps exist. (WCAG 2.1.1, 2.1.2)
6. Focus is visible and logical — A visible focus indicator appears on every interactive element during keyboard navigation. Focus order follows the visual layout and reading sequence. (WCAG 2.4.3, 2.4.7)
7. Skip navigation is provided — A "Skip to main content" link is the first focusable element on every page. It moves focus past the header and navigation. (WCAG 2.4.1)
8. Page language is declared — The HTML element includes a valid lang attribute. Content in a different language within the page uses the lang attribute on the containing element. (WCAG 3.1.1, 3.1.2)
9. Forms have proper labels and error handling — Every input has a visible, programmatically associated label. Required fields are identified. Errors are described in text and associated with the relevant field. (WCAG 1.3.1, 3.3.1, 3.3.2)
10. HTML is valid and well-structured — No duplicate IDs. Heading hierarchy is logical (H1 > H2 > H3, no skipped levels). Lists use proper list markup. Tables have headers. (WCAG 1.3.1, 4.1.1)
11. ARIA is used correctly — ARIA roles, states, and properties are valid and appropriate. Native HTML elements are preferred over ARIA when available. Dynamic changes update ARIA states. (WCAG 4.1.2)
12. Content reflows at 400% zoom — At 400% browser zoom (or 320px viewport width), content reflows into a single column without horizontal scrolling and without loss of information. (WCAG 1.4.10)
13. Motion and animation respect user preferences — Animations pause when the user's prefers-reduced-motion setting is enabled. No content flashes more than three times per second. (WCAG 2.3.1)
14. Touch targets meet minimum size — Interactive elements on touch devices are at least 24x24 CSS pixels (WCAG 2.2 target, recommended for mobile accessibility). (WCAG 2.5.8)
15. Documents are accessible — PDFs, Word documents, and spreadsheets published online are tagged for accessibility, have proper reading order, and include alt text for images. (Section 508 E205)

Frequently Asked Questions