Projet:Charte graphique/Accessibilité

L'atelier accessibilité a pris la succession de cette page.

Aigles et Lys se doit d'être accessible à tous, quelles que soient leurs aptitudes sensorielles, et en particulier visuelles. Cette page a pour but de recenser tous les points à surveiller et les actions à entreprendre en vue d'atteindre cet objectif.

Nous invitons tout particulièrement les personnes présentant un handicap ou une déficience sensorielle à nous faire part de leur expérience et de leurs suggestions.

Catégories de personnes concernées

• Personnes atteintes de daltonisme ou d'achromatopsie
• Personnes mal-voyantes ou non-voyantes
• Personnes à mobilité réduite

Problèmes spécifiques

Impression noir et blanc

L'impression d'un article doit rester lisible, notamment en noir et blanc quand la couleur de fond n'est pas imprimée. Les tableaux dont les cellules ne se différencient que par des couleurs de fond sont donc problématiques.

Daltoniens / Achromates

Les préférences permettent de régler l'apparence des liens. Les deux item les plus importants se trouvent dans "Préférences diverses" : cochez "Liens soulignés" et décochez "Liens vers les sujets non existants en rouge", ce qui les fait apparaître comme un point d'interrogation rouge après le texte entre crochets.

Autres problèmes rencontrés ?

Mal- ou non-voyants

Problèmes rencontrés ?

• Les images ne peuvent être vues. Aucune information ne doit s'y trouver exclusivement; ajouter une description de l'image de manière systématique: c'est ce que liront les lecteurs pour aveugles.
  • Il y a toutefois un problème : le "alt" et la légende (quand elle existe) sont identiques, or il y a pas mal de cas où ils devraient être différents. Prenons par exemple image:diag_phase_glace.png, je ne vois pas trop quel texte pourrait être satisfaisant pour les deux simultanément. R 6 avr 2005 à 14:40 (CEST)

Ben Diagramme de phase de la glace ... Jyp 6 avr 2005 à 14:45 (CEST)

C'est un titre, ce que tu proposes. Une légende devrait donner la signification des symboles utilisés, ici les traits pleins et pointillés. Le texte alternatif devrait expliciter l'information que l'on souhaite transmettre en plaçant l'image dans l'article.

Exemple de "bonne" légende : "Diagramme de phase pression-température de l'eau limité aux phases stables. L'échelle des pressions est logarithmique. Les traits pleins figurent les lignes de transition entre phases stables observées expérimentalement, les traits interrompus indiquent les lignes de transition prédites théoriquement. Les phases stables sont désignées sous forme abrégée (voir texte)." (NB : j'ai juste inventé un truc plausible, si ça se trouve, c'est faux.)

Exemple de "bon" texte alternatif : "Le diagramme de phase de l'eau a été exploré jusqu'à des pressions de l'ordre de 100 GPa. Au-dessus de 0,1 GPa, six phases solides stables ont été identifiées, en plus des trois phases de basse pression (glace ordinaire, liquide, vapeur). L'existence des phases glace-X pour des pressions supérieures à 100 GPa et glace-XI pour des pressions inférieures à 0,05 GPa et des températures inférieures à 90 K a été conjecturée." R 6 avr 2005 à 17:30 (CEST)

Je viens d'aller voir sur Accessiweb : le texte de l'attribut "alt" ne doit pas dépasser 60 caractères... Ce que propose Jyp est donc correct en tant que "alt". En revanche, le texte alternatif que je propose devrait pouvoir être accessible d'une manière ou d'une autre (attribut "longdesc" ?).

Au cas où la question serait encore d'actualité ou se reposerait: cette limite des 60 caractères est une extrapolation problématique des directives d'accessibilité propre à la méthode accessiweb. La seule règle réelle est la concision des alt, sans limite chiffrée. --Lgd 15 mars 2007 à 18:48 (CET)

Pour une description longue il y a longdesc. (MediaWiki pourrait l'implémenter en liant vers la page locale description de l'image.) — Régis Lachaume ✍ 27 avril 2007 à 00:43 (CEST)

