Section 508: A Practical Web Team Guide

Section 508 is one of the most frequently cited accessibility requirements in the United States and one of the least understood by the web teams responsible for meeting it. The regulation is referenced in procurement contracts, compliance audits, and agency policy documents, often with language that suggests a clear binary: your website is either "508 compliant" or it is not. The reality is more nuanced, more practical, and more achievable than most teams expect.

The practical version, the one that matters for a web team building and maintaining a government site, involves understanding what the standard actually asks for, which requirements cause the most compliance failures, how to test against them, and how to build a process that keeps a site compliant over time rather than passing a single audit.

What Section 508 is

Section 508 is an amendment to the Rehabilitation Act of 1973, a federal civil rights law. It requires that federal agencies make their electronic and information technology accessible to people with disabilities, both employees and members of the public. The requirement applies to federal agencies directly, and it flows to state and local governments, educational institutions, and private organizations through procurement contracts, grant conditions, and related regulations.

The original Section 508 standards (issued in 2001) defined accessibility requirements in technology-specific terms: web pages, software, video, telecommunications. The 2017 refresh (formally, the "Revised 508 Standards" issued by the U.S. Access Board) replaced most of those technology-specific requirements with a single reference to WCAG 2.0 Level AA for web content, electronic documents, and software. This alignment simplified compliance significantly: instead of interpreting 508-specific rules, web teams can refer to the well-documented, widely understood WCAG standard.

The scope is broader than websites. Section 508 covers all ICT that a federal agency develops, procures, maintains, or uses. This includes web applications, mobile applications, electronic documents (PDFs, Word files, presentations), multimedia, software, hardware kiosks, and telecommunications equipment. For a web team, the relevant scope is typically: the website itself, any web applications, any downloadable documents, and any embedded multimedia.

What WCAG 2.0 AA actually requires

WCAG 2.0 Level AA contains 38 success criteria organized under four principles: Perceivable, Operable, Understandable, and Robust. A web team does not need to memorize all 38, but understanding the ones that cause the most failures is essential.

Perceivable: can users perceive the content?

Text alternatives (1.1.1). Every non-text content element (images, icons, charts, buttons with images) must have a text alternative that serves the same purpose. For informative images, the alt text describes what the image communicates. For decorative images, the alt text is empty (alt=""). For complex images like charts, a longer description must be available.

Captions and audio descriptions (1.2). Pre-recorded video with audio must have captions. Pre-recorded video must have audio descriptions if the visual content is not conveyed by the audio track alone. Live video with audio must have captions.

Adaptable structure (1.3.1). Information, structure, and relationships conveyed visually must also be conveyed programmatically. Headings must use heading elements (<h1> through <h6>). Lists must use list elements. Form fields must be associated with their labels. Tables must have headers. This criterion catches the largest category of structural failures in government websites: visual formatting used in place of semantic markup.

Color not sole indicator (1.4.1). Color must not be the only way to convey information. A form error indicated solely by turning the field border red fails this criterion. The fix is adding an error message, an icon, or both.

Contrast (1.4.3). Text and images of text must have a contrast ratio of at least 4.5:1 against their background (3:1 for large text, defined as 18pt or 14pt bold). This is the most commonly failed criterion on government websites, often in footer text, placeholder text, and disabled-state styling.

Operable: can users operate the interface?

Keyboard accessible (2.1.1, 2.1.2). All functionality must be available through a keyboard interface. No keyboard traps: if a user can navigate into an element using the keyboard, they must be able to navigate out. This criterion fails most often in custom widgets (date pickers, dropdown menus, modal dialogs, tab panels) that were built for mouse interaction and never tested with a keyboard.

Focus visible (2.4.7). When an interactive element receives keyboard focus, it must have a visible focus indicator. Removing the browser's default focus outline without providing a custom one is a direct failure. This is common in government sites where a designer treated the blue focus ring as a visual defect rather than an accessibility feature.

Page titled (2.4.2). Every page must have a descriptive title. A site where every page is titled "MyAgency.gov" fails this criterion because the titles do not distinguish one page from another.

Link purpose (2.4.4). The purpose of each link must be determinable from the link text alone or from the link text together with its surrounding context. "Click here" and "Read more" fail this criterion when their purpose is not clear from context. "Download the FY2024 budget report (PDF, 2.3 MB)" passes.

Understandable: can users understand the content?

Language of page (3.1.1). The default human language of the page must be programmatically identified. This means a lang attribute on the <html> element. Omitting it is a single-line fix and one of the most common failures on government sites.

Labels and instructions (3.3.2). Form fields must have labels or instructions. Every input needs a visible label that is programmatically associated with the field. Placeholder text alone does not meet this requirement because it disappears when the user starts typing.

Error identification (3.3.1). When an input error is detected, the error must be identified in text. "Something went wrong" does not meet this criterion. "The email address field requires a valid email format" does.

Robust: is the content compatible with assistive technologies?

Parsing and name/role/value (4.1.1, 4.1.2). Content must be compatible with current and future assistive technologies. Custom interactive elements must expose their name, role, state, and value through standard mechanisms (native HTML semantics or ARIA attributes). A custom checkbox built from a <div> with a click handler, but no role="checkbox" or aria-checked state, fails this criterion because assistive technology cannot determine what the element is or what state it is in.

