Jump to content

Guide d'accessibilité pour les développeurs

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 70% complete.
Languages:

L’accessibilité est importante pour nos utilisateurs et nous pouvons l’améliorer si nous prenons en compte quelques idées et règles de base. L’accessibilité est difficile dans la mesure où il n’existe pas de normes techniques fixes et universellement acceptées qui fonctionnent réellement de manière cohérente et pour tous les utilisateurs. Cette page ne répertorie ni ne discute des problèmes d’accessibilité spécifiques dans MediaWiki. Elle tente de se concentrer sur les choix technologiques et les choses à faire et à ne pas faire pour éviter les problèmes d’accessibilité.

En termes de développement, je pense que ceci devrait être notre livre de règles :

  • Essayez d’activer nos utilisateurs (et cela signifie tous).
  • Essayez de contourner les problèmes d’accessibilité si cela est possible, mais pas à tout prix.
  • Nous devrions utiliser une approche d’amélioration progressive plutôt que de tolérance aux pannes.
  • Mettre en œuvre des choses qui sont technologiquement solides.

Fonctionnement de l'accessibilité

Quelques concepts importants que vous devez garder à l’esprit.

Des mesures d’accessibilité sous de nombreuses formes

L’accessibilité concerne une variété de choses, veuillez considérer ce qui suit :

  • Quelque chose doit être compréhensible : c’est-à-dire textuellement, visuellement, logiquement et en complexité.
  • Certains utilisateurs ont besoin d'un lecteur d'écran pour interagir, mais d'autres ont tout autant, sinon plus besoin: d'une loupe, d'un contraste plus élevé, d'un moteur de synthèse vocale, de paramètres CSS personnalisés ou d'un type particulier de clavier/d'appareil de saisie.
  • Il doit être accessible ; la réactivité, l’abordabilité, l’emplacement, la langue, le matériel, etc.

En résumé, l’accessibilité n’est pas seulement l’accessibilité du clavier, ou seulement l’accessibilité du lecteur d’écran. Nous nous concentrons souvent sur ces deux, car ils sont facilement négligés traditionnellement. Mais ces problèmes peuvent également être résolus et constituent souvent la base de tout autre type d’améliorations possibles.

Certains problèmes d’accessibilité ont tendance à être des problèmes de conception de produits, de choix stratégiques, de public cible, etc. Comme ces domaines sont plus difficiles à saisir dans des règles écrites qui s’appliquent universellement à l’écosystème MediaWiki, ils sortent du cadre de ce document.

C’est ce que nous appelons la navigation au clavier, mais ce que cela signifie vraiment, c’est : ne vous fiez pas à un dispositif de pointage (tactile, souris).

  • La navigation au clavier consiste à manipuler le focus et à exécuter des actions avec votre clavier.
  • Les éléments qui sont tabulables sont focalisables, mais tout ce qui est focalisable n'est pas tabulable.
  • Tout ce que vous pouvez faire avec une souris devrait être possible avec un clavier.
  • Les informations relatives à la navigation au clavier peuvent être utilisées par les lecteurs d'écran pour améliorer leur expérience.

