1159 sujets

Accessibilité du Web

Bonjour,

Je suis en train de mettre en place une page essayant de définir une procédure complète de validation de page :
http://www.acces-pour-tous.net/validateur/index.php
C'est encore en travaux et trop tôt pour une critique mais j'ai d'ores et déjà une question. A votre avis l'utilisation d'un lecteur vocal comme Jaws est-elle indispensable dans un processus d'auto-validation(1) ? Un usage réfléchi et commenté d'un navigateur en mode texte et/ou d'une extension comme Fang peut-il être suffisant.
Je suis déjà convaincu de l'utilité d'un tel logiciel mais là il s'agit de trouver un compromis entre la facilité de validation et le bien fondé de celle-ci.

(1) C'est à dire une validation effectuée directement par l'auteur de la page, non pas par un professionnel ou dans le cadre d'un label.
Bonjour,

Il me semble que dans un souci de facilité l'usage de Jaws n'est pas indispensable. Comme tu le dis, "un usage réfléchi et commenté d'un navigateur en mode texte et/ou d'une extension comme Fang" doivent permettre de détecter les difficultés liés à l'accessibilité. (je crois que les mots "réfléchi" et "commenté" sont les plus importants de cette phrase <sourire>)

Pour ma part, j'ai constaté que je n'utilisais finalement qu'assez peu souvent jaws (et autre synthèses vocales ou navigateur vocaux) au cours des audits. La raison est claire : quand (par bonheur) on a le choix, c'est vraiment pénible et fatiguant de naviguer avec ce type d'outil et si je peux vérifier avec lynx ou une barre d'outil, c'est cette dernière option que je choisis.

Cordialement,
Moi je trouve que ça peut être un plus pour les développeurs que de tester avec une synthèse vocale comme jaws.
Ca peut vous donner une idée de comment c'est... si c'est facile, ou pas de naviguer dans tel ou tel site.

Rappel : la version de démo est gratuite.
Une fois démarrée, elle ne fonctionne que pendant 40 minutes, mais il suffit de rebooter la machine pour qu'elle fonctionne à nouveau, et cela indéfiniment.
Ba je répondrai catégoriquement :

il faut tester avec un lecteur d'écran, et une alternate stylesheet


body {
background:#000;
}

body * {
color:#000;
}


pas mal de problèmes deviennent franchement criant.

Il faut de plus ne pas faire ce travail sur une page mais au minimum une dizaine. Une ébauche de site donc, parce que là les problèmes deviennent carrément hurlant (à hurler).
Modifié par clb56 (20 Sep 2005 - 19:37)
faites gaffe quand même : jaws interprète display:none et visibility:hidden. Ce qui, pour moi, est normal. On ne veut pas afficher le contenu, donc, on ne doit pas l'entendre non plus, c'est pareil et complètement logique.
Administrateur
QuentinC a écrit :
faites gaffe quand même : jaws interprète display:none et visibility:hidden.

Pas obligatoirement : "display" et "visibility" sont objectivement des propriétés d'affichage (donc a priori de média screen et non de media speech).
Je dis peut-être une bêtise, mais pour ma part, ça ne me paraît pas si logique que ça.
Raphaël > certes, mais display et visibility commandent le fait qu'on voie ou non le contenu. Si on ne voit pas le contenu à l'écran, il est por moi très logique qu'un lecteur d'écran ne lise pas le contenu s'il n'est pas affiché. Un lecteur d'écran n'est que censé transformer le texte présent sur ce média en parole pour le rendre acessible quand on a pas la chance de pouvoir regarder un écran.
Raphael a écrit :

Pas obligatoirement : "display" et "visibility" sont objectivement des propriétés d'affichage (donc a priori de média screen et non de media speech).
Je dis peut-être une bêtise, mais pour ma part, ça ne me paraît pas si logique que ça.


Une demi-bêtise, en fait Smiley cligne . Précisons ce qu'il en est, car le détail est un peu compliqué :

Du point de vue de l'implémentation, display n'est pas finalement une propriété d'affichage, en dépit de son nom et de ce que la spécification peut laisser supposer au premier abord. C'est bien une propriété de rendu valable quelque-soit le media, y compris aural et speech. La norme vers laquelle on s'achemine en effet serait que :
- un display:none sans précision de media (ou "all") s'applique dans un navigateur vocal comme dans un navigateur graphique,
- un display:none restreint au media screen ne s'applique pas dans un navigateur vocal.
- un display:block dans une CSS speech annule un display:none précédemment fixé pour tous les medias, en fonction des règles de la cascade (tout comme on le pratique pour une CSS print qui modifie le display d'une CSS all).

La confusion sur display et le média speech vient de ce que cette propriété est présentée par CSS2.x au chapitre du modèle de rendu visuel. Mais si on revient sur le modèle de traitement CSS2.x, on voit qu'il y a ambiguïté, car display supprime un élément (présent dans l'arbre du document) de la structure de formattage. Et ce n'est qu'après établissement de la structure de formattage que celle-ci est transférée vers le media. On peut en conclure qu'un display:none est valable quelque-soit le media.

