Accessible design happens while the layout, colour, and copy are still soft enough to change cheaply, well before a review pass at the end could catch anything. This page covers the decisions that matter most, in the order they usually get made. It applies to product design, UX writing, and design systems, against a conformance target of WCAG 2.2 AA.
We measure our own work against WCAG 2.2 AA and EN 301 549 directly, not against any single vendor’s interpretation of them. We monitor the accessibility landscape as it changes, and look to adopt the best approaches for designing the best experience for our users, but our components are tested and owned by us, not adapted from any one source.
This page applies across both of our design systems. Granite carries these practices forward across our established products. Helix, our system for next-generation applications, was built with them as a starting condition, so a designer working in Helix should find most of this already reflected in the components and tokens on offer, rather than something to add on top.
Colour and contrast
Every text and icon colour pair in a design must meet 4.5:1 contrast against its background (3:1 for large text at 24px/19px bold and above, and for icons and UI component boundaries). We check this at design time, not at QA, using the same contrast tokens engineering will consume — a colour that fails contrast shouldn’t exist in the palette a designer can pick from.
Colour is never the only signal. Status, required fields, validation, and selected state all pair colour with a shape, icon, or text label, so the interface still works for colour-blind users and in constrained-colour contexts like high-contrast mode.
Typography and readability
Body text sits at 16px minimum with 1.5 line height; line length stays under ~80 characters. Text and images of text scale to 200% without loss of content or function — we test this in the browser, not by eye. We avoid justified text and never truncate content that a screen reader would otherwise announce in full without an accessible name for what was cut.
Helix’s own tokens are scoped to components rather than running text, so we track control and
label sizing on its own terms rather than folding it into the body-text figure above. That sizing
scales with breakpoint: at the smallest screen tier (xs), where touch is the primary input,
control text sits at 18px with icons no smaller than 16px; at the largest tier (lg), where a
mouse or trackpad gives more precision, the same control drops to 14px text with icons down to
8px, and base/md sit in between at 16px. Smaller screens getting more room is the right
direction, but it’s worth checking any Helix control’s full hit area against WCAG 2.5.8’s 24px
target-size minimum at the lg tier specifically, where the headroom is tightest.
Focus and keyboard interaction
Every interactive element a designer places must have a visible focus state and a place in a logical tab order — this is designed, not left to the browser default, especially in custom components like data grids, kanban boards, and lobby tiles. If an interaction can only be described in terms of a drag gesture, it needs a keyboard-operable equivalent designed alongside it, not bolted on afterward.
Design review question: “If I unplugged the mouse right now, could I still complete this flow, and would I always know where I am?” If the answer is unclear from the mockup, the interaction isn’t finished.
Forms, validation, and error handling
Labels are visible and persistent — not placeholder text that disappears on input. Every error is specific about what happened and how to fix it, appears next to the field it concerns, and is announced by a screen reader without requiring the user to find it visually. Required fields are marked with text, not colour or an asterisk alone with no accessible explanation of what the asterisk means.
Motion and animation
Motion earns its place by clarifying a state change — never decoration for its own sake. Every
animation respects prefers-reduced-motion, and nothing flashes more than three times per second.
Auto-advancing carousels and auto-refreshing dashboards include a visible, keyboard-reachable
pause control.
Content and plain language
We write for the person under the most pressure, the one with the least time to spare. Instructions describe what to do next, and mention what the system already did only when it helps. Jargon is defined on first use or avoided; abbreviations are expanded at least once per page.
Inclusive design research
Where possible, usability research for major flows includes participants who use assistive technology as their primary means of access — a screen reader user, a switch-access user, someone with low vision using magnification. Simulated impairment (blurring a screenshot, using a mouse with your non-dominant hand) is a useful sensitising exercise for a design team, but it isn’t a substitute for testing with the people the feature is meant to serve. How we recruit and schedule that testing on a standing basis, rather than per project, is covered under Recruiting and testing with assistive technology users on the process page.