Legal

The Complete Section 508 Compliance Checklist for Websites (2025)

Accessibility Team
15 min read
Section 508ComplianceChecklistFederal AccessibilityWCAGGovernment Websites
Share:

Reading time: 8 minutes

What Is a 508 Compliance Checklist and Why Does It Matter?

Section 508 of the Rehabilitation Act is a federal law that requires all electronic and information technology developed, procured, maintained, or used by the federal government to be accessible to people with disabilities. Originally enacted in 1998 and significantly updated in 2017, Section 508 ensures that federal employees and members of the public with disabilities have equal access to information and data.

If you have ever asked yourself "what is a 508 compliance checklist?" — the answer is straightforward. A 508 compliance checklist is a structured set of requirements and best practices that organizations use to evaluate whether their websites, applications, and digital content meet the accessibility standards mandated by Section 508.

Non-compliance is not just a legal risk. It excludes millions of users with disabilities from accessing critical services and information. With lawsuits related to digital accessibility increasing year over year, having a thorough 508 compliance checklist for websites is no longer optional — it is essential.

This guide provides a complete, actionable 508 compliance website checklist that you can use to audit your site, fix accessibility issues, and maintain ongoing compliance.

Who Needs to Comply with Section 508?

Section 508 applies to a broader range of organizations than many people realize:

  • Federal agencies — All U.S. federal government departments and agencies must ensure their ICT (Information and Communications Technology) is accessible.
  • Federal contractors and vendors — Any organization that builds, sells, or provides technology products and services to federal agencies must meet 508 standards.
  • Organizations receiving federal funding — Universities, non-profits, state agencies, and other entities that receive federal grants or funding often fall under 508 requirements.
  • State and local governments — While Section 508 technically applies to federal entities, many state and local governments have adopted it as their accessibility standard, and Section 504 of the Rehabilitation Act imposes similar obligations.

Even if your organization is not legally required to comply with Section 508, following its standards is a proven way to improve usability for all users and reduce legal risk under the ADA and other accessibility regulations.

Section 508 vs WCAG 2.2: How They Relate

The 2017 refresh of Section 508 directly incorporated the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA as the technical standard for web content. Since then, WCAG has been updated to version 2.2 (published in October 2023), which adds nine new success criteria beyond WCAG 2.1.

Here is how they connect:

AspectSection 508WCAG 2.2
ScopeU.S. federal lawInternational standard (W3C)
Current referenceWCAG 2.0 Level AAWCAG 2.2 Level A, AA, AAA
Applies toFederal ICT in the U.S.Any web content globally
EnforcementLegal complaints, lawsuitsAdopted by laws worldwide

In practice, if you meet WCAG 2.2 Level AA, you will exceed the current Section 508 requirements. The 508 compliance testing checklist in this guide follows the WCAG structure (Perceivable, Operable, Understandable, Robust) since these principles form the backbone of both standards.

The Complete 508 Compliance Checklist

This is the core 508 compliance checklist organized by the four WCAG principles. Use these checkboxes to track your progress during an audit.

Perceivable

All information and user interface components must be presentable to users in ways they can perceive.

  • Text alternatives (1.1.1) — Every non-text element (images, icons, charts) has appropriate alt text.
  • Captions for audio/video (1.2.2) — All pre-recorded video with audio includes synchronized captions.
  • Audio descriptions (1.2.5) — Pre-recorded video content includes audio descriptions for visual-only information.
  • Content structure (1.3.1) — Information, structure, and relationships are conveyed through proper semantic HTML (headings, lists, tables, landmarks).
  • Meaningful sequence (1.3.2) — The reading order of content is logical and meaningful when the presentation is changed.
  • Sensory characteristics (1.3.3) — Instructions do not rely solely on shape, size, visual location, or sound.
  • Color not sole indicator (1.4.1) — Color is not used as the only means of conveying information or prompting action.
  • Contrast ratios (1.4.3) — Text has a contrast ratio of at least 4.5:1 against its background (3:1 for large text).
  • Text resizing (1.4.4) — Text can be resized up to 200% without loss of content or functionality.
  • Images of text (1.4.5) — Text is used instead of images of text wherever possible.
  • Reflow (1.4.10) — Content reflows at 320px width without requiring horizontal scrolling.
  • Non-text contrast (1.4.11) — UI components and graphical objects have at least 3:1 contrast ratio.