Sur le QT, je viens de chopper un truc : <span title="titre">…</span> que l'on pourrait utiliser pour encadrer l'image, mais je ne sais pas comment c'est interprété.

cdang | m'écrire 22 février 2007 à 10:36 (CET)

• Il y a un autre gros problème en suspens: les changements de langue. Lors de l'utilisation d'une synthèse vocale, les non et mal-voyants sont soumis à la prononciation de cette dernière. Si le mot relève d'une autre langue que la langue par défaut (le français pour "notre" Wiki), et si aucune indication n'est donnée à la synthèse, il sera lu avec l'accent français. Ça ira pour "parking", mais pas pour Gestalt qui sera lu géstalte. Et je ne vous parle pas là des mots en japonais qui émaillent nombre d'articles… Il n'est pas possible de corriger cela automatiquement. Mais on pourrait au moins suggérer à l'auteur d'indiquer cette langue (pour ceux qui s'y connaissent, un <span lang="de">Gestalt</span> par exemple, ou bien passer par un modèle {{de|Gestalt}}… GillesC -Жиль- 19 janvier 2006 à 09:35 (CET)

Comme Windows Vista intègre par défaut un moteur de synthése vocale multilingue, il est probable que ce type de modèle profite à tous. Message ajouté par Mirgolth (discussion · contributions)

Il n'y pas que Vista ; les autres systèmes d'exploitation n'ont pas forcément de synthèse vocale intégrée. GillesC →m'écrire 16 février 2007 à 17:53 (CET)

Le modèle générique {{lang}}(et ses « fils » comme {{arabe}} ) répond au besoin d’indication de langue pour les synthtiseurs vocaux.

Le modèle {{Indication de langue}} (et ses « fils » {{de}} {{fr}} {{en}} ...) sont des modèles qui donnent quant à eux, des indications visuelles difficiles à synthétiser en plus de la meta information de langue. Ils sont moins adaptés pour le corps des articles que {{lang}}.

Le but de ma remarque sur Vista est d’encourager l’utilisation de ces modèles qui profitent àun panel plus large que les mals voyant. --Mirgolth 16 février 2007 à 18:42 (CET)

L'indexation par les robots, par exemple. — Régis Lachaume ✍ 27 avril 2007 à 00:43 (CEST)

Personne à dextérité réduite

• Les caractères spéciaux comme # { [ | @ ] } sont indispensable à l'édition dans Aigles et Lys. Si vous ne parvenez pas à les saisir, voici quelques pistes (si vous êtes concerné des retours seraient les bienvenus) :

1. Vous pouvez utiliser un clavier « on the screen » (un clavier virtuel)
2. L'interface propose un outil équivalent : une ligne sous la fenêtre d'édition qui permet de saisir un grand nombre de caractères.

Cette ligne est devenue, au fil de ses enrichissements successifs, une source de problèmes d'accessibilité, étant donné la complexité du formulaire qui en résulte. Il s'agirait plutôt d'élaguer, actuellement ;) --Lgd 15 mars 2007 à 18:51 (CET)

1. En utilisant le navigateur Firefox vous pouvez utiliser l'extension Aigles et Lys, disponible sur le site bananeweizen (le site est anglophone mais l'extension est traduite). L'extension fournit de nombreuses aides à l'édition accessibles par une barre d'outils ou par un clic-droit.

• Si vous avez du mal à faire défiler un long texte, pensez à utiliser les sous-titres du sommaire pour accéder plus vite à la partie de l'article qui vous intéresse. Les contributeurs doivent de leur côté faciliter la navigation via le sommaire en prévoyant un découpage suffisamment détaillé des articles dont les paragraphes dépassent une hauteur d'écran 600x800.

Problèmes généraux