On pourrait objecter que display ne devrait pas être retenu au moment où s'établit la structure de formatage, car cette propriété pourrait être écartée à l'étape précédente du traitement, lorsque chaque élément est annoté avec des valeurs de propriétés en rapport avec le media cible. Mais le choix de ne pas procéder ainsi dans les implémentations, face à l'ambiguïté de la spécification, répond à une contrainte évidente pour les navigateurs vocaux et pour les lecteurs d'écran : si le document tel qu'il est lu a un contenu différent du contenu affiché, cela n'aura pas de sens pour un utilisateur, mal voyant ou non, qui utiliserait simultanéement les deux medias (comme on peut le faire actuellement avec Opera, Jaws, IBM HPR, etc). Le problème est encore plus criant dans une page Web avec interaction vocale. Il aboutirait à des situations ingérables dans les "verticals" (une application d'aide à la conduite embarquée dans un véhicule, par exemple).

visibility, en revanche, est sans ambiguïté une propriété propre aux medias visuels (screen, projection, handheld, print et tv) : son équivalent pour le media speech est la propriété speak.

Notons que si display était exclu du media speech, on ne pourrait retrouver un contenu identique à l'écran et en lecture que si un speak:normal pouvait annuler un display:none... ce qui serait totalement aberrant du point de vue de la logique des propriétés CSS. Sans compter le fait qu'un display:none appliqué à un élément parent n'est pas annulable pour un élément enfant, alors qu'un speak:none appliqué à l'élément parent peut-être annulé par un speack:normal pour un élément enfant... Bref, speack ne peut pas être l'équivalent de display, raison supplémentaire pour que celui-ci soit valable pour tous les medias.

Concernant le comportement des lecteurs d'écran actuels, la situation est brouillée par le fait que Jaws, IBM HPR, etc. ne sont pas actuellement des applications conformes à CSS.
- les media ne sont pas pris en compte correctement. Un display:none dans une CSS screen sera appliqué, et ne pourra pas être annulé faute de support des CSS aural ou speech.
- visibility est l'objet d'un second problème d'implémentation. Il ne devrait en aucun cas être pris en compte, mais il l'est souvent.
- display:none et visibility hidden seront ou non pris en compte en fonction d'une troisième série de problèmes d'implémentation, qui concerne le type de lien vers la feuille de style, selon le choix entre les éléments link, style, l'instruction xml stylesheet et leurs syntaxe précise (situation comparable à la prise en compte des CSS screen par les mobiles).

Au bout du compte :
- pour comprendre en pratique ce que donneraient des implémentations conformes, voir Opera 8.x qui implémente ce qu'il faut de manière correcte. Même si c'est encore marginal pour l'accessibilité, le fait qu'il existe au moins un navigateur vocal conforme est très bon signe pour l'avenir.
- pour les lecteurs d'écran actuels, étant donné la confusion des implémentations, éviter en effet de jouer sur ces deux propriétés.
Modifié par Laurent Denis (21 Sep 2005 - 07:51)
Bonjour,
stephkup a écrit :
A votre avis l'utilisation d'un lecteur vocal comme Jaws est-elle indispensable dans un processus d'auto-validation(1) ? Un usage réfléchi et commenté d'un navigateur en mode texte et/ou d'une extension comme Fang peut-il être suffisant.

Pour une auto-validation par un non professionnel, je rejoins l'avis d'Eric.

Si on en fait pas un usage régulier permettant d'acquérir des automatismes, la navigation à l'aide d'une synthèse vocale est très laborieuse et peut rebuter un non professionnel.
Le temps de trouver (ou retrouver) ses marques, d'assimiler un minimum de raccourcis clavier indispensables (qu'on oublie vite en cas d'utilisation occasionnelle)... les 40 minutes sont vite passées Smiley ohwell

Je ne verrais donc pas l'utilisation d'une synthèse vocale comme passage obligé dans un tel processus de validation.
Par contre, en remarque, il serait certainement utile de préciser que si des outils comme Lynx et Fang permettent de déceler les obstacles présents sur un site, seule la visite de celui-ci en conditions réelles (avec l'aide technique adéquate) permet d'en saisir l'impact sur la navigation.