Section 508 Compliance: The Complete 2026 Guide
Sidharth Nayyar

Section 508 Compliance: The Complete 2026 Guide
Who must comply, what WCAG standards apply, how to create a VPAT, which testing tools to use, and what enforcement looks like in 2026 — everything federal agencies and contractors need in one place.
By WebAbility Team May 28, 2026 Updated May 28, 2026 12 min readWhat You'll Learn
- What Is Section 508?
- The 2017 Section 508 Refresh Explained
- Who Must Comply with Section 508 in 2026?
- Section 508 WCAG Requirements
- Section 508 vs ADA vs WCAG: Key Differences
- What Is a VPAT? Step-by-Step ACR Guide
- Section 508 Compliance Checklist 2026
- Section 508 Testing Tools
- Section 508 for Documents, PDFs & Software
- Enforcement, Penalties & Legal Risk
- How to Achieve Section 508 Compliance
- Frequently Asked Questions
What Is Section 508 Compliance? (Quick Answer)
Section 508 compliance means ensuring that an organization's electronic and information technology (ICT) — websites, software, documents, and hardware — meets the accessibility requirements of Section 508 of the Rehabilitation Act of 1973. It applies to U.S. federal agencies and any contractors or vendors who develop, supply, or maintain digital technology for federal use. Following the 2017 Section 508 Refresh, compliance is defined by conformance to WCAG 2.0 Level AA for web and software content, with many agencies now expecting WCAG 2.1 AA.
If your organization sells software to the U.S. government, operates a federal agency website, or delivers any digital system that federal employees or members of the public interact with, Section 508 compliance is not optional — it is a binding legal requirement and a prerequisite for federal procurement.
Yet despite being law since 1998, Section 508 remains widely misunderstood. Many organizations confuse it with the ADA. Others assume their WCAG work already covers it. And far too many contractors show up to procurement without a VPAT — and lose the contract.
This guide cuts through all of it. You will find a plain-English explanation of the law, a breakdown of what WCAG standards actually apply, a step-by-step VPAT walkthrough, testing tool recommendations, enforcement statistics, and a practical compliance roadmap for 2026. Whether you are a federal CIO, a government contractor, or a web team preparing for a procurement audit, this is the reference you need.
For a broader look at the web accessibility landscape, see our Website Accessibility Compliance Guide and our full Web Accessibility Compliance Hub.
What Is Section 508?
Section 508 is an amendment to the Rehabilitation Act of 1973 — specifically, a provision added in 1998 that requires U.S. federal agencies to make their electronic and information technology (ICT) accessible to people with disabilities.
The original Section 508 (enacted in 1986) required federal agencies to consider accessibility when purchasing or developing technology. The 1998 amendment significantly strengthened enforcement, giving individuals with disabilities the right to file complaints and bring civil action in federal court.
In practical terms, Section 508 means that websites, web applications, software, mobile apps, kiosks, electronic documents, and hardware procured or used by federal agencies must be designed and built so that people with visual, auditory, motor, and cognitive disabilities can use them effectively.
The law is administered by the U.S. Access Board (which sets the technical standards) and enforced through the General Services Administration, the Department of Justice, and individual federal agencies. For organizations regulated under related frameworks, our ADA compliance overview provides useful context on how these laws interact.
Section 508 at a Glance
| Attribute | Detail |
|---|---|
| Law Name | Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. § 794d) |
| Original Enactment | 1986 (amended to current form in 1998) |
| Most Recent Refresh | January 2017 (effective January 18, 2018) |
| Governing Body | U.S. Access Board (standards), GSA (implementation) |
| Technical Standard | WCAG 2.0 Level AA (WCAG 2.1 AA strongly recommended) |
| Applies To | Federal agencies + contractors + federally funded ICT |
| Coverage | Websites, software, mobile apps, documents, hardware, kiosks |
| Documentation Requirement | VPAT / Accessibility Conformance Report (ACR) |
| Enforcement | Administrative complaints + civil action in federal court |
The 2017 Section 508 Refresh: What Changed and Why It Matters
The original Section 508 technical standards were published in 2001 and organized accessibility requirements by product type — separate rules for web, software, video, telecommunications, and hardware. By the mid-2000s, the standards were badly out of date. The line between a website and software had blurred entirely. Mobile did not exist as a category. And the global web community had already converged on WCAG as the universal technical benchmark.
On January 18, 2017, the U.S. Access Board published the final rule for the Revised Section 508 Standards, which took effect on January 18, 2018. The refresh was the most significant overhaul in the law's history.
Key Changes in the 2017 Refresh
1. Adoption of WCAG 2.0 Level AA
The refresh replaced the 2001 product-specific criteria with a direct incorporation of WCAG 2.0 Level AA as the baseline technical standard for web content and software. This aligned U.S. federal requirements with the global accessibility standard and eliminated the need to maintain a separate U.S.-only compliance checklist for web.
2. Functionality-Based Organization
The new standards are organized by functional performance criteria rather than product type. This is a critical shift — it means that whether something is a website, a native app, a kiosk, or an internal tool, the same accessibility principles apply based on what the technology does, not what category it falls into. This allows the standards to remain relevant as technology evolves without requiring constant rewrites.
3. Expanded Coverage
The refresh explicitly extended Section 508 requirements to cover:
- Native and web-based software applications
- Mobile applications (a category that did not exist in 2001)
- Electronic documents — PDFs, Word files, spreadsheets, presentations
- Cloud-based services used by federal agencies
- Content delivered through third-party platforms or SaaS tools
4. International Harmonization
The revised standards were written to align with the European standard EN 301 549, which governs ICT accessibility requirements across the EU. This harmonization simplifies compliance for multinational organizations that need to meet both U.S. and European accessibility requirements. Our European Accessibility Act compliance guide covers the EU framework in depth.
5. Safe Harbor Provision
The refresh included an important safe harbor: ICT that complied with the original 2001 standards before the compliance date (January 18, 2018) and has not been altered since does not need to be retroactively upgraded. However, any modification to legacy ICT after that date triggers the obligation to conform to the Revised Standards. In practice, for organizations with actively maintained digital systems, the safe harbor is largely irrelevant — nearly all federal digital assets have been updated since 2018.
Should You Target WCAG 2.0, 2.1, or 2.2?
The Revised Section 508 Standards formally reference WCAG 2.0 Level AA. However, WCAG 2.1 Level AA is backward-compatible — it includes all of WCAG 2.0 plus 17 additional success criteria covering mobile, low-vision, and cognitive accessibility. Many federal agencies now explicitly request WCAG 2.1 AA conformance in procurement, and the Access Board has signaled intent to update Section 508 to reference WCAG 2.1 in a future rulemaking.
Our recommendation: target WCAG 2.1 Level AA as your compliance baseline. Doing so satisfies Section 508, future-proofs against the anticipated update, and aligns with ADA expectations (which the DOJ's 2024 rule tied to WCAG 2.1 AA). Read our complete WCAG 2.2 accessibility compliance guide to understand the full standards landscape.
Who Must Comply with Section 508 in 2026?
Section 508 has a clearly defined scope. Understanding whether your organization falls within that scope — and how deeply — determines your compliance obligations.
Federal Agencies
Every U.S. executive branch federal agency is subject to Section 508. This includes cabinet departments, independent agencies, commissions, and government corporations. When a federal agency develops, procures, maintains, or uses ICT, that technology must conform to Section 508. This obligation applies to:
- Public-facing agency websites and web applications
- Internal systems used by federal employees
- Documents published for public download
- Kiosks and self-service terminals in federal facilities
- Video and multimedia content produced by or for the agency
- Communication hardware and telecommunications equipment
Federal Contractors and Vendors
Any company that sells, licenses, or delivers ICT products or services to a federal agency must ensure those products meet Section 508 standards. This is typically enforced through contract clauses requiring vendors to provide an Accessibility Conformance Report (ACR) — completed using the VPAT template — as part of the procurement process.
The obligation attaches to the ICT being delivered, not necessarily to the vendor's own corporate website. A software company's internal website does not need to be Section 508 compliant. But the software product it sells to a federal agency absolutely does.
Contractors of all sizes are subject to this requirement, regardless of contract value or company size. If you are delivering digital products or services to the federal government, Section 508 applies. Explore how WebAbility supports government and public sector accessibility.
Organizations Receiving Federal Funding
Organizations that receive federal funding to develop or maintain digital systems may also fall within Section 508's scope, depending on the nature of the funding agreement. Universities, nonprofit research institutions, and state agencies operating federal grant programs should consult their specific funding agreements and agency guidance.
Private Sector Organizations
Private companies without federal contracts or funding are not subject to Section 508. However, they are subject to the Americans with Disabilities Act, which carries its own web accessibility requirements under Title III. Since both laws use WCAG as the technical benchmark, meeting WCAG 2.1 AA covers both frameworks simultaneously.
Quick test: If your product or service will be used by a federal agency employee or member of the public accessing a federal service, Section 508 compliance documentation is required — regardless of whether your contract explicitly mentions it.
Section 508 WCAG Requirements: The Four Principles
Following the 2017 Refresh, Section 508 web accessibility requirements are defined by the four POUR principles of WCAG 2.0 Level AA: Perceivable, Operable, Understandable, and Robust. Each principle contains guidelines, which in turn contain testable success criteria.
1. Perceivable
Information and user interface components must be presentable to users in ways they can perceive. Under Section 508, this requires:
- Text alternatives (alt text) for all non-text content, including images, icons, charts, and diagrams — so screen reader users receive equivalent information
- Captions and transcripts for all pre-recorded audio and video, and live captions for live audio broadcasts
- Color contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt+ bold)
- No information conveyed by color alone — status indicators, charts, and form validation must use shape, pattern, or text in addition to color
- Resizable text up to 200% without loss of content or functionality
- Accessible documents — PDFs and Office files must be tagged with proper heading structure, reading order, and image descriptions
Use WebAbility's free color contrast checker and AI alt text generator to audit Perceivable failures quickly.
2. Operable
All functionality must be operable through a keyboard, without requiring specific timing or physical gestures. Section 508 Operable requirements include:
- Full keyboard accessibility — every feature accessible by mouse must also be fully accessible by keyboard alone (Tab, Enter, arrow keys, Escape)
- Visible focus indicators — when tabbing through interactive elements, the focused element must have a clearly visible outline or highlight
- No keyboard traps — users must be able to navigate into and out of every component using only keyboard controls
- Skip navigation links — pages must provide a mechanism to skip repeated navigation blocks and jump directly to main content
- Sufficient time — if sessions time out or content auto-advances, users must be able to extend time limits
- No seizure-inducing content — content must not flash more than three times per second
- Descriptive page titles — each page must have a unique, descriptive title that identifies both the page content and the site
Our web accessibility testing tools guide covers keyboard testing workflows in detail.
3. Understandable
Content and user interface operation must be understandable to users of all cognitive abilities. Section 508 Understandable requirements include:
-
Language declaration — the page language must be declared in
the HTML
langattribute so screen readers use correct pronunciation - Consistent navigation — repeated navigational components must appear in the same location across pages
- Accessible error messages — form validation errors must identify the field in error and describe the problem in plain language
- Error prevention — for forms involving legal or financial transactions, users must be able to review, correct, and confirm submissions
- Clear labels — all form fields must have programmatically associated labels that are visible and persistent (not just placeholder text)
- Predictable behavior — UI components must not change context unexpectedly when receiving focus or changing values
4. Robust
Content must be robust enough to be interpreted reliably by a wide variety of assistive technologies, both current and future. Section 508 Robust requirements include:
- Valid HTML and ARIA — markup must conform to web standards with proper nesting, complete start/end tags, and unique IDs
- Correct ARIA implementation — ARIA roles, states, and properties must be used correctly; incorrect ARIA creates barriers rather than fixing them
- Status messages — programmatic notifications (success alerts, error summaries, loading states) must be announced to screen readers using live regions or ARIA roles
- Name, Role, Value — every user interface component must have an accessible name, its role must be conveyed to assistive technology, and its state and value must be programmatically determinable
Run a free automated scan of your website at WebAbility's accessibility scanner to identify POUR failures across all four principles instantly.
Section 508 vs ADA vs WCAG: Key Differences Explained
Section 508, the ADA, and WCAG are related but distinct — and confusing them leads to compliance gaps. Here is a clear breakdown:
| Attribute | Section 508 | ADA | WCAG |
|---|---|---|---|
| Type | Federal law | Federal civil rights law | Technical standard (not a law) |
| Enacted | 1998 (refreshed 2018) | 1990 | Published by W3C/WAI since 1999 |
| Who Must Comply | Federal agencies & contractors | Private businesses, state & local govt | Anyone choosing to adopt it |
| Technical Standard | WCAG 2.0 Level AA (2.1 recommended) | WCAG 2.1 Level AA (DOJ 2024 rule) | WCAG itself (2.0, 2.1, 2.2) |
| Enforcement | Administrative complaints, DOJ, civil court | Private lawsuits, DOJ investigations | N/A — enforced through laws that reference it |
| Documentation Required | Yes — VPAT / ACR mandatory for procurement | No formal document required | Conformance reports recommended |
| Covers Documents | Yes — PDF, Word, Excel, PPTX | Partially — under ADA Title II | No — focused on web content |
| Covers Hardware | Yes — kiosks, copiers, phones | Partially — physical accessibility | No |
| International Equivalent | EN 301 549 (Europe) | EAA (Europe) | Global — used by 50+ countries |
The Practical Takeaway
WCAG is the technical rulebook that both Section 508 and ADA point to. Meeting WCAG 2.1 Level AA satisfies both frameworks simultaneously for web content. Section 508 adds a layer of documentation (VPAT) and extends requirements to hardware and non-web documents. ADA adds litigation exposure for private-sector organizations. The diagram is:
WCAG 2.1 AA → satisfies the technical requirements of both → Section 508 + ADA.
Learn more about the ADA web accessibility requirements, WCAG compliance overview, and the broader accessibility compliance landscape.
What Is a VPAT? Your Step-by-Step Guide to Creating an ACR
The Voluntary Product Accessibility Template (VPAT) is a standardized document published by the Information Technology Industry Council (ITIC) that vendors use to describe how their product conforms to accessibility standards. A completed VPAT becomes an Accessibility Conformance Report (ACR) — the document federal agencies require during procurement.
Without a current, accurate ACR, your product will almost certainly be disqualified from federal contracting opportunities. Federal buyers are increasingly sophisticated: they know the difference between a thorough ACR and a superficial one, and they will push back on vague "Supports" claims with no evidence.
VPAT Versions
ITIC publishes several VPAT editions. For Section 508 compliance, the current version is VPAT 2.5, which includes separate conformance tables for:
- WCAG 2.x (web content)
- Revised Section 508 (full ICT scope)
- EN 301 549 (European standard)
- WCAG2ICT (for applying WCAG to non-web software)
For products sold to U.S. federal agencies, complete both the WCAG 2.x table and the Section 508 table. If the product is also sold in Europe, add EN 301 549.
Step-by-Step: How to Complete a VPAT
- Run a comprehensive accessibility audit. Before you can fill out a VPAT, you need test results. Use automated tools (axe, WAVE, Lighthouse) for baseline coverage, then conduct manual keyboard testing and screen reader testing with NVDA and JAWS. Document every finding against its specific WCAG success criterion.
- Download the latest VPAT template. Get VPAT 2.5 from the ITIC website. Do not use outdated templates — federal reviewers will notice.
- Complete the product information section. Name, version number, description, evaluation methods used, evaluation date, and contact information for the person responsible for the document.
-
Fill in each success criterion row. For every WCAG success
criterion and Section 508 provision, choose from four conformance levels:
- Supports — the product fully meets the criterion
- Partially Supports — the criterion is met under some conditions
- Does Not Support — the criterion is not met
- Not Applicable — the criterion does not apply to this product
- Write meaningful remarks for every non-"Supports" entry. This is where most VPATs fail. "Partially Supports: some images lack alt text" is not enough. Describe which components are affected, what the barrier is, and — where possible — your remediation timeline.
- Include your testing methodology. Buyers want to know how you tested: which tools, which assistive technologies, which browsers and OS, what version of the product was tested, and when. This information builds credibility.
- Update the VPAT regularly. A VPAT is a point-in-time document. It becomes stale with every product update. Federal agencies often specify that VPATs must be less than 12–24 months old. Plan to refresh your ACR at least once per major release cycle.
WebAbility provides VPAT/ACR documentation support as part of our managed accessibility service. Our team conducts the audit, maps every finding to WCAG success criteria, and helps you draft a procurement-ready ACR that stands up to federal scrutiny.
Section 508 Compliance Checklist 2026
Use this checklist to assess your current Section 508 posture. For a full-coverage audit, supplement this list with professional testing — automated tools catch only 30–40% of accessibility issues.
Web Content
- ☐ All images have descriptive alt text (or empty alt="" for decorative images)
- ☐ All videos have synchronized captions
- ☐ All audio-only content has a transcript
- ☐ Color contrast ratio ≥ 4.5:1 for body text; ≥ 3:1 for large text
- ☐ No information is conveyed by color alone
- ☐ All interactive elements are fully keyboard accessible
- ☐ Focus order follows a logical reading sequence
- ☐ Visible focus indicators on all interactive elements
- ☐ Skip navigation link appears at the top of each page
- ☐ Each page has a unique, descriptive <title>
- ☐ HTML
langattribute set correctly on every page - ☐ All form fields have visible, programmatically associated labels
- ☐ Error messages identify the specific field and describe the fix
- ☐ No content flashes more than 3 times per second
- ☐ Session timeouts can be extended or disabled
- ☐ Navigation is consistent across pages
Documents (PDF, Word, Excel, PowerPoint)
- ☐ Document is tagged with proper heading structure (H1 → H2 → H3)
- ☐ All images have alt text in the document tag tree
- ☐ Reading order matches visual presentation
- ☐ Tables use header rows and/or column headers; no merged cells in data tables
- ☐ All form fields are accessible and properly labeled
- ☐ Document language is declared
- ☐ PDFs pass Adobe Acrobat Accessibility Checker or PAC 3
- ☐ Document title is set in Document Properties
Software and Applications
- ☐ All UI controls have accessible names and roles
- ☐ State changes (expanded/collapsed, selected, checked) are programmatically exposed
- ☐ Dialogs and modals trap focus correctly while open; release focus correctly when closed
- ☐ Dynamic content updates are announced via ARIA live regions
- ☐ Custom components (date pickers, carousels, data grids) are keyboard accessible
- ☐ Application passes screen reader testing with NVDA+Firefox and JAWS+Chrome
- ☐ No reliance on color alone for system status or error states
Documentation and Procurement
- ☐ Accessibility Conformance Report (ACR/VPAT 2.5) is current (within 12–24 months)
- ☐ ACR is based on documented testing, not self-assessment alone
- ☐ Accessibility statement published and linked from the product or website
- ☐ Remediation roadmap documented for known barriers
- ☐ Ongoing monitoring process in place
For a printable version and deeper per-criterion guidance, explore our accessibility checker comparison and accessibility FAQ .
Section 508 Testing Tools: Automated and Manual
No single tool can guarantee Section 508 compliance. The most reliable approach combines automated scanning for baseline coverage with expert manual testing using real assistive technologies. Studies consistently show that automated tools detect approximately 30–40% of WCAG/508 issues; the remainder requires human judgment.
Automated Testing Tools
| Tool | Type | Coverage | Cost | Best For |
|---|---|---|---|---|
| axe DevTools | Browser extension / CI integration | WCAG 2.0/2.1/2.2, Section 508 | Free (core); paid (Pro) | Developers, CI/CD pipeline |
| WAVE | Browser extension / API | WCAG 2.x, Section 508 subset | Free extension; API paid | Quick visual page audits |
| Google Lighthouse | Browser DevTools / CI | WCAG subset (via axe) | Free | General web performance + a11y |
| Accessibility Insights | Browser extension (Microsoft) | WCAG 2.1, Section 508 | Free | Guided manual walkthroughs |
| WebAbility Scanner | SaaS / continuous monitoring | WCAG 2.2, ADA, Section 508 | Free scan; paid monitoring | Ongoing compliance monitoring |
| Siteimprove | SaaS platform | WCAG 2.1, Section 508, EN 301 549 | Paid (enterprise) | Large federal / enterprise sites |
| Pa11y | Open source CLI / CI | WCAG 2.1, HTML_CS | Free | Automated batch testing |
Manual and Assistive Technology Testing
Manual testing using assistive technologies is non-negotiable for Section 508 compliance. The following combinations are the federal standard for screen reader testing:
| Screen Reader | Browser | OS | Notes |
|---|---|---|---|
| JAWS | Chrome, Edge | Windows | Market leader; most common in federal environments; paid license |
| NVDA | Firefox, Chrome | Windows | Free open-source; second most used; essential for budget-conscious teams |
| VoiceOver | Safari | macOS / iOS | Built into Apple devices; critical for mobile accessibility |
| TalkBack | Chrome | Android | Android screen reader; important for mobile and responsive content |
In addition to screen readers, manual testing should include:
- Keyboard-only navigation — unplug the mouse and navigate every workflow using only Tab, Shift+Tab, Enter, Space, and arrow keys
- Zoom testing — zoom to 200% and 400% in browser to verify no content is lost or obscured
- High-contrast mode — enable Windows High Contrast to confirm UI elements remain distinguishable
- Voice control — test with Dragon NaturallySpeaking or Windows Speech Recognition for motor-impaired user scenarios
See our detailed web accessibility testing tools guide and website accessibility testing tools comparison for in-depth tool reviews.
Section 508 for Documents, PDFs, and Software
One of the most underestimated aspects of Section 508 is its coverage of electronic documents and software applications. Most organizations focus on websites but neglect the PDF reports, Word policy documents, Excel data tables, and PowerPoint presentations they publish — all of which must be accessible under Section 508.
PDF Accessibility Under Section 508
PDFs are the most commonly failing document type in federal procurement audits. A Section 508-compliant PDF must:
- Be tagged — all content elements (headings, paragraphs, lists, tables, images) must have corresponding accessibility tags in the PDF tag tree
- Have a correct reading order — the sequence in which a screen reader reads the content must match the visual layout
- Contain alt text for all images, charts, and figures
- Have accessible tables with row and column headers programmatically identified
- Not be a scanned image — scanned PDFs are completely inaccessible to screen readers unless OCR is applied and the resulting text is tagged
- Have a document title set in Document Properties
- Have accessible forms with labeled fields, tab order, and accessible submit buttons if applicable
The most reliable way to check a PDF is to run it through the Adobe Acrobat Pro Accessibility Checker and validate the tag tree manually. The free tool PAC 3 (PDF Accessibility Checker) from Access For All is also widely used in federal environments.
Software and Application Accessibility
The 2017 Section 508 Refresh introduced the WCAG2ICT framework, which applies WCAG 2.0 principles to non-web software. Under this framework, native desktop applications, mobile apps, and SaaS platforms sold to federal agencies must meet the same functional accessibility requirements as websites.
Key software-specific requirements include:
- Platform accessibility API integration — applications must correctly expose UI information to operating system accessibility APIs (UI Automation on Windows, Accessibility API on macOS, AT-SPI on Linux)
- No disruption of assistive technology — applications must not interfere with system-level accessibility features like screen magnification, sticky keys, or high-contrast mode
- Accessible authentication — login flows must be operable with assistive technology; CAPTCHAs must have audio alternatives
- Closed functionality — for kiosks and fixed-function devices that cannot run third-party assistive technology, built-in accessibility features must be provided
Our technology sector accessibility guide covers software accessibility requirements in depth for technology vendors.
Section 508 Enforcement, Penalties, and Legal Risk in 2026
Section 508 enforcement has intensified significantly over the past decade, driven by a combination of DOJ activity, increased disability advocacy, and the growing role of accessibility in federal procurement processes.
How Section 508 Is Enforced
Unlike the ADA, which is enforced primarily through private litigation, Section 508 enforcement operates through three main channels:
1. Administrative Complaints
Any individual with a disability can file a complaint with the federal agency whose ICT created the barrier, or with the U.S. Department of Justice. The agency must investigate the complaint and take corrective action within a defined timeframe. Complaints are the most common enforcement mechanism and often lead to:
- Formal compliance reviews
- Corrective action plans with binding timelines
- Ongoing DOJ monitoring for severe or systemic cases
2. Civil Action in Federal Court
Individuals who exhaust administrative remedies — or where the agency fails to resolve the complaint — may bring a civil action in federal district court. Courts can order agencies to remediate barriers, mandate ongoing accessibility monitoring, and award attorneys' fees to successful plaintiffs.
3. Procurement Enforcement
For vendors and contractors, enforcement is primarily procurement-driven. Federal contracting officers are required to verify Section 508 compliance before awarding contracts for ICT. Failure to provide a current, complete ACR/VPAT — or providing one that is materially inaccurate — can result in:
- Disqualification from the procurement
- Contract termination for default
- Exclusion from future federal contracting opportunities
- In extreme cases, false claims liability if compliance was misrepresented
Penalties for Non-Compliance
Section 508 does not specify fixed fines in the same way that some other laws do. However, the financial consequences of non-compliance are substantial:
| Consequence | Estimated Cost |
|---|---|
| Lost federal contract (medium agency) | $1M–$50M+ |
| DOJ consent decree remediation | $500K–$5M+ (estimated) |
| Civil lawsuit settlement | $50K–$500K (depending on scope) |
| Accessibility remediation (post-launch fix) | 3–10× more expensive than building-in accessibility |
| Reputational damage / brand impact | Incalculable |
The Growing Enforcement Landscape
Digital accessibility enforcement is accelerating across the U.S. The DOJ's 2024 final rule under ADA Title II extended WCAG 2.1 AA requirements to all state and local government websites — an expansion that has raised awareness of Section 508 obligations among federal contractors and the procurement community. In 2025, more than 5,100 web accessibility lawsuits were filed in the United States, with administrative actions under Section 508 adding to that figure.
Federal agencies have also intensified procurement scrutiny. Contracting officers now routinely require current VPATs, ask follow-up questions about testing methodology, and conduct their own basic accessibility checks before awarding contracts. The era of submitting a pro forma VPAT claiming blanket "Supports" conformance and passing procurement is over.
Explore our ADA compliance overview and business case for accessibility to understand the full risk and opportunity landscape.
How to Achieve Section 508 Compliance: A Practical Roadmap
Section 508 compliance is achievable for any organization willing to take a structured, systematic approach. The five-phase roadmap below reflects best practice for both federal agencies undertaking self-remediation and vendors preparing for federal procurement.
Phase 1: Audit
Start with a thorough accessibility audit that covers your entire digital estate: website, web applications, mobile apps, electronic documents, and any ICT relevant to your federal contract scope.
An audit should combine:
- Automated scanning — use axe, WAVE, or WebAbility's scanner for baseline coverage across all page templates
- Manual keyboard testing — test every workflow end-to-end with keyboard only
- Screen reader testing — JAWS + Chrome (primary) and NVDA + Firefox (secondary) for web; VoiceOver for mobile
- Document audit — check all PDFs, Word files, and presentations against the Section 508 document checklist
Use our accessibility checker comparison tool to identify the right tool stack for your environment.
Phase 2: Prioritize
Not every issue requires immediate remediation. Prioritize by:
- Impact — failures on high-traffic pages, core workflows (login, checkout, search, form submission), and primary navigation cause the most harm and the most legal exposure
- Severity — Level A WCAG failures (complete barriers) before Level AA (partial barriers)
- Procurement deadline — if an ACR is due in 60 days, prioritize the product scope being evaluated over peripheral systems
- Quick wins — missing alt text, hardcoded contrast failures, and missing form labels can often be fixed in hours and improve your conformance score dramatically
Phase 3: Remediate
Remediate issues starting with the highest-severity, highest-impact findings. Use developer-ready guidance that maps each issue to a specific code fix — not just a WCAG citation. For example:
-
Missing alt text → add descriptive
alt=""attribute to<img>tags; use emptyalt=""for decorative images -
No form label → add
<label for="field-id">oraria-label/aria-labelledbyon the input -
Keyboard trap → ensure
TabandShift+Tabmove focus out of modal dialogs and custom widgets -
Missing focus indicator → add a visible CSS
:focusor:focus-visibleoutline (minimum 2px solid)
Our accessibility testing tools review includes remediation code patterns for the most common Section 508 failures.
Phase 4: Document
Once remediation is in progress, prepare your documentation:
- ACR / VPAT — completed based on the current, tested state of the product (not aspirational claims)
- Accessibility statement — published on your website or product, declaring your conformance level, known limitations, and contact information for accessibility support. Use WebAbility's free accessibility statement generator.
- Remediation roadmap — a documented timeline for resolving known issues, demonstrating good-faith commitment
Phase 5: Monitor and Maintain
Section 508 compliance is not a one-time certification — it requires continuous maintenance. Every CMS update, feature release, new page template, and third-party script integration is a potential regression point.
Continuous monitoring should include:
- Automated daily or weekly scans across all page templates
- Accessibility regression testing in your CI/CD pipeline
- Quarterly expert review with documented findings
- Annual full audit to refresh the ACR
- Accessibility training for content editors and developers
WebAbility's managed accessibility service provides continuous monitoring, quarterly expert reviews, and procurement-ready documentation — so your Section 508 posture stays current without burdening your internal team. View our pricing plans to find the right fit for your organization.
Is Your Website Section 508 Compliant?
Run a free automated scan of your website and get an instant Section 508 and WCAG compliance report — no registration required.
Run Free Section 508 Scan →Section 508 Compliance by Industry
Section 508 obligations and their practical implications vary somewhat by sector. Here is how the law applies across the industries most commonly affected.
Federal Agencies and Government
Federal agencies are the primary subject of Section 508 and face the highest scrutiny. Every public-facing website, internal employee system, procurement portal, and published document must meet the standard. CIOs and Section 508 Program Managers are responsible for agency-wide compliance programs, VPAT procurement review, and reporting to Congress on accessibility posture. Our government sector accessibility guide covers federal-specific compliance requirements in detail.
Defense and Intelligence Contractors
Defense contractors developing systems under DoD, NSA, or intelligence community contracts face rigorous VPAT requirements, often including additional security and interoperability constraints. Section 508 compliance is typically embedded in the contract's technical performance requirements.
Healthcare and Health IT
Healthcare organizations receiving federal funding (Medicare, Medicaid, VA, HHS) must ensure their patient portals, electronic health record (EHR) systems, and telehealth platforms are Section 508 compliant. Our healthcare accessibility guide explains the intersection of 508 and HIPAA.
Education and Research
Universities and research institutions receiving federal grants are increasingly subject to Section 508 requirements for the digital systems developed under those grants. The Department of Education and NSF have both issued guidance requiring grantees to address accessibility in funded digital systems. Our education sector accessibility guide covers higher-education compliance obligations.
Financial Services
Financial institutions working with federal programs (SBA loans, federal employee benefits, government-backed mortgages) must ensure their digital channels meet Section 508 standards for the federal-facing portions of their services. See our banking and finance accessibility guide.
Technology Vendors and SaaS
Software vendors selling to federal agencies — whether SaaS platforms, desktop applications, or development tools — face the broadest VPAT expectations. A compelling ACR is a competitive differentiator in federal procurement, and organizations that invest in genuine accessibility often win contracts that competitors lose due to inadequate documentation. Our technology sector accessibility guide covers software vendor compliance in full.
Section 508 Compliance: Frequently Asked Questions
What is Section 508 compliance?Section 508 compliance means meeting the accessibility requirements of Section 508 of the Rehabilitation Act of 1973, as amended. It requires U.S. federal agencies and their contractors to ensure that electronic and information technology (ICT) — including websites, software, documents, and hardware — is accessible to people with disabilities. Following the 2017 Section 508 Refresh, compliance means conforming to WCAG 2.0 Level AA for digital content.
Who must comply with Section 508?Section 508 applies to all U.S. federal government agencies, federal contractors delivering digital products or services, software vendors selling to federal agencies, and organizations receiving federal funding to develop digital systems. Private companies without federal contracts are not subject to Section 508, but may still need to comply with ADA requirements.
Does Section 508 require WCAG 2.1 or WCAG 2.2?The 2017 Section 508 Refresh formally references WCAG 2.0 Level AA as the technical standard. However, many federal agencies and procurement teams now expect alignment with WCAG 2.1 Level AA as a best practice. Meeting WCAG 2.1 AA fully satisfies Section 508 requirements and future-proofs your compliance posture.
What is a VPAT and why does it matter for Section 508?A VPAT (Voluntary Product Accessibility Template) is a document that describes how a product or service conforms to accessibility standards, including Section 508. Federal agencies require vendors to provide a completed VPAT — also called an Accessibility Conformance Report (ACR) — as part of the procurement process. Without a VPAT, vendors risk disqualification from federal contracts.
What is the difference between Section 508 and the ADA?Section 508 applies specifically to U.S. federal agencies and their contractors, governing ICT accessibility in federal procurement. The ADA applies broadly to private businesses open to the public and state/local governments. Both laws use WCAG as their technical benchmark, but Section 508 is procurement-driven while ADA is litigation-driven.
What does the 2017 Section 508 Refresh change?The 2017 Section 508 Refresh, effective January 18, 2018, modernized the 2001 standards in three key ways: it adopted WCAG 2.0 Level AA as the baseline for web and software accessibility; it reorganized standards by functionality rather than product type; and it expanded coverage to include software, mobile apps, and electronic documents. It also harmonized U.S. requirements with European standard EN 301 549.
What are the penalties for Section 508 non-compliance?Section 508 violations can result in administrative complaints filed with the relevant federal agency or the DOJ, corrective action mandates requiring costly remediation, procurement disqualification, and civil litigation. For vendors, losing a single federal contract due to non-compliance can mean millions of dollars in lost revenue. DOJ consent decree remediation costs can reach five figures to millions depending on scope.
What tools are used to test Section 508 compliance?Section 508 testing uses a combination of automated and manual tools. Common automated tools include axe DevTools, WAVE, Lighthouse, and Accessibility Insights. Manual testing uses screen readers like NVDA (free) and JAWS (paid), plus keyboard-only navigation testing. Automated tools catch roughly 30–40% of issues; manual expert review is essential for full compliance validation.
Does Section 508 apply to PDFs and documents?Yes. Section 508 applies to all electronic content, including PDF documents, Word files, Excel spreadsheets, and presentations. Documents must have proper heading structure, alt text for images, tagged tables, readable reading order, and accessible form fields. Federal agencies frequently audit document accessibility as part of procurement evaluations.
How long does it take to achieve Section 508 compliance?Timeline depends on the size and complexity of your digital estate. A simple website may achieve compliance within 4–8 weeks. Large federal portals, complex software platforms, or document libraries can take 3–6 months. Starting with a professional Section 508 audit to identify and prioritize issues is the fastest path to procurement-ready compliance.
Section 508 Compliance in 2026: Where to Start
Section 508 compliance has never been more important — or more achievable. The technical requirements are well-defined, the tooling is mature, and the business case is compelling: organizations that invest in genuine accessibility win more federal contracts, avoid costly enforcement actions, and build digital products that work for everyone.
The path forward is straightforward: audit your ICT against WCAG 2.1 AA, fix the issues in order of severity, document your conformance in an accurate and current ACR, and put a continuous monitoring process in place to prevent regression.
Whether you are a federal agency CIO building a compliance program from the ground up, a government contractor preparing for a procurement audit, or a SaaS vendor expanding into the federal market, WebAbility can help at every stage — from the initial scan to VPAT documentation to ongoing monitoring.
For the complete regulatory picture, explore our resources on ADA compliance, WCAG 2.2 standards, European Accessibility Act, and our complete website accessibility compliance guide .
Start Your Section 508 Compliance Journey Today
Get a free automated Section 508 compliance scan, explore our accessibility tools, and speak with our team about VPAT documentation and managed compliance support.
Free Compliance Scan Explore Managed AccessibilityRelated Resources
- Website Accessibility Compliance Guide (WCAG 2.2) — 2026
- ADA Web Accessibility Requirements
- What Is WCAG? Complete Overview
- European Accessibility Act Compliance Guide
- 12 Best Web Accessibility Testing Tools (2026 Reviewed)
- 12 Best Website Accessibility Testing Tools for 2026
- 12 Best Accessibility Tools for Websites (2026 Tested)
- Free Color Contrast Checker Tool
- AI Alt Text Generator
- Government & Public Sector Accessibility Guide
- Healthcare Accessibility Guide
- Education Accessibility Guide
- Free Accessibility Statement Generator
- Accessibility FAQ
Quick Questions
Tap to ask AI about this article







