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

Retour d'expérience sur la refonte du site de BrailleNet, avec du WordPress dedans

par Julie Moynat

Capgemini Creative Studio

Paris Web

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

Page d'accueil de BrailleNet.org montrant l'effet au survol (mais pas au focus) d'une actualité : une couleur se place par dessus le contenu

La refonte de BrailleNet.org

  • Simplicité
  • Contraste des couleurs
  • Échanges designer / intégratrice

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 !

Écran de contribution des menus dans WordPress

[BO WordPress] Les widgets

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

Écran de contribution des widgets dans WordPress

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 : « ... »

Écran de contribution d'un article dans WordPress

[BO WordPress] Les médias

Au clavier, soyez patient...

Écran d'ajout de médias dans un article WordPress

[Extensions WP] ACF - Advanced Custom Fields

Le répéteur d'ACF : seulement au survol

Téléchargement de fichier dans ACF : pas d'intitulé dans les boutons / liens

ACF, c'est génial.
Sauf dans le BO

  • Groupes de champs : où sont passés les fieldset ? : reprendre le libellé du groupe dans chaque label
  • Éléments qui ne s'affichent qu'au survol : les afficher tout le temps (CSS)
  • Liens et boutons sans intitulés : insérer un intitulé en JS

[Extensions WP] Polylang, dans le BO

Bouton de filtre des langues Polylang dans le back-office WordPress

“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

En-tête du site de BrailleNet avec le changement de langues


<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

J'ai testé :

J'ai vu dans le FO :

  • aucun ne gère les <fieldset> + <legend>
  • un seul attache les messages d'erreur à ses champs (Caldera forms)
  • des messages d'erreur à la volée (Ninja forms)
  • des champs sans <label> (Form maker by WD)

J'ai vu dans le BO :

  • non-respect des standards WordPress pour le BO
  • du "glisser / déposer" presque partout
  • des pseudo "boutons" inatteignables au clavier
  • des "boutons" / "liens" sans intitulé
  • paramétrage en mode formulaire sans <label> (Formidable forms)

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>

Option bricolage JS et CSS

  • pièges au clavier : supprimer les attributs onkeypress en JS
  • "liens" sans href : ajouter un href="#" en JS
  • boutons s'affichant au survol : les afficher tout le temps (CSS)
    Écran de modification d'un formulaire avec Gravity forms
  • accordéons non dépliables au clavier : les ouvrir tout le temps (et supprimer la position fixe) (CSS)
  • liens sans intitulé : ils ont un attribut title qui limite un peu la casse...
  • glisser / déposer : se faire accompagner... Émoticône triste

Conclusion

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

Quelques pistes :

Merci !

Pour retrouver les slides de cette conférence :
http://parisweb2017-accessibilite-bo.juliemoynat.fr

Informations complémentaires et vidéo

Transcription textuelle de la conférence

Des questions, envie d'échanger sur le sujet :
@juliemoynat

  • Merci à Paris Web et Carine Reignault, BrailleNet et Alex Bernier, Capgemini Nantes
  • Diaporama réalisé avec le génialissime outil Accesslide par Access42
  • Magnifiques photos d'illustration réalisées par moi-même Émoticône souriant (© Julie Moynat)