Every Section 508 Accessibility Audit check

Screen readers—used by blind and low-vision users and required for Section 508 2018 Refresh compliance under 502.3.1—rely on alt text as the sole description of image content. A content image missing alt text renders that information completely inaccessible. A decorative image with non-empty alt text forces screen readers to read irrelevant noise. Under WCAG 2.2 SC 1.1.1 (Level A), this is a non-negotiable baseline: failing it exposes agencies and federal contractors to Section 508 enforcement actions and excludes users with disabilities from core content.

Why this severity: Critical because WCAG 2.2 SC 1.1.1 is a Level A requirement—the floor of accessibility—and its absence completely blocks screen reader users from image-conveyed information.

Keyboard-only users—including people with motor impairments, power users, and anyone using assistive switches—cannot interact with any element unreachable by Tab or that traps focus without escape. WCAG 2.2 SC 2.1.1 (Level A) and SC 2.4.3 (Level A) are both at stake, as is Section 508 2018 Refresh 503.3.3. A modal that swallows keyboard focus indefinitely, or a custom widget that responds only to mouse clicks, locks these users out entirely. Federal procurement standards mandate full keyboard operability, and failure here triggers compliance findings.

Why this severity: Critical because broken keyboard access completely prevents interaction for users who rely solely on keyboards or assistive input devices, violating WCAG 2.2 SC 2.1.1 at Level A.

Low contrast text is the single most prevalent accessibility defect on the web, and it directly excludes users with low vision, color blindness, or age-related vision changes without any assistive technology involved. WCAG 2.2 SC 1.4.3 (Level AA) requires 4.5:1 contrast for normal text and 3:1 for large text (18pt+ or 14pt+ bold). SC 1.4.1 bars using color as the only visual means of conveying information. Section 508 2018 Refresh 502.3.3 incorporates these thresholds directly. Agencies and contractors that fail contrast requirements face procurement disqualification and Section 508 complaint proceedings.

Why this severity: Critical because insufficient contrast excludes users with low vision without requiring any assistive technology failure—it is a direct usability barrier affecting the largest share of users with visual disabilities.

Screen reader users navigate multi-page applications by listening to the page title—it is announced immediately on load and is the primary orientation cue in browser tab lists and browser history. When every route shares the same title or a page has no title at all, users cannot distinguish where they are in the application. WCAG 2.2 SC 2.4.2 (Level A) requires descriptive, unique titles. Section 508 2018 Refresh 503.3.2 mirrors this requirement. Missing or duplicate titles produce a disorienting experience that forces re-reading full page content on every navigation.

Why this severity: High because missing or duplicate page titles disorient screen reader users on every page load, but the failure does not block access to content the way a missing label or broken keyboard path does.

Screen readers expose a page outline built entirely from heading elements. Users—especially blind users navigating long pages—jump between headings using the H key to skim structure. A heading hierarchy that skips levels (H1 → H3, H2 → H4) breaks this outline, making the document feel structurally incoherent and forcing users to re-navigate to understand context. WCAG 2.2 SC 1.3.1 (Level A) requires information conveyed through structure to be programmatically determinable, and SC 2.4.6 (Level AA) requires headings to be descriptive. Section 508 2018 Refresh 502.3.6 incorporates both.

Why this severity: High because a broken heading hierarchy disrupts the primary navigation mechanism for screen reader users on content-heavy pages, though it does not prevent access to individual elements.

Federal agencies, state governments, and public institutions are required by Section 508 2018 Refresh 508.1 to procure or develop technology that meets documented accessibility standards. A VPAT (Voluntary Product Accessibility Template) or accessibility conformance statement is the mechanism through which conformance is communicated to procurement officers and users with disabilities. Without one, procurement evaluators cannot assess compliance, and users have no channel to report barriers or understand the scope of known gaps. Even partial documentation signals intentional governance. WCAG 2.2 SC 4.1.1 supports interoperability foundations that a VPAT codifies in policy terms.

