Accessibilité aux mal-voyants

Bonjour,
Depuis que je suis sur ce forum, je vois partout le mot accessibilité, et du coup, je n'ai toujours qu'une seule idée en tête, c'est l'accessibilité des sites web aux mal voyants.
J'ai pu tester sur un site un lecteur d'écran (sur un site fictif je crois... enfin je ne sais pas), que j'ai trouvé assez bien fait.

Mais étant donné que le site n'est pas réel (ou bien que je n'ai juste pas l'adresse, même en essayant de déchiffrer les images toutes floues données comme indice), je ne peux pas voir la structure du site.

Donc ma question est... Que et dans quel ordre un lecteur d'écran va-t-il lire ? Et doit-on créer une page différente pour une version pour les mal-voyants ou bien une page bien structurée et mise en page juste avec CSS est-elle suffisante ?

Donc plusieurs questions à la suite...
D'abord, je suppose qu'il va lire le code source de haut en bas, mais sait-on s'il reconnait bien toutes les balises, s'il ne va pas en sauter ?
Pour ce qui est des images, que va-t-il lire ? L'attribut alt ou title ? Même s'il s'agit d'un lien ?
Sait-on si les nouveautés de HTML5 vont permettre une meilleure accessibilité aux non-voyants ? (Avec des raccourcis sur leurs machines pour accéder directement au contenu, au menu, etc. étant donné que de belles balises ont été créées comme nav, section, details, etc.) Ah, tiens, est-ce pour ça que certains sites ont ces liens en haut ?
Peut-on avec css empêcher la lecture de certaines données qui pourraient sembler superflues pour un mal voyant ?

Ah, et qu'en est-il du JavaScript ? Il permet parfois de générer une grosse partie du code html (je sais, ce n'est pas bon, je ne soutiens pas cette façon de faire, mais elle existe...)

Merci pour vos réponses et désolé pour toutes ces questions inutiles/bêtes peut-être, mais surtout désordonnées...

Pour ceux qui voudraient tester le lecteur d'écran : http://webaim.org/simulations/screenreader-sim.htm (en anglais, je rappelle)
Modifié par Gothor (25 Jan 2012 - 23:36)

Bonjour,

Premières choses : Tu parles d'accessibilité au mal-voyants, mais tes questions sont orientées non-voyant, même si les très mal-voyants auront souvent les mêmes besoins que les non-voyants, Ils peuvent avoir des besoins très différents. Les non-voyants (et certains mal-voyants) doivent remplacer leurs yeux par un lecteur d'écran ou une console; alors que les mal-voyants pourront parfois se contenter d'une loupe.

Ensuite, attention, l'accessibilité le se limite pas au problème de vue !

Gothor a écrit :
Que et dans quel ordre un lecteur d'écran va-t-il lire ?

Toute la page affichée, dans l'ordre du code.

Gothor a écrit :
Et doit-on créer une page différente pour une version pour les mal-voyants ou bien une page bien structurée et mise en page juste avec CSS est-elle suffisante ?

Ne surtout pas créer une page différente (c'est plus difficile à maintenir et pas nécessaire). Une page codée en pensant à l'accessibilité sera suffisante.

Gothor a écrit :
D'abord, je suppose qu'il va lire le code source de haut en bas, mais sait-on s'il reconnait bien toutes les balises, s'il ne va pas en sauter ?

Oui, il reconnait toute les balises.

Gothor a écrit :
Pour ce qui est des images, que va-t-il lire ? L'attribut alt ou title ? Même s'il s'agit d'un lien ?

L'attribut alt, toujours. Une image n'est pas sencée avoir d'attribut title (sauf cas très particuliers). Suivant la configuration du lecteur d'écran, le title sera lu sur les liens (raison pour laquelle il ne faut pas en abuser).

Gothor a écrit :
Sait-on si les nouveautés de HTML5 vont permettre une meilleure accessibilité aux non-voyants ?

Non, aucun rapport. Ce qui permet une meilleure accessibilité c'est l'intégrateur.

Gothor a écrit :
(Avec des raccourcis sur leurs machines pour accéder directement au contenu, au menu, etc. étant donné que de belles balises ont été créées comme nav, section, details, etc.)

Ce n'est pas prévu pour le moment.

Gothor a écrit :
Ah, tiens, est-ce pour ça que certains sites ont ces liens en haut ?

Oui, il est d'ailleurs préférable de les utiliser et pas que pour les non-voyants.

Gothor a écrit :
Peut-on avec css empêcher la lecture de certaines données qui pourraient sembler superflues pour un mal voyant ?

Oui, mais qui es-tu pour juger de ce que serait supperflu pour un mal/non-voyant ?

Gothor a écrit :
Ah, et qu'en est-il du JavaScript ? Il permet parfois de générer une grosse partie du code html (je sais, ce n'est pas bon, je ne soutiens pas cette façon de faire, mais elle existe...)

Effectivement, et c'est pour cela que ce n'est pas bien de générer du contenu avec JavaScript.
Modifié par Felipe (29 Jan 2012 - 18:00)

Salut,

Je complète les propos de Laurie-Anne.

Un lecteur d'écran offre la possibilité de consulter une page Web de façon non linéaire. Par exemple, un utilisateur de lecteur d'écran peut parcourir la page titre par titre, lien par lien, liste par liste, voire paragraphe par paragraphe, et ce grâce à des raccourcis clavier ; de même, des raccourcis clavier lui permettent d'afficher une boîte de dialogue listant tous les liens présents dans la page ou tous les titres présents (ainsi que leur niveau).

Quant au JavaScript, les lecteurs d'écran y ont accès désormais, de même qu'ils peuvent lire du Flash. Même s'il est logique de fournir une alternative au JavaScript et au Flash, il ne faut pas négliger de rendre accessibles le JavaScript et les objets Flash.

Gothor a écrit :
je ne peux pas voir la structure du site.
Désactive les CSS Shift-Ctrl-S avec la Web Developer Toolbar sous Firefox

[quote=Gothor]Pour ce qui est des images, que va-t-il lire ? L'attribut alt ou title ? Même s'il s'agit d'un lien ?

Laurie-Anne a écrit :
L'attribut alt, toujours. Une image n'est pas sencée avoir d'attribut title (sauf cas très particuliers). Suivant la configuration du lecteur d'écran, le title sera lu sur les liens (raison pour laquelle il ne faut pas en abuser).

Il y a des personnes qui ne verront à coup sûr pas les title sur les liens, ce sont ceux qui naviguent sans souris mais avec un clavier ou équivalent, avec la touche tabulation, puisque les navigateurs sont buggés. L'infobulle n'apparait pas quand on tabule, seulement en survolant avec la souris (et encore, brièvement).
En passant les smartphones et tablettes ont pas trop de souris non plus pour faire apparaître les infobulles, mais ce n'est pas de l'accessibilité.

Gothor a écrit :
Sait-on si les nouveautés de HTML5 vont permettre une meilleure accessibilité aux non-voyants ? (Avec des raccourcis sur leurs machines pour accéder directement au contenu, au menu, etc. étant donné que de belles balises ont été créées comme nav, section, details, etc.)

Un peu oui. Mais c'est surtout une autre norme, ARIA, qui va permettre de faire correctement ce que tu as en tête.
Une machine ou un logiciel ne peut pas deviner seul quel élément nav parmi 12 dans une page est LE menu de navigation, s'il y en a d'autres, etc
Enfin avant de penser à ARIA, il faut déjà respecter LA norme d'accessibilité qu'est WCAG 2.0. Avoir un code HTML pertinent, une hiérarchie de titres correcte et des liens utiles est plus important que de rajouter des trucs super avancés. Et HTML4 permet tout ça, y a pas d'excuses.

Gothor a écrit :
Ah, tiens, est-ce pour ça que certains sites ont ces liens en haut ?

