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 87% 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". Vous ne pouvez pas déplacer votre doigt sur ce texte et donc le texte ne sera pas lu non plus. (l'attribut aria-label est souvent le meilleur choix).
    • 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.
    • Un aperçu détaillé des astuces de "masquage de contenu" est donné par Jonathan Snook.
  • Ne pas se répéter souvent. Par exemple, si vous avez 100 liens sur une page qui peuvent ouvrir un dialogue, alors n'ajoutez pas 100 étiquettes à ces 100 liens disant à l'utilisateur qu'il peut être utilisé pour ouvrir une interaction. Dire un utilisateur comment utiliser/quoi faire avec l'interface est une bonne chose, le faire de manière répétitive est tout simplement tannant. Trouvez une autre façon de l'expliquer une fois (un aria-live=polite pourrait être une idée dans ce cas?).
  • <a href="#">Hide</a> avec un gestionnaire de clic. VO lit ce type de JavaScript en tant que "internal link Hide". Use a proper button, or <a role="button" tabindex="0">Hide</a>, with 'Space' and 'Enter' key handlers in the onclick. Mais sans attribut href.
  • Do not nest interactive functionality inside another interactive element (links or buttons inside links). Cela conduit à des confusions pour les lecteurs d'écran.

Eviter

symboles Unicode
La plupart des technologies d'assistance ne sont pas compatibles avec les symboles. Par conséquent, évitez les caractères tels que ↑, → ou des caractères plus complexes, car beaucoup de lecteurs d'écran ne parviendront pas à les lire efficacement. S'ils sont requis, essayez—avec un span—de “wrap” avec l'attribut de titre, afin que l'attribut titre puisse véhiculer la signification implicite au sein du contexte, au lecteur.
Petites polices
Lisibilité est préféré. Si vous saisissez quelque chose de si petit qu'il est difficile à lire, en avez-vous vraiment besoin de cette saisie? Également, évitez d'utiliser de petites polices avec des valeurs de contrastes faibles ou intermédiaires (même s'ils sont conformes au Règles pour l'accessibilité des contenus Web, de petites tailles de polices exigent davantage de contraste que de tailles de polices plus grande, surtout quand de l'anticrénelage est activé)
Des tailles de polices exceptionnellement grandes
Si vous rendez du texte d'une taille beaucoup plus grand que la normale, cela peut également devenir difficile à lire (à moins que ce soit très court). Cela s'applique principalement au corps du texte, ou à tout qui occupe plus que quelques lignes. Mais plus le texte est grand, plus il en occupe de lignes.
tabIndex > 0
Le Système de gestion des commandes distribuées est préférable là où c'est possible. Le Système de gestion des commandes distribuées fournit du contexte pour les actions.
Solution de contournement
Traditionnellement, l'accessibilité "entière" a nécessité de nombreuses solutions pour le html lui-même, les navigateurs et même des logiciel spécifiques de lecture d'écran. Cependant, ces solutions sont souvent accompagnées d'effets secondaires, de bogues ou de comportements de fonctionnement non spécifiés, et créent inévitablement des dettes techniques.
À cause des raisons incluant les utilisateurs qu'elle cherche à servir, la quantité de code, et de son (manque) de financement, MediaWiki a tendance à préférer un code qui est pérenne au code qui se corrompt facilement. En tant que tel, cela évite généralement des solutions de rechange, même si cela pourrait parfois limiter l'accessibilité que nous pouvons fournir. Les décisions à ce sujet sont souvent influencées par le public relatif de la fonctionnalité dans MediaWiki. Si quelque chose est omniprésent pour tous les utilisateurs, une solution de rechange est plus garanti que si la fonctionnalité affectée n'est utilisée que par une minuscule partie du public (par exemple, la lecture d'une page plutôt à la modification de la configuration de l'installation).

Considérez

  • Rôles ARIA
    • Si une
      ou agit comme vrai bouton, utilise role="button". Vous voir aussi role="dialog" et role="alert"
    • Attention aux rôles! Par exemple, ne pas ajouter role="button" à un élément ‎<th>, puisque l'élément ‎<th> a un role="columnheader" implicite, qui sera remplacé. Utilisez plutôt des éléments emboîtés. 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=7615366"