Product managers, designers, engineers and compliance leads at healthcare software companies - patient portals, clinical tools, credentialing and operations platforms - who need a practical starting point for WCAG.
- In healthcare, accessibility is a quality and trust issue first and a legal one second. Patients, carers and clinicians all include people with disabilities.
- The most common failures are unglamorous: low contrast, missing text alternatives, unlabeled form fields, empty links and buttons. WebAIM found detectable WCAG failures on 95.9% of the top million home pages in 2026.
- Target WCAG 2.1 Level AA as your baseline. In the US, the HHS Section 504 rule requires it for HHS-funded organisations - now by May 11, 2027 for those with 15 or more employees.
- Build accessibility into your design system's components so every screen inherits it, instead of fixing screens one by one before an audit.
- Design's job is to make compliance achievable. Legal interpretation and sign-off stay with your compliance or legal team.
Accessibility conversations in most industries start and end with legal risk. In healthcare that framing misses the bigger point: an interface that is hard to read, hard to navigate or impossible to use without a mouse fails exactly the people healthcare software exists to serve - patients managing a condition, carers acting for someone else, clinicians working fast under pressure, and administrators handling sensitive information.
This is a practical guide to the Web Content Accessibility Guidelines (WCAG) for healthcare products: what the levels mean, where products actually break, what the current regulations reference, and how to build accessibility in rather than bolt it on.
This article is general guidance, not legal advice. Confirm your specific obligations with your legal or compliance team.
Who is affected
The World Health Organization estimates that 1.3 billion people - 16% of the world's population, or 1 in 6 - experience significant disability. In the United States, the CDC reports that more than 1 in 4 adults have some type of disability. Healthcare users skew towards people living with long-term conditions, older adults and people recovering from illness or injury - groups for whom accessibility barriers are more common, not less.
It is not only permanent disability. Temporary conditions (a broken wrist, post-operative fatigue), situational limits (bright light, a noisy ward, one hand holding a phone) and ageing eyesight all benefit from the same design decisions.
Where accessibility actually breaks
Most failures come from a small set of repeat offenders, not exotic edge cases. WebAIM's 2026 analysis of the top one million home pages found an average of 56.1 detectable errors per page, with 96% of all detected errors falling into six categories:
Source: WebAIM Million, 2026 report
View as table
| Failure type | Share of home pages |
|---|---|
| Low-contrast text | 83.9% |
| Missing alternative text for images | 53.1% |
| Missing form input labels | 51% |
| Empty links | 46.3% |
| Empty buttons | 30.6% |
| Missing document language | 13.5% |
Healthcare products add their own patterns on top of these:
- Low contrast on status labels and secondary text - exactly the information people most need to read accurately, such as "Pending" versus "Verified" or dosage notes.
- Forms that break without a mouse - custom date pickers, dropdowns and file uploads that cannot be reached or operated by keyboard.
- Missing semantic structure - headings, labels and landmarks that make screen-reader navigation workable. WebAIM's screen-reader user survey found 71.6% of respondents navigate long pages by headings first.
- Colour-only meaning - red and green status dots with no text, or error fields marked only by a red border.
- Session timeouts without warning - especially harmful for users who need more time to complete forms.
- Inaccessible documents - scanned PDFs of consent forms or results that screen readers cannot read.
None of these requires exotic engineering. They require accessibility to be decided alongside everything else in design, not added as a QA pass at the end.
What A, AA and AAA mean in practice
WCAG groups success criteria into three conformance levels. They are not a menu to pick from; each level includes the one below it.
| Level | What it covers | Healthcare examples | Practical stance |
|---|---|---|---|
| A | The basics that make content usable at all | Text alternatives for images, keyboard access to every function, no keyboard traps, form labels | Non-negotiable minimum |
| AA | The practical standard most regulations reference | Text contrast of 4.5:1 (3:1 for large text), resizable text, consistent navigation, clear error identification and suggestions, visible focus | Default target for the whole product |
| AAA | Enhanced requirements, not always achievable everywhere | 7:1 text contrast, sign language for video, extended time limits | Apply selectively to the highest-stakes flows |
The contrast thresholds come straight from WCAG: 4.5:1 for normal text and 3:1 for large text at AA, and 7:1 at AAA. A sensible healthcare platform targets AA as the baseline and applies AAA selectively where stakes are highest - credential verification, consent, medication information, anything a user cannot afford to misread.
What regulations currently reference
Regulations change, and several deadlines moved in 2026, so check dates before planning. As of September 2026:
| Regulation | Who it applies to | Standard | Key dates |
|---|---|---|---|
| HHS Section 504 rule (US) | Recipients of HHS federal financial assistance, including many providers and health plans | WCAG 2.1 Level AA for web content and mobile apps | May 11, 2027 (15+ employees); May 2028 (fewer than 15), after a one-year extension |
| ADA Title II rule (US) | State and local government entities, including public hospitals | WCAG 2.1 Level AA | April 26, 2027 (50,000+ population); April 26, 2028 (smaller) |
| European Accessibility Act (EU) | Many consumer-facing products and services, such as e-commerce and banking | Harmonised standards aligned with WCAG | Applies from 28 June 2025 |
| GIGW 3.0 (India) | Indian government websites and apps | Conformity with WCAG 2.1 Level AA | In force |
Even if your company is not directly covered, many of your customers are, and they will ask about accessibility during procurement. Being able to show a recent accessibility review and a roadmap is increasingly part of selling healthcare software.
Build accessibility into the system, not the backlog
Teams that handle accessibility well do not necessarily have bigger budgets. They have accessibility baked into their design system's defaults. If the base button, input, select, table and alert components meet contrast, focus and labelling requirements, every screen built from them inherits that. If accessibility lives only in a pre-launch checklist, every new feature reopens the same argument.
A practical component checklist:
- Colour: every text and background pairing documented with its contrast ratio; status colours paired with text and icons.
- Focus: a visible, consistent focus style designed as part of the component, not the browser default.
- Forms: visible labels (not placeholder-only), helpful error messages linked to fields, no information lost on error.
- Structure: components that output correct semantics - headings, lists, tables with header cells, landmarks.
- Motion: respect reduced-motion preferences; no content that flashes.
- Touch and pointer: targets large enough to hit reliably on mobile.
For more on this, see design systems for healthcare product teams.
A practical order of work
- Baseline. Run automated checks on key templates, then a manual keyboard and screen-reader pass on your most important journeys - sign-in, a core task, forms, and anything patient-facing.
- Fix the system first. Correct the shared components and colour pairings; many page-level issues disappear.
- Fix the critical journeys. Work through the flows where failure has the biggest consequence.
- Document decisions. Record which criteria you meet, known gaps and dates. This feeds procurement answers and accessibility conformance reports.
- Keep it in the process. Add accessibility acceptance criteria to tickets, include it in design review, and re-test after major releases.
Who owns what
| Role | Owns |
|---|---|
| Design | Contrast, focus states, structure, error and status patterns, content clarity |
| Engineering | Semantic markup, keyboard behaviour, ARIA where genuinely needed, testing tools |
| Product | Prioritisation, acceptance criteria, release gates |
| Content | Plain language, alt text, accessible documents |
| Legal / compliance | Interpreting obligations, conformance statements, sign-off |
The biggest accessibility mistake I see in healthcare products is not a missing ARIA label. It is timing. Teams treat accessibility as the thing you check before launch, so every fix becomes a retrofit made under deadline pressure against a UI that was never designed for it.
I have worked on WCAG A/AA/AAA accessibility for a major banking client's platform, and the lesson carries straight into healthcare: accessibility built into the design system from day one costs less, ships faster and holds up better than a pre-launch scramble. If you are starting a healthcare product now, it is the one decision worth getting right first.
Frequently asked questions
Is WCAG 2.1 or 2.2 the right target?
WCAG 2.1 Level AA is what the current US rules reference. WCAG 2.2 adds further criteria and is backwards compatible, so designing to 2.2 AA is a sensible way to meet 2.1 AA with some margin. Confirm with your compliance team.
Can automated tools confirm we are compliant?
No. Automated tools catch a useful share of issues such as contrast and missing labels, but many criteria need manual testing with a keyboard and screen reader, plus human judgement about content.
Do internal clinical tools need to be accessible too?
Yes. Clinicians and administrators include people with disabilities, and many regulations cover services regardless of who uses them. Internal tools are also used for long, repetitive, high-stakes work where accessibility problems compound.
How long does it take to make an existing product accessible?
It depends on the size of the product and how component-based the front end is. Fixing shared components and colours first often resolves a large share of issues quickly; bespoke screens take longer.
What is an accessibility conformance report?
A document, often based on the VPAT template, that describes how a product meets each WCAG criterion. Healthcare buyers frequently request one during procurement.
Not sure where your platform stands on accessibility?
Let's run a focused WCAG review against your actual product, not a generic checklist.
Sources
Every statistic in this article links to its original publisher. Figures were checked against these sources on September 29, 2026.
- Disability and health fact sheet - World Health Organization, March 2023
- Disability Impacts All of Us - US Centers for Disease Control and Prevention
- The WebAIM Million, 2026 report - WebAIM, 2026
- Screen Reader User Survey #10 results - WebAIM, 2024
- Understanding SC 1.4.3: Contrast (Minimum) - W3C
- Compliance with Section 504 of the Rehabilitation Act - Alston & Bird health care advisory, updated May 2026
- Fact sheet: new rule on the accessibility of web content and mobile apps - US Department of Justice, ADA.gov
- European Accessibility Act - European Commission
- New features of GIGW 3.0 - Government of India
