BodyAnswers

Accessibility statement

We want every student to be able to use this platform, including those using a screen reader, a keyboard alone, magnification, or a browser configured for reduced motion or larger text.

Conformance status

BodyAnswers is partially conformant with the Web Content Accessibility Guidelines 2.2 at level AA. Partially conformant means most of the platform meets the standard and the parts that do not are named below, with what we intend to do about each one.

Statement prepared
23 August 2026
Last tested
23 August 2026
Next review
1 February 2027
Standard
WCAG 2.2 level AA

What meets the standard

  • Every interactive control is reachable and operable by keyboard, with a visible focus indicator that is never suppressed.
  • Text and interface colours meet 4.5:1, and the borders of interactive controls meet 3:1, checked against the lightest surface each appears on.
  • The interactive anatomy explorer has a keyboard and screen-reader equivalent: every region is a labelled control in a list, so nothing depends on hover, pointer position or colour.
  • Quiz marking, search counts and anatomy selection are announced through live regions that are mounted before they have anything to say.
  • State is never conveyed by colour alone — a correct answer, a highlighted structure and an exceeded dose ceiling each carry a word or an icon.
  • Overlays trap focus, restore it on close, respond to Escape, and are never dismissed by the pointer leaving them.
  • Content structure uses real headings at the correct level, real tables with scope, real radio groups and native disclosures.
  • Text reflows to 320 CSS pixels wide and remains usable at 200% zoom without horizontal page scrolling.
  • Reduced-motion preferences are respected throughout.

Known exceptions

Named individually, with the criterion each relates to. This is the part of an accessibility statement worth reading.

  • The 3D body explorer

    The WebGL model itself cannot be made meaningfully accessible to a screen reader — a rotatable mesh has no reading order. The structure list beside it is the keyboard-and-screen-reader equivalent: every structure in the model is a button in that list, with the same name and the same description, and selecting one highlights it. The 3D view is an alternative presentation, not the only route to anything it conveys.

    Relates to
    1.1.1 Non-text content
    What we will do
    Considered a conforming alternate version rather than a fix to be made. Reviewed if the model ever becomes the only route to some content.
  • Some illustrations carry short alternative text

    Where a diagram's full content is described in the adjacent prose, the alternative text names the image rather than restating the description. Where a diagram carries information that is not in the text, it has a full description. The line between the two is a judgement, and we may not always have drawn it correctly.

    Relates to
    1.1.1 Non-text content
    What we will do
    Reviewed illustration by illustration as content moves into the new content model, where a description is a required field rather than an optional one.
  • No independent audit yet

    Everything above is our own testing: automated checks on every prerendered page in the build, plus manual keyboard and screen-reader walkthroughs of the anatomy explorer, the quiz and the forms. It has not been audited by an external accessibility specialist.

    Relates to
    Process, not a criterion
    What we will do
    An independent audit is planned before the first institution-wide rollout. We will publish the findings and the remediation, including anything that fails.
  • Video and audio

    There is currently no video or audio content anywhere on the platform, so captions, transcripts and audio description do not apply. This is worth stating rather than leaving blank, because an assessor will otherwise assume it was skipped.

    Relates to
    1.2 Time-based media
    What we will do
    Any future media ships with captions and a transcript, or it does not ship.

How we test

Every build runs an automated check across every prerendered page, which fails the build on missing alternative text, unnamed controls, skipped heading levels, duplicate ids, dangling ARIA references and unlabelled form fields. That catches markup problems and nothing else: contrast, focus order and live-region behaviour are checked by hand in a browser, and the anatomy explorer and the quiz get a keyboard walkthrough after any change to either.

We are honest about the limits of that. Automated checks find a minority of real barriers, and our manual testing is done by the people who built the thing, which is the least reliable kind. An independent audit is the fix, and it is planned.

Report a barrier

If something here stops you doing what you came to do, please tell us what you were trying to do and what got in the way. We aim to respond within five working days and to say plainly whether we can fix it, when, or why not.

If you are a student and your university provides access, you can also raise it with their disability or digital accessibility service — they can escalate it to us under our contract.

Contact us