Accessibility statement

We build accessible software for clients, so it would be difficult to explain an inaccessible site of our own. This page says what we have actually done rather than what we intend to do.

Each of these is checked automatically on every build, so it cannot quietly regress:

• Colour contrast is computed against the actual composited surface — including translucent panels, where testing against the background behind them would overstate every ratio. Text colours that fail are rejected by name at build time.
• Every page is checked with axe at desktop and mobile widths.
• Interactive targets are measured and must clear 24 by 24 CSS pixels (SC 2.5.8).
• Every focusable element is tabbed to with the fixed header present, and the focused element must never end up underneath it (SC 2.4.11).
• The page reflows at 320 pixels wide with no horizontal scrolling, and at 200% text size with no clipping.
• Every page is loaded with JavaScript disabled and must still render its full content, with every destination reachable.
• The reduced-motion preference is honoured, and animation is verified not to run when it is set.

Beyond the automated checks:

• Headings are in order and describe the structure rather than the styling.
• The skip link is the first thing you reach with the keyboard, and it moves focus rather than only scrolling.
• The mobile menu is a native dialog: focus is trapped while it is open, Escape closes it, and focus returns to the button that opened it.
• Form errors are announced, listed at the top of the form as links to each field, and repeated at the field itself.
• Nothing on this site is timed, auto-plays, flashes, or moves without you asking it to.
• The visual effect on this site has three fallbacks: no support for the effect, a stated preference for reduced transparency, and forced colours. All three are tested.

This is the part most statements leave out, so it is worth being direct about it.

• No third-party accessibility audit has been commissioned.
• No usability testing has been done with people who use assistive technology daily. Automated tooling decides perhaps a third of the WCAG success criteria; the rest is judgement, and ours is not the judgement that matters most here.
• Automated checks passing is not the same as a page being usable. We know the difference and are not claiming otherwise.

Things we know about and have not fixed:

• The display typography uses a fluid scale that becomes very large on wide screens. It has been checked for reflow and for 200% zoom, but at unusual window sizes the line breaks in headings can be awkward.
• The translucent surfaces reduce the visual separation between a panel and the page behind it. Contrast for text is verified against the composited surface, but the panel edge itself is decorative and does not meet a 3:1 boundary contrast — no control anywhere on the site relies on that edge alone to be identifiable.
• Some oversized type is set at very low contrast on purpose, as texture behind the translucent panels. It is marked as decoration, hidden from assistive technology, and carries no information — which is what makes it exempt under the incidental-text provision. We are naming it here rather than letting an automated report pass silently.
• We have not verified behaviour in screen readers other than through structural review of the markup. See the compatibility section.

If you hit something not on this list, we would genuinely like to know. That is what the list is for.

This site should work with current versions of the major browsers, and with assistive technology that works through standard web APIs.

Write to info@littlestone.world. Please say what you were trying to do, what happened, and what you were using — browser, assistive technology, and device if that is relevant.

We aim to respond within 7 working days. If the fix is quick we will make it and tell you. If it is not, we will tell you what we plan to do and roughly when.

If our response does not resolve it, say so and it will be escalated to the person who runs the studio rather than being closed.

This statement is prepared with reference to WCAG 2.2 and follows the structure recommended by the W3C for accessibility statements.

This statement is reviewed whenever the site changes materially, and at least annually. The "last updated" date at the top is enforced by the build: this content cannot change without it moving.