Section 508 Compliance Checklist for Healthcare & Government Websites

Section 508 of the Rehabilitation Act requires federal agencies and organizations receiving federal funding to make their electronic and information technology accessible to people with disabilities. For healthcare organizations and government contractors, Section 508 compliance isn't optional—it's a legal mandate with real consequences for non-compliance.

This checklist provides comprehensive guidance for achieving and maintaining Section 508 compliance: the technical requirements, testing procedures, documentation needs, and implementation strategies specific to healthcare and government contexts.

Understanding Section 508 Requirements

Section 508, part of the Rehabilitation Act of 1973, was significantly updated in 2017 to align with WCAG 2.0 Level AA. The current standard incorporates WCAG 2.0 success criteria as the technical baseline for web content accessibility.

Who Must Comply

Federal Agencies: All federal government agencies must ensure their websites, applications, and electronic documents are Section 508 compliant.

Federal Contractors: Organizations providing products or services to federal agencies must meet Section 508 requirements for deliverables.

Federal Funding Recipients: Healthcare organizations, educational institutions, and other entities receiving federal funding (Medicare/Medicaid, research grants, etc.) face Section 508 or related accessibility requirements.

State and Local Government: While Section 508 technically applies to federal entities, many state and local governments adopt similar standards, and all are subject to ADA Title II requirements.

Technical Standard

The Access Board's ICT Standards incorporate WCAG 2.0 Level A and AA success criteria for web content. Key requirements include:

• All WCAG 2.0 Level A success criteria
• All WCAG 2.0 Level AA success criteria
• Additional requirements for software, hardware, and documentation

Organizations should note that while Section 508 references WCAG 2.0, targeting WCAG 2.2 provides broader compliance coverage and future-proofing.

Section 508 Compliance Checklist

Perceivable Requirements

Content must be presentable in ways all users can perceive.

Text Alternatives (WCAG 1.1)

• [ ] Images have appropriate alt text — Informational images have descriptive alternatives; decorative images have empty alt attributes
• [ ] Complex images have extended descriptions — Charts, graphs, and infographics have full text explanations
• [ ] Image maps have text alternatives — Client-side image maps have alt text for each active region
• [ ] CAPTCHAs offer alternatives — Text-based CAPTCHAs have audio alternatives or other accessible options

Time-Based Media (WCAG 1.2)

• [ ] Videos have captions — All pre-recorded video content includes synchronized captions
• [ ] Audio content has transcripts — Podcasts and audio content provide text transcripts
• [ ] Videos have audio descriptions — Visual information not conveyed in dialogue is described
• [ ] Live content is captioned — Real-time presentations have live captioning when feasible

Adaptable Content (WCAG 1.3)

• [ ] Information structure is programmatic — Heading hierarchy, lists, and tables use proper HTML elements
• [ ] Reading order is logical — Content sequence makes sense when CSS is disabled
• [ ] Instructions don't rely solely on sensory characteristics — "Click the green button" includes additional identification
• [ ] Orientation isn't restricted — Content works in portrait and landscape orientations
• [ ] Input purpose is identified — Form fields use autocomplete attributes where appropriate

Distinguishable Content (WCAG 1.4)

• [ ] Color isn't the only indicator — Error states, required fields, and status don't rely on color alone
• [ ] Audio can be controlled — Auto-playing audio can be paused, stopped, or volume-adjusted
• [ ] Text contrast meets requirements — Normal text: 4.5:1 ratio; Large text: 3:1 ratio
• [ ] Text can be resized — Content remains functional at 200% text zoom
• [ ] Images of text are avoided — Real text is used instead of images containing text
• [ ] Non-text contrast meets requirements — UI components and graphics: 3:1 ratio
• [ ] Content reflows properly — No horizontal scrolling at 320px viewport width
• [ ] Text spacing can be modified — Content adapts to user-defined text spacing

Operable Requirements

Interface components must be operable by all users.

Keyboard Accessible (WCAG 2.1)

• [ ] All functionality is keyboard accessible — Every interactive element works via keyboard
• [ ] No keyboard traps exist — Users can navigate away from all components using keyboard
• [ ] Character key shortcuts can be disabled — Single-character shortcuts have disable/remap options