Why this severity: Info because absence of a VPAT or accessibility statement does not itself create a barrier for users, but it signals unmanaged compliance risk and blocks procurement eligibility for government contracts.

Accessibility defects are among the most regression-prone class of bugs—a layout change, a new component, or a dependency update can silently break contrast, focus management, or ARIA attribution. Manual testing catches defects at a point in time; automated tools like axe-core, jest-axe, and pa11y catch regressions continuously. WCAG 2.2 SC 4.1.1 targets robustness of implementation, and Section 508 2018 Refresh 508.2.2 requires that covered products be designed to support AT. Without automated testing, every release is a gamble that a new commit hasn't reintroduced a previously fixed Section 508 violation.

Why this severity: Info because missing automated testing does not itself block users, but it removes the safety net that prevents regressions from shipping undetected into production.

Placeholder text disappears when a user begins typing, leaving them with no reminder of what a field expects. Screen readers may not read placeholder text at all, or read it only once. When an input has no associated `<label>` or ARIA label, screen reader users hear only the input type—"edit text"—with no context about its purpose. WCAG 2.2 SC 1.3.1 (Level A) and SC 3.3.2 (Level A) both require inputs to have accessible names and purpose identification. Section 508 2018 Refresh 502.3.6 incorporates this. Every unlabeled form field is an enrollment, checkout, or support pathway rendered unusable for screen reader users.

Why this severity: High because unlabeled form inputs are directly unusable by screen reader users who cannot determine a field's purpose from type alone, blocking form submission workflows.

Keyboard users must be able to see where focus is at all times—without a visible focus indicator, they are navigating blind. The most common source of this defect is a global `outline: none` reset in CSS, often added to suppress the default browser ring for aesthetic reasons without substituting an equivalent. WCAG 2.2 SC 2.4.7 (Level AA) requires any keyboard operable interface to have a visible focus indicator, and the new SC 2.4.11 (Level AA, added in WCAG 2.2) tightens the minimum indicator specification. Section 508 2018 Refresh 503.3.3 mandates this. Users with motor disabilities who rely on keyboard navigation are most directly harmed, but cognitive disabilities also benefit from persistent focus visibility.

Why this severity: High because removing focus indicators makes keyboard navigation effectively unusable without completely preventing it—users can still tab, but cannot see where they are.

When a page has many navigation links, every keyboard user must tab through all of them before reaching main content—on every page load. For users with motor disabilities this is fatiguing; for screen reader users it is repetitive and disorienting. Skip links solve this with a single Tab press from the top of the page. WCAG 2.2 SC 2.4.1 (Level A) requires a bypass mechanism when blocks of content are repeated across pages. SC 2.1.2 (Level A) prohibits keyboard traps that prevent users from leaving a component. Section 508 2018 Refresh 503.3.3 covers both. Navigation-heavy sites with no skip link fail their most basic keyboard-user obligation.

Why this severity: High because sites with navigation-heavy headers force keyboard users through significant repetitive tabbing on every page load, but they do not completely block access to content.

Screen reader users frequently navigate pages by cycling through links alone, hearing each link text in isolation without surrounding paragraph context. When links read "Click here", "Read more", or "Download" repeatedly, users cannot distinguish between them or understand where each leads. WCAG 2.2 SC 2.4.4 (Level A) requires link purpose to be determinable from the link text or its programmatic context; SC 2.4.9 (Level AA) tightens this to link text alone. Section 508 2018 Refresh 502.3.7 requires textual information to be available to AT. Generic link text also harms SEO, compounding both accessibility and discovery failures.

Why this severity: Medium because non-descriptive link text impairs screen reader navigation and SEO but does not prevent users from accessing the linked content after identifying it through surrounding context.

When form validation fails, screen reader users must know three things: that an error occurred, which field is affected, and how to correct it. Displaying a red border or showing text only visually is invisible to AT. Without `aria-invalid` and `aria-describedby` wiring the error message to the input, screen reader users hear only the field name repeated—no indication that anything is wrong. WCAG 2.2 SC 3.3.1 (Level A) requires errors to be identified in text, and SC 3.3.3 (Level AA) requires suggestions for correction. Section 508 2018 Refresh 502.3.6 covers form field associations. Every form submission failure that goes unannounced to screen reader users silently breaks a user journey.