Common fix — adding alt text to images:

<!-- Bad: missing alt text -->
<img src="report-chart.png">

<!-- Good: descriptive alt text -->
<img src="report-chart.png" alt="Bar chart showing a 40% increase in website traffic from January to June 2025">

<!-- Good: decorative image marked correctly -->
<img src="decorative-border.png" alt="" role="presentation">

Operable

All user interface components and navigation must be operable by all users.

  • Keyboard accessible (2.1.1) — All functionality is available using a keyboard alone.
  • No keyboard traps (2.1.2) — Users can navigate to and away from every interactive element using the keyboard.
  • Timing adjustable (2.2.1) — If time limits exist, users can turn off, adjust, or extend them.
  • Pause, stop, hide (2.2.2) — Users can pause, stop, or hide any moving, blinking, or auto-updating content.
  • Three flashes threshold (2.3.1) — No content flashes more than three times per second.
  • Skip navigation (2.4.1) — A mechanism exists to skip repetitive navigation blocks.
  • Page titles (2.4.2) — Each page has a descriptive, unique title.
  • Focus order (2.4.3) — The focus order of interactive elements is logical and intuitive.
  • Link purpose (2.4.4) — The purpose of each link can be determined from its text or surrounding context.
  • Multiple navigation paths (2.4.5) — More than one way is available to locate a page (e.g., search, site map, navigation).
  • Visible focus (2.4.7) — Keyboard focus indicators are clearly visible on all interactive elements.
  • Focus not obscured (2.4.11) — When an element receives focus, it is not entirely hidden by other content.

Common fix — adding skip navigation:

<!-- Add as the first element inside <body> -->
<a href="#main-content" class="skip-link">Skip to main content</a>

<!-- Style the skip link -->
<style>
  .skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    padding: 8px 16px;
    background: #000;
    color: #fff;
    z-index: 1000;
  }
  .skip-link:focus {
    top: 0;
  }
</style>

<!-- Mark the main content area -->
<main id="main-content">
  <!-- Page content here -->
</main>

Understandable

Information and the operation of the user interface must be understandable.

  • Language of page (3.1.1) — The default human language of the page is identified in the HTML.
  • Language of parts (3.1.2) — The language of any passage or phrase that differs from the page default is identified.
  • On focus behavior (3.2.1) — Receiving focus does not trigger an unexpected change of context.
  • On input behavior (3.2.2) — Changing a form setting does not automatically cause an unexpected change of context.
  • Consistent navigation (3.2.3) — Navigation menus appear in the same relative order across pages.
  • Consistent identification (3.2.4) — Components with the same functionality are identified consistently across pages.
  • Error identification (3.3.1) — Input errors are clearly identified and described to the user in text.
  • Labels or instructions (3.3.2) — Form inputs have descriptive labels or instructions.
  • Error suggestion (3.3.3) — When an error is detected, suggestions for correction are provided (if possible).
  • Error prevention (3.3.4) — For pages involving legal or financial transactions, submissions are reversible, verifiable, or confirmed.

Common fix — proper form labels:

<!-- Bad: no label association -->
<input type="email" placeholder="Enter your email">

<!-- Good: explicit label association -->
<label for="user-email">Email Address</label>
<input type="email" id="user-email" name="email"
       aria-describedby="email-help">
<span id="email-help">We will never share your email with third parties.</span>

