Not for emergencies. If someone is seriously unwell or in immediate danger, call 999. For urgent medical help use NHS 111 or your local urgent-care route.
Display: Accessibility statement

Accessibility statement and design standard

Information and functions should work for the widest practical range of people.

This reconstructed prototype targets WCAG 2.2 AA and supports a broader accessible-information workflow. A formal statement for production must report tested conformance, known issues, alternatives and contact times honestly.

Prototype status: keyboard, focus, reflow, contrast, text scaling, reduced motion, semantics and image enlargement have been designed in and tested at a basic technical level. This package has not undergone a complete independent WCAG audit or representative user testing.

Included in this build

Practical accessibility features

Keyboard operation

Skip link, visible focus, navigable controls, Escape-to-close image viewer and no pointer-only core action.

Reading and reflow

Responsive layouts, scalable text, short line lengths, semantic headings, plain language and no essential text embedded only in raster images.

Visual preferences

High-contrast option, text-size controls, reduced-motion preference and colour-independent status wording.

Full-screen images

Every main-content image can be opened, zoomed, reset and closed, with alt text and a caption where available.

Forms and status

Visible labels, descriptive control names, clear notices and human-readable workflow states.

Alternatives

The provider design requires non-digital and assisted routes so lack of a suitable device does not remove care access.

Accessible information workflow

Beyond website conformance

Identify

Ask about information and communication needs.

Record

Store the need in a structured, useful way.

Flag

Make the need visible to authorised staff.

Share

Share appropriately across the care pathway.

Meet

Provide information and support in the required form.

Review

Check that the adjustment remains correct.

Production test plan

Evidence needed before claiming conformance

  • Automated tests across every public template, followed by expert manual review.
  • Keyboard-only, screen-reader, speech-input, zoom/reflow and high-contrast testing.
  • Representative iOS, Android, Windows and macOS browser/device combinations.
  • Testing of the complete app capture, camera permission, comparison, messaging and error workflows.
  • User research including people with visual, hearing, motor, cognitive, learning and communication needs.
  • Documented issues, severity, workarounds, owner and target resolution date.
  • An accessible route to report a problem and receive content in another format.

Reporting a problem

Production wording to complete before launch

The final statement should provide the accessibility contact email or telephone route, response target, escalation route, enforcement information and the statement’s preparation and review dates. Do not publish placeholder contact details.

Read the full accessibility policy