Web accessibility: what WCAG really asks of a Drupal developer

Web accessibility was long treated as a moral option. Not anymore: it is now a legal obligation for a growing share of the web — and, incidentally, a quality marker that separates serious teams from the rest. I work daily with W3C standards on the France Télévisions back offices, where accessibility is a public-service requirement. Here is what that means concretely for a Drupal developer.

The framework: WCAG, EAA, RGAA

• WCAG (Web Content Accessibility Guidelines): the W3C’s international standard. The level targeted in practice is AA. This is the common technical baseline.
• European Accessibility Act: since June 2025, accessibility obligations extend to large parts of the European private sector — e-commerce, banking, transport, digital media. If your product sells in Europe, you are probably in scope.
• RGAA: France’s national reference framework (106 audit criteria), mandatory for the French public sector and large companies, with a public accessibility statement and a multi-year plan. Other countries have equivalents — Section 508 in the US, BITV in Germany.

Translation for teams: “we’ll look at accessibility at the end” is no longer a plan. It is debt that shows up in an audit, gets declared publicly, and can be litigated.

What belongs to the developer (not the designer)

A large share of the criteria is decided in the code we write every day:

1. Semantics first. Real <button>s, real <a>s, hierarchical headings (one h1, no skipped levels), landmarks (header, nav, main, footer). A screen reader navigates by structure — a soup of clickable <div>s is unreadable.
2. Forms. Every field has an associated <label>, errors are announced (not just coloured red), groups have fieldset/legend. Drupal’s Form API gets the basics right — as long as the theme does not destroy them.
3. The keyboard. Everything doable with a mouse must be doable with a keyboard: visible focus, logical tab order, no focus traps in modals. Test your site for five minutes without a mouse — the cheapest audit in the world.
4. ARIA as a last resort. The first rule of ARIA: do not use ARIA when native HTML is enough. An inconsistent aria-label is worse than none.
5. Media and contrast. Meaningful alt text (and empty alt for decorative images), AA contrast ratios (4.5:1 for body text), no information carried by colour alone.

Drupal-specific realities

Drupal core is one of the most serious CMSs on this subject — the accessibility initiative’s work shows in Claro, Olivero and the Form API. Regressions almost always come from us:

• The custom theme that replaces native components with homemade <div>s without carrying the semantics over.
• JavaScript components (carousels, accordions, autocompletes) integrated without focus management or announcements (aria-live — and Drupal.announce() exists precisely for this).
• Editorial content: the best theme in the world cannot rescue images without alternatives and “click here” links. Accessibility is also trained on the contributor side — modules like Editoria11y check content as it is written.
• The back office itself: your editors deserve an accessible tool too. That is a selection criterion I apply to admin modules as a maintainer.

How to test, in practice

My minimal stack: automated audits (axe, Lighthouse) to catch ~30% of issues, systematic keyboard navigation, contrast checks at design time, and a screen-reader pass (VoiceOver/NVDA) on critical journeys. Automation is never enough — a form can pass axe and still be unusable.

Accessibility is not a finishing layer: it is an engineering requirement, like security or performance. And like them, it costs ten times less when taken on from the start.

Need a WCAG/RGAA assessment of your Drupal site, or accessibility training for your team? Let’s talk.