Accessibility
Accessibility at Assembly
Assembly exists for families who are being failed by systems that weren't designed around them. An inaccessible website would be a strange way to start. Here's what we do, and, further down, our contrast working shown live rather than asserted.
Our commitment
We aim for WCAG 2.2 level AA across this site, and we track the perceptual contrast model (APCA) that the WCAG 3 drafts are exploring alongside it. Where the two standards disagree, we say so openly below instead of quietly picking whichever suits us.
Aiming is not the same as arriving. Our conformance statement records where we actually stand against all 55 WCAG 2.2 level A and AA success criteria, one by one, including what is broken today and what nobody has assessed yet. It is generated from a record kept in our code, so it cannot quietly go stale. Further down that same statement, we also set out which of the stricter AAA criteria we borrow, and which we decline , and why.
Keyboard first
Skip links to navigation and to main content, visible focus rings on links and buttons, and menus that open, close and return focus predictably (Escape included). The focus ring's own contrast, held to WCAG 2.2's 3:1 non-text bar by a check over our colour tokens, is one of the three checks a change has to pass before it can be merged. The keyboard tests that drive the skip links with real key presses and read the outline your browser actually renders are not: they run on a pull request that touches this site and they go red, but they cannot refuse the merge. No test walks every interactive path on the site end to end.
Semantic structure
Proper landmarks on every page, one main, labelled navs and real headings in order. Automated checks over all 21 public pages cover the landmark and labelling rules, and run without being asked whenever a change touches this site, in light, in dark and at 320 pixels wide. They report rather than block, and a change that touches only the app never triggers them. Whether the resulting structure reads well through a screen reader is a separate question, and we have not yet answered it.
Motion is optional
Scroll animations respect prefers-reduced-motion: turn it on and content simply appears, with nothing hidden behind an animation. This is done per component rather than by one site-wide rule, so it is a convention we keep rather than something the site enforces for us.
Readable by design
Body text at 18–20px on long-form pages, line lengths capped near 66 characters, and nothing that blocks zoom. At the 200% zoom equivalent we measured no page that scrolled sideways. Around sixty individual text sizes are still set in fixed pixels, so they follow browser zoom but ignore a changed default font size.
Found something that doesn't work for you, a screen reader snag, a contrast problem, a keyboard trap? Email info@helloassembly.com and we'll fix it. Accessibility reports get the same priority as bugs, because they are bugs.
The contrast lab
Colour contrast has two rulebooks right now. WCAG 2.2 uses a luminance ratio designed in the 2000s: simple, testable, and famously wrong about one thing, it over-rewards dark text on saturated mid-tone colours, which is why it insists the world's orange buttons should carry black text that no design team believes is more readable. APCA (the Accessible Perceptual Contrast Algorithm, the candidate model for WCAG 3) models how vision actually responds to polarity, font size and weight.
Below, the colour pairs this site is built from are measured in your browser, right now, against both. Nothing is precomputed, flip your system to dark mode and the numbers remeasure. This is a working, not a full inventory: it renders the pairs the design system leans on hardest. Almost every pair in the system, including ones not shown here, is checked by a test over our colour tokens that has to pass before a change can be merged. Four pairs are not: they sit in a named quarantine while we finish splitting one colour into a fill version and an ink version, and our conformance statement records where each of them renders and what the fix is.
| Component | Sample | WCAG 2.2ratio · AA verdict | APCALc · verdict |
|---|---|---|---|
| The live measurements need JavaScript, this table measures the rendered colours in your browser rather than quoting precomputed numbers. With scripts off, the short version: an automated check over all 21 pages of this site, in light, in dark and at 320 pixels wide, reports no contrast failure. That check runs by itself whenever a change touches this site, but it is not one of the checks required to merge, so it reports rather than refuses. One element is excluded from it by name, and it is this page: the next section renders our old failing button on purpose so its numbers can be shown, and a demonstration of a violation is not a violation. There was a second exclusion, a small peach Download PDF pill inside the product illustration on our how it works page, which was genuinely below the contrast this standard asks for at that size. We deepened its background in August 2026 until it passes, and removed the exclusion in the same change, so the check now measures it like anything else. | |||
Measured from computed styles in this browser session. WCAG 2.2 AA requires 4.5:1 for normal text and 3:1 for large text (≥24px, or bold ≥18.7px). APCA verdicts use the draft bronze thresholds: Lc 75 for body text, Lc 60 for large/bold text, Lc 45 for very large display text. This table measures text. The things that aren't text but still carry meaning, focus rings and the borders that tell you where a field is, are held to WCAG 2.2's separate 3:1 rule by a test over our colour tokens rather than shown here.
The peach button, honestly
Our primary call-to-action used to be white text on a warmer peach. WCAG 2.2's formula scores that around 2.3:1, a hard fail, and scores near-black text on the same peach around 8:1, a resounding pass. APCA measures the same two options and finds them nearly equivalent, and in fact the "compliant" black text fails the perceptual model, because the old formula dramatically overestimates how readable dark-on-orange really is. That disagreement, times every orange button on the internet, is a big part of why a perceptual model is being explored for future guidance.
We refused to pretend the black-on-peach button was the accessible one, and we also refused to keep a button that failed both rulebooks. So we did the work and shipped the third option: a slightly deeper peach with large bold white type that satisfies both standards. All three, with their scores measured live in your browser:
Where we started
Get startedWhat WCAG 2.2 asks for
Get startedToday's button, passes both
Get startedThe third button is the one live across this site and the Assembly app (shipped July 2026). It keeps the brand where the brand lives, a warm peach pill with confident white type, while clearing WCAG 2.2 AA's large-text threshold (3:1 at bold ≥18.7px) and APCA's level for large bold text, which is why every real CTA renders its label at 19px bold. Standards met, soul intact. The change is also pinned by an automated contrast check over our colour tokens, which is one of the checks required to merge, so it can't quietly regress. One peach pill on the site is not 19px bold: the miniature Download PDF button drawn inside the product illustration on our how it works page, which is a picture of this button rather than the button. At that size the large-text threshold does not apply and the same colours fell short, at 3.17:1 against a bar of 4.5:1. We listed it as a live failure here for as long as that was true. In August 2026 we deepened the peach behind that one drawing until white passes at 4.96:1, kept its label so it still looks like the button it depicts, and removed the exclusion that had been keeping the page scan green over it. The retired entry is recorded in our conformance statement .
Where we stand
This page covers the marketing site at www.helloassembly.com and was last reviewed in August 2026. We test with keyboard-only navigation and automated tooling as part of development, not as a yearly audit: axe runs over all 21 public pages in light, in dark and at 320 pixels wide, each of those pages is also measured for whether it is wider than the screen it is being read on, and keyboard tests press real keys and measure the outline your browser draws. All of them start automatically on any change that touches this site, and not one of them is on the short list of checks that can actually block a merge here, so treat them as an alarm rather than a lock. We have not tested the Assembly app with a screen reader. We have a written test script for it and it has not yet been run, so nothing on this page should be read as a screen reader result. Doing that pass is the next thing on this list. No external audit has been carried out, so nobody outside Assembly has assessed this product.
The Assembly app has its own accessibility work. It is not yet held to the same bar as this site: the app's automated scans run after changes are merged rather than before, and they cover 10 of its screens rather than all of them. Where we stand against every WCAG 2.2 success criterion, on both, is set out in our conformance statement . If anything here doesn't match your experience, we want to know: info@helloassembly.com .