The Web Content Accessibility Guidelines (WCAG) exist because the web was designed to work for everyone. In practice, most websites fail this promise. They are built by sighted developers using mice, tested on the latest devices, and launched without anyone checking whether a screen reader user, a keyboard-only navigator, or someone with low vision can actually use them.
For healthcare websites, this failure has real consequences. A patient with a visual impairment who cannot navigate your booking form does not just leave your website. They miss an appointment. A patient with a motor disability who cannot click your undersised phone button does not just bounce. They go untreated, or they go to your competitor who made their site work.
The Four Principles of WCAG: POUR
WCAG is built on four foundational principles, known by the acronym POUR. Every success criterion in the standard maps back to one of these principles. Understanding them is essential for understanding what accessible design actually requires.
1. Perceivable
Information and user interface components must be presentable to users in ways they can perceive. This does not mean every user perceives content the same way. It means content must be available through multiple sensory channels. A sighted user sees your hero image. A screen reader user hears the alt text you wrote for it. Both receive the information, through different means.
For healthcare websites, perceivability means:
2. Operable
User interface components and navigation must be operable. Every function available via mouse must also be available via keyboard. This principle covers keyboard access, adequate time limits, seizure prevention, and navigability.
Healthcare-specific operability means your patient booking system works entirely with keyboard input. Your navigation menu does not trap keyboard focus. Your appointment calendar can be navigated without a mouse. Patients using switch devices or voice control can complete every task a mouse user can.
3. Understandable
Information and the operation of the user interface must be understandable. The content must be readable, the interface must behave predictably, and users must receive help avoiding and correcting errors.
In healthcare, understandability is critical. Medical terminology is already complex. If your website adds interface confusion on top of clinical complexity, patients abandon the booking process. WCAG 2.2 strengthened this principle with two important additions:
4. Robust
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. In practical terms, this means writing valid, semantic HTML that screen readers, voice control software, and braille displays can parse correctly.
Robust markup is not about passing an HTML validator. It is about ensuring that every interactive element on your website communicates its name, role, and state to assistive technology. A booking button must announce itself as a button. A dropdown menu must announce whether it is expanded or collapsed. A form field must announce its label and any error state.
The Three Conformance Levels: A, AA, and AAA
WCAG defines three conformance levels that represent increasing degrees of accessibility:
Healthcare-Specific Accessibility Challenges
Healthcare websites face accessibility challenges that other industries do not. The combination of complex medical content, regulatory requirements, and the critical nature of the services being accessed creates unique demands.
Patient Booking Forms
Booking forms are the conversion point of every healthcare website. If they are not accessible, you are excluding patients at the exact moment they have decided to seek care. Every form field needs a programmatically associated label. Error messages must identify the field in error and suggest corrections. Required fields must be identified before the user attempts submission, not after.
WCAG 2.2's Accessible Authentication criterion (3.3.8) is particularly relevant for patient portals and telehealth login systems. Authentication cannot require cognitive function tests like CAPTCHAs or memory-based security questions unless an alternative method is available. Permitted alternatives include copy-paste support for verification codes, object recognition tests, or personal content identification. CAPTCHAs are not banned outright — but a non-cognitive alternative must exist.
Medical Information Architecture
Healthcare websites often have extensive content about conditions, treatments, and procedures. This content must be structured with proper heading hierarchy so screen reader users can navigate by heading level. A page about knee replacement should use H2 for major sections (Procedure Overview, Recovery Timeline, Risks) and H3 for subsections, creating a navigable outline that assistive technology can present to users.
The AHPRA and WCAG Dual Burden
AHPRA-registered practitioners already operate under strict advertising guidelines that control testimonials, claims, and imagery. Adding WCAG compliance creates a dual regulatory requirement that most agencies are not equipped to handle. We manage both simultaneously. Our content is written to satisfy AHPRA guidelines while our markup ensures that content is accessible. The testimonial that is carefully worded for AHPRA compliance is also marked up with proper citation elements and contrast ratios for WCAG compliance.
NDIS Provider Obligations
NDIS providers have particular accessibility obligations given their participants have disabilities by definition. The NDIS Practice Standards require accessible communication, and an inaccessible website directly contradicts this requirement. We build NDIS provider websites with additional considerations including Easy Read formatting, AAC device compatibility, and accessible document downloads.
Telehealth Platform Accessibility
Telehealth has become a standard feature of healthcare delivery. The video consultation interface, appointment scheduling, pre-consultation forms, and post-consultation resources all need to be accessible. Video controls need keyboard operability. Captions should be available for hearing-impaired patients. The entire telehealth workflow from booking to follow-up must be navigable without a mouse.
"Accessibility is not a feature. It is a measure of how well you have built your website. A website that excludes 20 percent of the population has not been built well, regardless of how it looks."
Medical Marketing Group
Our Approach: Built In, Not Bolted On
The most common accessibility failure pattern in web development is treating it as a testing phase. The website gets designed, developed, and then someone runs an automated scan. The scan finds 200 issues. The developer fixes the easy ones, marks the rest as acceptable, and ships it. This approach fails because most accessibility issues are architectural. You cannot fix a heading hierarchy after the content is written. You cannot add keyboard navigation after the JavaScript is built. You cannot make a colour palette accessible after the brand guidelines are finalised.
We do it differently: