Accessibility on clinic websites — what compliance and care look like.

A clinic website serves a specific population that overlaps significantly with people who need accessible web experiences. Older patients. People with low vision. People with cognitive or neurological conditions. People who are anxious, unwell, or in pain when they visit the site. Accessibility in this context isn't an edge case or a compliance checkbox — it's core to the brief.

This is distinct from how accessibility is often framed in general web development, where it's positioned as something done for a small minority. In the clinic context, the population with accessibility needs is not a small minority. It is a substantial proportion of the people the site is built to serve.

The legal context in Australia

Australia's Disability Discrimination Act (DDA) requires that websites not discriminate against people with disability. WCAG 2.1 Level AA is the relevant technical standard — it's the benchmark referenced in most Australian legal and government guidance, and it's the level used to assess compliance in discrimination complaints.

Not following WCAG 2.1 AA creates both ethical and legal exposure. The ethical dimension is the more important one — a clinic whose physical premises are required to be accessible under building codes but whose digital premises are not accessible has made a choice about who it serves. The legal dimension is real, but it's secondary.

Colour contrast

The single most commonly failed WCAG criterion. Small grey text on a white or near-white background looks sophisticated in a design mockup. In a Figma file at 100% zoom on a calibrated studio monitor, it reads fine. On a patient's phone screen in daylight, it fails older readers and people with low vision.

The minimum contrast ratio for body text under WCAG 2.1 AA is 4.5:1. For large text (18px or above, or 14px bold), it's 3:1. These ratios need to be checked for every text element — not just body copy, but subheadings, form labels, placeholder text in input fields, navigation items, and footer links. Tools like the WebAIM Contrast Checker make this quick. The design process should include a contrast pass before anything goes to development.

Keyboard navigation

Every interactive element on the site — links, buttons, form fields, modal triggers, dropdown menus — should be usable with a keyboard alone. Tab through your contact form right now. Can you complete it without a mouse? Can you close a modal? Can you navigate the main menu?

Most people never test this because most people use a mouse or a touchscreen. For patients with motor impairments, or those using assistive technology like screen readers and switch controls, keyboard accessibility is essential. The test is straightforward: press Tab to navigate forward, Shift+Tab to navigate back, Enter or Space to activate. If any element is unreachable or unactivatable by keyboard, it needs to be fixed.

Focus indicators — the visible ring or highlight that shows which element is currently active — should also be visible. Many designs suppress the default browser focus ring because it's visually inconsistent. If you suppress the default, you must provide a custom focus indicator that's clearly visible. An invisible focus state is not a design choice; it's an accessibility failure.

Readable type and plain language

Accessibility includes cognitive accessibility — the ease with which someone can read and understand the content. For clinic sites, this matters because patients are often visiting at a moment of stress or uncertainty, and the content needs to be usable under those conditions.

Body type should be a minimum of 16px; most clinic sites should be using 17 or 18px for body copy. Line length should sit between 50 and 75 characters for optimal readability — lines that are too short feel choppy, lines that are too long are harder to track back to the start. Line height should be at least 1.5 for body text.

Language should be plain. A patient who has just been referred to a specialist for a potentially serious condition doesn't need to parse dense medical jargon to find out where to go or what to bring. Write at a reading level that's accessible to the full range of patients who might visit. Technical terminology should be explained when it's necessary, not assumed.

Alt text and form labels

Images need alt text that describes their content for screen readers. Not “image” or the filename — a description of what the image shows: “Treatment room with white walls, warm lighting, and a treatment table” tells a screen reader user what the image communicates. Decorative images that add no information should have empty alt attributes (alt="") so screen readers skip them.

Form fields need visible labels, not just placeholder text. Placeholder text disappears when the user begins typing, which means someone filling out a longer form has no way to check what a field is asking for without clearing their input. Visible labels remain. This applies to every field: name, email, phone, and any longer text areas.

Accessibility isn't in tension with considered design. The constraints it imposes — clear type, sufficient contrast, logical structure, explicit labelling — are the same constraints that produce good design. A site that meets WCAG 2.1 AA is, almost always, a better site for everyone who uses it, regardless of whether they have a disability.

The W3C Web Accessibility Initiative publishes the full WCAG criteria and testing guidance. If you're planning a new site or a rebuild, we factor accessibility in from the start — see our medical clinic websites and allied health clinic websites work for context.