Accessibility Statement

BEY AGENCY LTD is committed to making the ai2 design system (ai2.design) usable by the widest possible audience, regardless of technology or ability. Accessibility is treated as a core property of the product rather than a later addition: the components in the system are built with keyboard support, focus-visible indicators, reduced-motion handling, colour tokens chosen with contrast in mind and generous touch-target hit areas.

We aim for conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. This is the standard we design and test against, and the goal we hold ourselves to as the site and the component library continue to grow.

Across the site and the shipped components, our accessibility practices include the following:

• Semantic HTML markup, so that headings, lists, landmarks and controls carry their meaning to assistive technology.
• Visible focus-visible indicators on interactive elements, including links, so that keyboard users can always see where they are.
• Keyboard operability for interactive components, following the expected key patterns for the control type.
• Support for the prefers-reduced-motion user preference, so that motion-heavy interfaces can be calmed to the user's system setting.
• Colour contrast chosen and checked by measurement against WCAG 2.1 AA thresholds, using the ai2 colour tokens.
• Skip links and landmark structure where they are used, to help users move past repeated content.
• ARIA roles, states and properties added where native semantics are not sufficient on their own.
• Touch-target hit areas that extend the interactive region of small controls without changing their visual size.

We consider the core site and the components to be substantially aligned with WCAG 2.1 Level AA. This is a self-assessed target that we work towards continuously, not a certified result: the assessment reflects our own internal testing and has not been independently audited or verified by a third party.

Because the product is actively developed and some areas carry known limitations (see below), we describe our status as a work in progress rather than full conformance. We do not claim complete or independently-audited conformance, and we update this statement as the picture changes.

The following areas are known to fall short of our target in ways we are aware of and, where relevant, have mitigated:

• Two colour pairs in our own tokens sit below the AA threshold and we have accepted them deliberately rather than fixed them. Placeholder text in dark mode measures about 2.01:1; we treat placeholders as non-essential because the same information is carried by the field's visible label. The hairline borders on inputs and cards measure about 1.3:1; this matches the shadcn baseline our components stay compatible with. Both are recorded decisions, not oversights, and we will revisit them.
• A small number of touch targets remain below the 24 by 24 pixel minimum of WCAG 2.5.8. We measured every interactive element across the whole site and reduced the shortfall from 1,083 to 108. The 108 that remain are the slide buttons inside two carousel demonstrations, where the slides are rendered under a three-dimensional perspective transform: the only way to make them larger is to remove the effect they exist to demonstrate. The dot indicators beside them are full-size and do the same job, which is the equivalent-control exception the guideline allows. We would rather state the number than round it away.
• At 200 percent text size, several component documentation pages scroll horizontally. This affects the demonstration areas on pages such as calendar, combobox, tabs and one-time-password input, where the component's own layout grows past the viewport. We measured it, we have fixed the two shared containers that caused the worst of it, and the remainder sits in the tab strips and toggle groups inside the demonstrations. It is on our list rather than resolved, and it is present today.
• We have not yet completed a systematic screen-reader audit across the site. Components are built on primitives that carry the expected roles and labelling, and we check structure as we build, but we are not in a position to claim verified screen-reader conformance and would rather say so.
• Loading spinners keep rotating even when a visitor has asked for reduced motion. A frozen spinner reads as a hung page, so the rotation is carrying information rather than decorating. Every other animation on the site stops or softens under that preference.
• The Inspiration Gallery displays third-party screenshots that we do not author or control. Their content, contrast and any text baked into the image are outside our influence; we provide editorial captions but cannot guarantee a full text alternative for the source material.
• Live embeds, iframes and product previews can render content from external sources or from separate build environments. We cannot guarantee that embedded or previewed content fully conforms, and a cross-origin frame's own behaviour cannot be corrected from our side.
• Some marketing sections use richer animation to present the product. These rely on prefers-reduced-motion support to reduce or remove motion, and users can also lower motion through their operating-system settings.

Our testing combines automated checks with manual verification. In practice this includes:

• Measuring colour contrast against the WCAG 2.1 AA thresholds, rather than judging it by eye. Where a pair falls short we either fix it or record it as an accepted exception in section 4; we do not quietly leave it unmeasured.
• Keyboard walkthroughs of interactive flows, checking reachability, focus order and visible focus.
• Verifying that the prefers-reduced-motion preference is honoured where motion is used.
• Automated build gates that fail the release if a component animates without a reduced-motion counterpart, or if an interactive element ships without a visible focus ring.

Beyond the site itself, the components ship accessibility patterns to the projects that consume them, so that the same focus handling, keyboard behaviour and reduced-motion support carry through to downstream products.

If you encounter an accessibility barrier on ai2.design, please tell us. Email hi@bey.agency or hello@ai2.design and describe the page you were on, the problem you experienced and, where you can, the browser and any assistive technology you were using. Both addresses reach the same team.

We aim to acknowledge reports within a reasonable window of a few working days, and to prioritise remediation of issues that block people from completing a primary task. We cannot commit to a fixed resolution time for every report, but priority issues are addressed ahead of routine ones and tracked through to a fix.

If you are in the United Kingdom and you are not satisfied with our response, you may seek independent advice from the Equality Advisory and Support Service (EASS), which advises on issues covered by the Equality Act 2010. Contacting us first usually lets us resolve the problem more quickly.

We may update this statement as the site and the component library evolve, as our testing surfaces new issues, or as known limitations are resolved. Material changes are reflected in the version and last-updated details shown with this document.

ai2 (ai2.design) is operated by BEY AGENCY LTD, a private limited company registered in England and Wales under company number 16435596. Questions or reports about accessibility can be sent to hi@bey.agency or hello@ai2.design.