Ce site (alsacreations.com) Mais c'est mal implémenté, enfin pas aussi bien que ça le devrait. Place ton curseur dans la barre d'adresse (Ctrl-L ou F6 ou avec ta souris), appuie 10 fois sur Tab et tu verras les liens en question (qui ne disparaissent pas quand ils perdent le "focus" clavier).

L'idéal est qu'ils soient apparents tout le temps. Tous les sites labellisés par l'association Accessiweb le sont par exemple, c'est un critère obligatoire du référentiel qui sert de base à la labellisation. http://www.accessiweb.org/index.php/galerie.html
Les sites publics qui doivent respecter le RGAA ont cette obligation également, et le mieux c'est qu'on en trouve quelques-uns qui en disposent.

À défaut, que ces liens d'accès rapide soient visibles si JS est désactivé et qu'avec JS activé ils soient placés hors écran mais redeviennent visibles dès l'instant où ils sont parcourus (et qu'ils le restent une fois que le dernier a perdu le focus).
Alsacreations.com fait presque ça : sans JS ils ne sont pas visibles en permanence, juste au moment de la prise de focus.
Les mauvaises manières de faire, c'est de les cacher avec display: none; en CSS (les lecteurs d'écran les ignoreront, utilité zéro), de les placer hors écran avec left: -9999px ou text-indent négatif et de les y laisser ou de les camoufler en blanc sur blanc ou autre couleur et de ne prévoir rien d'autre au focus/survol (dans les 3 cas les lecteurs d'écran les liront mais les voyants qui utilisent le clavier ne pourront pas les voir, eux), d'avoir des liens vers des ancres qui n'existent pas, etc
Tuto de jpv sur ce site : http://www.alsacreations.com/article/lire/572-Les-liens-d-evitement.html

Gothor a écrit :
Peut-on avec css empêcher la lecture de certaines données qui pourraient sembler superflues pour un mal voyant ?

Même réponse que Laurie-Anne Ce n'est pas à nous de décider.
Il est possible de faire l'inverse mais déjà seuls les lecteurs d'écran les percevront et ce n'est de très loin pas la majorité des utilisateurs handicapés qui se servent d'un lecteur d'écran et c'est réservé à des cas particuliers, à moins de bien s'y connaître en accessibilité, ce sera en général mal fait ...

Gothor a écrit :
Ah, et qu'en est-il du JavaScript ? Il permet parfois de générer une grosse partie du code html (je sais, ce n'est pas bon, je ne soutiens pas cette façon de faire, mais elle existe...)

Les personnes handicapées qui activent JS percevront strictement la même chose que les autres qui activent aussi JS. Soit elles utilisent le même navigateur que toi et moi, soit le même navigateur avec une assistance technique. Cette assistance technique se sert de ce que lui envoie le navigateur donc pas ce qu'envoie le serveur (code HTML brut) mais "la totale" : HTML, CSS (3 aussi), DOM modifié par JS, d'autres technos, etc

Les personnes qui désactivent JS vont rater tout ça mais ça concerne quelques personnes handicapées ET pas mal d'autres : dans certaines grandes entreprises avec des admins qui bloquent JS, les utilisateurs de NoScript et autres raisons de sécurité, (absence de ) performance (mauvais réseau mobile ou 56k ou machine faiblarde), etc
Impossible de deviner, faut prévoir les 2 cas.

Cas particulier quand même : un lecteur d'écran lit du début à la fin (entre autres). Si le contenu de la page est modifié vers le début de la page alors que la lecture en cours approche de la fin, le non-voyant ne saura pas qu'il y a eu modification plus haut dans la page. Oups.
Modifié par Felipe (29 Jan 2012 - 18:59)

Après quelques jours...

Merci beaucoup à vous trois !

Laurie-Anne a écrit :
Ensuite, attention, l'accessibilité le se limite pas au problème de vue !

Quels autres problèmes sont concernés par l'accessibilité et comment y remédier ?
Le fait de mettre en page un document pour plusieurs supports fait-il partie de l'accessibilité ? (smartphone, imprimerie, etc.)

Victor BRITO a écrit :
il ne faut pas négliger de rendre accessibles le JavaScript et les objets Flash.

Comment rendre une application Flash accessible ?

