Questionnaire pour l'accessibilité du Web

[Guest Manue&Marc]

Bonjour,

Nous sommes deux étudiants ingénieurs informaticiens et dans le cadre de notre projet de fin d'étude, nous devons nous pencher sur l'accessibilité du Web aux malvoyants. Afin de proposer des solutions pour aider les webmasters à rendre leur site accessible, nous avons élaboré un questionnaire uniquement destiné aux personnes malvoyantes naviguant sur le net. Ce questionnaire a pour but de nous renseigner plus précisément sur l'ergonomie des sites et la façon de naviguer des malvoyants. Pour cela, il nous faut un certain nombre de réponses pour créer au final un modèle type de site adpaté. Si vous vous sentez concerné par notre démarche, merci de bien vouloir le remplir à partir du lien suivant:

http://www.hant.li.univ-tours.fr/questionn...stionnaire.html

Manue et Marc

[Nissone]

Bonjour Manue&Marc,

n'étant pas malvoyante, je ne répondrais pas à votre questionnaire mais j'espère que vous nous tiendrez au courant de votre projet et des résultats de ce sondage ; je suis sûre que cela intéresse beaucoup d'entre-nous ici

[Gribouille26]

Bonjour,

Je ne le suis pas moi-même, mais le Hub compte quelques membre defficients visuels.

Nous avions déjà tenté de faire un questionnaire sur le sujet, et de le faire circuler avec l'aide d'un membre mal-voyant...

Malheureusement, le taux de participation à ce questionnaire a été quaziment nul!

Il semblerai qu'ils préférent ne pas avoir de traitements spéciaux, ni même vraiment s'expliquer sur la question...

J'espère que tu aurras plus de chance et que tu nous feras part de tes résultats!

[Loupilo]

Étant voyant, je ne répondrai pas à votre sondage, mais je suis tout de même interpellé par

*Navigateur courant (Internet Explorer)

*Navigateurs spécifiques (Mozilla, Opéra, Firefox,�)

En quoi Firefox et Opéra ne sont pas des navigateurs courants ?

En quoi sont-ils "spécifiques" ?

Et tu poses beaucoup de questions sur l'accessibilité... des sites accessibles !

Par définition, un site accessible est accessible, non ?

*Selon vous, le plan dŽun site accessible est tŽil facile à trouver ?

*Les champs de saisie (recherche, etc.) présents dans les sites accessibles sont-ils facilement utilisables ?

Je ne comprend pas trop ça... Si le site est accessible, le plan est facile à trouver et le champ de recherche est adapté et simple...

Sinon, les questions sont assez pertinentes, esperons que le sondage aura du succès

Loupilo.

[iubito]

j'ai répondu, mais comme j'ai expliqué dans un long commentaire à la fin, la place du menu ou du champ de recherche c'est pas le plus important, mais des questions sur des p'tits détails (les <label> pour les cases à cocher, la "profondeur" des menus...) sont les petits plus et moins qui facilitent la navigation...

[jpv]

Pourquoi restreindre le questionnaire à l'accessibilité des "mal-voyants"...

L'accessibilité ne concerne pas que les déficits visuels mais aussi les déficits moteurs et cognitifs.

Par exemple la gestion de la navigation au clavier est un élément crucial d'un site web qui veut être accessible.

De même les enchainements d'action sur les formulaire et la navigation interne sont des éléments à prendre en compte pour tous les déficits cognitifs...

Dernier exemple la taille de certain lien image ou la nature et la gestion des actions de focus sur les objets de la page sont également un point très important.

Certe, les déficits visuels sont les plus caractéristiques et bénéficient de toutes les attentions en terme d'accessibilité, ce qui est nomal, mais il ne faudrait pas que cela soit fait au détriment des autres handicaps.

Votre projet de fin d'étude si il ne concerne que le handicap visuel risque fort de louper sa cible, confère la citation de Tim Berners Lee sur ce sujet :

"Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales."

[Valhala]

Je sais pas pour vous mais moi j'ai du mal a trouvé un compromis entre optimisation et respect des règles 508 sur les 3 propriétés.

J'ai éssayé de mettre mon site conforme a ces règles mais il faut tellement rajouter de codes que la page devient lourde rien que a cause de ca.

[Guest Manue&Marc]

