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
| 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 DescriptionWe 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 PurposeThe 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 AudioWe 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 coloursRather 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 measureOur 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 textWe 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 spacingThe 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 scrollZooming 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
| 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 stops mouse-only gestures being added. 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 we now block any change that would reintroduce one. |
| 2.2.3 No Timing | Adopt | Not met | This asks that nothing has a time limit at all. It is not met: the app has none, but the website's waitlist form can silently drop a very fast sign-up, which we are fixing. How we know: 2.2.3 No TimingThe app itself has no time limit anywhere. Our website's waitlist form has a hidden minimum submit time that can silently drop a genuine, fast signup behind a success message, and we are fixing that. |
| 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, but a demo in the app's welcome tour loops with no pause button. How we know: 2.2.4 InterruptionsWe already avoid pop-ups and anything that interrupts you unasked. The one gap is a demo animation in the app's welcome tour that loops with no pause control, which is worth a small fix rather than a whole project. |
| 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-authenticatingIf 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 and a session lasts over a day, and a test stops it getting shorter. How we know: 2.2.6 TimeoutsYour answers are saved as you go, one question at a time, and your session lasts well over a day even if you walk away, and we now test that the session length can never quietly shrink. |
| 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, and a check keeps every animation well under that speed. How we know: 2.3.2 Three FlashesNothing on our site or in our app flashes fast enough to be a seizure risk, a real concern for children more than adults, and we check every animation stays well under that speed. |
| 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 InteractionsBoth 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 LocationMost 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 printed report does this, but on screen a repeated 'Read the full definition' link does not name its term. How we know: 2.4.9 Link Purpose (Link Only)Our printed report already names every link clearly on its own. On screen, a repeated 'Read the full definition' link does not say which term it is about, and we are fixing that. |
| 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 HeadingsA 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 AppearanceOur 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 stops that changing. How we know: 2.5.6 Concurrent Input MechanismsNothing in our product works with touch only, or with a mouse only, and we block any change that would restrict how you interact with it. |
Understandable
| 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 plain-English word list opens wherever a term appears, but few real terms are in it yet. How we know: 3.1.3 Unusual WordsThis 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; we have barely started filling it with real terms rather than our own product words. |
| 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 AbbreviationsInitials like ADHD appear throughout our content with nothing yet spelling them out on first use. Our glossary already has a field ready to hold the full name; nothing has been written into it yet. |
| 3.1.5 Reading Level | Adopt | Partly met, and a test holds what's built | App wording is held at a reading age of 11, or 14 for consent and privacy. This is partly met, because finished pages and each child's report are not measured yet. How we know: 3.1.5 Reading LevelWe score wording with the Flesch-Kincaid formula, converted to a UK reading age. Inside the app, wording is held at a reading age of 11, the NHS target, and any piece that reads older fails the app's type-check, one of the checks a change must pass to be merged. 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 AI chat and the written report are told to write for a reading age of 12, and the report's overview for 9, but nothing yet measures what they actually write. PARTIAL is the honest status because the checks read the app's wording one piece at a time, not the finished pages as a parent sees them, and not the report, which is written fresh for each child. 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 PronunciationWe 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 RequestThe profiler moves you to the next question by itself, which is what makes a long questionnaire manageable. A "Keep moving on" switch on every question turns that off, 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 HelpWhere 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 HelpHelp 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.