Enough Time (WCAG 2.2)

• [ ] Timing can be adjusted — Session timeouts provide warnings and extension options
• [ ] Moving content can be paused — Carousels, animations, and auto-updating content have controls
• [ ] No content flashes more than 3 times per second — Prevents seizure triggers

Navigable (WCAG 2.4)

• [ ] Skip navigation is provided — Link to bypass repetitive navigation blocks
• [ ] Pages have descriptive titles — Each page has unique, descriptive title element
• [ ] Focus order is logical — Tab order follows visual and logical content flow
• [ ] Link purpose is clear — Link text describes destination (not "click here")
• [ ] Multiple navigation methods exist — Site map, search, and navigation menus available
• [ ] Headings and labels are descriptive — Headings accurately describe section content
• [ ] Focus is visible — Keyboard focus indicator is clearly visible
• [ ] Section headings organize content — Long pages use headings to structure content

Input Modalities (WCAG 2.5)

• [ ] Pointer gestures have alternatives — Multi-point gestures have single-pointer alternatives
• [ ] Pointer cancellation is supported — Actions fire on up-event, not down-event
• [ ] Labels match accessible names — Visible labels match programmatic names
• [ ] Motion actuation has alternatives — Device motion features have button alternatives
• [ ] Target sizes are adequate — Interactive elements meet minimum size requirements

Understandable Requirements

Content and operation must be understandable.

Readable (WCAG 3.1)

• [ ] Page language is identified — HTML lang attribute declares page language
• [ ] Language changes are marked — Inline language changes use lang attributes
• [ ] Unusual words are defined — Technical terms, jargon, and idioms are explained
• [ ] Abbreviations are expanded — Abbreviations are defined on first use

Predictable (WCAG 3.2)

• [ ] Focus doesn't trigger changes — Receiving focus doesn't cause unexpected context changes
• [ ] Input doesn't trigger unexpected changes — Form input doesn't cause unannounced changes
• [ ] Navigation is consistent — Navigation appears in same location across pages
• [ ] Components are identified consistently — Same functionality uses same labels throughout

Input Assistance (WCAG 3.3)

• [ ] Errors are identified — Input errors are clearly described in text
• [ ] Labels and instructions are provided — Form fields have clear labels and necessary instructions
• [ ] Error suggestions are offered — Error messages suggest corrections when possible
• [ ] Error prevention for legal/financial — Submissions are reversible, verified, or confirmed
• [ ] Context-sensitive help is available — Complex forms provide help documentation

Robust Requirements

Content must be robust enough for current and future technologies.

Compatible (WCAG 4.1)

• [ ] HTML is valid — No duplicate IDs, proper nesting, complete tags (Note: WCAG 2.2 removed formal parsing requirement, but valid HTML remains best practice)
• [ ] Name, role, value are programmatic — Custom components communicate state to assistive technology
• [ ] Status messages are announced — Dynamic updates are communicated without focus change

Healthcare-Specific Requirements

Healthcare websites face additional considerations beyond standard Section 508 requirements.

Patient Portal Accessibility

Authentication:

• Login processes must be keyboard accessible
• Password requirements must be clearly communicated
• Multi-factor authentication must have accessible alternatives
• Session timeout warnings must be perceivable and actionable

Medical Information:

• Test results must be accessible (not just images)
• Medication lists must be properly structured
• Appointment information must be clearly presented
• Secure messaging must work with assistive technology

Forms and Input:

• Health history forms must be fully accessible
• Consent forms must be readable and signable accessibly
• Prescription refill requests must be keyboard operable
• Insurance information entry must have proper labels

Telehealth Accessibility

Video Platforms:

• Video controls must be keyboard accessible
• Captions must be available for video calls
• Screen sharing must be perceivable to screen reader users
• Virtual waiting rooms must be accessible

Digital Health Tools:

• Symptom checkers must work with assistive technology
• Health tracking interfaces must be keyboard navigable
• Wearable device integrations must provide accessible data presentation

Medical Documents

PDFs:

• Prescriptions must be accessible when provided electronically
• Lab reports must be properly tagged and structured
• Discharge instructions must be readable
• Insurance explanations of benefits must be accessible

HIPAA Intersection

While HIPAA doesn't directly mandate accessibility, the privacy regulation's requirements for patient access to records imply accessible delivery mechanisms. Organizations cannot claim HIPAA compliance while providing health information in formats inaccessible to patients with disabilities.

Government-Specific Requirements

Government websites and contractor deliverables have particular Section 508 considerations.

Public-Facing Content

Forms and Applications:

• Permit applications must be fully accessible
• Benefit enrollment must work with assistive technology
• Tax filing interfaces must be keyboard navigable
• Licensing forms must have proper structure

Information Services:

• Public notices must be accessible
• Meeting agendas and minutes must be properly formatted
• Regulatory documents must be readable
• Data visualizations must have text alternatives

Civic Engagement:

• Public comment systems must be accessible
• Voting information must be clearly presented
• Town hall registrations must be keyboard operable
• Elected official communications must be accessible

Internal Systems

Section 508 also applies to internal systems used by employees:

HR Systems:

• Job applications must be accessible (internal and external candidates)
• Benefits enrollment must work with assistive technology
• Time tracking must be keyboard operable
• Training systems must be accessible

Operational Tools:

• Document management must be accessible
• Collaboration platforms must work with assistive technology
• Reporting systems must provide accessible output
• Communication tools must support accessibility

Procurement Requirements

Government procurement processes must address accessibility:

Solicitations:

• RFPs must include Section 508 requirements
• Vendor responses must address accessibility compliance
• Evaluation criteria must include accessibility assessment
• Contract terms must specify accessibility obligations

Product Evaluation:

• VPATs/ACRs must be requested and evaluated
• Accessibility testing must be part of acceptance criteria
• Non-compliant products must have remediation plans
• Ongoing compliance must be monitored

Testing Procedures

Comprehensive Section 508 testing combines automated and manual methods.

Automated Testing

Automated tools can detect approximately 30-40% of accessibility issues:

Recommended Tools:

• axe DevTools (browser extension)
• WAVE (browser extension)
• Lighthouse (Chrome DevTools)
• TestParty Spotlight (continuous monitoring)

Automated Testing Scope:

• Color contrast verification
• Missing alt text detection
• Form label association
• Heading structure analysis
• ARIA attribute validation
• Link text evaluation

Manual Testing Requirements

The remaining 60-70% of issues require manual evaluation:

Keyboard Testing:

• Navigate entire site using only keyboard
• Verify all interactive elements are reachable
• Confirm focus is visible at all times
• Check for keyboard traps
• Verify logical tab order

Screen Reader Testing:

• Test with NVDA (Windows, free)
• Test with JAWS (Windows, if available)
• Test with VoiceOver (Mac/iOS)
• Verify content is announced meaningfully
• Check form input and error handling

Visual Testing:

• Verify zoom to 200% maintains functionality
• Test with Windows High Contrast Mode
• Verify content remains usable without color
• Check focus visibility across color schemes

Testing Documentation

Maintain testing records for compliance demonstration:

• Testing date and methodology
• Tools used and versions
• Issues identified
• Remediation status
• Re-testing verification

Documentation Requirements

Section 508 compliance requires specific documentation.

Accessibility Conformance Reports (ACRs)

VPATs (Voluntary Product Accessibility Templates) become ACRs when completed:

VPAT Sections:

• Product information and version
• WCAG success criteria evaluation
• Section 508 requirements evaluation
• Remarks and explanations
• Supporting documentation references

Creating Accurate ACRs:

• Base evaluations on actual testing
• Document conformance level honestly
• Explain partial conformance clearly
• Identify planned improvements
• Update ACRs when products change

Accessibility Statements

Public-facing accessibility statements should include:

• Conformance status and target standard
• Known limitations and workarounds
• Contact information for accessibility issues
• Feedback mechanism for reporting problems
• Remediation timelines for known issues

Testing Documentation

Maintain records demonstrating ongoing compliance:

• Regular automated scan results
• Manual testing reports
• User feedback and responses
• Remediation tracking
• Training records