<!-- Good: error messaging -->
<label for="user-email">Email Address</label>
<input type="email" id="user-email" aria-invalid="true"
       aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email address.</span>

Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

  • Valid HTML (4.1.1) — HTML elements have complete start and end tags, are nested correctly, and contain no duplicate attributes.
  • Name, Role, Value (4.1.2) — All UI components have accessible names, roles, and states that are programmatically determinable.
  • Status messages (4.1.3) — Status messages are communicated to assistive technologies without receiving focus.

Common fix — ARIA for custom components:

<!-- Custom toggle button with proper ARIA -->
<button aria-pressed="false"
        onclick="toggleDarkMode(this)">
  Dark Mode
</button>

<!-- Live region for status messages -->
<div aria-live="polite" aria-atomic="true" id="status">
  <!-- Dynamically inserted status messages will be announced -->
</div>

How to Test for 508 Compliance

A reliable 508 compliance testing checklist combines automated scanning with manual testing. Neither approach alone is sufficient — automated tools catch roughly 30-50% of accessibility issues, while manual testing uncovers the rest.

Automated Testing Tools

Start with automated scanning to identify the most common and easily detectable issues:

  • achecker.ca — A free, comprehensive accessibility checker that scans your website against WCAG standards and generates detailed reports with specific fix recommendations. It is an excellent starting point for any 508 compliance audit.
  • axe DevTools — A browser extension by Deque Systems for in-browser accessibility testing during development.
  • WAVE — A web accessibility evaluation tool from WebAIM that provides visual feedback on accessibility issues directly on the page.
  • Lighthouse — Built into Chrome DevTools, it includes an accessibility audit as part of its site quality checks.

Manual Testing Methods

After running automated scans, perform these manual checks:

  1. Keyboard navigation — Tab through the entire page. Can you reach and operate every interactive element? Is the focus order logical? Is focus always visible?
  2. Screen reader testing — Test with at least one screen reader (NVDA on Windows, VoiceOver on macOS/iOS, TalkBack on Android). Listen for meaningful announcements of all content and controls.
  3. Zoom and reflow — Zoom to 200% and 400%. Does content reflow without horizontal scrolling? Is anything clipped or overlapping?
  4. Color and contrast — Use a contrast checker to verify text and UI element contrast ratios. View the site in grayscale to confirm color is not the sole indicator of meaning.
  5. Forms and error handling — Submit forms with invalid data. Are errors clearly communicated? Are labels properly associated with inputs?

Common 508 Compliance Failures and How to Fix Them

Based on analysis of thousands of website audits, these are the most frequently encountered accessibility failures:

1. Missing or Inadequate Alt Text

The problem: Images lack alt attributes, or alt text is generic (e.g., "image" or "photo"). The fix: Write alt text that conveys the same information or function as the image. For decorative images, use alt="".

2. Insufficient Color Contrast

The problem: Text color does not have enough contrast against its background, making it hard to read for users with low vision. The fix: Ensure a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). Use a tool like achecker.ca to identify contrast failures across your entire site.

3. Missing Form Labels

The problem: Form inputs rely on placeholder text instead of proper <label> elements. The fix: Add a <label> element with a for attribute matching the input's id. Placeholder text should supplement, not replace, labels.

4. Keyboard Inaccessibility

The problem: Custom components (dropdowns, modals, tabs) cannot be operated with a keyboard. The fix: Use native HTML elements wherever possible. For custom components, add appropriate tabindex, role, and keyboard event handlers. Ensure focus management is handled correctly in modals and dynamic content.

5. Missing Document Language

The problem: The HTML document does not declare its language. The fix: Add the lang attribute to the <html> element:

<html lang="en">

6. Missing Page Titles

The problem: Pages have generic or missing <title> tags. The fix: Give every page a unique, descriptive title that identifies the page's content and the site:

<title>508 Compliance Checklist - Accessibility Guide | YourSite</title>

508 Compliance Testing Checklist — Quick Reference