Pour les lecteurs

  • Un lecteur d'écran utilise un 'curseur' différent, qui parcourt habituellement la structure logique du DOM (Document Object Model).
  • Le focus tend à suivre le curseur du lecteur d'écran et réciproquement mais ce sont deux choses différentes.
    • Vous pouvez garder la trace de l'élément ciblé en définissant une expression en direct dans Chrome [1]
  • Un lecteur d'écran utilise les APIs d' 'accessibilité', que vous pouvez considérer comme étant la vue d'entrée / sortie par dessus le DOM initial.
  • ARIA sont des annotations DOM qui étendent ou orientent la manière dont la logique DOM est modifiée dans les APIs d'accessibilité. Ce n'est pas une alternative à la réécriture d'un nouveau code HTML et JavaScript. La navigation au clavier se fait simplement dans l'ordre logique du DOM ! Pour en savoir plus sur ARIA voir les explications sur w3.org et sur MDN.
  • Un lecteur d'écran n'est pas limité à la navigation dans la structure logique du DOM, mais c'est le fonctionnement par défaut.
    • Un lecteur d'écran peut lire par exemple ce qui se trouve sous le pointeur de la souris.
    • VoiceOver pour iOS utilise un curseur d'écran dirigé par le positionnement du pouce et les mouvements sur l'écran tactile.
    • La plupart des logiciels lecteurs d'écran possèdent des modes de navigation supplémentaires, où vous pouvez lister et naviguer parmi des zones prédéfinies, ou par un sommaire auto-généré, ou encore à l'aide de 'signets' utilisateur définis à l'intérieur d'une page.
  • Du point ci-dessus des méthodes de navigation multiples, suit : Il y a un début et une fin, mais aussi la gauche, la droite, le haut et le bas. Vous ne devez pas trop compter sur eux dans votre communication, mais vous ne devez pas non plus nier complètement leur existence. Ne confondez pas les capacités visuelles de l'utilisateur avec la conscience spatiale que le lecteur d'écran pourrait être en mesure de lui transmettre. Exemple :
    1. Une longue phrase [image] l’image ci-dessus montre... Still acceptable
    2. une longue phrase [image][image] l’image de gauche montre, l’image de droite montre... Still acceptable
    3. une longue phrase [image][image] l’image de droite montre, l’image de gauche montre... Not acceptable
    4. Une longue phrase [image][image] l’image ci-dessus montre... Not acceptable
    5. une longue phrase [image][image][image] l’image de gauche montre, l’image de droite montre... Not acceptable
    6. une longue phrase [image][image] quelque chose de totalement différent. l’image de gauche montre, l’image de droite montre... Definitely not acceptable

Règles du développement

Il existe plusieurs normes en matière d'accessibilité et, honnêtement, la plupart d'entre elles, bien qu'elles permettent d'identifier les problèmes, présentent des lacunes importantes en ce qui concerne les solutions techniques (elles présentent un taux élevé de "solutions de rechange laides"). Cela a suscité une grande controverse au sein des communautés. En tant que tel, nous devrions identifier les choses non controversées que nous devrions simplement toujours (ou jamais) faire et pourquoi. Il est beaucoup plus facile d'atteindre certains objectifs si nous séparons les éléments non controversés des éléments controversés.

Utiliser ou fournir toujours

Élément HTML sémantique approprié
Utilisez les éléments HTML conformément à leur finalité. Par exemple :
  • Utilisez ‎<button> et non ‎<div> ou ‎<span> ou ‎<a> avec un gestionnaire de clics
  • Si vous ressentez le besoin de mettre quelque chose en gras, demandez-vous s’il n’est pas plus approprié d’utiliser un en-tête ou un élément strong
Structure logique de la rubrique
Toutes les pages doivent toujours avoir une structure de titre logique et cohérente. Les titres sont l'un des principaux outils de navigation utilisés par les utilisateurs de lecteurs d'écran.
  1. Il ne devrait pas y avoir de lacunes dans la mise en place des niveaux de rubrique. (Donc, pas de 1 $.)
  2. Les titres doivent être descriptifs
  3. Les titres doivent être uniques à leur propre niveau. (Il ne devrait pas y avoir deux H3 avec le même contenu sous la même section H2)
  4. Il devrait y avoir des une séparation entre la navigation et le contenu
