GP Surgery Website Requirements (2026): Accessibility, Patient Tasks, and NHS‑Aligned Content

From 2026, a GP surgery website is no longer “nice to have” – it is the front door to the practice. To be compliant and genuinely useful, your site must support online access requirements in the 2025/26 GP Contract, surface key patient tasks clearly, and meet modern accessibility and performance standards.

This guide explains what a modern, NHS‑aligned GP website must do, offers a practical audit checklist, and shows how ClinicWeb.uk is built to meet these requirements out of the box.

---

Why GP Websites Are Changing in 2025–26

NHS England is tightening expectations around digital access and transparency.

By 1 October 2025, practices in England must:

• Keep an online consultation tool open during core hours (8:00–18:30) for non‑urgent appointment requests, medication queries and admin requests.
• Provide clear guidance on their website about how to use online access safely, including urgent care signposting and the new patient charter.
• Enable relevant digital services like GP Connect and publish “You and Your General Practice” information on the website.

At the same time, patients increasingly expect fast, mobile‑friendly, app‑like experiences, and regulators expect at least WCAG 2.2 AA accessibility.

If your practice is still on a legacy WordPress build with generic themes and many plug‑ins, there is a strong chance you are already falling short on speed, accessibility, and clarity of access routes.

---

A Practical Audit Checklist for Your GP Website

Use this high‑level checklist as you read the rest of the article. At the end, you can turn it into a downloadable PDF for staff.

Above‑the‑fold patient tasks:

• Can patients see and click to: appointments, online consultation, repeat prescriptions, test results, referrals/fit notes, practice contact details without scrolling?

Accessibility (WCAG 2.2 AA):

• Does every page meet contrast, focus visibility, keyboard access, and caption/alternative text requirements?

Urgent and holiday communications:

• Is there a clear urgent care banner, and is it easy to update bank holiday hours, closures and service changes?

Core Web Vitals and mobile:

• Does your site load fast on a typical 4G mobile and meet recommended thresholds for LCP, FID/INP, and CLS?

NHS‑aligned content:

• Is your patient charter, online access information, complaints/feedback route, and “how to contact us” presented clearly and consistently?

Editing and governance:

• Can non‑technical staff safely update banners, hours, alerts and content without breaking layout or accessibility?

---

Top Patient Tasks to Surface Above the Fold

Your homepage “above the fold” (before scrolling) should behave like a task dashboard, not a brochure.

The most important tasks to surface prominently are:

• Contact the surgery / online consultation link
• Book or request an appointment
• Request repeat prescriptions
• View or request test results
• Request sick notes / letters / referrals
• Practice phone number and opening hours
• Urgent care instructions (111 and 999)

These should not be buried in menus or text paragraphs. They should be presented as large, clearly labelled action buttons or task list items, using plain language patients recognise.

Examples of good practice:

A row or grid of buttons labelled:

• “Online consultation (non‑urgent requests)”
• “Book or cancel an appointment”
• “Order repeat prescriptions”
• “View test results”
• “Get a fit note or referral”

A persistent 'Contact the surgery' button that clearly explains:

• When to use the online form
• When to phone
• When to use 111 or 999 instead

Key design tips:

• Limit the top area to 4–6 core actions to avoid overwhelming patients.
• Use descriptive labels, not jargon (e.g. “Online form to contact us” rather than the vendor product name).
• Make sure these actions are equally accessible on mobile: no tiny links, no drop‑down menus needed for core tasks.

---

Accessibility Must‑Haves (WCAG 2.2 AA)

Your practice website is a public sector service, so it should meet at least WCAG 2.2 AA and comply with the UK Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations.

Focus on these four areas as a minimum.

Colour contrast

Text and interactive elements must be easy to read against their background.

• Normal‑sized text should have at least 4.5:1 contrast.
• Large text (18pt+ or 14pt bold) should have at least 3:1 contrast.
• Links and buttons must be distinguishable without relying solely on colour.

Practical tips:

• Use an online contrast checker against your brand colours.
• Avoid placing text directly over busy images.
• Ensure visited link colours still meet contrast requirements.

Focus visibility

Keyboard users (for example, patients with mobility impairments or screen‑reader users) must be able to see where they are on the page.