Implementation Strategy

Phase 1: Assessment (Weeks 1-2)

Automated Scanning:

• Deploy comprehensive scanning across all web properties
• Generate baseline compliance report
• Identify scope of remediation required

Manual Review:

• Conduct keyboard navigation testing
• Perform screen reader testing of critical paths
• Document findings with priority ratings

Gap Analysis:

• Map issues to Section 508/WCAG requirements
• Prioritize by severity and user impact
• Estimate remediation effort

Phase 2: Remediation (Weeks 3-8)

Template-Level Fixes:

• Address navigation and header accessibility
• Fix form components
• Resolve color contrast issues
• Implement skip navigation

Content Remediation:

• Add missing alt text
• Fix heading structure
• Improve link text
• Address document accessibility

Interactive Component Fixes:

• Remediate custom widgets
• Fix keyboard navigation
• Implement ARIA where needed
• Address dynamic content

Phase 3: Verification (Weeks 9-10)

Re-Testing:

• Automated verification of fixes
• Manual testing of remediated areas
• Regression testing of unchanged areas

Documentation:

• Update ACRs/VPATs
• Create accessibility statement
• Document testing methodology

Phase 4: Ongoing Compliance

Continuous Monitoring:

• Deploy automated monitoring
• Configure alert thresholds
• Establish response procedures

Process Integration:

• Integrate accessibility into development
• Train content creators
• Establish review procedures

Common Compliance Failures

Healthcare and government sites commonly fail on:

Technical Issues

Missing Form Labels: Complex forms without proper label associations prevent screen reader users from understanding inputs.

Inaccessible Documents: PDFs and Word documents without proper tagging exclude assistive technology users.

Keyboard Traps: Modal dialogs and custom widgets that trap keyboard focus prevent navigation.

Missing Skip Links: Long navigation repeated on every page without skip links wastes assistive technology users' time.

Insufficient Contrast: Light gray text on white backgrounds fails contrast requirements and reduces readability.

Process Issues

No Accessibility Testing: Releasing without accessibility evaluation guarantees compliance failures.

Untrained Content Authors: Staff creating content without accessibility knowledge produce inaccessible materials.

Third-Party Integration Issues: Embedded widgets and integrations from vendors introducing accessibility barriers.

Document Neglect: Focus on web pages while ignoring PDF, Word, and other document accessibility.

Q&A: Section 508 Compliance

Q: Does Section 508 apply to our healthcare organization?

A: If you receive federal funding (Medicare, Medicaid, federal grants), participate in federal programs, or contract with federal agencies, Section 508 likely applies to your digital properties. Even without direct federal connection, ADA Title III may impose similar requirements on healthcare providers as public accommodations.

Q: What's the relationship between Section 508 and WCAG?

A: The 2017 Section 508 refresh incorporated WCAG 2.0 Level A and AA as the technical standard for web content. Meeting WCAG 2.0 AA satisfies Section 508 web requirements. Targeting WCAG 2.2 AA provides additional coverage and future-proofing.

Q: What are consequences for Section 508 non-compliance?

A: Consequences include: loss of federal contracts, civil rights complaints to federal agencies, potential Department of Justice enforcement, and private litigation. For federal contractors, non-compliance can result in contract termination and debarment from future contracts.

Q: How do we handle third-party accessibility issues?

A: Document vendor accessibility status through VPATs/ACRs during procurement. Include accessibility requirements in contracts. Implement workarounds where possible. Plan for vendor remediation or replacement. Report persistent issues to contracting officers.

Taking Action

Section 508 compliance requires systematic approach—assessment, remediation, verification, and ongoing monitoring. Organizations serving healthcare and government sectors cannot afford compliance gaps that exclude users and create legal exposure.

Start with comprehensive assessment to understand current state, prioritize remediation by impact and severity, and implement continuous monitoring to maintain compliance over time.

Schedule a TestParty demo and get a 14-day compliance implementation plan.

Related Resources

• What is WCAG 2.2: Complete Guide
• WCAG 2.2 vs 2.1 Comparison
• Accessibility Audit Guide
• Form Accessibility Checklist