Use this condensed 508 compliance testing checklist as a quick reference during audits:

  • Run an automated scan with achecker.ca and fix all critical issues
  • Verify all images have appropriate alt text
  • Check color contrast ratios meet minimums (4.5:1 for text, 3:1 for large text and UI)
  • Tab through the entire site using only a keyboard
  • Confirm all forms have associated labels and accessible error messages
  • Test with a screen reader (VoiceOver, NVDA, or TalkBack)
  • Verify page titles are unique and descriptive
  • Check that the lang attribute is set on the <html> element
  • Confirm skip navigation links are present and functional
  • Validate that video content has captions and audio descriptions
  • Test content reflow at 200% and 400% zoom
  • Verify no keyboard traps exist anywhere on the site
  • Check that focus indicators are clearly visible
  • Ensure ARIA attributes are used correctly (valid roles, states, and properties)
  • Review and fix any validation errors in HTML markup

Save or print this checklist for use during your next audit. Many teams also look for a 508 compliance checklist PDF — you can generate one from this page using your browser's print-to-PDF function for offline reference.

Frequently Asked Questions

What is a 508 compliance checklist?

A 508 compliance checklist is a structured document that outlines the specific accessibility requirements defined by Section 508 of the Rehabilitation Act. It helps organizations systematically evaluate whether their digital content — websites, applications, documents, and multimedia — meets federal accessibility standards. Since the 2017 refresh, these requirements align with WCAG 2.0 Level AA success criteria, making the checklist essentially a WCAG-based audit tool tailored to federal compliance needs.

Is Section 508 the same as WCAG?

No, but they are closely related. Section 508 is a U.S. federal law that mandates accessibility for government ICT. WCAG is an international set of technical guidelines published by the W3C. Since 2017, Section 508 references WCAG 2.0 Level AA as its technical standard for web content. Meeting WCAG 2.2 Level AA will satisfy and exceed current 508 requirements.

Who enforces Section 508 compliance?

The U.S. Access Board sets the standards, while enforcement happens through multiple channels. Federal employees can file complaints with their agency's Equal Employment Opportunity (EEO) office. Members of the public can file administrative complaints with the relevant federal agency or pursue legal action under Section 508. The Department of Justice also plays a role in enforcement and has issued guidance on digital accessibility.

How often should I test my website for 508 compliance?

Accessibility is not a one-time project. Best practice is to integrate testing into your development workflow — scanning every new feature or content update before it goes live. At a minimum, conduct a comprehensive audit quarterly. Automated tools like achecker.ca make it easy to run frequent scans and catch regressions early. Pair automated scans with manual testing at least twice a year.

Can I get a 508 compliance checklist PDF?

Yes. You can use this guide as your reference and save it as a PDF using your browser's built-in print function (Ctrl+P or Cmd+P, then select "Save as PDF"). This gives you a portable 508 compliance checklist PDF that you can share with your team, include in project documentation, or use during offline audits.

Conclusion

Achieving and maintaining Section 508 compliance is an ongoing process, not a one-time task. This 508 compliance checklist for websites gives you a clear, actionable framework to evaluate your site against federal accessibility standards, identify gaps, and implement fixes.

The most effective compliance strategy combines automated scanning with manual testing, integrates accessibility into your development workflow, and treats it as a continuous quality practice rather than a periodic audit.

Ready to start your 508 compliance audit? Run a free accessibility scan of your website at achecker.ca. It takes seconds to get a detailed report of accessibility issues along with specific guidance on how to fix them. Whether you are a federal agency, a government contractor, or an organization that simply wants to build a more inclusive web, achecker.ca helps you identify and resolve compliance gaps quickly and confidently.

Test Your Website's Accessibility

Use our free accessibility checker to identify and fix issues on your website.

Start Free Scan

Related Articles

© 2025 Accessibility Checker. Built for WCAG compliance.