WCAG 2.1 Explained: What Every Product Designer Should Know About Accessibility
The accessibility rules that actually change design decisions, explained without the jargon, plus the checks that catch the majority of real-world issues.
WCAG is a specification, not a law, and most product designers encounter it late — usually as a bug ticket from an audit. The problem is that almost every accessibility failure traces back to a design decision made weeks earlier, when nobody was thinking about it.
The useful way to read WCAG is not as a checklist but as a set of underlying principles. If you understand the principles, you can reason about cases the spec does not explicitly cover.
Perceivable
Content has to be available to more than one kind of sense. Everything visual needs a text alternative, which in practice means writing real alt text rather than descriptions of the image itself.
Colour is never sufficient on its own to carry meaning. If an error state is communicated by red alone, a colour-blind user and a monochrome screen reader user both miss it. Add an icon, a border, or text.
Text needs a contrast ratio of at least 4.5:1 against its background, and 3:1 for large text. This is the single highest-impact check in the whole specification, and light grey on white is the most common violation I see.
Operable
Everything reachable by mouse must be reachable by keyboard, with visible focus. Losing focus styling is the fastest way to make a product unusable for keyboard users, and it is usually removed because it looked untidy in a review.
Nothing important should depend on hover, on drag, or on a gesture that has no single-pointer equivalent.
Understandable
This is where design has the most influence. Error messages need to say what happened and what to do next. Input fields need labels, not just placeholders, because a placeholder disappears the moment someone types.
Consistent navigation and predictable behaviour reduce the cognitive load the criterion is really about. Unexpected behaviour is an accessibility problem even when every control technically works.
Robust
Code needs to expose the semantics that assistive technology depends on. A div with a click handler is invisible to a screen reader unless you add the right role, state, and keyboard handling. This one is a front-end concern, but the designer decides whether the component is even capable of it.