This browser is too old for this site. Some pages may not work. Update your phone, or try a different device.

Accessibility

Beyond AA

Beyond AA: what we borrow from AAA

AAA is the strictest level of WCAG 2.2. WCAG itself advises against requiring all of it, because some content cannot meet every AAA criterion. So we do not claim AAA. Instead we look at each AAA criterion on its own and decide whether to adopt it, aim for it or decline it, and we record why.

Our list has 36 rows. It covers the AAA criteria of WCAG 2.2, with 1.4.8 Visual Presentation split into its five parts, plus 3.2.6 Consistent Help, a level A criterion that 3.3.5 Help depends on.

None of this is a claim that we meet AAA. A row reads as met only where a test already protects it: 4 of the 36. Another 12 have a test that protects part of the work, or protects the fact that we publish nothing the criterion applies to. No other row is shown as met, even if it is true today, because nothing would stop it breaking.

We adopt this: 26 of 36
We have decided it is worth doing, whatever state it is in today.
Aim for: 4 of 36
We do the cheap, useful part now, and will not claim the rest until we can measure it.
We decline this: 6 of 36
We have decided not to do it, and each row says why.

Where we are today: 4 met and protected by a test, 19 partly met, 7 not met yet, 1 not assessed, and 5 that do not apply to anything we publish. Adopting a criterion does not mean we meet it. It means we are working towards it.

Perceivable

WCAG 2.2 level AAA Perceivable success criteria, with what Assembly decided and why.
Criterion Our decision Where it stands Why
1.2.6 Sign Language (Prerecorded) Decline Not applicable

This asks for a sign language interpreter in every video. We publish no video, so it does not apply, and we have chosen not to adopt it.

How we know: 1.2.6 Sign Language (Prerecorded)

We publish no video, and promising a British Sign Language interpreter for every future video is a commitment that never gets cheap. We caption everything instead, and we would revisit this if an NHS contract asked for it by name.

1.2.7 Extended Audio Description Decline Not applicable

Extended audio description pauses a video to describe what is on screen. We publish no video, so it does not apply, and we decline it: any future narration would already say what is shown.

How we know: 1.2.7 Extended Audio Description

We publish no video. If we ever do, our production rule is to write the narration so it already says what the screen shows, which is the cheaper and more reliable answer to the same problem.

1.2.8 Media Alternative (Prerecorded) Adopt Not applicable

This asks for a full written version of any video. We have no video today, so it does not apply, but any future video will come with a written transcript.

How we know: 1.2.8 Media Alternative (Prerecorded)

We have no video today, but we are adopting this ahead of time: any future video gets a written transcript from day one, because the script already exists and a transcript costs almost nothing on top of it.

1.2.9 Audio-only (Live) Decline Not applicable

This asks for a text version of live audio. Nothing on our site streams live audio, so it does not apply, and we have chosen not to adopt it.

How we know: 1.2.9 Audio-only (Live)

Nothing on our site streams live audio, and nothing is planned. A page nobody maintains reads as coverage while holding nothing, so we are not adding one.

1.3.6 Identify Purpose Decline Not met

This asks for page parts to be labelled in a way software can read and adapt for you. We do not meet it and have chosen not to, because no browser or assistive tool reads those labels today.

How we know: 1.3.6 Identify Purpose

The technique this criterion asks for depends on a machine-readable format that no browser or assistive technology actually reads today, so claiming it would not help anyone using our product.

1.4.6 Contrast (Enhanced) Aim for Not met

This asks for stronger contrast between text and its background. It is not met: we aim to raise body text where a simple colour change does it, but not on every coloured panel.

How we know: 1.4.6 Contrast (Enhanced)

We are raising our body text to the stronger contrast bar where it is a simple colour step, but not across every coloured panel: that would undo contrast decisions we already tuned carefully, including a signed-off welcome colour, for a gain that is mostly theoretical there.

1.4.7 Low or No Background Audio Adopt Not applicable

This is about keeping background sound quiet behind speech. We have no audio today, so it does not apply, but any future video will have no music behind the voice.

How we know: 1.4.7 Low or No Background Audio

We have no audio today, and we are adopting the rule now: no music behind the voice in any future video, because a music bed makes speech harder to follow for people with auditory processing differences, who are common among our users.

1.4.8(a) Visual Presentation: user-selectable colours Decline Not met

This asks for a way to choose your own text and background colours. We do not meet it and have chosen not to build one, and aim instead to respect the colour settings on your device.

How we know: 1.4.8(a) Visual Presentation: user-selectable colours

Rather than build our own colour picker, we would rather make the product properly respect the contrast and colour settings you have already set on your own device.

