Aller au contenu principal

Accessibilité RGAA avec Ruby on Rails : le guide

Ruby on Rails est le framework full-stack historique de Ruby, utilisé par GitHub, Shopify, Basecamp et de nombreuses applications SaaS. Avec l'arrivée de Hotwire (Turbo + Stimulus), Rails a modernisé sa stack front-end tout en restant server-rendered. Cette approche est généralement favorable à l'accessibilité. Ce guide couvre Rails 7 et 8, les patterns ERB accessibles, Turbo navigation et Stimulus controllers conformes RGAA.

Rails et l'accessibilité server-side

Le server-side rendering de Rails bénéficie naturellement à l'accessibilité : HTML complet à la première requête, lisible immédiatement par les lecteurs d'écran, sans dépendre d'hydratation. Turbo Drive et Turbo Frames ajoutent de l'interactivité sans compromettre la sémantique de base, à condition de gérer correctement le focus.

3M+

Applications Rails actives

15%+

Part des apps SaaS

Yes

Shopify runs on Rails

En Bref : L'essentiel à retenir

  • Framework : Ruby on Rails nécessite une attention particulière à la sémantique HTML.
  • Point Critique : Gestion du focus lors de la navigation dynamique.
  • Outil Recommandé : simple_form.
  • Critères RGAA clés : 7.1, 8.9, 11.1.

Erreurs Fréquentes avec Ruby on Rails

form_with sans labels

Le helper form_with génère des inputs mais pas les labels associés automatiquement. Il faut explicitement utiliser form.label.

À éviter
<%= form.text_field :email %>
Bonne pratique
<%= form.label :email %><%= form.text_field :email %>

link_to avec icône sans texte

Les link_to contenant juste une icône FontAwesome ou SVG n'ont pas de texte accessible.

À éviter
<%= link_to '<i class="fa fa-edit"></i>'.html_safe, edit_path %>
Bonne pratique
<%= link_to edit_path, aria: { label: "Modifier" } do %><i class="fa fa-edit" aria-hidden="true"></i><% end %>

Turbo Stream sans annonce

Les mises à jour Turbo Stream modifient le DOM sans annoncer le changement aux lecteurs d'écran. Une aria-live region est nécessaire.

Turbo navigation focus perdu

Turbo Drive remplace le body entre pages mais ne déplace pas le focus. L'utilisateur clavier reste « en place ».

Flash messages non annoncés

Les flash messages Rails sont rendus dans le layout mais sans aria-live, ils ne sont pas annoncés aux lecteurs d'écran.

À éviter
<%= flash[:notice] %>
Bonne pratique
<div role="status" aria-live="polite"><%= flash[:notice] %></div>

Bonnes Pratiques Ruby on Rails

Layout application.html.erb structuré

Utilisez header, main, nav, footer dans le layout global. Ajoutez un skip link en début de body, visible au focus.

Form helpers avec labels

Toujours utiliser form.label avant chaque input. Considérez simple_form gem qui génère automatiquement les labels corrects.

Turbo frame avec focus management

Ajoutez des Stimulus controllers qui écoutent turbo:frame-load pour déplacer le focus sur le contenu mis à jour.

aria-live pour Turbo Streams

Créez une region <div id="flash" aria-live="polite"></div> dans le layout et ciblez-la depuis les turbo_stream actions.

simple_form + accessible-dropdown-rails

Utilisez des gems reconnues pour générer des formulaires et composants accessibles par défaut.

Critères RGAA clés pour Ruby on Rails

Ces critères du référentiel RGAA sont particulièrement importants pour les sites Ruby on Rails.

7.1

Scripts

Turbo Drive et Streams avec gestion focus et annonces

8.9

Landmarks

application.html.erb avec header, main, footer

11.1

Étiquetage

form.label systématique sur chaque input

12.7

Lien d'évitement

Skip link dans application.html.erb

13.2

Nouvelles fenêtres

link_to target: '_blank' avec aria-label et rel noopener

Checklist accessibilité Ruby on Rails

Vérifiez ces points essentiels avant de mettre votre site Ruby on Rails en production.

  • application.html.erb avec landmarks HTML5
  • Skip link en début de body
  • form.label avant chaque input
  • Flash messages dans div role="status"
  • Turbo Streams avec aria-live region
  • Stimulus controller focus management
  • link_to avec texte ou aria-label
  • simple_form ou helpers a11y
  • ESLint/Rubocop avec règles a11y
  • Tests system avec axe-rspec

Questions Fréquentes sur Ruby on Rails et l'accessibilité

Rails est-il bien adapté à l'accessibilité ?

Oui. Le SSR Rails est naturellement favorable : HTML complet à la première requête, lisible par les lecteurs d'écran sans dépendre de JS. Les enjeux modernes sont liés à Turbo et Stimulus, gérables avec discipline.

Comment gérer Turbo navigation pour l'accessibilité ?

Utilisez les événements turbo:load et turbo:frame-load dans un Stimulus controller global qui déplace le focus sur l'élément main ou un h1 cible. N'oubliez pas tabindex="-1" pour que l'élément soit focusable.

simple_form ou form_with pour les formulaires accessibles ?

simple_form génère automatiquement les labels, wrappers et messages d'erreur, ce qui réduit les erreurs. form_with reste utilisable mais demande plus de discipline pour ne pas oublier les labels.

Auditez votre site Ruby on Rails gratuitement

Vérifiez si votre application respecte les 106 critères RGAA en moins de 30 secondes.

Lancer un audit RGAA gratuit