Skip to main content
INS // Insights

Section 508 Compliance for Web Applications

Updated March 2026 · 7 min read

Section 508 of the Rehabilitation Act requires federal agencies — and their contractors — to ensure electronic and information technology is accessible to people with disabilities. For web applications developed on government contracts, this isn't optional: non-compliant deliverables can be rejected, and agencies face legal liability when accessibility requirements aren't met.

This article covers what Section 508 compliance actually requires in a web application development context, and what prime contractors need from engineering subcontractors delivering government-facing software.

Section 508 and WCAG: The Relationship

Section 508 standards, as revised in 2018, incorporate WCAG 2.0 Level AA as the technical standard for web content and applications. In practice, most government programs are implementing WCAG 2.1 Level AA, the current widely referenced standard.

WCAG is organized around four principles, often abbreviated POUR:

  • Perceivable: Information must be presentable in ways users can perceive (text alternatives for non-text content, captions for audio/video, sufficient color contrast)
  • Operable: Interface components must be operable (keyboard accessible, no seizure-inducing content, sufficient navigation)
  • Understandable: Information and UI operation must be understandable (readable text, predictable behavior, error identification)
  • Robust: Content must be robust enough that it can be interpreted by a wide variety of assistive technologies (valid HTML, name/role/value for UI components)

For web applications, each of these principles translates into specific technical requirements with testable success criteria.

What Technical 508 Compliance Requires for Government Web Applications

Keyboard Accessibility

Every function in the application must be operable with a keyboard alone — no mouse required. This means:

  • All interactive elements (buttons, links, form fields, modals) are reachable via Tab key
  • Logical, predictable focus order that follows visual layout
  • Visible focus indicator on all interactive elements (not removed via outline: none)
  • Modal dialogs trap focus correctly and return focus to the trigger element on close
  • Custom widgets (dropdowns, date pickers, sliders) implement ARIA keyboard interaction patterns

Keyboard accessibility testing is a manual process — automated tools catch some issues but miss complex interaction patterns.

Screen Reader Compatibility

Screen readers (NVDA, JAWS, VoiceOver) read the DOM and announce content to blind users. For government web applications:

  • Semantic HTML: use <nav>, <main>, <section>, <button> correctly rather than generic <div> elements with click handlers
  • ARIA roles and attributes where semantic HTML is insufficient — custom components need role, aria-label, aria-expanded, aria-describedby as appropriate
  • Dynamic content changes (AJAX updates, toast notifications, modals) must announce to screen readers via ARIA live regions
  • Images need descriptive alt text; decorative images need alt=""
  • Form inputs need associated <label> elements or aria-label attributes

The official guide to building 508-compliant government websites covers additional implementation details for common government web patterns.

Color and Contrast

WCAG 2.1 AA requires:

  • 4.5:1 minimum contrast ratio for normal text
  • 3:1 for large text (18pt or 14pt bold) and UI components
  • Color cannot be the only means of conveying information (error states, status indicators need text or icons, not just color)

Automated tools like axe, Lighthouse, or WAVE catch most contrast failures. Run these early and continuously — contrast issues are often introduced during visual design refinement.

Forms and Error Handling

Government forms — applications, data entry, search — require:

  • All form fields labeled with associated <label> or ARIA equivalents
  • Required fields indicated by text (not just an asterisk without explanation)
  • Error messages that identify the field in error and describe the problem — not just "invalid input"
  • Error messages associated with the relevant field via aria-describedby
  • No timeout that loses user input without warning and the option to extend

Documents and PDFs

Federal agencies deliver a large volume of information via PDF. Section 508 requires PDFs to be tagged for screen reader access. This means PDFs must be created or remediated with proper PDF tags (headings, tables, lists, alt text for images). Untagged PDFs — scanned documents or print-to-PDF files — are not 508-compliant.

Testing and Validation Requirements

Government programs typically require a Voluntary Product Accessibility Template (VPAT) — a standardized document that assesses conformance against WCAG 2.1 success criteria. The VPAT becomes part of the contract deliverable documentation.

Automated testing: Tools like axe DevTools, Lighthouse accessibility audit, and WAVE catch approximately 30–40% of accessibility issues. They're necessary but not sufficient.

Manual testing: Keyboard navigation testing, screen reader testing with NVDA (Windows) and VoiceOver (macOS/iOS), and manual review of dynamic interactions are required to catch issues automated tools miss.

User testing with assistive technology users: Best practice for government programs that will be used by the public or agency staff with disabilities. Not always contractually required but increasingly common.

Continuous integration: Accessibility checks should be part of the CI pipeline — automated axe or Pa11y checks on every PR prevent regression and catch obvious issues before they reach review stages.

What Primes Should Require From Web Development Subs

Prime contractors delivering government web application contracts need subs who treat 508 compliance as a first-class engineering concern, not an afterthought:

  • Built-in accessibility from design: 508-compliant components and design patterns from the component library, not a retrofit pass at the end
  • Automated checks in CI: axe or equivalent integration that prevents obvious regressions
  • Manual testing documentation: Test plans and test results for keyboard navigation and screen reader compatibility
  • VPAT preparation capability: Experience completing VPATs for production government applications
  • ATO documentation support: 508 compliance is one of several security and compliance control areas that ATO documentation must address

The cost of retrofitting inaccessible government software — after design and development — is substantially higher than building accessibly from the beginning.

Learn how Rutagon delivers Section 508 compliant government web applications →

Frequently Asked Questions

What is the current technical standard for Section 508 compliance in web applications?

The revised Section 508 standards (2018) incorporate WCAG 2.0 Level AA as the minimum technical standard. Most government programs are implementing WCAG 2.1 Level AA. The success criteria are organized around four principles: Perceivable, Operable, Understandable, and Robust.

How much of Section 508 compliance can be caught with automated testing tools?

Automated tools like axe, Lighthouse, and WAVE typically catch 30–40% of accessibility issues. They're excellent for color contrast, missing alt text, and missing form labels, but miss keyboard interaction patterns, screen reader announcements for dynamic content, and logical focus order. Manual testing is required for full compliance verification.

What is a VPAT and when is it required?

A Voluntary Product Accessibility Template (VPAT) is a standardized document that assesses a product's conformance against WCAG 2.1 criteria. Government contracts typically require a VPAT as a deliverable for web applications. The VPAT documents both what's fully conformant and what partially conforms or doesn't conform, with explanations.

How do government contracts enforce Section 508 compliance?

Contracts specify 508 compliance as an acceptance criterion for software deliverables. Government CORs (Contracting Officer's Representatives) can reject deliverables that fail accessibility testing. Agencies also face OCR complaints and legal liability for inaccessible public-facing systems.

Is Section 508 compliance different for mobile applications?

WCAG 2.1 success criteria apply to mobile web applications. Native mobile apps follow WCAG 2.1 principles but are also guided by platform-specific accessibility APIs — VoiceOver on iOS, TalkBack on Android. Most government mobile requirements reference WCAG 2.1 AA as the standard, sometimes with additional mobile-specific test procedures.