1.4.8(b) Visual Presentation: 80-character measure Adopt Partly met

Short lines of text are easier to follow. This is partly met: the website and printed report keep lines short, but some app cards and the report screen run too wide.

How we know: 1.4.8(b) Visual Presentation: 80-character measure

Our website and our printed report already keep lines of text short and easy to follow. The gap is inside the app, where some cards and the report screen still run wider than we would like.

1.4.8(c) Visual Presentation: no justified text Adopt Partly met, and a test holds what's built

Justified text, stretched to line up at both edges, leaves uneven gaps between words that are hard to read with dyslexia. This is partly met: we avoid it wherever we can, and a test holds what is built.

How we know: 1.4.8(c) Visual Presentation: no justified text

We keep text ragged rather than justified everywhere we can, on screen and in the printed report, because justified text creates uneven gaps between words that are harder for dyslexic readers to follow, and dyslexic parents are exactly who this criterion is for.

1.4.8(d) Visual Presentation: line and paragraph spacing Adopt Partly met

Enough space between lines and paragraphs makes text easier to read. This is partly met: we widened the spacing in August 2026, but only the website is measured automatically.

How we know: 1.4.8(d) Visual Presentation: line and paragraph spacing

The space between paragraphs used to be too tight across our website, our printed report and the app. We widened it on all three in August 2026, setting it against each surface's own line height rather than one number everywhere. It is partly met rather than met because only the website version is measured automatically, and that check is one we watch rather than one that can block a change.

1.4.8(e) Visual Presentation: 200% without horizontal scroll Adopt Partly met

When you zoom to 200%, pages should not make you scroll sideways. This is partly met: no page does today, but the automatic check only warns us and cannot stop a change that breaks it.

How we know: 1.4.8(e) Visual Presentation: 200% without horizontal scroll

Zooming in to the 200 percent equivalent causes no page to scroll sideways. In August 2026 we made that an automatic check rather than a one-off measurement, and included the report page and a question page for the first time. It stays partly met because the check is one we watch rather than one that can block a change.

1.4.9 Images of Text (No Exception) Adopt Partly met, and a test holds what's built

This asks that words are never shown as a picture. It is partly met: two tables that were pictures are now real text, but our check only reads image names.

How we know: 1.4.9 Images of Text (No Exception)

Two articles used to show a whole information table as a picture. Both are now real text you can select, resize and have read aloud, and a test keeps them that way. It stays partly met because that test reads image file names and cannot see words inside a picture with an ordinary name.

Operable

WCAG 2.2 level AAA Operable success criteria, with what Assembly decided and why.
Criterion Our decision Where it stands Why
2.1.3 Keyboard (No Exception) Adopt Partly met, and a test holds what's built

This asks that everything works by keyboard, with no exceptions. It is partly met: every control works with a keyboard alone, and a check blocks the drag and slider patterns that would need a mouse.

How we know: 2.1.3 Keyboard (No Exception)

Every control in our product already works from a keyboard alone, with nothing that needs a drag or a mouse-only gesture, so meeting this in full costs us nothing extra, and a check blocks the drag and slider patterns that would bring one back.

2.2.3 No Timing Adopt Not met

This asks that nothing has a time limit at all. It is not met: a session a school runs for a parent on the school's device ends after 90 minutes.

How we know: 2.2.3 No Timing

Our website's forms used to drop a message sent in under 2 seconds behind a success message. That hidden limit was removed in October 2026. In the app, a session a school runs for a parent still ends after 90 minutes.

2.2.4 Interruptions Aim for Partly met

This asks that nothing interrupts you unless you ask. It is partly met: there are no pop-ups, and the welcome tour's slider demo now plays once, but the picture on the tour's first step still moves on a loop.

How we know: 2.2.4 Interruptions

We already avoid pop-ups and anything that interrupts you unasked. The slider demo in the app's welcome tour used to loop with no pause control; since October 2026 it plays once and stops. The picture on the tour's first step still moves on a loop with no pause control, and the slider demo is the only part a test checks, so this stays partly met.

2.2.5 Re-authenticating Adopt Partly met

If you have to sign in again, you should not lose your work. It is partly met: your saved answers are kept, but we have not checked what happens to something half typed.

How we know: 2.2.5 Re-authenticating

If your sign-in link expires, we already send you back to exactly where you were with your saved answers untouched. What we have not confirmed is what happens to anything you were mid-way through typing at that exact moment.

2.2.6 Timeouts Adopt Partly met, and a test holds what's built