Laurie-Anne a écrit :
Oui, mais qui es-tu pour juger de ce que serait supperflu pour un mal/non-voyant ?

Un simple voyant qui ne connais même pas de mal/non-voyant, donc difficile de juger en effet ^^
Mais il est certaines applications (par exemple en Flash, vu qu'on en parlait juste au dessus) qui sont présentes uniquement pour décorer ou qui auraient peut-être un contenu trop complexe. Je n'ai pas énormément travaillé sur Flash, mais je pense que ça ne doit pas être évident de faire un site en Flash vraiment accessible.
On peut-être peut-on penser à une page dont le contenu affiché sur les écrans serait un site en Flash et un code HTML présent, mais non visible (enfin, il y a toujours un moyen) afin d'éviter justement de séparer en deux pages le contenu pour les écrans et celui pour les non voyants ?

Oui, ce n'est pas beaucoup de remarques, mais je n'ai pas beaucoup de question par rapport aux vôtres, c'était si complet ^^'

Gothor a écrit :
Quels autres problèmes sont concernés par l'accessibilité et comment y remédier ?

Liste non exhaustive des handicaps concernés par l'accessibilité du Web :
* déficience visuelle,
* surdité,
* troubles de la perception des couleurs (daltonisme),
* problèmes de motricité empêchant de manier avec dextérité une souris,
* utilisation d'un poste de travail où JavaScript est désactivé,
* utilisation d'un poste de travail où des plug-ins comme Flash sont désactivés,
* handicaps temporaires (bras cassé).

Pour y remédier, il est impossible de tout dire de manière synthétique en un message. Le mieux est de suivre une formation à l'accessibilité du Web, comme celles dispensées par Braillenet.

Gothor a écrit :
Le fait de mettre en page un document pour plusieurs supports fait-il partie de l'accessibilité ? (smartphone, imprimerie, etc.)

Je ne serais pas aussi catégorique ; mais, c'est une très bonne pratique de servir une même page Web quels que soient les supports de consultation utilisés.

Gothor a écrit :
Comment rendre une application Flash accessible ?

Une conférence donnée à Paris Web en 2009 a évoqué ce sujet (vidéo et slides).

Tu peux lire cette documentation si tu désires vraiment approfondir le sujet, (ce n'est d'ailleurs pas le seul document).

http://www.braillenet.org/accessibilite/comprendre-wcag20/CAT20110616/Overview.html

a écrit :
Quels autres problèmes sont concernés par l'accessibilité et comment y remédier ?

La liste des handicaps est trop longue à énumérer mais voici quelques cas qui peut-être te feront comprendre que ça ne se limite pas à la vue :

_Personnes qui tremblent (navigation clavier).
_Personnes trop lentes (limitation temps).
_Personnes qui ne peuvent bouger ou difficilement (navigation clavier et limite de temps).
_Personne avec une vue limitée (bonne hiérarchie visuelle, possibilité d’agrandir le texte, bon contraste de couleur)
_Personne sensible à certains contenu (ex:épilepsie, daltoniens) (bon mélange de couleurs, pas de scintillement, pas de rouge vif)

Tu as par exemple cette page qui te donne quelques technologies d'assistance utilisées http://www.ideose.eu/documents-accessibilite/handicap-moteur/les-technologies-assistance/ pour le cas des handicaps (limitations) moteurs.

a écrit :
Le fait de mettre en page un document pour plusieurs supports fait-il partie de l'accessibilité ? (smartphone, imprimerie, etc.)

Non pas vraiment, bien que la capacité d'une site à s'adapter à plusieurs supports est un plus.

a écrit :
Comment rendre une application Flash accessible ?

Voir plus haut "comprendre les WCAG 2.0"

Gothor a écrit :
Quels autres problèmes sont concernés par l'accessibilité et comment y remédier ?

... sans oublier les handicaps cognitifs, souvent omis, comme les personnes ayant des troubles de l'apprentissage (mémoire à court/long terme, qui peut compliquer la navigation; dyscalculie...), de la compréhension (problèmes avec les textes complexes ou la syntaxe "cryptique", comme les SMS...), de lecture (dyslexie...)

En fait, un des principes qui sous-tendent les WCAG est qu'il est présomptueux et peu productif d'essayer d'imaginer des situations de handicap pour en déduire des règles de construction de page ou de design. Le plus efficace est de garder en tête que quel que soit l'utilisateur, il accède à un contenu en se servant d'un outil. Or il existe des règles pour ces outils, qui assurent qu'ils restituent le mieux possible un contenu correctement écrit (ce sont les User Agent Accessibility Guidelines - UAAG). Donc écrire pour ces outils, c'est optimiser ses efforts afin de garantir un rendu acceptable quel que soit l'outil de consultation des contenus utilisé.

Gilles a écrit :

Le plus efficace est de garder en tête que quel que soit l'utilisateur, il accède à un contenu en se servant d'un outil. Or il existe des règles pour ces outils, qui assurent qu'ils restituent le mieux possible un contenu correctement écrit (ce sont les User Agent Accessibility Guidelines - UAAG).

Travaillant depuis quelques mois dans un atelier informatique pour handicapés, j'ai pu constater qu'ormis un ou deux clavier/joystick spécifique et deux systèmes de zooms, la majorité utilisent les même outils que les non-handicapés. Un navigateur, une souris et/ou un clavier. Même si certains outils existent, il faut en avoir connaissance, avoir les moyens ou l'envie d'investir les moyens pour se les offrir, pouvoir obtenir une formation à l'utilisation correcte, etc.

Dès lors, un design graphique de qualité, qui place en premier lieu la bonne compréhension du contenu, et qui établit une hiérarchie simple, claire et intuitive, est un élément essentiel de l'accessibilité. En plus, ce sera un atout pour les visiteurs sans handicaps. Si l'intérêt du w3c n'est plus à prouver, le consortium a plus d’intérêt à défendre le web sémantique que finalement l'accessibilité. Si un web clair et sémantique est indubitativement un avantage, on le rapporte trop souvent à l'accessibilité, alors que la métadonnée est plutôt le nerf de la guerre en terme d'économie des réseaux.

Voilà c'était mon coup de gueule, tout ça pour dire que l'accessibilité se fait aussi et pour beaucoup sur le visuel.

Coucou Gothor,

Une bonne solution consiste à prendre contact avec des non-voyants ... et se placer physiquement derrière eux pour voir comment ils travaillent. J'avoue que ça m'a permit de découvrir tout un tas de problèmatique nouvelle, et mettre de côté certains problèmes que je pensais plus dérangeant.
Bon, il existe beaucoup d'écart de pratique entre DV : ceux qui préfère les synthèses vocales, ceux qui privilégie le braille, etc.
Un truc qui m'a beaucoup surpris, c'est que globalement, ils ont beaucoup plus de patience que les gens valident. N'étant pas moi même un impulsif, ca m'a donné un point commun avec les différents joueurs/admin DV de mon projet.

Il y'a beaucoup de non-voyants/mal-voyants sur le net. Ca ne devrait pas être trop difficile de prendre contact, surtout si ton objectif est globalement l'avancé de l'accessibilité sur le Web.

kéké
Modifié par keke (07 Feb 2012 - 15:17)

Bonsoir,

kéké, j'aurais en effet voulu voir comment travaillaient les non voyants, mais je m'imagine mal aller voir un mal-voyant lui demander : "Bonjour, je peux venir voir comment vous utiliser internet ?" =°

Merci encore à tous pour vos réponses =)

Et bien pourquoi pas? Là où je travaille des demandes similaires sont fréquentes. Prend contact avec une institution/association dans ta région qui répondront probablement favorablement à ta demande s'ils connaissent des mal-voyants utilisant internet.
Généralement, une personne souffrant d'un handicap n'est pas réfractaire aux initiatives visant à améliorer l'accessibilité .

@kustolovic Quand je parle d'outil, je ne fais pas référence uniquement à des outils spécialisés. Un navigateur graphique est un outil