Aller au contenu principal

Accessibilité

Pourquoi l'accessibilité ?​

  • Pour que toute personne puisse accéder et utiliser nos applications
  • 1.3 milliard (16%) des personnes dans le monde a une invalidité
  • Certaines personnes sont dépendantes d'une technologie assistée (lecteur d'écran, contrôle vocal, navigation clavier), d'autres d'un zoom ou d'une plus grande taille de texte
  • Handicaps/invalidités
    • Moteur (paraplégique, entorse,...)
    • Sensoriel : auditif, visuel (malvoyance, daltonisme,...)
    • Mental
    • Cognitif (dyslexie, autisme,...)
    • Psychique
  • Une invalidité peut être permanente (ex : surdité, malvoyance), temporaire (ex : bras cassé, infection à l'oreille), ou situationnelle
  • Outils d'accessibilité
    • Lecteur d'écran
      • Utilisé par les personnes malvoyantes
      • Tous les éléments à l'écran sont lus par le lecteur d'écran
      • Il est possible d'interagir avec le clavier ou des gestes
      • Lecteurs d'écran sur téléphone : sur Android "Talkback", sur iOS "VoiceOver"
    • Navigation clavier
      • "Tab" pour aller au prochain élément actif
      • "Shift + tab" pour aller au précédent élément actif
      • "Enter" pour soumettre un formulaire, appeler une action,...
      • D'où l'intérêt d'avoir un focus qui se fait, et dans l'ordre !
  • Les éléments sémantiques amènent un fonctionnel supplémentaire déjà fourni par le navigateur (ex avec le button)
  • Effet de bord positif de l'utilisation d'un HTML sémantique pour le SEO

Quelles règles/guidelines, et légalité​

"La directive européenne de 2016 exige la mise en accessibilité de tous les sites web publics au plus tard le 23 septembre 2020 (les sites publics créés après le 23 septembre 2018 devaient être accessibles au plus tard le 23 septembre 2019)."

  • WCAG : Web Content Accessibility Guidelines = guidelines internationales d'accessibilité créé par le W3C.
    • Le W3C est la gamme qui définit les standards, normes d'internet.
    • Trois niveaux du WCAG : A (le moins bon), AA (niveau minimum recommandé), AAA
    • 4 principes
      • Perceptible : chacun doit pouvoir percevoir l'information. Mettre des alternatives textuelles aux images, la couleur ne doit pas être seule porteuse d'information, contraste suffisant...
      • Utilisable : navigable avec un clavier ou lecteur d'écran, alternatives aux gestuelles
      • Compréhensible : lisible, prédictible, assistance sur les champs (communiquer les erreurs sur les formulaires,...)
      • Robuste : compatible avec une grande variété d'appareils et de technologies
  • ATAG : Authoring Tool Accessibility Guidelines
    • Guidelines pour les outils de création
    • c'est à dire tout ce qui permet à un utilisateur d'être auteur/créer du contenu, ça va du CMS, au réseau social
    • En résumé, l'outil qui va être utilisé doit permettre à l'auteur de créer un contenu accessible (exemple : Twitter doit pouvoir laisser la possibilité aux utilisateurs de renseigner un texte alternatif aux images)
  • RGAA - Référentiel Général d'Amélioration de l'Accessibilité, mis en place par le gouvernement français (le DINUM)
    • Se base sur les règles du WCAG 2.1. Trois niveaux comme pour le WCAG : A, AA et AAA
    • Obligations légales de conformité pour certaines entreprises (dont services de l'Etat, établissements publics,...). Depuis 2004, il s'applique aussi au secteur privé (entreprises dont le CA en France est supérieur à 250 millions d'euros)
    • 4 obligations : mention de la conformité en page d'accueil, déclaration d'accessibilité, lien vers la déclaration depuis toutes les pages, schéma pluriannuel d'accessibilité
      • Mention à afficher : "Accessibilité ... conforme" entre : non (pas d'audit ou audit < 50%) / partiellement (>50%) / totalement (= 100%)
      • La déclaration d'accessibilité doit mentionner : un état de conformité, un point de contact et une voie de recours juridique. Il y a un gabarit qui est imposé par la directive européenne.
      • Jusqu'à 20 000€ d'amende si non-respect de ces 4 obligations
  • Législation européenne
    • WAD (Web Accessibility Directive)
    • EN 201 549 : correspond aux guidelines du WCAG 2.1 AA (pour les organisations gouvernementales)
    • EAA (European Accessibility Act)

Fonctionnement du navigateur​

  • Les navigateur créent une version alternative du DOM, appelée "accessibility tree", qui est passée à l'OS de l'utilisateur pour les lecteurs à voix haute

En pratique​

  • Utiliser les media queries de préférence (exemple : prefers-reduced-motion pour les personnes qui préfèrent avoir moins de mouvements et d'animations sur leurs écrans)
  • Utilisation d'éléments HTML sémantiques
    • = moins de code à écrire, les role="" sont déjà renseignés, les tabindex sont déjà pris en compte, le style au focus est là par défaut, le navigateur amène du fonctionnel js supplémentaire (exemple le clic espace ou entrée), attribut disabled pris en compte sans js supplémentaire
  • Si pas possible (ou si info supplémentaire à apporter), utiliser les balises ARIA
    • ARIA = Accessible Rich Internet Applications ... => spec créée par le W3C => permet d'apporter des infos supplémentaires aux technologies assistantes (lecteur d'écran par ex)
    • Roles : landmark roles (main, header, footer, section), headings (h1-h6), widget roles (tabpanel, combobox, etc), live region role
    • aria-label

Listes d'éléments HTML non exhaustif​

  • Pour la structure de la page
    • Idéalement tous les éléments devraient être dans un élément de structure
    • <hgroup> : regroupe plusieurs headings <hx>
    • <article> : composition d'éléments (pas unique au rôle d'article au sens figuré - type blog post, on peut appeler <article> des commentaires également par ex). Un article est un indépendant, on vient plutôt présenter un fil structuré de contenu.
    • <section> : section générique, généralement avec un header. Les headings sont réinitialisés dans la section, on peut mettre un h1 dans une section sans se soucier de sa place dans le DOM. Une section forme une partie de qqchose (ex: un chapitre d'un livre)
    • <nav> : section qui liste des liens. Pas tous les groupes de liens ont besoin d'être dans <nav>, principalement la navigation majeure. Dans le footer pas besoin d'utiliser <nav>, footer suffit à lui seul.
    • main, aside, header, footer,...
  • Autre
    • listes : ol/ul => ne peuvent pas être des enfants de <p>
    • dl/dt/dd : liste d'association
    • em, strong, small
    • <s> : quand le contenu est déprécié (<del> si c'est une modif dans le document)
    • <address> pour les infos de contact (ex : auteurs d'un article, email, adresse postale,...)
    • <cite> : titre d'un travail (livre, essai, film,...)
    • quotes : <q>
    • dfn : definition, souvent d'une abbréviation : <abbr>
    • kbd : user input (exemple : "appuyer sur <kbd>F3</kbd>")

En tant qu'UX/UI​

  • Annoter les alt dans les maquettes (+ ne pas oublier que les testeurs devraient tester les alt). S'il y a un label à côté qui décrit le picto pas besoin, l'icône est uniquement décorative.
  • Annoter les sr-only (ex: ce qui se cache derrière un "i" avec popin)

Accessibilité et écriture inclusive​

Rétrocompat​

  • Répéter les role sur des balises qui contiennent déjà des rôles (ex : <main role="main">) permet d'assurer la rétrocompat RGAA 4

Sources​

Dernière mise à jour le