alt attribut pour les images avec des valeurs significatives
Si une image est décorative, utilisez une valeur vide explicite pour l'attribut alt ; mieux encore, transformez-la en image de fond CSS.
L’alt image est généralement prioritaire sur l’attribut title des images et même sur l’attribut title des liens qui enveloppent une image.
title pour les liens
Elles sont généralement affichées sous forme d'infobulles
N’utilisez des titres que s’ils diffèrent du texte du lien.
La plupart des titres de liens ne sont pas réellement prononcés par les lecteurs d’écran, à moins que le lecteur d’écran n’ait été explicitement configuré de cette façon.
Attributs lang, dir et hreflang
L’utilisation de lang et hreflang permet de sélectionner une voix appropriée dans les lecteurs d’écran, de choisir la bonne correction orthographique dans les navigateurs, etc.
Contraste suffisant
Vérifiez vos couleurs pour suffisante de contrastées. Pour le texte, un contraste plus élevé est nécessaire pour un texte plus petit (en raison de l’anticrénelage).
Mise au point pour la navigation au clavier
Faites pas enleves le contour à partir d’éléments activables, sauf si vous définissez votre propre contour pour l’état :focus.
  • N’utilisez pas outline: 0 sinon.
  • Si vous définissez une pseudo-classe, comme :hover ou :active, veuillez également définir un style :focus.
Navigation au clavier
Les éléments interactifs d’une page devrait être navigables par un clavier. Assurez-vous que la navigation par tabulation est activée dans votre navigateur et qu’elle vous permet de contrôler chaque élément interactif sans utiliser de dispositif de pointage.
  1. Utilisez tabIndex: 0 pour rendre les éléments accessibles au clavier, qui ne sont pas accessibles au clavier implicitement (tout sauf ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. Dans ce cas, ajoutez également un gestionnaire de touches répondant à Entrée (keyCode 13) et espace (keyCode 32)
  2. Utilisez tabindex: -1 pour supprimer des éléments de l’accessibilité. (utilisez ceci sur les liens qui sont des étiquettes pour l’action à l’intérieur d’un ‎<li>...‎</li> par exemple)
  3. Les éléments qui sont implicitement accessibles au clavier transmettra la touche entrée/espace vers le bas au gestionnaire de clics
Dialogues, etc.

Lorsque l'accessibilité n'est pas bien prise en compte, les dialogues sont parmi les éléments les plus inaccessibles pour les utilisateurs de lecteurs d'écran et de claviers. Passez un peu de temps là-dessus.

  • L’élément qui ouvre la boîte de dialogue doit avoir aria-haspopup
  • La boîte de dialogue elle-même devrait avoir role=[dialog | alertdialog | tooltip]
  • La boîte de dialogue doit être insérée dans l'ordre DOM, [1] ou aria ont besoin de spécifier cette relation entre l'élément d'ouverture et la boîte de dialogue.
  • Lors de l’ouverture de dialogue, mémorisez le dernier élément concentré et décaler le focus sur le premier élément focusable tabbable à l’intérieur de la dialogue
  • Lorsque le dialogue est modal, empêchez l'interaction avec le reste de la page
    • Capturez les clics en dehors de la dialogue et ignorez-les ou laissez-les congédier la dialogue
    • Assurez-vous que vous ne pouvez pas tabuler vers des liens ou des éléments d’entrée en dehors de dialogue
    • Rendre les éléments en dehors de dialogue inaccessibles pour le lecteur d’écran, en utilisant aria-hidden
  • Assurez-vous qu’il existe un mode de fermeture (touche Échap et un bouton de fermeture activable avec un titre descriptif)
  • La fermeture devrait ramener le (clavier) focus au point AF d’origine que vous avez enregistré lors de l’ouverture de la boîte de dialogue. Pour que les lecteurs d’écran reviennent au même point, assurez-vous de spécifier le droit propriétaire de la dialogue, si vous n’avez pas inséré de la dialogue dans l’ordre DOM.
  • Lisez : Modaux Aria, dialogue modale Aria, dialogue non modale ARIA, infobulles ARIA.
WCAG 2.1 Lignes directrices
Suivez partout où possible.
Et ses documents d'accompagnement:

À ne pas faire

  • Il y a conseil commun d'utiliser left: -1000px pour pousser quelque chose (souvent les étiquettes des boutons d'icône) hors du point de vue pour les utilisateurs visuels et de le garder dans le DOM d'accessibilité. text-indent: -9999px est une variante de ceci. C'est un mauvais conseil.
    • Cela casse notre rendu RTL dans plusieurs navigateurs. Plus précisément, en mode rtl, il crée un grand canevas à gauche de la fenêtre et des barres de défilement, tout comme +1000px le créerait en mode ltr. (Le cas échéant, top: -1000px est préféré à left: -1000px pour éviter cela.).
    • VoiceOver sur mobile ne peut pas utiliser ce texte comme une rétroaction, car il s'agit d'un lecteur d'écran "positionnel". You cannot move your finger over this text and thus the text will not be read either. (aria-label is often the better choice).
    • Enfin, cela élargit la surface de rendu nécessaire pour calculer la page Web finale et cela peut avoir un impact sur les performances [2] sur les appareils mobiles.
    • Insightful overview of 'hide text offscreen' tricks are given by Jonathan Snook.
  • Things should not be repeated often. If you have a 100 links on a page that can open a dialog, then don't add 100 labels to those 100 links telling the user that it can be used to open a dialog. Telling a user how to use/what to do with the interface is a good thing, doing it consistently is simply annoying. Find a different way to explain it once (an aria-live=polite might be an idea in this case ?).
  • <a href="#">Hide</a> with an onclick handler. VO reads such JS as "internal link Hide". Use a proper button, or <a role="button" tabindex="0">Hide</a>, with 'Space' and 'Enter' key handlers in the onclick. But no href attribute.
  • Do not nest interactive functionality inside another interactive element (links or buttons inside links). This confuses screen readers.

