Healthcare Website Accessibility: How to Pass WCAG 2.2 AA Without Hiring a Big Agency

Why accessibility matters for GP practices and healthcare providers

Accessible websites are no longer a “nice to have” in UK healthcare – they are a legal and clinical safety requirement. GP practices and NHS providers must meet WCAG 2.2 AA as part of the UK Public Sector Bodies Accessibility Regulations and the Equality Act 2010, and NHS policy explicitly expects services to reach WCAG 2.2 AA as a minimum. This applies to your main practice website, online consultation tools you control, and any patient-facing portals you procure.

The good news: you do not need a big agency to get most of the way there. With a structured spot-check and some practical fixes, you can dramatically improve accessibility and reduce your risk, often using the tools you already have.

---

WCAG 2.2 AA and UK healthcare: what you actually need to do

The legal and NHS context

For GP practices and NHS providers, the key requirements are:

• Meet WCAG 2.2 Level AA for websites and public-facing apps.
• Publish a clear Accessibility Statement explaining how accessible your site is and how patients can report problems.
• Regularly review and improve accessibility – not a one‑off project.
• Make reasonable adjustments for disabled users under the Equality Act (for example, alternative contact routes if the website is not usable for someone).

NHS England guidance and the NHS Accessibility Checklist both point to WCAG 2.2 AA as the baseline and recommend using accessible components, testing regularly, and embedding accessibility into day‑to‑day web work.

For a typical GP website, the most critical user journeys are:

• Registering with the practice
• Booking or cancelling appointments
• Requesting prescriptions
• Contacting the practice urgently or for advice
• Accessing information in different formats (text, video, documents)

If these journeys are accessible, you reduce clinical risk and complaints and support digital inclusion.

---

A 15‑minute accessibility spot‑check for practice owners and managers

You can do a quick, high‑value accessibility check yourself without specialist tools. Block 15 minutes and work through this workflow on your homepage and one key task page (for example, “Contact us” or “Register as a patient”).

1. Headings and page structure (3 minutes)

You are checking that the page has a clear outline: one main heading and logical subheadings.

What to do

• Install a browser extension like a “headings map” or “HTML outline” viewer.
• Check:
  • There is exactly one main page heading (usually your page title).
  • Headings move in order (H1 → H2 → H3) and are not skipped randomly.
  • Headings describe sections meaningfully (for example, “Register as a new patient” rather than “Click here”).

Quick fixes you can request

• Ask your web supplier to:
  • Make page titles true headings, not just large bold text.
  • Remove decorative headings; keep them for real sections only.
  • Fix any “jumps” (e.g. H1 → H4 with no H2/H3 in between).

2. Landmarks and navigation (2 minutes)

Landmarks help screen reader users jump to main areas like navigation and main content. What to do

• With a browser extension or your dev tools, check for:
  • A main landmark (the main content).
  • A navigation landmark for the main menu.
  • A footer landmark.
  • On the keyboard, press Tab from the top of the page:
    • You should see a “Skip to main content” link appear before the navigation.

Quick fixes you can request

• Ask your supplier to:
  • Add a visible “Skip to main content” link that appears on keyboard focus.
  • Use semantic landmarks (<main>, <nav>, <header>, <footer>) on templates.

3. Images and alt text (2 minutes)

Non‑decorative images must have meaningful alternative text so screen readers can announce them. What to do

• Right‑click a key image (for example, a banner or button graphic) and inspect it.

• Check for alt="…" text.

• Consider:

  • If the image conveys information (e.g. opening hours, “Contact us” button), alt text must describe the content or action.
  • Purely decorative images should have empty alt text (alt=""), so they are skipped. Quick fixes you can request

• Ask your content editor or supplier to:

  • Add descriptive alt text for all content images (for example, “GP practice reception desk” rather than “Image1”).
  • Remove meaningless alt text like file names or “photo”.
  • Mark decorative images as alt="".

4. Forms and labels (3 minutes)

Most clinical risk on websites sits in forms: contact forms, registration forms, online triage signposts. Labels and error messages must be clear and announced properly.

What to do

