Skip to main content

Policy

Accessibility statement

What we have built in, how we test it, and what we still owe.

Target

This site aims to meet WCAG 2.2 Level AA. It has not been audited by an independent accessibility specialist and does not yet carry a formal conformance claim. That needs to happen before launch, and it needs a disabled user to be part of it.

What is built in

Keyboard

  • Every interactive element is reachable and operable by keyboard, in a logical order.
  • A skip link is the first focusable element on every page.
  • Focus indicators use outline rather than box-shadow, so they survive forced-colours mode.
  • The mobile menu is a real disclosure button controlling a real navigation landmark, and closes on Escape.
  • No keyboard traps.

Screen readers

  • Landmarks are present: header, navigation, main, complementary, contentinfo.
  • Every page has exactly one h1, and heading levels are not skipped.
  • Search results are in an aria-live region so changes are announced.
  • Emergency notices use role="alert" with aria-live="assertive".
  • Icons are decorative and hidden from assistive technology; every icon is paired with text.
  • Breadcrumbs are an ordered list, with separators drawn in CSS rather than announced as characters.

Colour and contrast

  • Text contrast meets AA across the palette.
  • Colour is never the only signal of urgency. Warnings carry an icon, a text label ("Emergency", "Get advice today") and a shape change.
  • Links are distinguished by more than colour alone in body copy.

Text and zoom

  • Layouts are fluid and work at 200% zoom and at 400% on a small screen.
  • No fixed pixel heights on text containers.
  • Every article has a three-step text size control, saved in local storage only.
  • Long questions and headings wrap rather than truncate.

Motion

  • All animation is disabled under prefers-reduced-motion.
  • No motion is the only carrier of meaning.

Forms and errors

  • Every input has a real, visible or programmatically associated label.
  • Error and empty states are announced, and no-result states explain what happened rather than showing an empty box.

Other

  • No animation is automatic beyond a 140 ms debounce on typing.
  • The site is static and small, so it loads on poor connections.
  • No third-party script, font CDN or tracking of any kind, which also removes a class of accessibility risk from embedded widgets.
  • Medical terminology is defined in plain language wherever it is introduced.

Known gaps

  • No independent WCAG audit has been carried out.
  • Content has not been tested with users of screen readers, magnification, switch access or speech input.
  • Several diagrams are visual explanations with text equivalents in their captions, but they are not fully described for a blind reader. Each caption states the key point, but this is a partial solution rather than a complete one.
  • Plain-language summaries at Easy Read level are not yet available.
  • Content in British Sign Language has not been produced.

Feedback

If anything here is hard to use, or you need this information in a different format, please tell us. Accessibility problems are treated as bugs, not as feedback to be considered in due course. Contact details are on the contact page.

How we check

Automated tests check the built HTML for heading structure, landmark presence, unique IDs, alt text, label associations, unlabelled buttons and empty links. Those catch structural problems only. Automated checks cannot tell you whether a page reads well with a screen reader, and we do not claim otherwise.