• Every interactive element must have a visible focus outline.
• The focus indicator should not be removed by the theme, and should be clearly visible on all backgrounds.
• Focus order should follow the logical reading order (top‑left to bottom‑right, menu to content).

Practical tips:

• Press Tab from the top of a page and move through all interactive items.

Confirm that the focus outline:

• Is visible on links, buttons, form fields and menu items
• Does not “trap” in carousels or pop‑ups

Keyboard accessibility

All core interactions must be possible without a mouse.

• Navigation menus, appointment buttons, online forms and search should be fully usable with keyboard alone.
• No component should require hover‑only interactions to access.

If you use dialogs, accordions or menus, they must:

• Open and close with the keyboard
• Return focus appropriately

Practical tips:

• Try to complete core tasks (e.g. “Order repeat prescriptions”) using only Tab, Shift+Tab, Enter and Space.
• Check for keyboard traps – places where you cannot move focus away.

Captions, alt text and non‑text content

Patients with visual or hearing impairments must be able to access your information.

• All meaningful images must have accurate alt text.
• Decorative images should have empty alt attributes so they are skipped by screen readers.
• Videos must have captions (and ideally transcripts) for patients who are deaf or hard of hearing.
• Icons used as the only indication of meaning (e.g. a bell for alerts) should have associated text labels.

Practical tips:

• Audit a sample of pages to ensure images, icons and PDFs have text alternatives.
• Avoid linking to scanned PDFs for core information (like registration or complaints) unless they are fully tagged and accessible; web pages are usually better.

---

Urgent / Holiday Banners and Emergency Communications

Patients must know what to do in an emergency, and how service changes affect them, without digging around.

A good GP website will always:

• Display a persistent urgent care message: “For urgent medical help, use 111 online or call 111. For life‑threatening emergencies, call 999.”

Use a prominent, visually distinct banner for:

• Bank holiday closures and altered opening hours
• Short‑notice changes (e.g. phone outage, building works)
• Public health alerts (e.g. vaccine clinics, infectious disease advice)
• Make it easy for staff to schedule and update banners.

Practical configuration ideas:

A red or amber alert banner at the top of every page with:

• Short, plain‑English wording
• Clear call‑to‑action (e.g. “See holiday opening times”)
• A dedicated Service Status and Opening Times page linked from the banner.

A standard emergency paragraph that appears on:

• Homepage
• Contact page
• Online consultation / appointment request pages

Governance tip: assign a named digital lead in the practice who is responsible for updating banners before each bank holiday and when significant changes occur.

---

Core Web Vitals and Why Speed Matters for Patients

Core Web Vitals are Google’s way of measuring real‑world user experience. For GP sites, they are more than SEO metrics – they directly affect patient safety and satisfaction.

Key metrics to understand:

• Largest Contentful Paint (LCP) – how quickly the main content appears.
• Interaction to Next Paint (INP) – how quickly the site responds to taps/clicks.
• Cumulative Layout Shift (CLS) – how stable the layout is as it loads.

Why this matters for patients:

A slow or unstable site increases the chances that:

• Patients give up when trying to request appointments or repeat prescriptions.
• Urgent signposting (111 / 999) is missed because the page takes too long to load on slower connections.
• Many patients access websites on older smartphones, poor Wi‑Fi or 4G, particularly in deprived areas.
• Faster, more stable sites reduce support calls (“I couldn’t get the form to load”) and improve equity of access.

Targets to aim for:

• LCP: ≤ 2.5 seconds on a typical 4G mobile connection.
• INP: ≤ 200 ms for interactive elements.
• CLS: ≤ 0.1 so buttons and links don’t jump around as content loads.

Practical steps to improve performance:

• Remove unnecessary plug‑ins and heavy themes.
• Optimise images (automatic responsive image serving, WebP/AVIF formats).
• Use server‑side rendering and caching to deliver pages quickly.
• Avoid third‑party scripts you don’t really need.

---

How Most Legacy WordPress Builds Fail on Speed and Accessibility

Many GP practices still use WordPress sites built years ago, often adapted from generic business themes. These commonly fail in four areas:

1. Bloated themes and plug‑ins

