Digital accessibility: what the law really requires
4 min read
Key takeaways
- Below two products and three people designing, a design system costs more than it brings in.
- Start with tokens — colours, typography, spacing — before components.
- A design system lives in code as much as in the design tool; otherwise it drifts apart within three months.
- Budget for a first usable version, then an ongoing upkeep budget.
- The most reliable signal: your developers keep asking for the same spacing value three times.
"We need a design system." We hear this sentence in companies that have a single product, a single designer, and not yet a second screen. In that case, the honest answer is no — and it costs us assignments.
A design system is an industrial investment. It becomes profitable beyond a certain threshold, and costly below it. Here is how to place your company relative to that threshold.
The five signals that show the time has come
Count how many you tick.
- You have at least two products or surfaces — a mobile app and a back office, a website and an extension, two business apps.
- At least three people produce interface, designers and developers combined.
- The same question comes up every week: "what colour for this button?", "what spacing between these blocks?", "is there already a component for that?".
- You see visible divergences: three almost identical shades of blue, four button sizes, two form field styles in the same journey.
- The time to ship a screen is increasing even though the team is more experienced than a year ago.
Three or more signals: build it. One or two: settle for a shared component library, without the governance and documentation that come with it. Zero: focus on the product.
The three-spacings test. Ask three developers on your team what margin they would put between a section title and the next paragraph. If you get three different values, you're already paying the cost of having no system — it's simply invisible because it's spread across everyone.
What to build, in order
The classic mistake is to start with the most visible components. Thirty button variants are designed, nothing is documented, and six months later each team has recreated its own.
1. Tokens (2 to 4 days)
Colours, typography, spacing, radii, shadows, animation durations. These are the most structuring decisions and the cheapest to make. They must exist as variables, in the design tool and in code — the same value, the same name.
A six-value spacing scale is enough in 90% of cases. On its own it eliminates half the debates.
2. Primitives (1 to 2 weeks)
Button, input field, selector, checkbox, badge, card, modal, alert message. With all their states: default, hover, focus, active, disabled, loading, error. States are what distinguish a real component from a pretty mock-up — and it's also where accessibility is decided, a subject we cover in our article on RGAA and digital accessibility.
3. Patterns (ongoing)
Long form, data table, empty state, loading, error handling, onboarding. These are assemblies of primitives with usage rules. They are added as real needs arise, never in anticipation.
4. Documentation (ongoing)
For each component: what it's for, when not to use it, and a copyable example. Three sentences are enough. Forty pages of documentation that nobody reads are worth less than one sentence in the right place.
The real cost
| Scope | Budget | Lead time |
|---|---|---|
| Tokens + 10 components, one platform | On quote | 3 to 5 weeks |
| Tokens + 25 components, web + mobile | On quote | 8 to 12 weeks |
| Annual upkeep | 10 – 15% of the initial cost | Ongoing |
The item everyone forgets is the last one. A design system isn't a deliverable: it's an internal product with users, change requests and debt. Without an identified owner and dedicated time, it becomes a museum in under a year.
Starting from an existing base
In most cases, we recommend not starting from scratch. A mature open-source base gives you accessibility, keyboard handling, states and the behaviour of complex components for free — selectors, modals, menus. These are precisely the parts that take longest and are easiest to get wrong.
You then apply your brand tokens, and build custom only the components that genuinely set you apart. Typical saving: 60 to 70% of the initial cost, and far better accessibility than a team produces starting from nothing.
The best design system isn't the most complete, it's the one the team uses without thinking about it. Any component that people work around is a component to fix or remove.
How to know whether it works
Three indicators, measurable without any special tool:
- The time to produce a new standard screen. It should fall by at least 30% within three months of adoption.
- The number of unique colour and spacing values in the code. It should decrease, not increase.
- The proportion of screens built solely from system components. Below 70%, the system doesn't meet real needs: it's its rules that need revisiting, not the team's discipline.
If you're unsure about your situation, tell us about your products and the size of your team. We'll tell you honestly whether the time has come — including when the answer is "not yet".
Sources
- Design Tokens Community Group — W3C Community Group
- ARIA Authoring Practices Guide | APG | WAI — W3C WAI
