Section 508 Compliance Checklist 2026: Complete Guide for Federal Agencies
Updated April 30, 2026 · 18 min read · By Accessalyze
Who this applies to: Section 508 of the Rehabilitation Act requires all federal agencies — and vendors and contractors doing business with the federal government — to ensure their Information and Communications Technology (ICT) is accessible to people with disabilities. Non-federal organizations that receive federal funding are also subject to Section 504 and related requirements.
Section 508 is often misunderstood as a website compliance law. In reality, it covers your entire ICT portfolio: public websites, internal web applications, desktop software, electronic documents, multimedia, hardware, and every technology product you procure. This checklist covers each domain so federal agencies and their contractors can systematically verify and document compliance.
Understanding the 2018 Refresh and WCAG Integration
The Section 508 Standards were substantially revised in January 2017 with changes effective January 2018 — commonly called the "508 Refresh." Key changes from the original 2001 standards include:
WCAG 2.0 Level AA incorporated by reference — Web content and software must meet all 38 Level A and AA success criteria from WCAG 2.0.
Technology-neutral approach — Rather than prescribing specific technologies, the Refresh defines functional performance criteria and references international standards.
Harmonization with international standards — The Refresh aligns closely with EN 301 549, the European accessibility standard, making compliance more consistent for multinational vendors.
WCAG 2.1 alignment recommended — The Access Board and GSA guidance encourage agencies to target WCAG 2.1 AA, which adds 17 additional criteria addressing mobile, cognitive, and low vision needs.
Best practice: Build to WCAG 2.1 AA, not WCAG 2.0 AA. The additional criteria in 2.1 address real needs — reflow on mobile, non-text contrast, input purpose — and adoption now avoids a remediation effort when the next Section 508 update formalizes the requirement.
Section A — Public-Facing Web Content
All publicly available federal web content must meet WCAG 2.1 AA success criteria. This section is the highest-visibility compliance area and the most commonly audited by disability rights organizations and OCR investigators.
A1 — Perceivable: Text Alternatives and Non-Text Content
All non-decorative images have descriptive alt attributes that convey image meaning
Decorative images use empty alt text (alt="") and do not confuse screen readers
Complex images (charts, infographics, maps, diagrams) have extended text descriptions accessible nearby or via a link
CAPTCHAs have audio or text alternatives
Buttons and icon-only controls have accessible names via aria-label or visible text
SVG icons used as controls have appropriate title elements or aria-label
CSS background images that convey information have equivalent accessible markup
A2 — Perceivable: Time-Based Media
Pre-recorded audio-only content has a text transcript
Pre-recorded video-only content has a text description or audio description track
Pre-recorded video with audio has synchronized closed captions
Captions are accurate — auto-generated captions alone are not sufficient without review
Live video content has real-time captions (may use CART or automated captioning reviewed post-event)
Pre-recorded video has audio descriptions for visual-only information where needed
Extended audio descriptions are available for videos with insufficient pause time for standard descriptions
Sign language interpretation is available for pre-recorded multimedia (Level AAA — note for best practice)
A3 — Perceivable: Adaptable and Distinguishable Content
Content structure is communicated through semantic markup (headings, lists, tables) not just visual presentation
Reading and content sequence is meaningful when CSS is removed
Information is not conveyed through color alone — shape, pattern, or text labels supplement color coding
No audio plays automatically for more than 3 seconds without a pause/stop mechanism
Text color contrast ratio is 4.5:1 minimum for normal text; 3:1 for large text (18pt or 14pt bold)
UI component and state boundaries (focus rings, button borders, form field outlines) have 3:1 contrast against adjacent colors (WCAG 2.1)
Text can be resized to 200% via browser zoom without loss of content or functionality
Images of text are avoided; when used they have accessible text equivalents
Content reflows at 320px viewport width without requiring horizontal scrolling (WCAG 2.1)
Spacing between text, letters, lines, and paragraphs can be increased by user without loss of content (WCAG 2.1)
Hover and focus-triggered content (tooltips, dropdowns) can be dismissed, hovered, and persists until dismissed (WCAG 2.1)
A4 — Operable: Keyboard and Navigation
All functionality is accessible via keyboard alone — no mouse-only interactions
No keyboard traps exist on any page — user can always navigate away using Tab/Shift+Tab
Skip navigation links are provided at the top of each page to bypass repeated header content
All pages have unique, descriptive <title> elements
Focus order follows a logical, meaningful sequence matching visual layout
Link and control purpose is clear from text alone or from surrounding context
Multiple ways exist to find pages: navigation menu, site search, and/or site map
Page headings and form labels accurately describe their content and purpose
Keyboard focus indicator is visible at all times — not removed with CSS outline:none without replacement
Focus indicator has sufficient contrast (3:1 against adjacent colors — WCAG 2.1 enhanced)
No timing requirements unless user can turn off, adjust, or extend time limits
No content flashes more than 3 times per second
Users can pause, stop, or hide any automatically moving, blinking, or scrolling content
Pointer gestures that require a path (swipe, drag) have single-pointer alternatives (WCAG 2.1)
Pointer actions trigger on up-event, not down-event, allowing cancellation (WCAG 2.1)
Motion-activated features (shake, tilt) have UI alternatives and can be disabled (WCAG 2.1)
Page language is declared via <html lang="en"> (or appropriate language code)
Language changes within page content are marked with lang attribute on the element
Navigation menus and UI patterns are consistent across all pages
Components with the same function are identified consistently
On-focus and on-input do not trigger unexpected context changes (new page, form submission)
Unusual words, jargon, and abbreviations are explained or defined
Form inputs have clearly associated labels — not just placeholder text
Error messages are specific: they identify which field failed and how to fix it
Input format requirements are communicated before the user submits (e.g., "Date: MM/DD/YYYY")
Legal, financial, and data-submission actions can be confirmed, reversed, or checked before submission
Input purpose for personal data fields (name, email, address) is programmatically determinable via autocomplete attribute (WCAG 2.1)
A6 — Robust: Compatible Markup
HTML validates without critical errors (no duplicate IDs, properly nested elements)
All UI components have accessible name, role, and state — via native semantics or ARIA
Status messages (form success, error alerts, loading indicators) are announced to screen readers without requiring focus (ARIA live regions) (WCAG 2.1)
Dynamic content updates use appropriate ARIA live region roles (aria-live, role="alert", role="status")
Modal dialogs trap focus appropriately and return focus on close
ARIA attributes are used correctly — not incorrectly overriding native semantics
Section B — Internal Web Applications and Software
Internal-facing tools used by federal employees are equally required to meet Section 508. Many agencies focus on public-facing compliance while neglecting the productivity tools, case management systems, and HR platforms that employees use daily — this creates barriers for employees with disabilities.
B1 — Internal Web Applications
All web-based internal applications meet WCAG 2.1 AA criteria (all items in Section A apply)
Internal portals, intranets, and collaboration tools are included in audit scope
Employee onboarding, training, and HR systems are accessible
Data entry and workflow applications support keyboard-only operation
Internal dashboards and data visualizations provide accessible text alternatives
B2 — Desktop Software (Section 508 E205–E207)
Desktop applications do not override system accessibility settings (high contrast, large fonts, sticky keys)
Applications are compatible with common assistive technology: JAWS, NVDA, ZoomText, Dragon NaturallySpeaking
All user interface components have accessible names determinable by assistive technology via platform accessibility APIs
Platform accessibility services are not blocked by the application
Software documentation is itself accessible (accessible PDFs, web pages)
Section C — Electronic Documents
PDFs, Word documents, PowerPoint presentations, and spreadsheets are ICT under Section 508. Document accessibility is one of the most neglected compliance areas and one of the most commonly cited in complaints.
C1 — PDF Accessibility
PDFs are tagged — all content has appropriate tag types (headings, paragraphs, lists, tables)
PDF reading order (tab order) matches the visual reading order
All images in PDFs have alt text or are tagged as artifacts (decorative)
PDF forms have labeled fields — form labels are associated with their controls
PDF forms are completable using keyboard alone
PDF form required fields are programmatically indicated
PDF document language is set in Document Properties
PDF document title is set in Document Properties (not just the filename)
Scanned PDFs are avoided — if unavoidable, OCR is applied and output is reviewed for accuracy
Tables in PDFs have defined header cells
PDF color contrast meets 4.5:1 for text content
PDF passes automated checker (Adobe Acrobat Accessibility Checker or PAC 3)
C2 — Microsoft Word Documents
Built-in heading styles (Heading 1, 2, 3) are used — not just manually bolded/sized text
All images have alt text added via Format Picture → Alt Text
Decorative images are marked as decorative
Tables use the Table Design tab to define header rows
Lists use built-in bulleted/numbered list styles, not manual formatting
Document language is set in language settings
Hyperlinks have descriptive text — not bare URLs or "click here"
Word's built-in Accessibility Checker has been run and issues resolved
C3 — PowerPoint Presentations
Every slide has a unique, descriptive title
All images, charts, SmartArt, and icons have alt text
Reading order is checked via Selection Pane (View → Selection Pane) — order should match logical reading sequence
Color is not the only way information is conveyed in charts and diagrams
Font sizes are sufficient for readability (minimum 18pt for body text recommended)
Color contrast meets 4.5:1 for text
Slide transitions do not include flashing effects
Embedded videos have captions
PowerPoint's built-in Accessibility Checker has been run
C4 — Excel Spreadsheets
Data is structured as Tables (Insert → Table) with defined headers
Charts have alt text that summarizes the key data trend or values
Each sheet tab has a descriptive name (not "Sheet1," "Sheet2")
Cells have sufficient color contrast — data is not conveyed by cell color alone
Hyperlinks have descriptive text
Excel's built-in Accessibility Checker has been run
Section D — Multimedia and Communications
All agency-produced videos have accurate closed captions
Auto-generated captions are reviewed and corrected before publishing
Audio-only content (podcasts, audio briefings) has full text transcripts
Video descriptions are available for visual-only information not conveyed in the audio track
Video players on agency websites are keyboard-operable
Video player controls (play, pause, volume, captions toggle) have accessible labels
Web conferencing tools procured by the agency meet Section 508 (captioning integration, screen reader compatibility)
Virtual meeting recordings are captioned before being posted to internal or public platforms
Training videos and required employee videos have captions and transcripts
CART (Communication Access Realtime Translation) or captioning services are available for live events
Section E — Hardware, Kiosks, and Physical ICT
Section 508 covers hardware and physical ICT including kiosks, ticket machines, check-in terminals, and ATMs operated by or for federal agencies.
Self-service kiosks meet Section 508 hardware criteria (Chapter 4 of the Revised Standards)
All kiosk controls are operable from a seated position (forward reach ≤ 48 inches, side reach ≤ 54 inches)
Kiosks provide both visual and auditory (or tactile) output options
Kiosks that accept audio input provide non-voice alternatives
Hardware biometric authentication has accessible non-biometric alternatives
Kiosk screens have sufficient brightness and contrast for users with low vision
Touch targets on hardware are large enough for users with motor impairments
Hardware with real-time voice communication has volume control and compatible with hearing aid T-coil
Section F — Procurement and Vendor Management
This is one of the most important — and most overlooked — compliance areas. Federal agencies are prohibited from procuring ICT that does not meet Section 508 standards unless a documented exception applies. Procurement failures downstream create compliance failures in deployed systems.
F1 — Pre-Procurement Requirements
Section 508 requirements are included in all ICT solicitations, RFPs, and contracts
Solicitations specify which VPAT edition is required (Section 508 and/or WCAG edition)
Accessibility evaluation is part of the source selection criteria — not an afterthought
Technical evaluators include someone with accessibility expertise or training
Market research includes accessibility assessment of available products
F2 — VPAT Evaluation
Vendors provide a current VPAT / Accessibility Conformance Report (ACR) for products being purchased
VPATs are dated within the last 12–18 months or correspond to the product version being purchased
VPATs are reviewed critically — "Supports" claims are spot-checked, not accepted at face value
VPATs with excessive "Not Applicable" or blank remarks columns are flagged for clarification
Spot-check testing of key product functions is conducted before contract award for high-value purchases
VPAT review results are documented in the procurement file
F3 — Post-Award and Contract Management
Contract language includes accessibility obligations and remediation timelines
Vendor is required to update VPAT with major releases
Non-compliance discovered post-award triggers a documented remediation plan with vendor
Third-party SaaS tools and cloud services have current VPATs on file
Contracts include right-to-audit accessibility provisions for critical systems
Common procurement failure: Many VPATs claim "Supports" for criteria that are actually non-conformant. Accepting a VPAT without review passes legal risk to your agency. Always request, review, and document VPAT evaluations — especially for high-use internal tools and public-facing platforms.
Section G — Testing and Verification
Documented testing is essential for compliance verification, remediation prioritization, and providing evidence of good-faith compliance efforts. Testing should cover automated detection, manual keyboard navigation, and screen reader evaluation.
G1 — Automated Testing
Automated WCAG scan completed for all public-facing web properties
Automated scan covers representative pages: homepage, navigation, forms, media, and data content
Scan results are documented with issue count, severity breakdown, and violation types
High-severity violations (critical/serious) are prioritized for immediate remediation
Scan results are exported and stored as part of compliance documentation
Ongoing automated monitoring is scheduled — not just a one-time scan
Automated scan results are used to populate VPAT conformance tables
G2 — Manual Testing
Keyboard-only walkthrough completed for all critical user journeys (apply, search, submit, log in)
No keyboard traps confirmed — user can navigate into and out of all interactive components
Focus order confirmed as logical across all key flows
Screen reader testing covers at minimum: page navigation, form completion, error handling, and dynamic content
Mobile accessibility tested with iOS VoiceOver + Safari and Android TalkBack + Chrome
Color contrast verified programmatically for all text and UI components
Testing methodology and environment (OS, browser, AT version) are documented
Manual test results are documented with issue descriptions and remediation tracking
G3 — Document Testing
PDF accessibility tested with Adobe Acrobat Accessibility Checker (full check)
PDFs tested with PAC 3 (PDF Accessibility Checker) for Matterhorn Protocol compliance
Word and PowerPoint accessibility checked with Microsoft's built-in Accessibility Checker
Representative sample of existing document library audited — not only new documents
High-priority legacy documents (forms, policy docs) scheduled for remediation
Section H — Exceptions and Documentation
Section 508 provides for three categories of exceptions where full compliance is not required. These must be formally documented — they cannot be applied informally.
Exception Type
When Applies
Documentation Required
Undue Burden
Compliance would require significant difficulty or expense
Written determination, alternative access method provided
Fundamental Alteration
Compliance would fundamentally change the nature of the product or service
Written determination with explanation of alteration
Best Meets
No commercially available product fully conforms; purchase most conformant option
Market research showing no fully conformant alternative exists; documented selection rationale
All exceptions are documented in writing with appropriate approvals
Exceptions are reviewed periodically — circumstances change and exceptions may no longer apply
When exceptions are applied, alternative access methods are provided to users with disabilities
Exception documentation is retained in the procurement or project file
Exceptions are not applied to public-facing content without compelling justification
Priority Order for Getting Started
If your agency is assessing compliance for the first time or returning from a gap period, use this prioritized sequence:
HIGH
1. Audit your top 20 most-visited public pages — Highest visibility, highest complaint risk. Start with the homepage, search, forms, and key transactional flows.
HIGH
2. Fix critical user journey barriers — Any form, application, sign-in, or data submission that cannot be completed by a screen reader user or keyboard-only user is your highest priority remediation.
HIGH
3. Review VPATs for your top 10 procured tools — Internal productivity software, case management, HR systems. Identify tools with materially inaccurate or outdated VPATs.
MED
4. Remediate mission-critical documents — Focus on forms, policy documents, and public-facing reports. Build accessible document templates to prevent future issues.
MED
5. Set up ongoing automated monitoring — A one-time audit degrades quickly. Schedule recurring scans and build accessibility checks into your CI/CD or content publication workflow.
LOW
6. Create or update your accessibility statement — Publish a current statement with a contact method for users who need accommodations.
LOW
7. Train developers and content authors — Procedural fixes without skill-building create recurring violations. Training on accessible authoring reduces long-term maintenance burden.
Start With an Automated Scan
Run Accessalyze on your public-facing federal web properties to surface WCAG 2.1 AA violations by severity and criterion. The $19 full report gives you a complete, exportable violation list you can use to populate VPAT tables and build your remediation backlog.
This checklist is for informational purposes only and does not constitute legal advice. Section 508 requirements are complex and agency-specific. Consult your agency's Section 508 coordinator or qualified legal counsel for compliance guidance specific to your situation.
Try it yourself
Enter your website URL to get a free accessibility score.
Check your website accessibility score freeScan Now →