What accessibility basics should a designer know?

Most accessibility problems are decided in the design file, before a developer writes a line. The standard to know is WCAG 2.2, which W3C published as a Recommendation on 5 October 2023.

Six things are in your hands as a designer:

Motion has its own rules, covered below. Everything here comes from W3C's own pages.

Text. Success criterion 1.4.3 asks for "a contrast ratio of at least 4.5:1." Large text only needs 3:1. Large means at least 18 point, or 14 point bold. W3C notes these are "approximately 18.5px and 24px" (14 point bold and 18 point).

The exceptions: text in an inactive component, pure decoration, text no one can see, text inside a busy photo, and logos.

Everything that is not text. Criterion 1.4.11 asks for 3:1 against adjacent colours for the visual parts needed to identify UI components and their states, and for graphics needed to understand content. That covers input borders, icon buttons, toggle states, and chart lines. W3C's explanation adds that a focus indicator needs enough contrast against its background too.

The fix is usually in your tokens. If your grey placeholder text fails, it fails on every screen. Check contrast once at the design system level, and every component inherits it.

Criterion 2.5.8 is new in WCAG 2.2. It says "The size of the target for pointer inputs is at least 24 by 24 CSS pixels," at Level AA.

It has five exceptions, which W3C lists as:

• Spacing: a smaller target is fine if a 24 pixel circle centred on it does not touch another target or its circle.
• Equivalent: the same action is available through another control that meets the size.
• Inline: the target sits inside a sentence, like a text link.
• User agent control: the browser sets the size and you have not changed it.
• Essential: a specific presentation is essential or legally required.

Treat 24 by 24 as the floor, not the goal. Small close buttons and tight icon rows are where designs fail this most.

Focus. Criterion 2.4.7 says any keyboard operable interface needs a mode where "the keyboard focus indicator is visible." In practice: design a focus state for every interactive component, next to hover and pressed. Never hand off a design that removes the browser outline without a replacement.

WCAG 2.2 also adds 2.4.11 Focus Not Obscured (Minimum), Level AA: a focused component must not be "entirely hidden due to author-created content." Watch sticky headers, cookie banners, and chat bubbles that can cover a focused field.

Colour. Criterion 1.4.1 says colour must not be "the only visual means of conveying information." Two common failures W3C names:

• Links that differ from body text only by colour.
• Form errors or required fields marked only in red.

The fix is a second signal. W3C's design tips suggest "an asterisk in addition to color" for required fields. Add an icon or text to errors, and an underline to links.

Criterion 1.1.1 asks that all non-text content has "a text alternative that serves the equivalent purpose." Developers write the alt attribute, but you decide what it should say. Put it in your handoff notes.

• Meaningful images: write what the image tells the user, not what it looks like pixel by pixel.
• Icon-only buttons: give each a label, like "Close" or "Search".
• Decorative images: mark them as decorative so assistive technology can skip them. W3C notes that alt text on decoration distracts screen reader users.

My handoff guide covers where notes like these belong.

Two criteria cover motion:

• 2.2.2 Pause, Stop, Hide (Level A). Anything moving, blinking, or scrolling that starts on its own, lasts more than five seconds, and sits next to other content needs a way to pause, stop, or hide it. Think auto-playing carousels and looping backgrounds.
• 2.3.3 Animation from Interactions (Level AAA). Motion triggered by interaction can be turned off, unless it is essential. AAA is WCAG's highest level, above the AA most rules here sit at.

The tool for this is the CSS prefers-reduced-motion media feature. MDN describes it as detecting whether a user "has enabled a setting on their device to minimize the amount of non-essential motion." W3C lists it as a sufficient technique (C39) for 2.3.3.

This is how I build syedsarib.com. I designed and coded the site, and its rule is that every animation respects prefers-reduced-motion, through Tailwind's motion-reduce: classes and shared motion tokens. That does not make the site fully WCAG conformant. It means motion is one area I handle by default instead of fixing later.

As a designer, specify the reduced version in your file: what fades instead of slides, and what simply appears.

1. Check your colour tokens against 4.5:1 for text and 3:1 for borders and icons, and fix the ones that fail.
2. Add a focus state to every interactive component in your library.
3. Measure your smallest tap targets and bring them to at least 24 by 24, or space them out.
4. Turn on reduced motion in your phone or computer settings and use your own product for ten minutes.

Then run a usability test with these fixes in place, and write the accessibility decisions into your UX case study.