On your contact or registration form:

• Check each field has a visible label next to, above, or clearly associated with it (for example, “Date of birth”, “Preferred contact method”).

• Place your cursor in each field and see if the label stays visible (placeholder-only fields are a red flag).

• Intentionally submit the form with required fields left empty:

  • Error messages should appear next to the relevant field and at the top of the form.
  • The error summary at the top should link back to each field. Quick fixes you can request

• Ask your developer to:

  • Connect labels and inputs using proper markup (for example, <label for="dob">Date of birth</label> with id="dob" on the input).
  • Add a clear error summary at the top, with links to each problem field.
  • Ensure error messages use simple language (for example, “Enter your date of birth in DD/MM/YYYY format”).

5. Focus order, keyboard traps, and visible focus (3 minutes)

People who use keyboards, switches, or voice control rely on a logical focus order and visible focus. What to do

• Put your mouse aside.
• Press Tab repeatedly to move through interactive elements:
  • Focus should move from the top, through skip link, main navigation, main content, and then footer, in a logical order.
  • You should be able to reach all links, buttons, and form fields.
  • You should see a clear visible focus indicator (for example, a thick outline around the active element).
  • Press Shift + Tab to move backwards.
  • Make sure there are no traps:
    • If you open a menu or popup, you should be able to Tab within it and then close it with Esc or a close button.

Quick fixes you can request

• Ask your supplier to:
  • Restore visible focus outlines (many themes remove them for cosmetic reasons).
  • Fix any elements that cannot be reached with the keyboard.
  • Ensure modals and menus trap focus inside while open and return focus to the trigger when closed.

6. Colour contrast and text size (2 minutes)

Good contrast is essential for older adults and people with low vision – a large part of most GP patient lists. What to do

• Use a colour contrast checker (browser extension or website).
• Test:
  • Body text against its background – aim for at least 4.5:1 contrast.
  • Large text (18pt regular or 14pt bold) – aim for at least 3:1.
  • Buttons and links, particularly pale text on coloured backgrounds.

Quick fixes you can request

• Ask your supplier to:
  • Switch to higher‑contrast colour pairs for text and buttons.
  • Avoid light grey text on white backgrounds.
  • Increase default font size if body text is very small.

---

Common accessibility fails on legacy healthcare themes

Many GP and clinic websites still run on older themes not designed with WCAG 2.2 AA in mind. These are some of the most common and fixable problems. Missing or broken skip links

• No “Skip to main content” link.
• Skip link exists but is invisible or unusable by keyboard users.

Headings used only for styling

• Large bold text that is not coded as a heading.

• Random heading levels used to adjust font size rather than structure.

• Entire paragraphs set as H3/H4 to “make them stand out”. Image‑based buttons and banners

• “Contact us”, “Register now”, or “Order prescription” provided as images with no alt text, or “Image1”.

• Banners showing opening hours or urgent contact details with no text alternative.

Form patterns that fail screen readers

• Labels implemented as placeholder text only (“Your name” disappears when you type).

• Required fields not marked clearly; instructions buried in small print.

• Error messages only in red text at the top with no links and no connection to the fields. Poor focus handling

• Focus indicators removed by CSS.

• Off‑canvas mobile menus that trap keyboard users or do not receive focus.

• Pop‑ups that appear but do not grab focus, leaving keyboard and screen reader users “behind” the visible interface.

Low‑contrast design trends

• Pale text on pastel backgrounds.

• Links distinguished only by colour, not underlining.

• Important notices in coloured boxes with white text that fails contrast requirements. PDF‑heavy content

• Key information (leaflets, registration forms, policies) only available as imported PDFs that are not tagged, not structured, and hard to use on mobile or with assistive technology.

---

Forms that announce errors correctly (without a specialist auditor)

Forms are a focus area in WCAG 2.2 because they are where patients submit clinical and personal data. Poorly implemented forms can block access and increase risk.

What an accessible healthcare form looks like

Clear labels and instructions

• Every field has a visible label that does not disappear when you type.
• Mandatory fields marked consistently, for example:
  • “Email address (required)”
  • Complex fields (for example, NHS number) include a short description of the required format.

