Accessibility is not a checklist, it is an architecture

Most of the RGAA audits I have seen arrive too late shared the same original flaw: accessibility had been thought of as a list of fixes, never as a design constraint.

The classic symptom

A design system that does not build in contrast or keyboard navigation from the outset will generate hundreds of non-conformities, repeated on every screen that uses it. Fixing them afterwards means reworking each screen individually.

What an architectural approach changes

• Base components (buttons, forms, modals) are validated once, then accessible everywhere
• Semantic HTML structure choices are made upstream, not retrofitted (a heading hierarchy check is enough to verify the foundation)
• Accessibility tests are built into the development cycle, not left to the end of acceptance testing

The economic benefit

The cost of fixing an accessibility defect grows with the number of screens that depend on it. Dealing with it at design system level divides that cost by the number of screens concerned, sometimes by hundreds.

A concrete example of propagation

A poorly contrasted form button, validated just once in the design system, is then reproduced on every screen that uses it: login page, checkout funnel, contact form, customer area. Fixing it at the source instantly sorts out all these screens. Fixing it screen by screen, once the product is in production, means finding every occurrence, checking that no local variant has been introduced in the meantime, then retesting each one individually. The difference in workload is not linear, it is multiplied by the number of screens concerned.

It is this same reasoning that justifies dealing with accessibility at design system level rather than screen by screen: a one-off investment at the source, rather than a debt paid as many times as there are screens.

The design system as a foundation: the DSFR example

The French State Design System (DSFR) applies this logic across public websites. Each component is documented with an accessibility sheet: expected keyboard behaviour, rendering by screen readers, relevant RGAA criteria. The modal, for example, relies on the ARIA Dialog pattern: focus stays inside the window while it is open, then returns to the button that triggered it.

This is the model I recommend for a private design system: the accessibility sheet is part of the component, just like its code and its variants. But an accessible component does not make a page compliant on its own. A perfectly coded button labelled "Click here" is still a non-conformity, and it is the integration that creates it, not the component. Architecture sorts out the foundation, integration review sorts out usage.

The components to check first

When I audit a design system, I do not start with the 106 criteria of RGAA 4.1.2. I start with the five components that propagate the most, because a defect there is multiplied across the whole site.

Component	What breaks most often	Relevant RGAA criteria	Quick test
Button and link	Vague label, insufficient contrast	3.2, 6.1, 7.1	Read the label out of context, measure with a contrast checker
Form field	Missing label, error not announced	11.1, 11.10	Clicking the label should place the cursor in the field
Modal	Focus escaping, no return to the trigger	7.1, 12.8	Open, tab all the way through, close with Esc
Menu and navigation	Inconsistent tab order, invisible focus	10.7, 12.8	Go through everything with the Tab key, using the hidden focus detector
Page template	Skipped heading levels	9.1	Read the list of headings on its own: it should form a table of contents

These five rows do not replace an audit. They show where a defect costs the most to let slip.

Building tests into the development cycle

An accessible architecture is checked at three points, not one. In continuous integration, an automated engine such as axe-core blocks obvious regressions: contrast, missing attribute, missing label. Deque, its publisher, estimates that its automated tools detect 57% of the issues found in its own audits (a 2021 study, measured by volume of issues and not by number of WCAG criteria covered). The rest requires a human eye.

In code review, each new component goes through the same short grid: accessible name, role, focus management, keyboard behaviour. In acceptance testing, the main user journeys are run with the keyboard and then with a screen reader. The official RGAA methodology actually requires this for JavaScript components, some of whose tests "require checking how content is rendered with assistive technologies". For a first assessment without in-house tooling, my site health scan runs a page through the axe-core engine.

Accessibility statement and multi-year plan

The architectural approach extends all the way to regulatory deliverables. The accessibility statement shows a conformity status calculated on the criteria: fully compliant if all are met, partially compliant if at least 50% are, non-compliant below that. A fixed design system raises this rate on every page at once.

The multi-year plan (schéma pluriannuel), provided for by article 47 of the law of 11 February 2005, covers at most three years and is broken down into annual action plans. It is the right place to schedule the rework of components, rather than a list of pages to fix one by one. Elsewhere I detail what the RGAA obligation requires in 2026 and which companies are concerned.

An RGAA audit at the end of a project measures symptoms. An architecture designed for accessibility treats the cause.

This is the approach I apply in my accessibility practice: treating accessibility as an architecture, not as an end-of-project fix.

Further reading: why accessibility by design costs less than late compliance

Frequently asked questions

Is an accessible design system enough to make a site RGAA compliant?

No. It sorts out the foundation (contrast, roles, focus management) but not how it is used: link labels, image alternatives, heading hierarchy and editorial content still have to be checked page by page.

Which components should a design system audit start with?

Those that propagate the most: buttons and links, form fields, modals, navigation and page template. A defect in any one of them is reproduced on every screen that uses it.

Are automated tests enough to validate accessibility?

No. They are good at spotting repetitive technical errors, but the relevance of a label, the reading order or rendering by a screen reader require human testing, which the RGAA methodology demands for JavaScript components.