Leaving the product idle should not lose your work without warning. It is partly met: answers are saved as you go, a session lasts 7 days, and a test fails below 20 hours.

How we know: 2.2.6 Timeouts

Your answers are saved as you go, one question at a time, and your session lasts 7 days even if you walk away. A test fails if it ever drops below 20 hours.

2.3.2 Three Flashes Adopt Met, and a test holds it

This asks that nothing flashes fast enough to cause a seizure. It is met: nothing on our site or in our app flashes that fast. A check fails fast repeating animations in most of our code.

How we know: 2.3.2 Three Flashes

Nothing on our site or in our app flashes fast enough to be a seizure risk, a real concern for children more than adults. A check fails any fast repeating CSS or SVG animation in most of our code, but it cannot yet see animation driven by script.

2.3.3 Animation from Interactions Adopt Partly met

Animation you set off by using the product should stop if you ask your device to reduce motion. It is partly met: both products follow that setting, but no test yet catches a new animation that ignores it.

How we know: 2.3.3 Animation from Interactions

Both the app and this website follow your device's reduce-motion setting through one shared rule, and the app's own Reduce motion setting does the same. The two animations driven by script, which that rule cannot reach, the report's tab underline and the chat's scroll, now check both settings themselves. It stays partly met because no test yet fails when a new animation ignores the setting.

2.4.8 Location Adopt Partly met

You should always be able to tell where you are. It is partly met: a trail of links and a progress bar help, but the app's menu does not yet show your page.

How we know: 2.4.8 Location

Most of our product already tells you where you are, with breadcrumbs and a progress bar. The app's own menu does not yet mark your current page, and children's profile tabs need a clearer label than colour alone.

2.4.9 Link Purpose (Link Only) Adopt Partly met

Each link should make sense from its own words alone. It is partly met: the report's definition links name their term for screen readers, but we have not rechecked every link in the app.

How we know: 2.4.9 Link Purpose (Link Only)

Our printed report names every link clearly on its own. On screen, each 'Read the full definition' link also carries its term's name for screen readers. We have not rechecked the rest of the app's links against this stricter test.

2.4.10 Section Headings Adopt Partly met

Sections should have headings so you can find your way around. It is partly met: a few report tabs hide their section heading, and we are putting those headings back.

How we know: 2.4.10 Section Headings

A parent or a school reading the report by its headings hits a few tabs where we deliberately hid the section heading. We are putting those headings back.

2.4.12 Focus Not Obscured (Enhanced) Aim for Not met

The item you move to by keyboard should never be even partly covered. It is not met: we are fixing headers and footers that sometimes cover it, but nothing yet measures this fully.

How we know: 2.4.12 Focus Not Obscured (Enhanced)

We are fixing the underlying problem, a fixed header or footer sometimes covering the very thing you have just tabbed to, because it is worth doing on its own. We will only claim the stricter, enhanced version once something actually measures that nothing is ever covered.

2.4.13 Focus Appearance Adopt Partly met, and a test holds what's built

The keyboard focus outline should be thick and clear enough to see. It is partly met: the thin outlines are gone and a check stops them returning, but we measure the outline on only some screens.

How we know: 2.4.13 Focus Appearance

Our default keyboard focus ring is the right size and colour in both apps, we removed the handful of thinner overrides that fell short of it, and a check blocks that thin pattern from coming back. It stays partly met because the ring as actually drawn is measured on only some screens, by a check that reports rather than blocks.

2.5.5 Target Size (Enhanced) Adopt Not met

This asks for larger buttons and links that are easy to tap. It is not met: the tap targets in our 75-question questionnaire are smaller than we would like.

How we know: 2.5.5 Target Size (Enhanced)

The tap targets on our 75-question profiler are smaller than we would like today. Getting this right matters more to us than to most products, because motor skills are one of the very things our profiler assesses.

2.5.6 Concurrent Input Mechanisms Adopt Met, and a test holds it

You should be free to use touch or a mouse, whichever suits you. It is met: nothing works with touch only or a mouse only, and a check blocks the common ways to change that.

How we know: 2.5.6 Concurrent Input Mechanisms

Nothing in our product works with touch only, or with a mouse only. A check blocks the common ways to add such a restriction, but not every way.

Understandable

WCAG 2.2 level AAA Understandable success criteria, with what Assembly decided and why.
Criterion Our decision Where it stands Why
3.1.3 Unusual Words Adopt Partly met, and a test holds what's built

Unusual words, such as clinical or school terms, should be explained. It is partly met: a word list opens wherever a term appears, but a person has not yet checked most of its terms.

How we know: 3.1.3 Unusual Words

