28220 sujets
Concernant les modèles, je partage cet avis.
Comme j'ai pu le préciser, ce up fait suite à des questions posées dans le salon "handicap et accessibilité", notamment concernant la lecture d'un référentiel sur ce point, à savoir :
Dans le contexte de ce fil, je m'appuie sur ce modèle à titre d'exemple pour essayer de comprendre ou plus exactement d'identifier les critères qui vont amener telle ou telle structure ... dans ma quête de l'accessibilité et l'intégration des comportements spécifiques aux équipements adaptés.
Et, un exemple est parfois plus parlant que 3 pages d'explications verbales .
En l'occurence, je ne "matérialise pas" ce cas :
Mais je vais y réfléchir !
Modifié par Vero (02 Sep 2005 - 17:48)
Comme j'ai pu le préciser, ce up fait suite à des questions posées dans le salon "handicap et accessibilité", notamment concernant la lecture d'un référentiel sur ce point, à savoir :
a écrit :
L'ordre d'apparition de l'information doit être identique lorsqu'une mise en forme spécifique est désactivée.
Certaines techniques permettent de construire la page html avec des feuilles de styles. Lorsque les feuilles de styles sont désactivées par l'utilisateur, il faut que la structure logique de la page soit respectée.
Il faut veiller que l'ordre d'apparition des divisions (DIV), par exemple, soit équivalent entre l'affichage sur un navigateur graphique et l'affichage sur un navigateur en mode textuel.
Dans le contexte de ce fil, je m'appuie sur ce modèle à titre d'exemple pour essayer de comprendre ou plus exactement d'identifier les critères qui vont amener telle ou telle structure ... dans ma quête de l'accessibilité et l'intégration des comportements spécifiques aux équipements adaptés.
Et, un exemple est parfois plus parlant que 3 pages d'explications verbales .
En l'occurence, je ne "matérialise pas" ce cas :
jpv a écrit :
Le cas que j'essayais d'illustrer est surtout celui ou des liste de liens intermédiaires pourraient créér une confusion avec le menu de navigation principal.
Mais je vais y réfléchir !
Modifié par Vero (02 Sep 2005 - 17:48)
a écrit :
Le mieux pour arriver à ce résultat est bien un lien haut de page. Et tant qu'à faire doté d'un accesskey.
Oui mais malheureusement l'accesskey risque de n'etre utile en majorité qu'aux personnes non voyantes ou tout au moins les personnes n'ayant pas de problèmes au niveau des membres.
Il faut donc aussi faire attention à la façon dont les tabindex sont organisés dans le sens ou le lien haut de page doit etre absolument renseigné à ce niveau là et etre la suite logique du contenu.
Le tabindex parait quand même être une solution alternative mais ajouté à un travail en profondeur sur les ancres et l'insertion de liens d'acces direct directement dans le contenu ainsi que pour les différents menus.
Ce que jaws propose pour les aveugles par exemple choisir la lecture d'un contenu (choix des titres , paragraphes,....) pourquoi ne pas essayé de le mettre en oeuvre par exemple par des titres cliquables (rien n'empeche un titre d'etre un lien) renvoyant de suite au titre d'apres, ce qui offre une navigation de titre en titre rien qu'en utilisant tab et entrée.
Je suis persuadé qu'il est possible avec les outils que nous avons en notre possession de pouvoir decouper une page en plusieurs parties accessibles independement et rapidement pour des personnes atteintes de handicaps necessitant une navigation exclusivement au clavier.
Cela pourrais même permettre à des personnes utilisant un trackball mais difficilement de pouvoir avoir une navigation simplifiée par le clavier.
Il y auras toujours l'argument qui fracasse "il faut du temps pour le faire et le temps c'est de l'argent"
Mais en passant au dessus de ça, le jeu n'en vaut il pas la chandelle?
Ce que jaws propose pour les aveugles par exemple choisir la lecture d'un contenu (choix des titres , paragraphes,....) pourquoi ne pas essayé de le mettre en oeuvre par exemple par des titres cliquables (rien n'empeche un titre d'etre un lien) renvoyant de suite au titre d'apres, ce qui offre une navigation de titre en titre rien qu'en utilisant tab et entrée.
Je suis persuadé qu'il est possible avec les outils que nous avons en notre possession de pouvoir decouper une page en plusieurs parties accessibles independement et rapidement pour des personnes atteintes de handicaps necessitant une navigation exclusivement au clavier.
Cela pourrais même permettre à des personnes utilisant un trackball mais difficilement de pouvoir avoir une navigation simplifiée par le clavier.
Il y auras toujours l'argument qui fracasse "il faut du temps pour le faire et le temps c'est de l'argent"
Mais en passant au dessus de ça, le jeu n'en vaut il pas la chandelle?
Bonjour,
@vero :
Le haut de page à un statut particulier : c'est une zone toujours identifiable avec certitude
, à la différence de "après le contenu" qui est une zone éminemment "relative".
La difficulté pour un non voyant étant de prendre en main la structure, plus celle-ci est susceptible d'être complexe, plus on à intérêt à placer la navigation en premier. On aura au moins la certitude qu'en cas de problème de compréhension ou de maitrise du logiciel de lecture, il sera toujours possible au visiteur handicapé de revenir en haut de page, soit par une fonctionalité propre à son logiciel, soit simplement par un "reload".
Cela offre en quelque sorte la garantie que la navigation est toujours identifiable avec certitude "en dernier recours".
Autre scénario très simplifié pour mieux illustrer: Une page présente des critiques de films, le contenu contiens tout à la fin un lien vers un site partenaire annonçant les salles et les horaires.
Le menu est placé "après le contenu", je suis non-voyant, je lis le contenu, à la fin je joue le lien, je visite le site partenaire, je reviens avec l'historique. A ce moment là je n'ai plus aucune utilité du "contenu", je veux aller voir la critique suivante ou une autre page. La page étant rechargée, il est évident que le menu, placé en haut de page, sera plus efficace.
C'est évidemment un cas très simplifié mais c'est juste pour illustrer le fait que ce choix "navigation, contenu" doit être pensé non pas sur des "modèles" mais simplement sur la réalité du site.
Quant à la "recommandation" que tu cites, je suis sur ce point tout à fait d'accord avec Laurent, le référentiel de l'ADAE, fondé sur celui d'Accessiweb comporte un certain nombre d'interprétations discutables qui créées plus de confusion qu'elles n'apportent d'éclairsissement.
Celle-ci en particulier ne veut absolument rien dire, on dirait que les rédacteurs ont voulu inventer une sorte de "linéarisation" des divs qui n'à aucun sens dans une pratique cohérente de la mise en page CSS.
Le réferentiel de l'ADAE et d'Accessiweb est fondé, avant tout, sur l'ambition de rendre accessible de l'existant.
Cela à conduit Accessiweb à éclater les 78 critères du WCAG 1.0 en 92 Critères, à créer des sortes de zones de recouvrement qui pemettent de valider des structures qui ne passeraient pas WAI et d'adapter certaines ambitions importantes du WCAG, notamment le point 5.3 qui est purement et simplement ignoré.
Ce point interviens très tôt (priorité 2) dans le WCAG, le but étant de créer les conditions de la disparition de cette technique qui pose de redoutables problèmes dans la gestion du flux et donc, in fine, l'accessibilité.
En la matière, le référentiel Accessiweb et celui de l'ADAE ne doit être utilisé que pour "valider au regard de la législation française" une mise aux normes WAI, le travail en amont doit-être réalisé sur le WCAG 1.0 qui est la "mère de toutes les références" .
L'accesskey est un des plus grand échecs de l'accessibilité et je ne résiste pas à vous proposer ce petit test :
En mode "normal" les accesskey sont accessibles par la combinaison de deux touches, ce qui, l'utilisateur d'un head-stick par exemple est un non sens.
Mais il y à pire encore : les utilisateurs handicapés moteurs utilisent généralement leur clavier en mode "accessible" où le pavé numérique remplace la souris. Dans cette configuration l'accesskey n'est utilisable que par la combinaison de TROIS touches, la combinaison "normale" plus la touche MAJ, si si faites l'expérience, vous ne rêvez pas.
Ajouter à ça que les valeurs d'accesskeys sont limités aux 9 chiffres (et encore) et on à là un immense gachis.
Néanmoins ils peuvent être utiles, donc on peut les utiliser, mais je suis, comme knarf assez circonspect sur leur utilisation et en tout cas il ne faut pas en faire un élément essentiel d'un dispositif d'accessibilité.
En passant, un autre point délicat d'Accessiweb, est la préconisation de l'accesskey "s" pour le lien d'évitement "passer au menu", ne l'employez surtout pas, vous désactiveriez la fonction "enregistrer sous" de firefox et mozilla par exemple.
J'ai exactement les même réserves, un bon test pour valider la cohérence d'un flux est d'ailleurs de tester la navigation tabulaire sans tabindex, si la page est facilement utilisable on à une bonne chance d'avoir une cohérence entre le flux et la mise en page.
Pour ma part, je ne les utilise pas et je les supprime, sauf exeption, des sites que je normalise, quite à retravailler sur la structure jusqu'à obtenir une cohérence satisfaisante.
N'oubliez pas non plus, que la moindre modification dans la page (rajouter un lien apr exemple) vous obligera à refaire tout ou partie des tabindex.
C'est toujours le grand défi, l'adaptation aux non-voyants est généralement assez facile, celles nécessaires à la navigation clavier est toujours la plus difficile et la plus insatisfaisante parce qu'il y à nécéssité de faire apparaitre les aides ce qui pose dans la plupart des cas des problèmes en terme de design.
A l'heure actuelle, en attendant les apports des normes en préparation, l'implémentation d'une vraie navigation clavier me parait très difficile, sauf dans le cas de site ou d'application dont on peut maitriser les usages, comme un intranet ou des interfaces d'administrations par exemple.
Dans ce cas là, il est facile d'implémenter des solutions scriptées, de gestion de la navigation clavier, ce qui reviens à remplacer les accesskey par des raccourcis à une touche et d'en étendre le potentiel à toutes les touches du clavier. On peut ainsi "rendre un ensemble applicatif utilisable sans jamais avoir recours au dispositif de pointage.
Au delà, comme pour les lecteur d'écrans, ça me parait tout autant relever de la conception web que de l'apport de fonctionnalité des navigateurs qui en la matière sont très peut convaincant.
JP
@vero :
Le haut de page à un statut particulier : c'est une zone toujours identifiable avec certitude
, à la différence de "après le contenu" qui est une zone éminemment "relative". La difficulté pour un non voyant étant de prendre en main la structure, plus celle-ci est susceptible d'être complexe, plus on à intérêt à placer la navigation en premier. On aura au moins la certitude qu'en cas de problème de compréhension ou de maitrise du logiciel de lecture, il sera toujours possible au visiteur handicapé de revenir en haut de page, soit par une fonctionalité propre à son logiciel, soit simplement par un "reload".
Cela offre en quelque sorte la garantie que la navigation est toujours identifiable avec certitude "en dernier recours".
Autre scénario très simplifié pour mieux illustrer: Une page présente des critiques de films, le contenu contiens tout à la fin un lien vers un site partenaire annonçant les salles et les horaires.
Le menu est placé "après le contenu", je suis non-voyant, je lis le contenu, à la fin je joue le lien, je visite le site partenaire, je reviens avec l'historique. A ce moment là je n'ai plus aucune utilité du "contenu", je veux aller voir la critique suivante ou une autre page. La page étant rechargée, il est évident que le menu, placé en haut de page, sera plus efficace.
C'est évidemment un cas très simplifié mais c'est juste pour illustrer le fait que ce choix "navigation, contenu" doit être pensé non pas sur des "modèles" mais simplement sur la réalité du site.
Quant à la "recommandation" que tu cites, je suis sur ce point tout à fait d'accord avec Laurent, le référentiel de l'ADAE, fondé sur celui d'Accessiweb comporte un certain nombre d'interprétations discutables qui créées plus de confusion qu'elles n'apportent d'éclairsissement.
Celle-ci en particulier ne veut absolument rien dire, on dirait que les rédacteurs ont voulu inventer une sorte de "linéarisation" des divs qui n'à aucun sens dans une pratique cohérente de la mise en page CSS.
Le réferentiel de l'ADAE et d'Accessiweb est fondé, avant tout, sur l'ambition de rendre accessible de l'existant.
Cela à conduit Accessiweb à éclater les 78 critères du WCAG 1.0 en 92 Critères, à créer des sortes de zones de recouvrement qui pemettent de valider des structures qui ne passeraient pas WAI et d'adapter certaines ambitions importantes du WCAG, notamment le point 5.3 qui est purement et simplement ignoré.
a écrit :
5.3 (Do not use tables for layout unless the table makes sense when linearized.)
Ce point interviens très tôt (priorité 2) dans le WCAG, le but étant de créer les conditions de la disparition de cette technique qui pose de redoutables problèmes dans la gestion du flux et donc, in fine, l'accessibilité.
En la matière, le référentiel Accessiweb et celui de l'ADAE ne doit être utilisé que pour "valider au regard de la législation française" une mise aux normes WAI, le travail en amont doit-être réalisé sur le WCAG 1.0 qui est la "mère de toutes les références"
.a écrit :
Oui mais malheureusement l'accesskey risque de n'etre utile en majorité qu'aux personnes non voyantes ou tout au moins les personnes n'ayant pas de problèmes au niveau des membres.
L'accesskey est un des plus grand échecs de l'accessibilité et je ne résiste pas à vous proposer ce petit test :
En mode "normal" les accesskey sont accessibles par la combinaison de deux touches, ce qui, l'utilisateur d'un head-stick par exemple est un non sens.
Mais il y à pire encore : les utilisateurs handicapés moteurs utilisent généralement leur clavier en mode "accessible" où le pavé numérique remplace la souris. Dans cette configuration l'accesskey n'est utilisable que par la combinaison de TROIS touches, la combinaison "normale" plus la touche MAJ, si si faites l'expérience, vous ne rêvez pas.
Ajouter à ça que les valeurs d'accesskeys sont limités aux 9 chiffres (et encore) et on à là un immense gachis.
Néanmoins ils peuvent être utiles, donc on peut les utiliser, mais je suis, comme knarf assez circonspect sur leur utilisation et en tout cas il ne faut pas en faire un élément essentiel d'un dispositif d'accessibilité.
En passant, un autre point délicat d'Accessiweb, est la préconisation de l'accesskey "s" pour le lien d'évitement "passer au menu", ne l'employez surtout pas, vous désactiveriez la fonction "enregistrer sous" de firefox et mozilla par exemple.
a écrit :
Sur l'utilisation des tabindex j'ai toujours les même réserves. Cela traduit plus, à mon sens, un déficit de la structuration html qu'autre chose.
J'ai exactement les même réserves, un bon test pour valider la cohérence d'un flux est d'ailleurs de tester la navigation tabulaire sans tabindex, si la page est facilement utilisable on à une bonne chance d'avoir une cohérence entre le flux et la mise en page.
Pour ma part, je ne les utilise pas et je les supprime, sauf exeption, des sites que je normalise, quite à retravailler sur la structure jusqu'à obtenir une cohérence satisfaisante.
N'oubliez pas non plus, que la moindre modification dans la page (rajouter un lien apr exemple) vous obligera à refaire tout ou partie des tabindex.
a écrit :
Je suis persuadé qu'il est possible avec les outils que nous avons en notre possession de pouvoir decouper une page en plusieurs parties accessibles independement et rapidement pour des personnes atteintes de handicaps necessitant une navigation exclusivement au clavier.
C'est toujours le grand défi, l'adaptation aux non-voyants est généralement assez facile, celles nécessaires à la navigation clavier est toujours la plus difficile et la plus insatisfaisante parce qu'il y à nécéssité de faire apparaitre les aides ce qui pose dans la plupart des cas des problèmes en terme de design.
A l'heure actuelle, en attendant les apports des normes en préparation, l'implémentation d'une vraie navigation clavier me parait très difficile, sauf dans le cas de site ou d'application dont on peut maitriser les usages, comme un intranet ou des interfaces d'administrations par exemple.
Dans ce cas là, il est facile d'implémenter des solutions scriptées, de gestion de la navigation clavier, ce qui reviens à remplacer les accesskey par des raccourcis à une touche et d'en étendre le potentiel à toutes les touches du clavier. On peut ainsi "rendre un ensemble applicatif utilisable sans jamais avoir recours au dispositif de pointage.
Au delà, comme pour les lecteur d'écrans, ça me parait tout autant relever de la conception web que de l'apport de fonctionnalité des navigateurs qui en la matière sont très peut convaincant.
JP
@jpv
Merci d'avoir étoffé ton point de vue. L'exemple que tu cites est convaincant.
J'ai effectivement été étonnée par l'approche des tables dans le référentiel.
Pour l'instant, je ne différencie pas très bien les différentes aides aux claviers, mais ce post est une bonne introduction.
La combinaison de touches, je confirme, est inutilisable pour un handicapé moteur, même leger ... par contre, la touche tabulation s'avère très pratique dans ce cas.
Ceci dit, toutes ces ambiguités voire ces contradictions ne facilitent pas la quête ... c'est le moins quon puisse dire !
Merci à tous pour vos réponses.
Merci d'avoir étoffé ton point de vue. L'exemple que tu cites est convaincant.
J'ai effectivement été étonnée par l'approche des tables dans le référentiel.
Pour l'instant, je ne différencie pas très bien les différentes aides aux claviers, mais ce post est une bonne introduction.
La combinaison de touches, je confirme, est inutilisable pour un handicapé moteur, même leger ... par contre, la touche tabulation s'avère très pratique dans ce cas.
Ceci dit, toutes ces ambiguités voire ces contradictions ne facilitent pas la quête ... c'est le moins quon puisse dire !
Merci à tous pour vos réponses.
jpv a écrit :
Autre scénario très simplifié pour mieux illustrer: Une page présente des critiques de films, le contenu contiens tout à la fin un lien vers un site partenaire annonçant les salles et les horaires.
Le menu est placé "après le contenu", je suis non-voyant, je lis le contenu, à la fin je joue le lien, je visite le site partenaire, je reviens avec l'historique. A ce moment là je n'ai plus aucune utilité du "contenu", je veux aller voir la critique suivante ou une autre page. La page étant rechargée, il est évident que le menu, placé en haut de page, sera plus efficace.
C'est évidemment un cas très simplifié mais c'est juste pour illustrer le fait que ce choix "navigation, contenu" doit être pensé non pas sur des "modèles" mais simplement sur la réalité du site.
Pas vraiment d'accord avec toi.
Tu poses toi même que le mode premier de consultation de la page est bien la lecture du contenu ce qui encourage à placer celui ci au plus tôt dans le document. Ce que tu décris par ailleurs est absolument non problématique si on a pris le soin de mettre des liens d'accès directs en entrée de documents.
Sinon concernant la notion de zone identifiable je me permet une petite digression pour indiquer qu'elle met en valeur la nécessité de la structuration du document via les entêtes de section (hn).
N'y aurait-il pas de ce point de vue avantage à plus utiliser la plus structurantes de ces entêtes, soit h1, pour réellement informer "tout" le contenu html des documents (tout, c'est à dire dès le début du body) ?
Soit un squelette comme ceci
<body>
<h1>Environnement : section pré-contenu</h1>
... liens d'accès directs par exemple ...
<h1>Titre se référant au contenu</h1>
... contenu ...
<h1>Environnement : section post-contenu</h1>
ou carrément
<h1>Menus</h1>
</body>
Je parle de celà car je trouve toujours un peu bizarre de voir (dans des bons sites) des éléments qui se balladent un peu hors de la structuration.
Modifié par clb56 (12 Jun 2005 - 10:24)
a écrit :
N'oubliez pas non plus, que la moindre modification dans la page (rajouter un lien apr exemple) vous obligera à refaire tout ou partie des tabindex.
Il y as moyen de parer jusqu'a un certain point ce probleme en utilisant une numerotation espacée par exemple:
100
108
116
ce qui permet l'ajout de liens sans avoir à retoucher aux tabindex.
a écrit :
Il y as moyen de parer jusqu'a un certain point ce probleme en utilisant une numerotation espacée.
Oui c'est la technique habituelle. Ca deviens un peut plus compliqué dans le cas de pages dynamiques.
En tout état de cause, la navigation tabulaire si elle n'est pas linéaire est souvent signe de soucis sur l'organisation du flux et peut provoquer de la gêne lors de l'utilisation à l'écran, où il semble "naturel" qu'on passe au lien suivant en utilisant la tabulation.
a écrit :
Ce que tu décris par ailleurs est absolument non problématique si on a pris le soin de mettre des liens d'accès directs en entrée de documents.
Oui mais là c'est le serpent qui se mord la queue, pourquoi ne pas mettre le menu avant le contenu avec un lien d'évitement pour aller au contenu ?
C'est strictement équivalent, sauf que dans le scénario que je donne, le retour par l'historique sera plus profitable en évitant de devoir jouer un lien d'évitement...
Cet exemple est volontairement très simplifié, mais sur des structures plus complexes faisant intervenir des sections et des listes de liens dans le corps du contenu, il est souvent plus simple et plus ergonomique de mettre la navigation en premier, ce qui permet également d'implémenter des ancres d'accès aux sections du document.
a écrit :
N'y aurait-il pas de ce point de vue avantage à plus utiliser la plus structurantes de ces entêtes, soit h1, pour réellement informer "tout" le contenu html des documents (tout, c'est à dire dès le début du body) ?
Si la sémantique du document est correctement faite, tu n'auras pas besoin d'un système de cette nature.
Le rôle des balises hn n'est pas de donner des informations sur l'organisation de la structure.
Enfin, je me vois très mal faire avaler un système comme ça à un client, avec lequel il faut déjà batailler ferme pour tenter d'implémenter des aides aussi basiques que les liens d'évitements.
JP
Bonjour
j'ai l'impression, mais je peux me tromper, que l'on s'éloigne du sujet d'origine qui ne concernait que le flux d'une page et l'interprétation du référentiel ADAE.
Pour revenir au sujet et éclairer Vero sur la question initiale, j'ai créé un site dont le flux des pages est différent (via l'utilisation du float) selon le navigateur utilisé.
A savoir, la colonne gauche du site en question est utilisée uniquement pour placer des images destinées à apporter un plus décoratif au site, et surtout, aucune info complémentaire au contenu texte de la page.
Sur un navigateur graphique, on a une colonne gauche (images) une colonne centrale (données texte), une colonne droite réservée aux menus complémentaires de navigation.
Sur un navigateur texte, le contenu de la colonne gauche est tout en bas de la page, ce qui permet d'accéder directement aux données, sans avoir à traverser la zone d'images. Ce qui n'empêche pas la mise en place de liens directs sur la page, autant pour accéder directement aux données que pour remonter en haut de page.
Une dernière précision, le site évolue et la colonne gauche est susceptible de recevoir maintenant des données graphiques complémentaires aux textes et la mise en page du site est en cours de modifications
j'ai l'impression, mais je peux me tromper, que l'on s'éloigne du sujet d'origine qui ne concernait que le flux d'une page et l'interprétation du référentiel ADAE.
Pour revenir au sujet et éclairer Vero sur la question initiale, j'ai créé un site dont le flux des pages est différent (via l'utilisation du float) selon le navigateur utilisé.
A savoir, la colonne gauche du site en question est utilisée uniquement pour placer des images destinées à apporter un plus décoratif au site, et surtout, aucune info complémentaire au contenu texte de la page.
Sur un navigateur graphique, on a une colonne gauche (images) une colonne centrale (données texte), une colonne droite réservée aux menus complémentaires de navigation.
Sur un navigateur texte, le contenu de la colonne gauche est tout en bas de la page, ce qui permet d'accéder directement aux données, sans avoir à traverser la zone d'images. Ce qui n'empêche pas la mise en place de liens directs sur la page, autant pour accéder directement aux données que pour remonter en haut de page.
Une dernière précision, le site évolue et la colonne gauche est susceptible de recevoir maintenant des données graphiques complémentaires aux textes et la mise en page du site est en cours de modifications
Bonjour,
Justement, Dominique, tu m'as orienté sur ce topic alors que je me posais la question.
Effectivement, tout dépend du site ...
dominique a écrit :
j'ai l'impression, mais je peux me tromper, que l'on s'éloigne du sujet d'origine qui ne concernait que le flux d'une page et l'interprétation du référentiel ADAE.
Justement, Dominique, tu m'as orienté sur ce topic alors que je me posais la question.
Effectivement, tout dépend du site ...
clb56 a écrit :
Le mieux pour arriver à ce résultat est bien un lien haut de page. Et tant qu'à faire doté d'un accesskey.
Cette précaution est-elle vraiment nécessaire si on dote chaque item du menu de navigation d'un accesskey spécifique ?
Edit : woups je n'avais pas vu la 2e page, bon à la rigueur je retombe dans le sujet, non ?
Modifié par naholyr (26 Jun 2005 - 11:23)