Accessibilité, je t'emmènerai jusqu'au bout du back

Sommaire

1. Une petite diapo sur le front-office (plutôt design)
2. Un tour dans le back-office
   1. Le back-office de WordPress natif
   2. 2 extensions de renom : ACF et Polylang (un peu front et beaucoup back)
3. Les extensions de formulaires (front et back)

[FO] Un design pensé accessible en amont

Un petit tour dans le back-office

« Mais non, on s’en fiche de l’accessibilité, c’est du back-office ! »

[BO WordPress] Les menus

Onglets, accordéons, colonnes... Facile quand on voit !

[BO WordPress] Les widgets

Une option "Accessibilité" bien cachée...

Sinon, il y a aussi la solution "Customizer" (Merci Gaël Poupard !) : Menu > Apparence > Personnaliser

[BO WordPress] La contribution de contenu

1. TinyMCE : « Moi d'abord ! »
2. Permalien : « ... »

[BO WordPress] Les médias

Au clavier, soyez patient...

[Extensions WP] ACF - Advanced Custom Fields

[Extensions WP] Polylang, dans le BO

“Don't hesitate to report other accessibility issues that you may discover. You can use GitHub to be sure that I will not miss it.”

Chouby, Polylang

Merci ! Coeur

[Extensions WP] Polylang, dans le FO

Libre de produire le code le plus accessible possible

<p>Langue</p>
<ul aria-label="Langue">
  <li class="current-lang">
    <a href="http://www.braillenet.org/" hreflang="fr" title="Français (langue actuelle)" lang="fr">
      <span aria-hidden="true">fr</span>
      <span class="screen-reader-text">Français</span>
      <span class="screen-reader-text">(langue actuelle)</span>
    </a>
  </li>
  <li>
    <a href="http://www.braillenet.org/en/" hreflang="en" title="English" lang="en">
      <span aria-hidden="true">en</span>
      <span class="screen-reader-text">English</span>
    </a>
  </li>
</ul>

Les formulaires : front et back, un champ de bataille

Un formulaire accessible en front, c’est quoi (a minima) ?

• tous les champs ont une étiquette (généralement <label>)
• les groupes de champs sont regroupés correctement (<fieldset> + <legend>)
• messages d'erreur attachés à leur champ (aria-describedby="ID-du-message")
• message d'erreur global sous forme d'alerte (role="alert")

L'excellent guide de l'intégrateur pour des formulaires accessibles : https://disic.github.io/guide-integrateur/6-formulaires.html

Les formulaires : la folie des extensions

Les formulaires : Gravity forms, extension de rêve ? Le FO

La dernière possibilité : Gravity forms...
jamais sans son WCAG 2.0 form fields for Gravity Forms

• Des <fieldset> + <legend> !
• Un message d'erreur global avec role="alert" en haut du formulaire avec ancres
• Mais : messages d'erreur individuels non rattachés à leur champ

Les formulaires : Gravity forms, extension de rêve ? Le BO

Plongée en apnée dans le code source

<a href="#" onclick="return false;" onkeypress="return false;" class="gf_tooltip tooltip_bottomleft tooltip_form_standard_fields" title="<h6>Champs standards</h6>Les champs standards fournissent les fonctionnalités d’un formulaire de base."><i class="fa fa-question-circle"></i></a>

<a class="" onclick="DuplicateForm(2);return false;" onkeypress="DuplicateForm(2);return false;" title="Dupliquer ce formulaire" href="#" target=""> Dupliquer</a>

Conclusion

WordPress et ses extensions sont encore loin d'être parfaits pour l'accessibilité mais ça progresse.

Quelques pistes :

• Créer des tickets pour WordPress
• Rejoindre la communauté accessibilité de WordPress
• Créer des tickets aux développeur·euse·s d'extensions en leur donnant des pistes de solution et en expliquant les impacts utilisateurs
• Ouvrir sa plateforme de gestion de tickets pour favoriser le suivi et la contribution (même si votre extension n'est pas open source)
• Respecter les standards de WordPress