This is the criterion our whole product exists to satisfy: a plain-English glossary for clinical and school language, tapped open wherever it appears. The mechanism is built and protected from regressing. It holds over 250 terms, most of them drafted from cited sources and not yet checked by a person.

3.1.4 Abbreviations Adopt Not met

Short forms such as ADHD should be spelled out. It is not met: nothing yet spells them out the first time they appear.

How we know: 3.1.4 Abbreviations

Initials like ADHD appear throughout our content. Our glossary shows the full name for many of them, but nothing yet spells them out the first time they appear in the text.

3.1.5 Reading Level Adopt Partly met, and a test holds what's built

App messages are held at a reading age of 11, or 14 for consent and privacy. This is partly met: the report's fixed wording and short messages are not held to it.

How we know: 3.1.5 Reading Level

We score wording with the Flesch-Kincaid formula, converted to a UK reading age. Inside the app, any message of 15 words or more that reads older than 11, the NHS target, fails the app's type-check, one of the checks a change must pass to be merged. Shorter messages are too short to score, and the questionnaire statements are not measured. The NHS asks for 9 to 11 and accepts 11 to 14 where information is hard to make simpler, so consent and privacy wording is held at 14 the same way, because shortening it can drop part of what we are promising. A short named list of exceptions, all of it consent and privacy wording, is each held at its own ceiling so it cannot quietly get harder. Long-form articles on the public site are written for parents researching a topic, so their limit is 19, held the same way. The report's fixed wording is measured too, but nothing stops it getting harder, and it reads at about 16. The AI chat and the written report are told to write for a reading age of 12, and the report's overview for 9. We measure and store the reading age of each report the AI writes, but a hard one is not stopped, and if the measuring fails the report still goes out with no score. Chat replies are measured only in test runs. Each area of the app is also scored as a whole, and reported rather than held. That is why this is partly met. We are not promising a separate easy-read version of the whole site, which we could not keep maintained.

3.1.6 Pronunciation Decline Not assessed

This asks for help with words whose meaning depends on how they are said. We have chosen not to adopt it and have not assessed it, because we know of no such word but have not checked everything.

How we know: 3.1.6 Pronunciation

We have not found any word in our content whose pronunciation is genuinely ambiguous, so there is nothing yet for this criterion to apply to. We have not done the content review that would settle it either way.

3.2.5 Change on Request Aim for Met, and a test holds it

Big changes should happen only when you ask. It is met: a 'Keep moving on' switch stops the questionnaire moving on by itself, and a test checks the switch keeps working.

How we know: 3.2.5 Change on Request

The profiler moves you to the next question by itself, which is what makes a long questionnaire manageable. A "Keep moving on" switch turns that off. It appears when you go back to a question, and once you turn it off it stays off. With a keyboard, nothing moves on until you press Enter. A test fails if the switch stops working or stops remembering your choice.

3.2.6 Consistent Help Adopt Partly met

Help should be in the same place on every screen. It is partly met: where help exists it stays put, but a few screens, including the safety questions, have no help at all.

How we know: 3.2.6 Consistent Help

Where help exists, it sits in the same place every time. A handful of screens, including the safety questions, offer no help at all today, and that is the gap we are closing.

3.3.5 Help Adopt Partly met

Help should be there when you need it. It is partly met: there is good guidance where we have built it, but it is missing on the checklist and safety questions.

How we know: 3.3.5 Help

Help is genuinely good where we have built it: real guidance first, before anything automated. It is missing on exactly the most frightening steps, the screener and the safety questions, which is where it matters most.

3.3.6 Error Prevention (All) Adopt Partly met

You should be able to undo mistakes. It is partly met: you can change answers for a while and delete a child record yourself, but a removed comment cannot be brought back.

How we know: 3.3.6 Error Prevention (All)

You can go back and change an answer during a grace window before it is final, and you can delete a child record yourself, including one you added twice by mistake. Two slips still lose what you typed: removing a comment has no undo, and leaving a page before you save loses a draft.

3.3.9 Accessible Authentication (Enhanced) Adopt Met, and a test holds it

Signing in should never ask you to remember or solve anything. It is met: you use an emailed link or code with no password or puzzle, and a test keeps it that way.

How we know: 3.3.9 Accessible Authentication (Enhanced)

You sign in with a link we email you, or, if you would rather type something, a short code we email instead. Neither asks you to remember or work anything out: the code is one field you can paste into or let your device fill, and there is still no password and no CAPTCHA anywhere in the product. We test that none of those can quietly sneak back in.

The Reading age page shows how each area of the app scores against 3.1.5 Reading Level.