Toute image doit être décrite en employant une syntaxe du type [[NomImage.png|Description de l'image]]. Cela permet d'avoir un texte indiquant ce que représente l'image dans le cas des navigateurs ne pouvant pas représenter ces images (texte seulement, image désactivée, lecture vocale,...)

Informer

Il faut :

• sensibiliser tous les contributeurs au problème
• informer les personnes concernées des possibilités existantes

Actions à entreprendre

La référence en la matière est le site Accessiweb qui a recensé 92 critères pour évaluer l'accessibilité des sites.

• Des liens [accéder au contenu] [accéder à la navigation] (avec des raccourcis) pourraient sans doute aider la lecture par les aveugles. (à noter que je n'ai trouvé ce critère dans la page sus-citée)

ces liens sont présents dans le code mediawiki, quoique de manière non optimale et nettemet améliorable, mais il faut toucheru au template de base. --Lgd 15 mars 2007 à 18:53 (CET)

Quelques conseils

1. Éviter toute information uniquement présente sur des images (illisible pour les aveugles) ou sur la couleur (daltoniens) ;
2. pour les images, utiliser systématiquement les alt qui sont remplis correctement si on les indique avec la syntaxe wiki. Seuls les alt sont lus par les logiciels pour aveugles ;
3. ne jamais coder en dur les polices et les couleurs ;
4. utiliser les * / # (ul/li/…) pour les listes verticales qui seront interprétées correctement par des logiciels pour aveugles (et les « , » et « ; » pour les listes horizontales). D'une manière générale avoir des pages en HTML correct ;
5. éviter l'utilisation de tableaux pour la mise en page ; les systèmes pour aveugle, vocal ou braille, lisent les tableaux ligne par ligne de gauche à droite ;
6. Quand on utilise des caractères spéciaux dans un titre, par exemple œ, Œ, É, Ê, Ç,… faire un redirect depuis un titre sans caractères spéciaux ;
7. ne pas fixer la taille d'une police, préférer les balises <big></big> <small></small>…  ;
8. pour les liens externes, donner des intitulés explicites ; la lecture d'une URL ou « cliquez ici » n'est pas forcément parlant quant à la destination ;
9. pour les formules mathématiques, utiliser tant que faire se peut l'écriture classique : les formules générées par la syntaxe TeX (avec les balises <math>…</math>) génèrent des images PNG qui ne sont pas lisibles par les lecteurs vocaux, et avec un alt incompréhensible ; par exemple, préférer ρ·g·z à $\rho \cdot g\cdot z$.

L'un et l'autre sont également non accessibles. Le problèmes très spécifique des formules mathématiques n'a pas actuellement de solution d'accessibilité déployable ici. --Lgd 15 mars 2007 à 18:55 (CET)

C'est-à-dire que les agents utilisateurs ne lisent pas les caractères grecs et ne « traduisent » pas les sdot en « multiplié par », c'est cela ?

Tout va dépendre du dictionnaire personnalisé mis en place par l'utilisateur du lecteur d'écran. Un lecteur régulier de documents mathématiques aura a priori renseigné ce dictionnaire conformément aux documents qu'il lit le plus souvent, mais ce ne sera pas le cas pour tous, et les formules mathématiques gagneraient à être évitées en fait dans les articles non spécialisés. D'autre part, le dictionnaire du lecteur ne peut pas tout faire, et des formules complexes resteront énigmatiques dans tous les cas. Pour aller au-delà, ce sont des outils spécifiques de codage et d'accès qui sont mis en oeuvre dans certains instituts universitaires américains, bien au-delà de ce qu'on peut faire en HTML. --Lgd 25 avril 2007 à 15:03 (CEST)

Intéressant à savoir. Le MathML qui permet un codage syntaxique n'est pas reconnu par les outils spécialisés ? (De toute façon MediaWiki transforme en MathML soupe de tags, alors, cela ne nous concerne pas.)— Régis Lachaume ✍ 27 avril 2007 à 00:39 (CEST)

cdang | m'écrire 25 avril 2007 à 12:23 (CEST)

C'est essentiellement le navigateur qui doit faire le travail adéquat (réutilisation des préférences systèmes pour couleur/font).

Accessibilité des tableaux

Bonjour,

je viens de rajouter les attributs spécifiques dans Aide:Réaliser un tableau en code wiki#Accessibilité aux malvoyants, d'apèrs les indications de LgD. Quelqu'un (Lgd ?) peut-il valider ?

cdang | m'écrire

Bravo (et surtout merci ;) ). Quelques précisions à apporter, en tenant compte des niveaux de priorité WCAG1.0 pour l'accessibilité (A=vital pour percevoir l'essentiel du contenu, AA=nécessaire pour en percevoir la totalité, AAA= confort équivalent à celui d'un utilisateur qui n'est pas en situation de handicap):

• la page Aide:Réaliser un tableau en code wiki#Accessibilité aux malvoyants... utilise elle-même une somme importante de tableaux de présentation, et gagnerait à être revue de ce côté :D
• scope (niveau A) répond bien aux besoins pour les tableaux à simple entrée, mais les tableaux à double entrée nécessitent id et headers, hélas franchement affreux à écrire pour les rédacteurs. (un patch du parser Wiki de mediawiki permettrait de les générer automatiquement, mais ce n'est apparemment pas à l'ordre du jour côté développement).
• Un tableau accessible devrait avoir un élément <caption> (titre du tableau, niveau AA), mais il pose inévitablement des problèmes de rendu graphique (il n'est que partiellement stylable, et beaucoup de gens trouvent son rendu "pas bô")
• le summary (niveau AAA) doit surtout indiquer le mode d'organisation du tableau, et répondre à la question: comment se lit-il ? Il est donc idéalement aussi explicite que possible, par exemple sous la forme: "le tableau indique, pour chaque numéro de candidat (colonne 1), le nom de la personne (colonne 2) et le score obtenu (colonne 3)".
• abbr (Niveau AAA) ne sert pas, contrairement à l'usage qui en fait dans la page Aide:Réaliser un tableau en code wiki#Accessibilité aux malvoyants, à expliciter une abréviation contenu dans une cellule d'en-tête, mais à donner au contraire la forme abrégée d'une cellule d'en-tête dépassant 20 caractères, pour éviter une répétition fastidieuse dans un lecteur d'écran lorsque l'utilisateur parcourt les cellules de données (l'en-tête correspondant est répété à chaque cellule).

Finalement, le mieux serait ici de se concentrer sur le critère de niveau A, c'est à dire scope ou id/headers (qui est évidemment le moins aisé pour les rédacteur, sinon la vie serait bien faite ;) ). C'est en effet le mécanisme d'accessibilité qui "lève" le blocage le plus simportant, c'est à dire la compréhension de la structure logique des données mises en tableau.

Dès que possible (question de disponibilité), je pourrai regarder de près les modèles. A moins que Gilles ne s'y colle ? ;)

Cordialement, --Lgd 25 avril 2007 à 14:57 (CEST)

scope (niveau A) répond bien aux besoins pour les tableaux à simple entrée, — pourtant, la page du W3C donne un exemple à double entrée (même si l'en-tête de ligne est un td et non pas un tr). Ou bien ?

cdang | m'écrire 26 avril 2007 à 10:32 (CEST)

C'est un problème d'implémentation selon les lecteurs d'écran: les scope de tableaux à double entrée (donc à la fois sur des th de ligne et des th de colonnes) ne seront pas correctement pris en compte par tous les lecteurs, au contraire des id et headers. Plus généralement HTML4.01 et WCAG1.0 contiennent plusieurs dispositions d'accessibilité de ce type, dont l'implémentation est actuellement insuffisante, ou s'est même parfois avérée impraticable. Un certain recul sur ces normes est donc nécessaire ;) Cordialement --Lgd 26 avril 2007 à 11:07 (CEST)

J'ai reformulé la page et changé les exemples. Est-ce que cela convient ? — Régis Lachaume ✍ 27 avril 2007 à 00:36 (CEST)

PS : vu que les développeurs n'ont toujours pas troqué <b> et <i> pour <strong> et <em>, je doute que ce genre de détails les intéresse. Tu as posté un bogue au sujet ou pas ? — Régis Lachaume ✍ 27 avril 2007 à 00:36 (CEST)

Ressources

• Accessibilité du web
• Standards et accessibilité
• Wikipedia:en:Alternative text for images