Just as with eco-design, Drupal isn't a "magic bullet" that guarantees compliance with a single click. It provides a powerful and pre-optimized technical foundation, but RGAA compliance is achieved through a comprehensive, cross-cutting approach: rigorous configuration, semantic theming (front-end), and strict discipline in content contribution. The Drupal Accessibility Initiative (A11Y) is central to the community, meaning that Drupal's core is designed to comply with international standards (WCAG), of which RGAA is the French version. Here's how to reconcile Drupal and RGAA V4 at each stage of your project.

The Drupal foundation (core and administration)

The good news is that Drupal (versions 9 and 10+) does a lot of the work for you, especially on the back end.

Claro Administration Theme: The default administration theme, Claro, was designed to comply with WCAG 2.1 AA standards. This is also true for the Gin theme, which was a community theme that was integrated into the core due to its popularity. It is the leading administration theme in the community today and undergoes regular accessibility audits.

This means that the contributors' work tools are themselves accessible (keyboard navigation, contrast, semantics). This is an essential prerequisite, as accessibility concerns not only website visitors but also the staff of organizations.

Olivero Front-End Theme: The default front-end theme, Olivero, is also designed with accessibility as a priority. It natively supports high contrast, keyboard navigation, and semantic structure.

Rendering API: Drupal's APIs (Render API, Form API) generate semantic HTML by default. For example, forms generated by Drupal natively include the necessary `<label for="...">`, `<fieldset>`, and `<legend>` tags.

Front-end theme and UX/UI design

Contrary to popular belief, digital accessibility isn't just about design. The front-end theme incorporates most of the RGAA's graphic and technical criteria. A custom theme must integrate accessibility from the very first line of code.

HTML Semantics (Criteria 8 & 9)

Drupal (Twig) technique: This is the core of the work. You must override the Twig templates (.html.twig) to use semantic HTML tags. Don't use <div> tags for everything.

• page.html.twig: Must contain <header>, <nav>, <main>, and <footer>.
• node.html.twig: Must contain the <article> tag.
• block.html.twig: A navigation block must be enclosed within a <nav> tag.

The core provides examples that can serve as models for best practices.

Heading hierarchy (<h1>, <h2>...): The theme must guarantee only one <h1> per page (generally the title of the main content). Block and view titles must follow a logical hierarchy.

Keyboard Navigation (Criterion 12)

CSS Technique: All interactive elements (links, buttons, fields) must have a visible and contrasting :focus state. Never remove the outline (outline: none;) without providing an alternative (e.g., box-shadow).

Front-end (JS) Technique: For complex components (sliders, tabs, modals), you must manage focus manually using JavaScript (trap it in the modal, move it within the tabs using the arrow keys).

ARIA (Criterion 7)

Drupal Technique (JS/Twig): Use ARIA (Accessible Rich Internet Applications) attributes for dynamic components. Drupal facilitates this through its drupalSettings system and the *.libraries.yml files.

Colors and Contrast (Criterion 3)

UX/UI Technique: This point is addressed from the initial design phase of the graphic charter. The colors chosen for text and backgrounds must respect contrast ratios (4.5:1 for normal text). Tools like "Contrast Checker" are useful for testing contrasts.

Example link title: ‘Download the report (PDF - 1.2 MB)’

Content contribution and management

A technically compliant website can be rendered inaccessible by its contributors. Drupal must be configured to guide and constrain them.

Image alternatives (Criterion 1): This is a crucial point. (See the section "Managing image alternatives" below).

Heading Hierarchy (Criterion 9) - Drupal Technique (CKEditor 5): Configure the text editor to allow only semantic styles. Disable the choice of color and font size (which should be managed by CSS) and limit headings to Heading 2, Heading 3, etc. (Heading 1 being managed by the theme).

Explicit Links (Criterion 6) - Drupal Technique (CKEditor 5): Train teams not to use "Click here" links. The link text must be explicit. CKEditor's link editor allows you to add a "Title" (title attribute) to provide more context, which is a good practice.

Downloadable documents (Criterion 13) - Drupal (Twig) technology: The RGAA requires that the format, size, and language of the files be indicated. Configure the display of the "File" field (field--file.html.twig) to automatically add this information next to the link.

Ecosystem (Modules “Contrib”) and audit

Auditing contribution modules: Before adding a module (a slider, a complex form, a data visualization), check its accessibility level. Look in the module's issue queue on drupal.org for the keywords "accessibility" or "a11y".

"High-risk" modules: Beware of modules that generate a lot of front-end JavaScript (e.g., sliders, complex galleries).

Useful Modules:

• Views (Core): Very user-friendly, as it generates HTML that you fully control via Twig templates.
• Webform: Extremely powerful and very well configured for accessibility (good handling of labels, fieldsets, and errors).
• CKEditor Accessibility Auditor: Can be added to CKEditor to audit content before publication.

Manage image alternatives (Criterion 1)

The RGAA (General Accessibility Guidelines for Administrations) stipulates that any image containing information must have alternative text (alt). Any decorative image must have an empty alt attribute (alt="").

By default, the "Image" field in Drupal requires alternative text. How can a contributor be allowed to mark it as decorative?

Technical solution

Edit the image field:

• Go to Structure > Content Types > [Your type] > Manage fields.
• Edit your "Image" field.
• Uncheck the "Alternative text required" box.
• Check the "Show 'Alternative text' field" box (it will remain visible).

Add a "Decorative Image" field:

• On the same content type, add a new Boolean field (checkbox).
• Name it "Decorative Image" (field_image_decorative).
• Configure its display to appear directly below the image's alt text field.
• Optionally, use a module like conditional_field or custom code to hide the alt text field based on the checkbox's value to ensure a smooth user experience.

Logic in Twig:

• Override the Twig template of your image field (e.g., field--field-image.html.twig) or of the image itself (image.html.twig).
• Add logic to force an empty alt attribute if the checkbox is selected.

Result: The contributor has a clear choice. If they don't select "Decorative Image," the alt field (which they will have filled in) will be used. If they select it, the alt="" attribute will be generated, ensuring compliance.

Avoidance links and semantics (Criterion 12.7)

The RGAA requires skip links to allow keyboard users to skip repetitive blocks (such as the main menu or header).

The technical solution (theme):

In page.html.twig: Place these links at the very top of your <body> element. They target the IDs of the main areas of your page.
The essential CSS: These links should be invisible by default, but become visible when they receive focus (via the Tab key).
CSS

Result: The first press of "Tab" upon arriving on the page reveals these links, allowing the user to jump directly to the content.

Conclusion

Digital accessibility is not an option, nor even a regulatory requirement; it's an essential aspect of your website's quality. It enhances user experience, improves SEO, and empowers people with disabilities to gain greater independence in their daily lives by fully utilizing your online services. This translates to a potential 15 to 20% increase in users and visitors able to browse or shop on your site.
If you have questions about the accessibility of your Drupal site or are considering a redesign, contact Smile to audit, design, or develop your site to ensure the highest level of compliance with the RGAA (General Accessibility Guidelines for Administrations).
We possess comprehensive expertise across the entire digital accessibility value chain and offer our Sobki installation profile, developed by our R&D team to precisely meet these requirements from the initial architecture phase, based on the principle of accessibility by design.