Logical grouping

• Related fields grouped together with a clear heading, for example:
  • “About you”
  • “How we contact you”
  • Use fieldsets and legends for radio buttons and checkboxes, such as:
    • Fieldset legend: “Preferred contact method”
    • Options: “Phone”, “SMS”, “Email” Error handling that works for all users

When a patient submits a form with mistakes:

• The page scrolls to an error summary at the top with:
  • A clear heading such as “There is a problem”.
  • A bullet list of each error with links to the field.
  • Each problematic field:
    • Is highlighted with a red border or icon.
    • Has a clear error message immediately next to it (for example, “Enter your date of birth”).
  • Screen readers announce that there are errors:
    • Error summary marked so that assistive tech focuses on it.
  • Error messages use plain language:
    • “Enter a valid email address, like name@example.com” rather than “Invalid input”. Case example

A practice replaces a generic contact form plugin that only shows “Validation failed” at the top in red text. They move to a form component where:

• Each error is listed with a link.
• Field labels, error messages, and hints use the same pattern across all forms.

Result: fewer failed submissions, reduced admin time chasing incomplete forms, and better support for patients using screen readers or mobile devices.

---

Media captions, transcripts, and accessible alternatives

Video is increasingly used for explaining services, online triage, and health education. To meet WCAG 2.2 AA and NHS expectations, your media must be usable for people who are deaf, hard of hearing, blind, or who cannot process audio easily.

Practical rules for GP and clinic websites

Captions for all essential videos

• Any video that explains how to use services (for example, “How to use our online consultation tool”, “How to register”) should have:
  • Closed captions that can be turned on/off.
  • Captions that include speech and important sounds (for example, “phone ringing” if relevant).

Transcripts as a robust fallback

• Provide a full transcript beneath or next to the video for:
  • Health advice content.
  • Patient information or service explainer videos.
  • Transcripts should:
    • Include all spoken content and key visuals (for example, “Dr Smith demonstrates how to use an inhaler”).

Avoid “video‑only” instructions

• Do not rely on video as the only way to explain a process.
• Always include the same information in text on the page.

Audio‑only content

• Provide a transcript for any podcasts or audio messages, especially if they relate to appointments, service changes, or clinical advice. Embedded players

• Check that your video player:

  • Can be controlled with a keyboard.
  • Has adequate contrast and focus states.
  • Does not auto‑play with sound (or can be easily stopped).

---

A plain‑English remediation plan for your practice

You do not need to fix everything overnight. You do need a clear, realistic plan.

Step 1: Triage your top journeys

• List the 3–5 key tasks on your site:
  • Registering with the practice
  • Requesting prescriptions
  • Booking / cancelling appointments
  • Contacting the practice for urgent or non‑urgent help
  • Focus initial accessibility work on the pages and forms that deliver these journeys. Step 2: Fix the “big blockers” first

Across those pages, prioritise:

• Keyboard and focus issues

• Ensure all interactive elements (menus, links, buttons, forms) are reachable and operable by keyboard, with visible focus.

• Form labels and errors

• Make sure all critical forms have proper labels and accessible error handling as described above.

• Contrast and text

• Fix any low‑contrast text and tiny fonts on important content and calls to action. Step 3: Improve content and structure

• Rewrite headings and link text to be clear and action‑oriented:

  • Use “Register as a new patient” instead of “Click here”.
  • Break long pages into clear sections with meaningful headings.
  • Reduce reliance on PDFs; copy key content into HTML pages where possible.

Step 4: Address images and media

• Add or correct alt text on content images.

• Provide captions and transcripts for key videos or use text‑only equivalents where video is not essential. Step 5: Update your Accessibility Statement

• Publish or update an Accessibility Statement that:

  • States your aim to meet WCAG 2.2 AA.
  • Summarises known issues and when you expect to fix them.
  • Provides a contact route for reporting accessibility problems and requesting information in other formats. Step 6: Build accessibility into everyday updates

• Agree simple internal rules:

  • No new PDF without discussing an HTML alternative.
  • Every new page uses proper headings and descriptive link text.
  • Every new form is tested with a keyboard before going live.

