Building Accessible Hospital Websites: WCAG Requirements for Healthcare

Hospital websites have a specific problem that most sites do not. The people who most need to access the site correctly, patients managing chronic conditions, elderly people navigating care options, people with visual impairments or cognitive disabilities, are often the people most likely to be failed by an inaccessible site. The demographic that most needs accessible healthcare information is the demographic that inaccessible websites hurt the most.

That is not an abstract argument for good design. It is the reason accessibility in healthcare carries real regulatory and reputational weight.

Why Healthcare Faces Stricter Scrutiny

In the United States, hospital and health system websites face Title III of the Americans with Disabilities Act. Courts have consistently ruled that websites are "places of public accommodation" under Title III, and healthcare organisations have been named in ADA web accessibility lawsuits at a significant rate. Hospitals and health systems have the resources to be sued and the brand exposure to make settlement and remediation worth pursuing.

In Australia, the Disability Discrimination Act 1992 applies through a similar logic. WCAG 2.1 AA is the accepted standard, and while Australian enforcement has been less litigious than the US, the Australian Human Rights Commission has been clear that digital services are covered.

What this means practically is that healthcare organisations face legal exposure from inaccessible websites that most retail or hospitality businesses do not face at the same urgency. Not because accessibility matters more in healthcare in principle, it matters everywhere, but because the legal framework has been applied more actively to health and government entities.

The St Rose Hospital Project

St Rose Hospital came to us needing a complete website rebuild. Seventy pages, multiple service lines, physician information, patient resources, and the community health content that a community hospital produces over years of operation.

The accessibility requirement was not optional. The brief was explicit: every element on every page needed to meet WCAG 2.1 AA. That meant auditing every component we built before it went to the site, not running a single audit at the end and patching what failed.

The difference between treating accessibility as a build constraint versus an afterthought is significant. When you treat it as a constraint, the component architecture is built around accessible patterns from the start. When you treat it as an audit and patch process, you spend twice as much time fixing things that were built wrong.

Seventy pages meant seventy pages of content structure, heading hierarchies, image alt text, form labelling, link text, colour contrast, and interactive element focus states. Every one of those pages was reviewed before launch. Every interactive element was tested with keyboard navigation. Screen reader testing with both NVDA and VoiceOver covered the main patient flow paths.

What Fails Accessibility Audits Most Often

After running accessibility audits across multiple healthcare sites, the failure patterns are consistent.

ARIA labels are the most common technical failure. ARIA (Accessible Rich Internet Applications) attributes allow developers to add semantic meaning to HTML elements that do not have native semantic roles. But ARIA used incorrectly is worse than no ARIA at all. A button with aria-label="click here" tells a screen reader nothing useful. A navigation menu with incorrect ARIA roles creates a confusing experience for screen reader users that a sighted user never encounters.

The rule is: use native HTML elements with native semantics wherever possible. Use ARIA only when native HTML cannot achieve the required semantic meaning, and when you use it, test it with a screen reader before shipping.

Colour contrast failures are second. WCAG 2.1 AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Healthcare sites often use brand colours, light blues, warm greys, and muted tones, that look clean and professional on a design mockup but fail the contrast ratio when measured. The brand colour stays; the combination with the background text colour changes.

This is not a visual taste argument. It is a legibility argument. Text that fails the contrast ratio is genuinely harder to read for people with low vision or colour vision deficiencies, not just technically non-compliant.

Keyboard traps are the third common failure. A keyboard trap is any interactive element that captures keyboard focus in a way that prevents a user from navigating away without using a mouse. Modal dialogs are the classic source. A modal opens, a keyboard user navigates into it, and there is no keyboard-accessible way to close the modal and return to the page. The user is stuck.

Custom dropdown menus, date pickers, and carousel navigation controls fail keyboard accessibility regularly. Native HTML form elements have built-in keyboard accessibility. Custom-built JavaScript components often do not.

Missing skip navigation links are frequently overlooked. A user navigating a page with a keyboard or screen reader should be able to skip past the main navigation to the page content without tabbing through every menu item. A single "skip to main content" link at the top of the page, visually hidden but accessible to keyboard and screen reader users, is a basic requirement that many sites still omit.

The Testing Process

Our accessibility testing for hospital sites runs in two stages. Automated testing catches the technical failures: missing alt text, insufficient contrast ratios, missing form labels, invalid ARIA, and structural issues in the HTML. Tools like axe and Lighthouse catch approximately 30-40% of WCAG failures automatically.

Manual testing catches the rest. Keyboard-only navigation through every interactive element. Screen reader testing with NVDA on Windows and VoiceOver on Mac, because they interpret page structures differently. Testing at 200% browser zoom to confirm the layout does not break. Testing with Windows High Contrast mode enabled.

Manual testing takes more time than automated testing. For a 70-page hospital site, it is a significant investment. But it is the part that catches the issues that automated tools miss, and automated tools miss the interaction-level failures that are the ones most likely to strand an actual user.

Maintaining Accessibility After Launch

A hospital site is not static. Content is added, pages are updated, new features are built. Every addition is a potential accessibility regression.

The maintenance approach we recommended for St Rose Hospital included: all new content editors trained on accessible content practices (heading hierarchy, descriptive alt text, link text that makes sense out of context), a lightweight accessibility check built into the content review process, and a full technical audit every 12 months.

Healthcare organisations that treat accessibility as a launch deliverable rather than an ongoing standard will see their compliance erode over time as content is added by people who have not thought about accessibility since the original training.

The ongoing cost of maintaining accessibility is substantially lower than the cost of remediating a site that has been allowed to drift. And it is considerably lower than the cost of an ADA complaint or DDA investigation.

If you are planning a healthcare website build or redesign and need accessibility to be a genuine deliverable rather than a checkbox, see how we approach healthcare digital projects or get in touch.