Eviter

symboles Unicode
Most assistive technologies are not good with symbols. Therefore, try to avoid characters such as ↑, →‎ or more complex characters, because many screen reader won't understand them. If they are required, try to wrap with a span element with the title attribute, so that the title attribute can communicate the implicit meaning within the context to the reader.
Petites polices
Lisibilité est préféré. If you make something so small that it is hard to read, do you even need it to begin with? Also avoid small fonts with low or mediocre contrast values (even if they fall inside the WCAG guidelines, small sizes require more explicit contrast then large sizes, especially with anti aliasing enabled).
Unusually large fonts
If you make text much larger than normal, it can become similarly hard to read (unless it's very short). This applies mostly to body text, or anything that takes up more than a couple lines. But the larger the text is, the more lines it will take up.
tabIndex > 0
DOM order is preferred wherever possible. DOM order provides context for the actions.
Solution de contournement
Traditionally, accomplishing 'full' accessibility has required a lot of workarounds for html itself, the browsers and even specific screenreader software. However these workarounds often come with side effects, make use of bugs or unspecified behavior and inevitably create technical debt.
MediaWiki, because of the users it seeks to serve, the amount of code, it's (lack) of funding, etc tends to prefer future proof code over code that easily breaks. As such it generally avoids workarounds even if that might sometimes limit the accessibility we can deliver. Decisions on this are often influenced by the relative audience of the feature in MediaWiki. If something is ubiquitous for all users a workaround is more warrented than if the feature affected is only used by a tiny part of the audience (for instance, reading a page vs modifying the configuration of the installation).

Considérez

  • ARIA Roles
    • If a div or span behaves like an actual button use role="button". also role="dialog" and role="alert"
    • Be careful with roles. For instance, don't add role="button" to a ‎<th> element, since the ‎<th> element has an implicit role="columnheader", which will be overwritten. Instead use nested elements. Similarly for ‎<li> which has an implicit role="listitem"
    • If a button creates a popupdialog, use aria-haspopup.
    • Use aria-labelled-by for contexts where this is not fully logical by itself (so everywhere except for labels in forms and headers in tables).
  • Avoid tables for layout purposes and test on smaller screen widths.
  • hide stuff: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • skip/jump to links

Voir aussi

Références

  1. ↑ Voir ordre DOM à w3.org et Propriété d’ordre de style à w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/fr&oldid=6733717"