Why this severity: Medium because inaccessible error messages impair form completion for screen reader users but do not prevent them from eventually reaching the correct field through sequential navigation.

Captions are the primary mechanism through which deaf and hard-of-hearing users access spoken video content. WCAG 2.2 SC 1.2.2 (Level A) requires captions for all prerecorded synchronized media; SC 1.2.4 (Level AA) extends this to live video. Section 508 2018 Refresh 503.4 mandates caption controls for AT users. An uncaptioned product demo, testimonial, or tutorial video excludes deaf users entirely from that content. Auto-generated captions from hosting platforms (YouTube, Vimeo) are frequently inaccurate and do not satisfy the synchronization or accuracy standards required by Section 508 procurement evaluators.

Why this severity: Medium because missing captions exclude deaf and hard-of-hearing users from video content specifically, but the failure is scoped to video elements rather than blocking site-wide navigation.

Audio-only content—podcasts, voice announcements, audio guides—is entirely inaccessible to deaf users without a transcript. Video content that conveys information through visual actions (screen recordings, code walkthroughs, data visualizations) is inaccessible to blind users without audio descriptions narrating what is shown. WCAG 2.2 SC 1.2.1 (Level A) requires transcripts for audio-only content; SC 1.2.3 (Level A) requires audio descriptions or transcripts for prerecorded video. Section 508 2018 Refresh 503.4.1 incorporates these. A podcast series or tutorial library with no transcripts excludes an entire class of users from the site's core value proposition.

Why this severity: Low because missing transcripts and audio descriptions affect discrete media assets rather than site-wide navigation, and workarounds (seeking specific timestamps, reading docs instead) may partially substitute.

PDF documents that are scanned images, untagged, or exported without accessibility settings are effectively invisible to screen readers—the document exists as a visual artifact with no machine-readable structure. Screen reader users cannot extract headings, read table data, or complete embedded forms. Section 508 2018 Refresh 504.2 requires electronic documents to conform to file-format-specific accessibility standards (PDF/UA, WCAG 2.2 SC 1.3.1). Annual reports, grant applications, policy documents, and compliance filings distributed as inaccessible PDFs shut out blind users from legally required public information.

Why this severity: Low because inaccessible documents affect downloadable assets rather than the interactive web experience, and an accessible HTML alternative can substitute without requiring PDF remediation.

Data tables without semantic markup are read by screen readers as an undifferentiated stream of cell values—users hear numbers and words but cannot determine which column header or row label a cell belongs to. `<th>` elements with `scope` attributes are the mechanism that associates data cells with their headers, enabling screen readers to announce "Region: North America, Sales: $2.5M" instead of just "North America $2.5M". WCAG 2.2 SC 1.3.1 (Level A) requires information conveyed through presentation to be programmatically determinable. Section 508 2018 Refresh 502.3.6 specifically requires that tables preserve semantic meaning for AT. Complex tables (multi-level headers, row spans) that lack semantic markup are entirely unusable for blind users.

Why this severity: Low because table markup failures affect specific data components rather than navigation or form submission, but they completely destroy the meaning of tabular data for screen reader users of those tables.

Touch targets that are too small cause users with motor impairments—including tremor, limited dexterity, or large fingers—to mis-tap adjacent controls repeatedly. This affects both assistive switch users and any mobile user on a small device. WCAG 2.2 SC 2.5.8 (Level AA, new in WCAG 2.2) sets a minimum 24x24 CSS pixel target size with spacing, and SC 2.5.5 (Level AAA) recommends 44x44 pixels. Section 508 2018 Refresh 503.3.7 requires that AT-operable controls meet size requirements. Undersized touch targets are particularly damaging on government services where users may need to complete critical tasks like submitting forms or accessing benefits.

