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

Accessibility

How we test

What we do, and what we do not

What we do

  • An automated colour contrast test over every colour pair in our design system, in light and dark mode. It is one of the three checks that has to pass before any change can go in.
  • An automated accessibility checker (axe) tests 34 of the public website's 43 pages and 21 of the app's 72 routes. A route is a web address in the app, and many show nothing on screen. Each is tested in light and dark mode and at 320 and 640 pixels wide, and the app also with forced colours.
  • Every page and route the checker leaves out is listed with a reason. Most have nothing to test, such as downloads or system checks. A few are screens our tools cannot reach, and a few are real gaps.
  • The website's tests start by themselves when a change touches the website or the parts it is built from. The app's run on our main code once a change is in, or when we ask. A smaller set also runs earlier, on changes to the app's colours or display settings.
  • Every night since 28 September 2026 we open each app screen our map of the service can reach with made-up test data, about 60 of them, and run the checker on each in light mode, dark mode and at 320 pixels wide. This sees a screen in the state a person meets it, such as a questionnaire half done, where the test above checks each web address once. Any finding turns that night's run red unless it is on a named list with a reason and a planned fix. Some steps are not screens at all, such as a download, and a few screens still need a person to click through to reach them, so this check does not see them yet.
  • Keyboard tests that press real keys and measure the outline your browser draws. We also test the website for pages wider than the screen, and the app for keyboard focus, 200% zoom, text spacing and screen rotation.
  • A full sweep, run when we ask, that turns on all 105 of the checker's rules across 284 combinations of page, colour mode and screen width. It last ran on 8 August 2026.

What we do not do

  • We have not had an external accessibility audit. Nobody outside Assembly has assessed this product.
  • No person has yet used the app with a screen reader. An AI agent has run two screen readers over parts of it, and no person has listened to any of it. Apple's VoiceOver did 5 of the questionnaire's 108 screens on 16 August 2026 and the questionnaire's help chat on 27 August 2026. NVDA, a free Windows screen reader, did 19 screens on 27 September 2026: one of each kind of questionnaire screen, both report screens and both chats. JAWS has not been tried at all, and nor has any screen reader on a phone.
  • Our page tests cannot stop a change going in. Only the colour contrast test above can. On the website a change goes live as soon as it is in, so a failing page test there only warns us. On the app, the page tests run again once a change is in, and a failure stops that change reaching the live app unless we override it and record why. And before a change goes in, each product's page tests start only if the change touches that product. The nightly check of every screen cannot stop anything: it runs on changes already in, and it only tells us.
  • The automated checker has no rule for pages that scroll sideways. Our own measurement covers that on the website, but whether a narrow page is easy to use still has to be judged by looking at it.
  • Automated tools cover roughly a third of the standard. They found 10 real failures across 284 page states. The most serious problem in this list was found by a person reading code, and no tool can see it.
  • Nothing we have tested has run on a physical phone or tablet, only desktop browsers set to the size of a phone. That misses problems only a real device shows, such as the on-screen keyboard covering what you type, or a button big enough for a mouse but not a thumb.

Hands-on checks, by date