The most common failures on government sites

The WebAIM Million study and GSA's Section 508 assessment reporting consistently identify the same categories of failure. Understanding where sites fail most often helps a web team allocate testing and remediation resources effectively.

1. Low contrast text. The single most common failure across all websites, government or otherwise. The fix is straightforward (adjust color values) but requires a systematic review of every text/background combination, including hover states, focus states, disabled states, and error states.
2. Missing alt text. Content images without text alternatives. The fix is adding appropriate alt text. The challenge is scale: a large government site may have thousands of images, and writing meaningful alt text for each requires content expertise, not just development time.
3. Missing form labels. Input fields without programmatically associated labels. The fix is adding <label> elements with for attributes matching input id values, or wrapping the input in the label element.
4. Empty links and buttons. Interactive elements with no accessible name. Common causes: icon-only buttons without aria-labels, links wrapping images without alt text, empty <a> tags used as click targets.
5. Missing page language. No lang attribute on the <html> element. A single line of code.
6. Keyboard inaccessibility. Custom interactive components that cannot be operated with a keyboard. This is the most expensive category to fix because it often requires rebuilding components rather than adding attributes.

How to test

A web team does not need to hire an accessibility consultant to do basic 508 testing. The process combines automated scanning (which catches the easy issues) with manual testing (which catches the important ones).

Automated scanning identifies a meaningful but incomplete share of WCAG failures; published research shows results vary by tool and by how the denominator is counted. Run an automated scanner (axe DevTools, WAVE, Lighthouse, Silktide's free toolbar, or equivalent) on every template and representative page. The Silktide toolbar includes a disability simulator alongside its WCAG checker, which lets a team combine automated testing with a quick experiential check in a single pass. Automated scans catch: missing alt text, contrast failures, missing form labels, missing language attributes, heading hierarchy violations, and some ARIA misuse. They do not catch: keyboard operability, reading order, meaningful alt text quality, focus management, or screen reader experience.

Keyboard testing catches the failures that matter most to users. Tab through every page using only the keyboard. Verify: every interactive element is reachable, every element has a visible focus indicator, there are no keyboard traps, all functionality works with Enter, Space, Escape, and arrow keys as appropriate, and a skip navigation link is present and functional.

Screen reader testing verifies the full assistive technology experience. Use VoiceOver (built into macOS and iOS) or NVDA (free, Windows). Navigate by headings, landmarks, and form fields. Verify that the page structure makes sense when heard rather than seen. A 15-minute screen reader test on each page template catches structural problems that no automated tool detects.

Document testing applies to every downloadable PDF, Word document, or presentation. Open the document in a screen reader and verify that it reads in the correct order, headings are navigable, tables have headers, and images have alt text. Documents are the most commonly overlooked part of 508 compliance on government sites.

Building a sustainable process

Passing a single audit is achievable. Maintaining compliance over time is harder, and it is the actual requirement: Section 508 applies to the agency's ICT continuously, not once.

Build accessibility into templates. When the base page templates, form components, navigation patterns, and content types are accessible, new content inherits that accessibility. A content author adding a page to an accessible CMS template produces accessible content by default (assuming they follow content guidelines for alt text, headings, and link text).

Set standards for content entry. Train content authors on: writing alt text, using heading levels correctly, writing descriptive link text, and structuring tables with headers. Provide in-CMS guidance. These are not technical skills; they are content skills, and they prevent the most common failures.

Test with each release. Include accessibility checks in the QA process for every deployment. Automated scans can run in CI/CD pipelines. Keyboard testing should be part of the manual QA checklist for any change that touches interactive components.

Include accessibility in procurement. Require vendors to document their WCAG conformance (a VPAT, Voluntary Product Accessibility Template, or an ACR, Accessibility Conformance Report). Test their claims before purchasing. Procurement is the highest-leverage intervention point because an inaccessible platform creates debt across everything built on it.

Assign ownership. Someone on the web team must be responsible for accessibility, with the authority to block a release that introduces a compliance failure. Without ownership, accessibility becomes everyone's concern and nobody's responsibility, which means it does not get done. Every government web team that maintains sustained compliance has this role filled; every one that cycles between audit-driven remediation sprints does not. The correlation is not subtle.

What Section 508 does not cover

Section 508 sets a floor, not a ceiling.

The standard references WCAG 2.0 AA, which was published in 2008. WCAG 2.1 (2018) and WCAG 2.2 (2023) added criteria addressing mobile accessibility, cognitive accessibility, and authentication. Meeting only WCAG 2.0 AA leaves gaps that newer standards address: touch target size, content reflow on small screens, focus appearance, accessible authentication, and others. A web team that aims for WCAG 2.2 AA covers the Section 508 requirement and addresses real usability issues that the older standard does not.

Section 508 does not provide guidance on plain language, reading level, or content clarity. These are usability concerns that affect people with cognitive disabilities, limited English proficiency, and low digital literacy, populations that government websites disproportionately serve. The Plain Writing Act of 2010 addresses some of these concerns separately.

Section 508 does not require user testing with people with disabilities, though such testing is the most reliable way to identify barriers that technical testing misses. Compliance with the technical standard is the legal requirement. Genuine usability for people with disabilities requires more.