Section 508 & WCAG 2.1 Accessibility Checker
Section 508 of the Rehabilitation Act requires federal agencies and their contractors to make electronic and information technology accessible to people with disabilities. WCAG 2.1 Level AA provides the technical standard. This tool assesses your healthcare application across the four WCAG principles — Perceivable, Operable, Understandable, and Robust — plus testing and documentation practices critical for ensuring equitable access to health information and services.
Progress: 0/22
Perceivable
0/5Operable
0/5Understandable
0/5Robust
0/4Testing & Documentation
0/3Perceivable
Assessment of whether information and UI components are presented in ways all users can perceive.
Q1
Do all non-text content elements (medical images, charts, icons, buttons) have meaningful text alternatives (alt text, aria-label) that convey the same information to screen reader users?
Q2
Do all text and images of text meet the WCAG 2.1 Level AA minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text, including within clinical dashboards and data visualizations?
Q3
Can users resize text up to 200% without loss of content or functionality, and does your layout adapt responsively without requiring horizontal scrolling at 320px viewport width?
Q4
Are data tables (lab results, medication lists, appointment schedules) properly marked up with header cells, scope attributes, and captions so screen readers can navigate them?
Q5
Do video or multimedia clinical education materials include synchronized captions and audio descriptions for all pre-recorded content?
VertiComply
Build HIPAA-compliant healthcare applications with AI-powered code generation.
Product
Features
Pricing
Tools
Company
About
Blog
Contact
Legal
Privacy
Terms
Compliance
© 2026 VertiComply. All rights reserved.
Built for HIPAA + SOC 2 Type II
About the Section 508 Compliance Checker
This checker scores digital health interfaces against Section 508 of the Rehabilitation Act and the WCAG success criteria it incorporates. The Revised 508 Standards adopted WCAG 2.0 Level AA by reference, and the Department of Justice's 2024 ADA Title II rule set WCAG 2.1 Level AA as the technical standard for state and local government entities, with compliance dates in April 2026 and April 2027 depending on population size. Questions are organised by the four WCAG principles — perceivable, operable, understandable, robust — and weighted toward the failures that actually block a user rather than those that merely fail a linter. Healthcare carries specific weight here: patient portals, telehealth interfaces, intake forms and appointment booking are precisely the surfaces where an accessibility failure denies access to care rather than to content, and they are disproportionately used by people with disabilities.
What this Section 508 assessment covers
The 22-question assessment scores 100 points across 5 weighted categories. Each category reflects a distinct Section 508 control domain.
Perceivable · 24 pts · 5 questions
Assessment of whether information and UI components are presented in ways all users can perceive.
Operable · 24 pts · 5 questions
Evaluation of keyboard accessibility, navigation, and input mechanisms.
Understandable · 22 pts · 5 questions
Assessment of content readability, predictable behavior, and input assistance.
Robust · 16 pts · 4 questions
Evaluation of markup validity and assistive technology compatibility.
Testing & Documentation · 14 pts · 3 questions
Assessment of accessibility testing processes, documentation, and remediation workflows.
Common Section 508 compliance gaps
The patterns we see most frequently in Section 508 self-assessments and remediation work. Each is the kind of finding an auditor flags first.
Automated scanning is treated as sufficient. Automated tools reliably detect roughly a third of WCAG failures. Focus order, meaningful sequence, error identification quality, and whether alt text is actually useful all require manual testing — and those are where the real barriers are.
Form errors are signalled by colour alone. Intake and registration forms commonly mark invalid fields with a red border and nothing else, failing 1.4.1 Use of Colour and 3.3.1 Error Identification. Every error needs a programmatically associated text message.
Custom components lack accessible names and states. Design-system dropdowns, modals, date pickers and tab panels built from div elements without ARIA roles and state are the most common serious failure in modern healthcare interfaces, and they are invisible to sighted testing.
Keyboard traps in modals and telehealth controls. Users who cannot escape a dialog with the keyboard are locked out entirely. This fails 2.1.2 and is a total barrier rather than a degradation.
PDFs are excluded from scope. After-visit summaries, lab results and consent forms delivered as untagged PDFs are inaccessible, and they are frequently the most important documents in the whole product.
Video consultations lack captions. 1.2.4 requires captions for live audio content in synchronous media. Telehealth platforms often ship captioning as a later phase, which excludes deaf and hard-of-hearing patients from the core service.
Focus indicators removed for aesthetics. A CSS reset that strips the default outline without providing a visible replacement fails 2.4.7 across the entire application from a single line of code.
What to do with your Section 508 results
Your score is a starting point — these are the steps that convert the assessment into actionable remediation.
Test with a keyboard only, end to end, through your highest-value journey — registration, booking, joining a consultation. This takes an hour and finds more real barriers than any scanner.
Test with an actual screen reader on the same journey. VoiceOver or NVDA. Expect the experience to differ substantially from what the accessibility tree suggests.
Fix custom components at the design-system level rather than page by page. One correct dialog primitive resolves the same failure everywhere it is used.
Bring PDFs and other documents into scope. Tag them properly or replace them with accessible HTML, which is usually the better answer for clinical documents anyway.
Publish an accessibility statement with a real feedback route, and act on what arrives. It is expected practice, and user reports are the highest-signal source of the failures testing missed.
Section 508 compliance FAQ
Does Section 508 apply to private healthcare companies?
Section 508 directly binds federal agencies and, in practice, their vendors through procurement requirements. Private healthcare organisations are more often reached through ADA Titles II and III, Section 504, and Section 1557 of the Affordable Care Act, which applies to recipients of federal financial assistance — a category that includes most providers accepting Medicare or Medicaid. The practical technical standard is WCAG Level AA in every case.
Which WCAG version and level should a healthcare app target?
WCAG 2.1 Level AA is the working answer. It is the standard set by the DOJ's 2024 ADA Title II rule, it is a superset of the WCAG 2.0 AA that the Revised 508 Standards incorporate, and it adds criteria that matter on mobile — orientation, reflow, and target size among them. WCAG 2.2 adds further criteria and is a reasonable forward target.
Can an accessibility overlay make our app compliant?
No. Overlay widgets do not remediate underlying markup, and they have been named in a substantial volume of US accessibility litigation. Some interfere with the assistive technology users already rely on. Accessibility failures need fixing in the application itself.
How much of WCAG can automated testing catch?
Roughly 30 to 40 percent of failures, and mostly the mechanical ones — missing alt attributes, contrast ratios, absent form labels. Whether alt text is meaningful, whether focus order follows a logical sequence, whether an error message explains how to fix the problem, and whether a custom widget behaves as its role implies all require human judgement.
Are telehealth video sessions covered?
Yes. Live captioning falls under 1.2.4, and the surrounding interface — joining, muting, consent, chat — must be keyboard operable and screen-reader accessible. Because a telehealth session is the delivery of care rather than the delivery of content, an accessibility failure here denies access to the service itself.
Build it instead of buying it
Generate a Section 508-compliant healthcare app with the controls built in
VertiComply generates production-ready healthcare applications with Section 508 controls scaffolded from the first commit — no add-on tier, no platform lock-in, code exported to your GitHub.
Start free