Wikipédia:Atelier accessibilité/FAQ
Quelques idées reçues (sans aucune intention péjorative) à propos de l'accessibilité, rencontrées ici ou là sur Wikipédia.
L'accessibilité, c'est...
modifierL'accessibilité, c'est l'accès pour tous aux ressources du Web
modifierEn bref : dans ce cadre, non.
L'accessibilité du Web est techniquement et méthodologiquement avant tout la possibilité pour des utilisateurs handicapés visuels, moteurs auditifs ou cognitifs d'exploiter les ressources du Web.
Cependant, elle a de nombreux effets induits qui bénéficient à un public beaucoup plus large : les seniors, mais aussi toute personne placée (temporairement) dans une situation pour elle handicapante (ne pas avoir de souris, passer par une connexion en bas débit, être dans des conditions d'affichage dégradées, etc.).
Enfin, elle recoupe en partie d'autres aspects qualitatifs du Web, ou d'autres préoccupations telles que l'ergonomie. Il importe cependant de bien l'en différencier afin de s'en tenir à une approche rigoureuse et finalement plus efficace pour tous.
L'accessibilité, ce sont les aveugles et les synthèses vocales
modifier
En bref : pas seulement, et de loin.
L'accessibilité Web concerne l'ensemble des handicaps et fait abstraction des déficiences elles-mêmes (motrices, visuelles, auditives, cognitives) : ce sont davantage des situations de handicap qu'elle prend en compte. Un utilisateur temporairement dans l'incapacité d'utiliser une souris (parce qu'il n'en a pas, par exemple, ou qu'il porte un plâtre) entre dans le champ de l'accessibilité au même titre qu'un aveugle.
Les aveugles et autres utilisateurs de lecteurs d'écran sont simplement plus emblématiques que d'autres de l'accessibilité du Web, pour des raisons en particulier historiques.
L'accessibilité, ce sont aussi les mobiles
modifierEn bref : oui, mais non.
Oui, et non. Stricto sensu, les normes d'accessibilité visent prioritairement les utilisateurs en situation de handicap. Mais les utilisateurs de mobiles partagent de nombreuses caractéristiques avec ceux-ci. Les Directives pour le Web mobiles font donc explicitement référence à une partie des Directives d'accessibilité. En résumé : ces deux préoccupations se recoupent partiellement. Tout ce qui pertinent pour l'accessibilité n'est pas forcément utile du point de vue du Web mobile, et celui-ci a en outre d'autres exigences qui lui sont propres.
L'accessibilité est un état déterminé d'un site
modifierEn bref : non.
L'accessibilité est une gestion de risque permanente, nécessitant un suivi. La question n'est pas de déterminer si le site atteint un état théorique d'accessibilité à un moment donné, mais de gérer ses facteurs d'inaccessibilité en continu.
Je peux tester avec...
modifierJe peux évaluer le degré d'accessibilité avec un navigateur texte
modifier
En bref : non.
Les navigateurs textes sont fréquemment employés comme illustration des problématiques d'accessibilité. Ils ne constituent pas cependant, et de très loin, des outils de tests suffisants. Un page peut être correctement affichée et utilisable dans un navigateur texte sans pour autant répondre aux critères minimaux d'accessibilité. Inversement, elle peut souffrir d'un manque apparent d'alternatives textuelles exploitables au vu de son rendu dans un navigateur texte, sans que cela ne signale davantage que l'état de l'implémentation dans celui-ci.
Je peux évaluer le degré d'accessibilité avec un lecteur d'écran
modifierEn bref : non.
Les lecteurs d'écrans font partie des aides techniques utilisées par des handicapés visuels, et sont sans doute la plus connue ou la spectaculaire d'entre-elles. Tester le rendu dans un lecteur d'écran fait en effet partie des tests d'accessibilité, mais ne constitue pas cependant, et de très loin, un test suffisant. Une page peut être correctement lue et utilisable dans un lecteur d'écran sans pour autant répondre aux critères minimaux d'accessibilité.
Je peux évaluer le degré d'accessibilité avec un validateur
modifierEn bref : non.
Très peu de choses sont automatisables et évaluables via des validateurs logiciels dans ce domaine. Ils ne sont pas pour autant inutiles, mais ne sont qu'une petite pièce du puzzle.
Je peux évaluer le degré d'accessibilité avec un test utilisateur
modifierEn bref : partiellement.
Un test utilisateur permet difficilement de détecter les facteurs d'inaccessibilité les plus bloquants. Lorsqu'une information est inaccessible, un utilisateur dans une situation de handicap telle qu'elle l'empêche de consulter cette information ne pourra tout simplement pas savoir qu'elle est présente, et donc ne signalera pas de contenu inaccessible.
D'autre part, les utilisateurs développent leurs propres stratégies de contournement de l'inaccessibilité, particulièrement quand ils disposent d'une aide technique puissante telle qu'un lecteur d'écran (avant tout conçu pour tirer le meilleur parti possible de pages non accessibles). L'habitude aidant, ces utilisateurs finissent par trouver « normal » de devoir passer par des moyens détournés pour accéder à l'information, ou de percevoir fréquemment des informations non compréhensibles dont ils ont fini par faire systématiquement abstraction.
Enfin, un test utilisateur ne reflète qu'un contexte utilisateur unique et spécifique, étroitement lié à une combinaison de facteurs personnels (handicap(s), usages), logiciels (navigateur, aide technique), et matériels (périphériques utilisés). Une variation d'un seul facteur peut suffire à modifier entièrement le degré d'accessibilité perçu.
Comment évalue-t-on l'accessibilité ?
modifierEn bref : avec des méthodes expertes
L'évaluation du niveau d'accessibilité d'une page Web repose des tests normalisés issus des Directives WCAG, dans le cadre de méthodes d'application de celles-ci : RGAA par exemple. Mais ces outils restent à élaborer dans le cas de Wikipédia, compte-tenu de ses particularités. Des méthodes comme le RGAA sont un point de départ pertinent et un substitut en attendant.
Mediawiki...
modifierMediawiki produit un contenu accessible
modifierEn bref : non.
Mediawiki a un potentiel important qui lui permettrait de produire des contenus accessibles, mais :
- ce CMS comporte également plusieurs défauts importants
- l'accessibilité du contenu dépend autant de l'usage qui en est fait que du CMS lui-même. À cet égard, mediawiki confère une responsabilité majeure aux contributeurs, notamment à travers le système des modèles.
Les préférences utilisateur sont un outil pour l'accessibilité
modifierEn bref : non.
La possibilité de paramétrer certains aspects de l'interface et des contenus de wikipédia (exemple) peut améliorer de manière marginale l'accessibilité pour certains utilisateurs. Face à un problème d'accessibilité du site tel qu'il se présente par défaut, ce n'est cependant pas une solution pertinente.
Un site accessible est accessible par défaut, ou comporte une version alternative accessible par défaut.
Les légendes des thumb améliorent l'accessibilité
modifierEn bref : non.
Telle qu'elle est implémentée actuellement dans mediawiki, la légende des thumb ne constitue pas une solution accessible.
La table des matières d'un article est une amélioration de l'accessibilité
modifierEn bref : très marginalement.
La présence d'un table des matières au début du contenu est une amélioration marginale du point de vue de l'accessibilité, et davantage une question ergonomique. Les aides techniques fournissent en effet à leurs utilisateurs, si nécessaire, des tables des matières des pages Web dotées de fonctionnalités plus pertinentes.
Le résumé introductif d'un article est une amélioration de l'accessibilité
modifierEn bref : marginalement.
Le rôle clé revient, du point de vue de l'accessibilité, aux titres h1…, c'est-à-dire notamment, dans wikipédia, aux titres de sections.
Pour être accessible, il faut...
modifierVulgariser les contenus trop compliqués
modifierEn bref : non.
L'accessibilité ne vise pas à simplifier les contenus complexes. Elle demande en revanche que les utilisateurs en situation de handicap ne soient pas désavantagés par rapport à d'autres face à des contenus complexes. Par exemple, les problèmes d'accessibilité actuels des formules mathématiques ne tiennent pas à leur niveau de complexité, mais au fait que certains utilisateurs, qui n'ont pas accès aux images, n'auront accès qu'à leur syntaxe LaTeX.
Supprimer les images et faire une version texte
modifierEn bref : surtout pas.
L'accessibilité ne nécessite pas de supprimer les images, il s'agit de gérer leur alternative textuelle.
Éviter tout scroll horizontal dans le navigateur en 800 × 600
modifierEn bref : aucun rapport avec le sujet
Le scroll horizontal du navigateur peut, dans certains cas, être considéré comme un défaut ergonomique. En revanche, quelle que soit la résolution considérée, ce n'est pas un défaut d'accessibilité : le contenu reste perceptible via les fonctionnalités natives du navigateur.
Éviter les images trop grandes ou trop petites (largeur/hauteur)
modifierEn bref : aucun rapport avec le sujet
La taille excessive ou insuffisante des images peut, dans certains cas, être considéré comme un défaut ergonomique. En revanche, ce n'est pas un défaut d'accessibilité.
Éviter l'utilisation des tableaux et des infobox
modifierEn bref : ça n'est pas la question
Deux types de tableaux HTML doivent être différenciés :
- les tableaux de données sont accessibles dès lors qu'ils répondent à certains critères techniques (garantissant que leur structure sera exploitable par des aides techniques).
- les tableaux de présentation sont accessibles lorsque leur structure ne prête pas à confusion avec celle d'un tableau de données, et sous réserve de leur linéarisation cohérente.
Ajouter des raccourcis clavier (accesskey)
modifier
En bref : non
Les raccourcis clavier associés aux liens et aux éléments de formulaires par le biais de l'attribut HTML accesskey étaient un des dispositifs d'accessibilité initialement recommandés par les normes WCAG. Mais l'usage a montré que ce dispositif entrait en conflit avec d'autres raccourcis clavier des navigateurs et des logiciels d'aide, et qu'il était une source de difficulté trop fréquente pour être pertinent.
L'utilisation des accesskey est donc fortement déconseillée.
Éviter les pages trop longues
modifierLa quantité de texte ou le poids total d'une page Web ne sont pas en eux-mêmes des critères d'accessibilité. En revanche, une page « longue » (Exemple) nécessitera d'autant plus de soin quant à sa structure (titrage, listes).
Privilégier les liens vers des sources en français
modifierEn bref : ce n'est pas la question
Un lien vers une source qui n'est pas en français doit simplement, pour être accessible, permettre à l'utilisateur d'anticiper le résultat de son action avant qu'il ne décide de le visiter. Pour cela, il suffit que le libellé du lien soit lui-même dans la langue en question, ou que celle-ci soit mentionnée s'il est en français.
L'attribut title est utile sur d'autres éléments que les liens
modifier
En bref : non.
L'attribut title n'est pertinent pour apporter une information nécessaire à l'accessibilité que sur les liens, les abréviations et les acronymes. Dans mediawiki, cela se réduit aux liens, mais les contributeurs n'ont pas le contrôle du contenu de leurs title.
La présence d'un title sur un élément span ou div ne permet pas d'apporter une information supplémentaire de manière pertinente pour l'accessibilité.
Une version audio est une amélioration de l'accessibilité
modifierEn bref : non.
Les versions audio d'une page Web, qu'elles soient téléchargeables ou consultables via une interface embarquée, ne sont pas pertinentes en tant que solutions d'accessibilité. Les utilisateurs susceptibles d'en bénéficier sont en effet déjà équipés d'outils performants de synthèse vocale, dotés de fonctionnalités avancées leur permettant d'exploiter toutes les informations et métadonnées présentes dans la page consultée.
En revanche, des illustrations sonores peuvent améliorer l'accessibilité d'un contenu, au même titre que des illustrations graphiques.
Éviter les éléments et attributs HTML de présentation (center, b, etc.)
modifier
En bref : ce n'est pas le problème.
Mediawiki génère un code HTML qui comporte plusieurs éléments et attributs de présentation. Ils ne constituent pas un obstacle en eux-mêmes pour l'accessibilité. Mais ils deviennent problématiques quand ils sont utilisés à la place de la syntaxe pertinente qui produit, elle, un élément structurel accessible. Par exemple, la mise en gras ne doit pas remplacer un élément de titre du type ===...===
Ne pas utiliser javascript, les utilisateurs de lecteurs d'écran ne l'ayant pas
modifierEn bref : si.
Les utilisateurs de lecteurs d'écran utilisent toujours un navigateur graphique, généralement Internet Explorer, et sont dans la même situation que n'importe quel autre utilisateur de ces navigateurs : javascript peut y être activé ou non. On ne peut donc ni supposer qu'une fonctionnalité javascript sera disponible, ni qu'elle ne peut pas faire de mal puisque javascript ne serait pas activé.