Guide de développeur Drupal 8 pour l'Accessibilité web ARIA

28 May 2018

Contenu

  • C’est quoi l’Accessibilité web ?
  • L’Accessibilité sur Drupal 8
  • Les bonnes pratiques
  • Outils D’audite pour Accessibilité

C’est quoi l’Accessibilité web ?

L’Accessibilité web est un ensemble de bonnes pratiques, pour les développeurs et designers à mettre en place, dans le but de créer des sites web de haute qualité sans exclure les personnes âgées ou ayant des difficultés à utiliser, comprendre ou meme naviguer sur le web. Quels que soient leurs supports d’accès (desktop, mobile etc.).

L’Accessibilité sur Drupal 8

Les développeurs du core Drupal ont mis de très grands efforts afin d'intégrer l’accessibilité dans leurs écosystèmes, en introduisant l’internationalisation, Formes API, jquery UI ainsi incluant les bonnes pratiques ARIA sur le thème par défaut Batrik, qui respecte parfaitement les bonnes pratiques d’accessibilité. Les modules de contribution ne respectent pas les règles d’accessibilité, le markup généré et la gestion d’erreur, dont les modules ne sont quasiment pas accessibles .

Les bonnes pratiques

Pour les développeurs back-end :

  • Utiliser hook_form_alter pour ajouter les tags aria aux
  • Changer ou supprimer le message des liens “read more” sur les teasers des nodes á l’aide de hook_link_alter .
  • Ajouter les attributs Aria aux blocs, grace au module Block ARIA Landmark rôles.
  • Fournir aux utilisateurs un outil qui leur permettra de changer la taille de texte , á l’aide du module Text Resize.
  • Utiliser Drupal.announce() pour notifier les utilisateurs avec les “Lecteurs d’Ecrans” les changements faits sur la page en AJAX ou JS .
  • Éviter le Captcha le plus possible .
  • Ajouter un alt texte pour les images avec un texte qui décrit l’image .
  • Améliorer l’affichage des messages d’erreurs , par exemple:
    • Le champs Nom est incorrecte
    • Le champs Nom doit contenir des lettres uniquement
       

Pour les développeurs front-end :

  • Associer un label avec tout élément de form (input,select, textarea …).ex: <label for="male">Male</label> <input id="male" name="gender" type="radio" value="male" />
  • Identifier la langue de la page , spécifiquement pour les sites
  • Mettre en place les attributs aria sur les non-standard éléments, ( Slider , caroussel , list block).Ex : role=&amp;quot;menuItem&amp;quot; (Pour le menu item ) aria-checked=&amp;quot;true&amp;quot; (pour les formulaires , checkbox par exemple) aria-disabled=&amp;quot;false&amp;quot; (pour les formulaires , button par exemple) aria-expanded=&amp;quot;true&amp;quot; (ex : toggle menu) aria-labelledby=&amp;quot;label&amp;quot; (pour les formulaires , sections ,blocks) aria-describedby=&amp;quot;idDedescirption&amp;quot; (tout les elements) aria-required=&amp;quot;true &amp;quot; (pour les formulaires) aria-hidden=&amp;quot;true&amp;quot; (tout les elements) aria-current=&amp;quot;page&amp;quot; (lien de navigation) aria-pressed=&amp;quot;true&amp;quot; (button pressed) Les rôles ARIA sont quatre role (accessible via le module block area comme mentioné en haut ), pensez à ces rôles comme des global role :

    1. Landmark : identifier les zones larges de contenu ; il facilite la navigation pour les lecteurs d’ecran . Si landmark est utilisé, il faut que tout le contenu dessous soit prêt pour la navigation . Ex :

    <footer role="contentinfo">&nbsp;</footer>Les rôles possibles : banner, complementary, contentinfo, form, main, navigation, region, search.

     

    2. Document : se sont les rôles qui organisent le contenu sur la page , généralement ne sont pas des contenus intéractifs. Les rôles possibles : application, article, cell, columnheader, definition, directory, document, feed, figure, group, heading, img, list, listitem, math, none, note, presentation, row, rowgroup, rowheader, separator, table, term, toolbar, tooltip.

    3. Widget : se sont les blocks ou les éléments interactifs sur la page, généralement des petits block , comme derniers articles ... Les rôles possibles : button, checkbox, gridcell, link, menuitem, menuitem checkbox, menuitem radio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem.

    4. Abstract : Les rôles abstraits sont uniquement utilisés par les navigateurs pour organiser et rationaliser un document, et jamais par les développeurs pour baliser le code HTML. Ils ne sont pas mappés sur les lecteurs d'écran et ne fournissent aucune information d'accessibilité supplémentaire directement entre HTML et le lecteur d'écran.

  • Assurer que tout les éléments interactifs sont accessibles par clavier.
    • La touche ESC doit quitter le model ou popup.
    • La touche Tabulation doit changer dans un ordre cohérent le focus entre les liens et éléments interactive JS.
    • Le model de Datepicket doit également permettre a l'utilisateur de saisi la date manuellement.
    • Tout les interaction JS (Ajax) doit etre lu par les lecteurs d'ecran.
    • éviter le max possible les évènements suivantes: ondblclick,onmousedown,onmouseup,onfocus,onblur tant qu'ils n'ont accessible par clavier ou lecteur d'ecran .
  • L’augmentation de la taille de texte ne doit pas impacter les autres éléments .
  • Fournir aux utilisateurs la possiblité de “Skip content”, passer d’un block vers un autre (Header, navigation, footer, newsletter…).
  • Éviter le plus possible l’utilisation de display: none en dure, et remplacer là par aria-hidden Ex: <div class="text"><label for="first" id="tp1-label">First Name:</label></div> <div aria-hidden="true" class="tooltip" id="tp1" role="tooltip">&nbsp;</div>Your first name is optional Et en css : ( n'est pas supporter sur IE9) :
    • div[aria-hidden="true"] {display:none;}
    • div[aria-hidden="false"] {display:block;}

 

Rédigé par: A.S