Website accessibility for clinics and practices

Oxford has a large healthcare sector. Beyond the NHS hospitals at Headington, there are GP surgeries, private clinics, dentists, physiotherapists, opticians, counsellors and care providers in every part of the city and county. Their websites are often the first thing a patient sees, and they are used under conditions that make accessibility especially important.

Someone booking an appointment may have poor eyesight, a tremor, a cognitive condition or simply be worried and tired. They may be using an old phone on a slow connection. They may be reading in a second language. A website that works well for all of them also works better for everyone else.

What the standard asks

The Web Content Accessibility Guidelines, known as WCAG, are the international benchmark. Version 2.2 is current, and level AA is the usual target. NHS bodies and other public sector organisations in the UK are covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, and government guidance points them to WCAG 2.2 AA as the standard to meet, with an accessibility statement published on the site. Private practices are not covered by those regulations, but the Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and an inaccessible website can fall short of that.

WCAG is long and written in technical language, but most of it comes down to four principles. Content must be perceivable, operable, understandable and robust. In practice, for a typical clinic website, that means the following.

Text that people can read

• Body text large enough to read comfortably on a phone, with good line spacing.
• Strong colour contrast between text and background. Pale grey text on white, very common on clinic websites, often fails.
• Pages that still work when the user zooms to 200 per cent or increases the text size.
• No important information carried only in images of text, such as a price list uploaded as a picture.

Navigation that works without a mouse

Many people navigate with a keyboard, a switch device or a screen reader. Every menu, button and form field should be reachable and usable with the tab key, and the current position should always be visible. Drop-down menus that only open on hover, and booking widgets that trap the keyboard inside them, are common problems.

Forms that help

Booking and enquiry forms are where accessibility failures cause the most harm, because they stop someone getting care. Good forms have:

• Labels that remain visible, rather than placeholder text that disappears when you start typing.
• Clear instructions about required fields and formats, such as date of birth.
• Error messages that say what went wrong and how to fix it, next to the field concerned.
• No time limits, or a way to extend them.
• A confirmation that the message was sent, with what happens next.

If your booking runs through a third-party system, test it too. You may not control its code, but you can choose a provider that takes accessibility seriously, and offer a phone or email alternative alongside it.

Language that people understand

Healthcare websites often drift into clinical or legal language. Plain English is part of accessibility. Explain treatments in everyday words, put the most important information first, use short paragraphs and headings that describe what follows. Where a medical term is necessary, explain it the first time it appears.

Images and video

Photographs need alt text that describes what matters. A picture of your reception area might simply say "the reception desk and waiting area at the clinic", which helps someone using a screen reader to picture where they will be going. Purely decorative images should have empty alt text so they are skipped. Videos need captions, and any video that explains a procedure should ideally have a text version too.

Quick wins for most clinic websites

If you are not ready for a full audit, these changes fix a large share of the problems we see:

1. Check text contrast with a free contrast checker and darken any pale text.
2. Make sure each page has a single main heading and that headings follow in order.
3. Tab through your booking or contact form and fix anything you cannot reach or see.
4. Replace any price lists or timetables uploaded as images with real text.
5. Rewrite link text that says "click here" so it describes where the link goes.
6. Add alt text to meaningful images.
7. Publish an accessibility statement explaining what you have done and how to report a problem.

A worked example: the booking journey

Take a typical private clinic site and follow one patient through it. She has arthritis in her hands, uses a phone with the text size turned up, and wants to book a first appointment.

1. She lands on the home page from a search. The heading says "Welcome", which tells her nothing, and the treatments are hidden in a menu that opens only on hover.
2. She finds the price list, but it is a photograph of a printed leaflet. At large text sizes it does not enlarge, and she cannot read it.
3. She taps "Book now". The booking widget opens in a pop-up with tiny date buttons, close together, that are hard to hit accurately.
4. The form asks for her date of birth in a format it does not explain. When she gets it wrong, the field turns red with no message.
5. She gives up and phones, during clinic hours, if she can find the number.

None of these faults is unusual, and each has a simple fix: a descriptive heading, a visible menu, prices in real text, a booking tool with large targets, and labelled fields with clear error messages. Fixing them helps every patient, not only those with a disability.

Who is responsible for what

Part of the site	Usually controlled by	What you can do
Page templates, colours, fonts	Your web designer	Ask for WCAG 2.2 AA in the brief and for test results at handover
Page text, images, PDFs	Your own staff	Train editors on headings, alt text and plain language
Booking or payment widget	A third-party supplier	Ask for their accessibility statement; test it yourself; offer a phone or email alternative
Embedded maps and video	Third parties	Add a text address and directions; turn on captions

This split matters because many practices assume their designer has dealt with accessibility once and for all. In practice, most new problems arrive later, through new content added by staff.

Testing properly

Automated checkers are useful but catch only a portion of issues. The rest need a person to test with a keyboard, a screen reader and a phone. For clinics, it is also worth asking a few patients to try booking an appointment while you watch. The problems they hit are usually obvious once seen.

Accessibility is not a one-off job. Every new page, image and form can introduce new problems, so it helps to build checks into the way your team updates the site.

If you would like a second pair of eyes, our accessible websites service starts with an audit of your key templates and booking journey. We work with many practices in Headington, close to the hospitals, and the same principles of plain language apply to the copy on every page. For more on writing for specialist and general readers at once, see writing website copy for expert readers.