Why this severity: Low because touch target sizing affects mobile usability for motor-impaired users specifically, but workarounds (pinch-zoom, assistive touch) may partially compensate on many devices.

Users with low vision rely on browser zoom and operating system text scaling to increase font size to a readable level. When layout uses absolute pixel units, fixed container widths, or overflow hidden on text containers, zooming to 200% causes content to overflow off-screen, overlap other elements, or disappear entirely. WCAG 2.2 SC 1.4.4 (Level AA) requires text to be resizable to 200% without loss of content or functionality, and SC 1.4.10 (Level AA) requires content to reflow without horizontal scrolling at 320 CSS pixel width. Section 508 2018 Refresh 502.3.3 incorporates SC 1.4.4. Failing this check excludes the millions of users with low vision who use browser zoom rather than a screen reader.

Why this severity: Low because text resize failures affect low-vision users specifically and only manifest at elevated zoom levels, but at those levels content may become completely unreadable.

Modal dialogs that do not trap keyboard focus allow Tab to move focus outside the modal into background content that is visually obscured, leaving keyboard users unable to see or interact with the focused element. Modals without `role="dialog"` are not announced as dialogs by screen readers, so users receive no cue that a blocking overlay has appeared. When focus fails to return to the trigger element on close, users lose their place in the page entirely. WCAG 2.2 SC 2.1.1 (Level A) and SC 4.1.2 (Level A) both apply; Section 508 2018 Refresh 502.3.2 requires that the full dialog lifecycle be accessible to AT. Broken modal focus is one of the most common Section 508 findings in government application audits.

Why this severity: Medium because broken modal focus management disrupts keyboard and screen reader users at a critical interaction point, but it does not prevent access to content outside the modal.

Users with cognitive disabilities, motor impairments, or those using assistive technology work more slowly and may legitimately need longer to complete tasks. A session that expires silently and discards form data—a grant application, benefits form, or tax filing—causes real harm beyond mere inconvenience. WCAG 2.2 SC 2.2.1 (Level A) requires that users be warned before a time limit expires and given an opportunity to extend it without data loss. SC 2.2.2 (Level A) targets automatic page updates that move content without user control. Section 508 2018 Refresh 503.3.5 incorporates timing control requirements. Silent session expiry during form-heavy government workflows is a common Section 508 complaint category.

Why this severity: Info because session timeout issues are scoped to authenticated flows and do not block access to public content, but they cause significant data-loss harm to users working slowly on form-heavy tasks.

Icon-only buttons and SVG graphics convey meaning entirely through visual shape—a trash can means delete, a gear means settings, an X means close. Without a text alternative, screen readers announce only "button" or the SVG element name, leaving users with no indication of the action they are about to take. WCAG 2.2 SC 1.1.1 (Level A) requires all non-text content to have a text alternative; SC 4.1.2 (Level A) requires that UI components expose name, role, and value to AT. Section 508 2018 Refresh 502.3.1 mirrors this. Toolbar rows of unlabeled icon buttons are one of the most common Section 508 failure patterns in web applications.

Why this severity: Info because icon labeling failures affect specific interactive controls rather than global navigation, and users may sometimes infer intent from context or position—but the failure is still a Level A WCAG violation.

Single-page applications update content dynamically—cart counts change, search results replace prior results, toast notifications appear, status messages resolve—all without a page reload. Screen readers only announce DOM changes inside `aria-live` regions; DOM changes elsewhere are silent. WCAG 2.2 SC 4.1.3 (Level AA) requires status messages to be programmatically determinable without receiving focus, and SC 1.3.1 (Level A) requires that information conveyed through presentation be available to AT. Section 508 2018 Refresh 502.3.14 requires applications to notify AT of relevant UI events. A cart update, form submission success, or real-time filter that silently changes the DOM shuts screen reader users out of the live application state.

Why this severity: Medium because missing `aria-live` regions cause screen reader users to miss status messages and dynamic content changes, degrading usability of dynamic interactions without preventing access to static content.