---

How ClinicWeb.uk helps you pass WCAG 2.2 AA by default

ClinicWeb.uk is designed specifically for UK healthcare providers, so accessibility is built into the platform rather than bolted on later. This reduces your reliance on external agencies and makes compliance achievable for small practices.

Accessible components by default

• Navigation and layout
• Semantic landmarks (<header>, <nav>, <main>, <footer>) baked into templates.
• Keyboard‑operable menus with visible focus and a working “Skip to main content” link.
• Heading structures
• Templates enforce a single H1 per page and correct heading nesting for standard content blocks.
• Form patterns

Form components follow GOV.UK and NHS design patterns:

• Connected labels and inputs.
  • Error summaries with links to invalid fields.
  • Clear hint text and consistent error messaging.
• Buttons and links
• High‑contrast, accessible colour palettes tested against WCAG contrast ratios.
• Link styles that are not dependent on colour alone.

Automated checks on deploy

ClinicWeb.uk integrates automated accessibility testing into its deployment pipeline:

• Each release and content update is scanned against key WCAG 2.2 AA rules:

  • Missing form labels.
  • Empty or suspicious alt text patterns (for example, file names).
  • Low‑contrast text.
  • Missing language attributes and page titles.
  • Issues are flagged to the ClinicWeb.uk team and/or the practice site owner so they can be resolved before or shortly after changes go live. Content guidance built into the CMS

• Inline prompts in the editor:

  • Reminders to add alt text for images.
  • Warnings if headings are skipped (for example, H1 to H3).
  • Encouragement to use descriptive link text.
  • Patterns for common healthcare tasks:
    • “Contact us” pages that include accessible, consistent forms.
    • Service pages aligned with NHS and GOV.UK patterns for layout and headings.

Case example

A medium‑sized GP practice migrates from a legacy theme to ClinicWeb.uk:

• Before: menus not keyboard accessible, pale grey text, contact form with placeholder‑only labels, and video explainers with no captions.
• After migration:
  • Navigation uses accessible menus and skip links by default.
  • Forms switch to standard ClinicWeb.uk components with error summaries.
  • Automated checks highlight low‑contrast brand colours, which are adjusted once in the theme and fixed across the site.
  • Practice staff receive prompts when uploading images or embedding videos, making accessible content the default.

Result: better patient feedback on usability, reduced complaints about “website not working on my screen reader”, and a much stronger position for meeting regulatory expectations without commissioning a full external audit.

---

Key takeaways and next steps

Key takeaways

• As a GP practice or healthcare provider in the UK, you are expected to meet WCAG 2.2 AA for your websites and public‑facing apps.
• You can dramatically improve accessibility without hiring a big agency, by:
  • Running a 15‑minute spot‑check focusing on headings, landmarks, alt text, forms, focus order, keyboard access, and contrast.
  • Prioritising fixes on your most critical patient journeys, especially forms.
  • Forms, error handling, and media are high‑risk areas and deserve immediate attention.
  • Platforms like ClinicWeb.uk reduce the burden by shipping accessible components and running automated accessibility checks at deploy time.

Practical next steps for your practice

• Block out 30–60 minutes this week to:
  • Run the 15‑minute spot‑check on your homepage and one key task page. List 5–10 issues you find, grouped under:
• Navigation and structure
  • Forms and errors
  • Images and media
  • Contrast and text
• Ask your current web supplier:
  • Whether your theme or platform is configured to meet WCAG 2.2 AA.
  • What they can fix quickly (skip links, headings, focus outlines, basic form labels).
  • Update or create your Accessibility Statement, being honest about current limitations and timelines.
  • For your next redesign or supplier review, include:
    • WCAG 2.2 AA compliance as a non‑negotiable requirement.
    • Questions about automated accessibility tests and use of accessible component libraries, such as those used by ClinicWeb.uk.

By treating accessibility as an ongoing quality and safety requirement—rather than a one‑off technical exercise—you make your digital front door safer, fairer, and easier to use for every patient who relies on your services.