Après quelques semaines, nous revenons pour faire un peu le point sur les résultats du questionnaire. Les réponses que nous avons reçues nous ont permis de définir certains points aidant à la navigation des personnes déficientes. Comme l'a fait remarqué iubito (d'ailleurs, merci pour ta réponse ), on ne peut pas définir un modèle type d'un site en disant qu'il faut placer telle chose à tel endroit, mais le but et de faire en sorte que le visiteur (qu'il soit déficient ou non, tous les visiteurs sont concernés) puisse facilement naviguer sur le site sans se perdre dans l'arborescence du menu. Il faut donc que le site soit structuré correctement, l'arborescence doit être équilibrée, et chaque menu et sous-menu ne doit pas contenir un trop grand nombre de rubriques. Ensuite, pour les personnes déficientes, il faut faire attention à la profondeur de l'arborescence car certaines d'entre elles ont plus de mal à retenir le chemin qu'elles ont parcourut.

Ensuite, il faut penser à mettre en place quelques "outils" pratiques pour les visiteurs, par exemple retracer le chemin parcouru depuis la racine du menu vers la page courante, ajouter des liens "retour", faire en sorte que le menu, le plan du site et le moteur de recherche soient toujours accessibles depuis n'importe quelle page du site.

Ce ne sont que des détails mais il clair que si nous faisons attention à tout cela durant la construction d'un site, la navigation sera bien facilité. D'ailleurs, tous ces points sont aussi valables pour les personnes non déficientes car si la navigation est facilitée pour les personnes déficientes, elle le sera aussi pour les personnes non déficientes.

Sinon, pour répondre à jpv, notre travail consiste avant tout à savoir ce qui est nécessaire pour rendre un site accessible aux mal voyants et aux non voyants. Cependant, il ne faut pas oublier que les directives de la WAI sont là pour guider les webmasters à rendre un site accessible aux personnes handicapées et non spécifiquement aux déficients visuel. Donc nous n'oublions pas les gens qui ont une déficience motrice ou cognitive mais nous nous concentrons, dans un premier temps, aux personnes ayant un handicap visuel.

Nous remercions tous ceux qui ont répondu au questionnaire et ceux qui nous ont aidés ou soutenus.

Manue & Marc

[jpv]

par exemple retracer le chemin parcouru depuis la racine du menu vers la page courante, ajouter des liens "retour", faire en sorte que le menu, le plan du site et le moteur de recherche soient toujours accessibles depuis n'importe quelle page du site.

La question des liens "retour" est un cas d'espèce à ne pas généraliser, dans la mesure où ça viens se rajouter d'une part à la fonctionnalité page précédente du navigateur et d'autres parts aux fonctionnalités propres au logiciel adapté utilisé par le visiteur mal-voyant.

Tous les lecteurs d'écrans et navigateur vocaux possèdent leur propre gestion de l'historique ainsi que leur propres raccourcis.

Il apparait donc inutile de rajouter, en plus de ces mécanismes logiciel un lien "retour" généralisé, si celui-ci n'apporte rien de plus à ces mécanismes natifs.

Par contre il peut être très pertinent d'utiliser un lien retour pour revenir à l'origine d'un processus d'enchainement d'action.

Par exemple une série de formulaire enchainé à tout intérêt à utiliser un dispositif de ce type pour pouvoir revenir à l'étape 1.

Très utile également dans le cas d'affichage séquencé de type slideshow intégré à une page.

La remarque vaut également pour le fil d'ariane qui est rès efficace dans une structure linéaire simple (page-rubrique-sous-rubrique) mais deviens plus difficilement gérable si la structure deviens plus complexe.

N'oubliez pas que les logiciels adaptés possèdent leur propre gestions de l'historique de navigation qui sera plus familier à l'utilisateur.

Une bonne définition du titre des pages et un plan du site suffiront dans la majeure partie des cas, sans qu'il soit nécessaire de doubler ce dispositif "simple" par des dispositifs annexes plus sophisitiqués.

l'arborescence doit être équilibrée, et chaque menu et sous-menu ne doit pas contenir un trop grand nombre de rubriques.

Là encore la généralisation est délicate, si il est souhaitable qu'un élement de menu ne contienne pas trop (trop combien ?) d'items, il est par contre fortement déconseillé de créer artificiellement des arborescences inutilement compliqués pour restreindre le nombre d'items d'une liste de menu.

Par ailleurs cette remarque est en contradiction avec la carte d'un site qui est, par définition, la page contenant le plus grand nombre de liens internes du site.

Par exemple, accessiweb à formalisé cette approche en mesurant et en rendant "obligatoire" les limites de 9 catégories pour l'arborescence d'un menu et 40 liens pour le nombre de liens de la page "hors liens de navigation".

Le WCAG 1.0, référence d'accessiweb ne donne aucune limite, mais note simplement que la navigation doit être cohérente.

D'aure part ces limites sont par essence innaplicables, par exemple le grand chalon, labellisé accessiweb OR possède au moins une page possédant plus de 40 liens hors navigation.

Si on applique stricto-sensu la regle des 9 catégories à un annuaire, ou un catalogue en ligne comment fait-on ?, certains catalogue ne pouvant pas se réduire à 9 catégories, problème encore plus ardus avec un annuaire généraliste.

C'est le grand avantage du WCAG 1.0 qui de ce point de vue demande à l'auteur d'interpréter ces règles et de les adapter à la réalité du contenu.

Il faut donc faire très attention de bien faire comprendre que ces dispositfs et ces recommandations doivent être analysés en fonction de la réalité du contenu et du projet éditorial, faute de quoi on prends le risque de faire apparaitre ces dispositions comme restrictives, ce qu'elles ne sont pas, en tout cas dans l'esprit du WCAG 1.0

Je persiste également à penser que focaliser l'accessibilité sur les mal-voyants est une approche dangereuse en ce qu'elle ne permet pas d'évaluer les dispositifs à mettre en place dans leur globalité et que d'autre part les dispositions spécifiques à ces autres handicaps sont notoirement insuffisants comme la gestion calamiteuse des accesskey par exemple.

Et plus généralement cela me parait un chouia discriminatoire..

Modifié 26 Janvier 2005 par jpv

[Guest Manue&Marc]

jpv > nous sommes tout à fait d'accord sur le fait qu'il ne faut pas généraliser les points que nous avons retenus à tous les sites. Effectivement, certains sites seront des cas particuliers qui demanderont une étude un peu plus spécifique. Mais justement, notre but, pour le moment, est simplement de trouver des points auxquels il faut prêter attention si l'on veut faciliter la navigation. Donc, forcément, notre démarche est assez généraliste et nous ne prenons pas en compte les cas particuliers.

Concernant les restrictions proposées par Accessiweb, nous pensons également qu'il ne faut pas les prendre au "pied de la lettre" car certains sites, s'ils appliquent ces pseudo-normes, perdront de leur cohérence au niveau de la structure.

Je persiste également à penser que focaliser l'accessibilité sur les mal-voyants est une approche dangereuse en ce qu'elle ne permet pas d'évaluer les dispositifs à mettre en place dans leur globalité et que d'autre part les dispositions spécifiques à ces autres handicaps sont notoirement insuffisants comme la gestion calamiteuse des accesskey par exemple.

Nous ne les oublions pas, c'est simplement que nous commençons par traiter le cas des mal voyants Et puis, n'oublie pas que si les directives de la WAI sont mises en application sur un site alors celui-ci est accessible aux personnes handicapées, pas seulement aux déficients visuel

Modifié 26 Janvier 2005 par Manue&Marc

[Monique]

Bonjour,

J'aimerai savoir...

Dans les réponses que vous avez reçues, tous les types de navigateurs étaient-ils représentés ?

Avez-vous constaté des différences notoires dans les réponses selon le navigateur utilisé ?

[jpv]

_AT_manu&marc :

Effectivement, certains sites seront des cas particuliers

En fait la réalité du terrain c'est plutôt que chaque site est un cas particulier...

Dans les missions d'audit que je mène, je m'interesse d'abord à la structure du site et au layout avant même de plonger dans le détails des adaptations, car il est souvent très facile en modifiant l'architecture des pages et la gestion du flux de résoudre énormément de problèmes sans avoir besoin de les traiter ultérieurement par le WCAG 1.0.

Pour ne prendre que cet exemple, exprimer des listes de lien avec des éléments de listes fixe la règle des liens adjacents sans qu'il soit nécessaire de recourir au célébrissime "pipe", sans modification notable du design.

Je suis venu à l'accessiblité par l'entremise d'une amie tétraplégique utilisant un head-stick et pour cette sorte de public la navigation internet est un véritable défi, face aux improvisations des architecture de liens.

Quand aux accesskey ils sont très difficilement utilisables pour les handicaps moteurs, même si ils sont correctement implémentés.

Essayez avec un seul doigt de déclencher un accesskey numérique avec le clavier en mode "accessibilité", vous vous rendrez compte de la bonne blague...

C'est pourquoi je suis toujours un peut méfiant quand accessibilité= mal et non-voyants car on ne règle qu'une partie du problème (Il y à plus de handicaps moteurs que de non-voyants)

Accessiweb n'est pas une nome ni une pseudo-norme mais selon la définition qu'en donne l'ADAE une "méthode d'application" reprise in-extenso dans son référentiel qui va servir de cadre d'application des futurs décrets.

Braillenet fait du super boulot, surtout en terme de sensibilisation, mais on peut regretter que leurs grilles d'évaluations se focalisent essentiellement sur les handicaps visuels (c'est leur coté braille) et n'apporte pas autant d'importance à l'utilisation de langages standardisés et de leur répercussions éminement positives sur le layout.

En tout cas, bravo pour votre travail et M... pour la suite...