Product Design & UX · Chapter 4 of 5
Design systems and accessibility
48% and 51% of postings. The two things that separate a product designer from a screen producer.
Both of these are really the same skill: designing the rule rather than the instance.
Design systems
- A component library is not a design system. The system is the decisions — spacing scale, type scale, colour roles, interaction patterns — and the library is one expression of them.
- Tokens are the contract between design and engineering. Named semantically (surface, danger, muted) rather than literally (grey-100), so a theme change does not require renaming everything.
- The hard part is adoption, exactly as with an internal platform. A system product teams route around is a museum. Contribution paths and genuine responsiveness to requests are what prevent that.
- Version and deprecate deliberately, or you accumulate three button components and nobody knows which is current.
Accessibility
- It is a design constraint, not an audit. Retrofitting contrast and focus order at the end is expensive and produces worse design than accounting for them at the start.
- The four that catch most issues: contrast ratios, keyboard operability with visible focus, meaningful labels and alternative text, and not using colour alone to convey meaning.
- Motion and reduced-motion preferences, which are routinely forgotten and genuinely affect people.
- It is increasingly a legal requirement, not only an ethical one, which is part of why 51% of postings name it.
What a design system is actually for
A design system is usually justified as consistency. Consistency is the visible benefit and the smaller one. The real benefit is that decisions get made once — how focus states look, how errors are announced, how a form behaves on a small screen — and then stop being re-litigated on every screen by whoever happens to be building it.
- The failure mode is a component library nobody uses, because it is faster to build a one-off than to find, learn and bend the shared component. Adoption is the metric, not component count.
- Which means the system has to be easier than not using it. If contributing a variant takes three weeks of review, people will fork instead, and every fork is a decision re-made badly.
- Accessibility is the strongest argument for the system, because it is where ‘decide once’ pays most. Getting focus management, keyboard interaction and screen-reader announcement right in a date picker is genuinely hard; getting it right once is achievable, and getting it right on every team's own date picker is not.
- And a system with inaccessible components actively scales the problem, which is the risk nobody names when adopting one.
Accessibility, in the order that finds the most problems
1. Can you use it with the keyboard alone? Tab through the whole flow. If you cannot reach a control, cannot see where focus is, or get trapped in a modal, that is a blocking defect and it takes two minutes to find. This single test finds more real problems than any automated scan.
2. Do images and controls have meaningful names? An icon button with no accessible name is a button that reads as ‘button’.
3. Does colour carry meaning on its own? Red for error and green for success, with no text or icon, is invisible to a substantial share of users.
4. Is contrast sufficient? Automated tools do this well — it is one of the few things they genuinely settle.
5. Are errors announced, not just displayed? A message that appears visually but is never announced does not exist for a screen-reader user, and this is the most commonly missed item in forms.
The framing that gets it prioritised: automated tools catch perhaps a third of real issues, so a clean scan means very little. But the keyboard test is free, requires no tooling and no training, and can be run by anyone in the team on any pull request. Make that the bar and you will be ahead of most products.
Check yourself