• Large multipurpose themes load CSS and JavaScript for components you never use.
• Chains of plug‑ins (forms, sliders, cookie banners, analytics, calendars) add extra weight and can conflict.

2. Poor mobile optimisation

• Pages designed for desktop with complex layouts collapse awkwardly on small screens.
• Tiny tap targets, cramped menus and long drop‑downs make mobile tasks hard.

3. Accessibility gaps

• Custom components without proper ARIA roles or focus management.
• Colour schemes failing contrast, especially for links and buttons over images.
• Third‑party widgets (e.g. embedded forms) that ignore keyboard navigation or screen readers.

4. Fragile content editing

• Staff copy‑paste formatting from Word, producing inconsistent heading structures and inaccessible layouts.
• There is no pattern library of pre‑tested, accessible NHS‑style components, so each content update can inadvertently break accessibility or branding.

This is exactly the problem space ClinicWeb.uk is designed to fix.

---

How ClinicWeb.uk Ships These Requirements Out of the Box

ClinicWeb.uk is built specifically for GP practices and UK healthcare providers, using Next.js and a Core Web Vitals‑first architecture.

Key ways it addresses your 2026 requirements:

Performance by design

• Next.js server‑side rendering and static generation ensure pages load quickly on first visit.
• Built‑in image optimisation and code‑splitting minimise load on mobile connections.
• Core Web Vitals are monitored and used as a design constraint, not an afterthought.

Prebuilt NHS‑style components

• Alert banners for emergencies, service changes and bank holidays, matching NHS‑style patterns.
• Task lists and action panels for core patient tasks, following “front door” best practice.
• Accessible forms and buttons aligned with NHS design principles and WCAG 2.2 AA.

Accessibility engineered in

• Components are tested for colour contrast, focus visibility, keyboard access, and proper ARIA attributes.
• Global templates encourage correct heading order, link text, and alt text usage.
• “No code” editing surfaces only accessible‑by‑design layouts, reducing the risk of staff introducing barriers.

Online access and patient journey alignment

• Clear slots for:
  • Online consultation / contact the surgery links
  • NHS App and other digital front doors
  • “You and Your General Practice” and the patient charter
• Configurable call‑to‑action labels to match the access model of your PCN or practice.

Simple editing for practice staff

• Structured content model: staff fill in fields (titles, body text, hours, links) rather than designing from scratch.
• Dedicated areas for:
  • Opening times and bank holiday schedules
  • Service updates and alerts
  • Complaints, feedback and compliments
• Changes can be made quickly without developers, while the system preserves accessibility and performance.

---

Example: Modernising a GP Website from Legacy WordPress

Consider a typical legacy scenario:

A practice uses a six‑year‑old WordPress theme with:

• A slow carousel, heavy fonts and multiple analytics scripts.
• Online consultation links buried in a long “Online Services” page.
• Holiday hours posted as a scanned PDF in the “News” section.

Common issues observed:

• LCP on mobile over 4 seconds, with CLS causing buttons to jump as the slider loads.
• Poor contrast on key buttons (white text on light blue).
• Patients struggling to find repeat prescriptions without scrolling and guessing which menu to use.
• No clear urgent banner; instructions for emergencies buried in a footer link.

After migrating to ClinicWeb.uk:

• LCP reduced to under 1.5 seconds on 4G mobile.
• Task buttons now meet WCAG contrast requirements and are keyboard accessible.
• Homepage redesigned with a clear task grid: patients find repeat prescriptions in one click.
• Prominent urgent care banner visible on every page, easily updated by reception staff.

---

Conclusion and Next Steps

In 2026, your GP surgery website must be more than a digital brochure. It needs to:

• Surface core patient tasks above the fold
• Meet WCAG 2.2 AA accessibility standards
• Load fast on mobile devices
• Communicate urgent information clearly
• Align with NHS design principles and the new patient charter

If your current site falls short on any of these areas, now is the time to act. A modern, purpose‑built platform like ClinicWeb.uk can help you meet 2026 requirements while reducing the burden on practice staff.

Ready to modernise your practice website? Contact ClinicWeb.uk for a free website audit and discover how we can help your practice thrive in 2026 and beyond.