The tests above run by themselves. Each entry below is a time someone went through the product and judged it. Each says who did it, what they used, and what it did not cover. A person last went through the product on .

  1. NVDA's own speech record, listening to the chat

    Done by
    An AI agent, not a person
    On
    Assembly app , at 1280x720 pixels
    Using
    A real NVDA screen reader and a real Chrome browser on a Windows computer in the cloud, started by an AI agent, which read what NVDA spoke from NVDA's own record of its speech, including during a ten-second wait with no key pressed. Run before and after a fix.

    The same 19 screens as TS-7, with the two chat screens listened to while nothing was pressed, so the test itself could not drown out a quiet notice. Before the fix, neither the 'Assembly has replied.' notice nor the 'Thinking' notice was spoken on either chat screen, because of how both were added to the page. After the fix, NVDA spoke both on both chat screens. The two comment screens that seemed silent in TS-7 turned out to be a fault in the test, not the app, and all 19 screens now read out.

    What this did not cover: No person listened to any of it. NVDA only, not VoiceOver or JAWS. A desktop screen reader on a desktop-sized screen, so it tells us nothing about a phone. Whether NVDA reads the finished reply itself is not settled by this record.

  2. First NVDA walk of the app

    Done by
    An AI agent, not a person
    On
    Assembly app , at 1280x720 pixels
    Using
    A real NVDA screen reader and a real Chrome browser on a Windows computer in the cloud, started by an AI agent, which read the results from the record the run wrote. Run twice, the second time after two fixes to the test.

    19 screens: one of each kind of questionnaire screen, both report screens and both chat screens. 16 of the 19 screens were read out in full on both runs, and the two runs matched on all but one screen. Both comment screens were silent on both runs, for a reason we do not yet know. The safety notice's 'e.g.' is read out as 'e dot g'. The 'Assembly has replied.' notice appeared on both chat screens but is not in what NVDA was recorded saying. As with VoiceOver in August, that is not yet a result, because the way the test listens can drown out a quiet notice.

    What this did not cover: No person listened to any of it. A desktop screen reader on a desktop-sized screen, so it tells us nothing about VoiceOver on an iPhone or TalkBack on Android, which is how most parents use the app. 19 of the questionnaire's 108 screens. Not JAWS.

  3. First screen-reader walk of the chat

    Done by
    An AI agent, not a person
    On
    Assembly app
    Using
    A real VoiceOver screen reader and a real Chrome browser on a Mac in the cloud, started by an AI agent, which read the results from the record the run wrote.

    The two chat screens: the help panel inside the questionnaire, and the chat about one child. VoiceOver only, listening for the 'Assembly has replied.' notice. On the help panel, the notice appeared on screen while VoiceOver was running, but it is not in what VoiceOver was recorded saying. That is not yet a result: the way the test listens moves VoiceOver's place on the page, which can itself drown out a quiet notice. The chat about one child was never reached, because of a fault in the test, not in the app.

    What this did not cover: No person listened to any of it. VoiceOver only, not NVDA or JAWS. One of the two chat screens, and a listening method that may hide the very notice it listens for, so this run neither confirms nor rules out the problem.

  4. SENCO meeting sheet and org roster

    Done by
    Stef Lewandowski
    On
    Assembly app
    Using
    A desktop browser, used by hand, signed in as a test school staff account for a made-up school.

    The SENCO meeting sheet for one child's report, and the school's roster and list of parent views. Four problems with how things look, such as coloured dots with no key and sections that ran together when scrolling. A fifth point was looked into and not filed, because the code records it as an earlier deliberate choice.

    What this did not cover: One child's report and one roster, as one type of user. The screen size was not recorded, so this says nothing about narrow screens. No assistive technology, no keyboard-only check, no dark mode.

  5. Mobile pass over the whole child-creation flow

    Done by
    Stef Lewandowski
    On
    Assembly app , at 375x812 pixels
    Using
    A desktop browser set to the size of a phone, NOT a handset, used by hand. Each finding was saved with its exact address and screen size.

    Sign-up and the whole questionnaire, for every type of user, from the welcome and safety screens to the report preview. Thirty-one findings, from the first time a person used the rebuilt app at phone size. They range from layout faults seen only on narrow screens, such as a footer covering the Continue button, to wording problems. Four ask to reverse an earlier decision and are waiting for a ruling.

    What this did not cover: No real phone was used, so this says nothing about the on-screen keyboard, touch under a thumb, or toolbars that come and go as you scroll. One finding, about the keyboard covering the help chat, is an open question for that reason. The width was 375 pixels, so it does not count as the 320 pixel check that WCAG 1.4.10 still needs. It covered the app, not the website, with no screen reader or other assistive technology.

  6. First screen-reader walk of the profiler

    Done by
    An AI agent, not a person
    On
    Assembly app , at 1280x720 pixels
    Using
    A real VoiceOver screen reader and a real Chrome browser on a Mac in the cloud, started by an AI agent, which read the results from the record the run wrote.

    Five of the parent questionnaire's 108 screens, in English, in light mode, with reduced motion. The first time the rebuilt app had been used with a screen reader at all. It was partial in every way, and its own record says so.

    What this did not cover: No person listened to any of it, and no person has used this product with a screen reader, on this date or any other. VoiceOver only, not NVDA or JAWS. Five screens of 108, at desktop size, without reaching the report screens or the chat.

  7. Text-spacing overlap walkthrough

    Done by
    An AI agent, not a person
    On
    Public website and Assembly app
    Using
    An AI agent reading screenshots of both products with the extra text spacing that WCAG 1.4.12 describes, applied exactly as our automated tests apply it.

    Both products, sampled where two pieces of text could overlap. Our automated test catches text being cut off, but it cannot see text running into other text. No overlap.

    What this did not cover: A sample, not every page, and an AI agent looking at still images, not a person using the product. No assistive technology.

  8. Narrow-screen judgement pass over the public website

    Done by
    An AI agent, not a person
    On
    Public website , at 320x812 pixels
    Using
    An AI agent using a browser automation tool, reading page captures against four set questions: reading order, hidden content, whether tables and figures can be read, and whether controls can be reached.

    23 pages of the public website, at the width WCAG 1.4.10 Reflow is about. 18 had no problems. Three rough edges, none bad enough to make a layout unusable: a table that scrolled sideways with no sign it could, what looked like blank space between numbered steps, and a glossary too long to find one term in. What happened to each is tracked in the known problems on our accessibility statement.

    What this did not cover: An AI agent, not a person, in light mode only, with every pop-out and tab left closed. The signed-in app was not checked. So WCAG 1.4.10 still needs a person to check this width.