1178 sujets

Accessibilité du Web

Guide accessiweb

Bonjour,

Accessiweb viens d'annoncer sur sa liste de diffusion la publication de la version 1 (55 critères niveau bronze) nouveau guide d'application de la méthode accessiweb, lié au label du même nom.

Du coté de la forme, beaucoup d'améliorations par rapport à la première version, la version en ligne est claire, bien présentée et bien documentée.

Du coté du fond, pas de grands changements...

Les experts accessiweb ont notamment conservés des interprétations très discutables de certains items du WCAG et surtout, cruelle déception, argumentés le point 10.3 dont l'intitulé "Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ?" est toujours aussi obscur.
Ce point est censé formaliser une nécessité de synchroniser l'ordre d'apparition des éléments du flux avec l'ordre d'apparition (ou de consultation) de sa représentation graphique.

Accessiweb argumentant un concept de "linéarisation" d'une structure CSS dont il reste à expliquer le background technique, CSS étant justement destiné à libérer le flux de ce genre de contraintes que l'on retrouve dans la conception de mise en page par tableaux.

Le soucis c'est qu'appliquer stricto-sensu ce point des critères accessiweb contraint à respecter un modèle normé de mise en page où un élément de structure "précédent" (dans le flux) est obligatoirement placé à gauche de l'élément de structure "suivant" dans sa représentation graphique et inversement.

Exemple :


#header
#menu
#contenu


Ne peut s'exprimer pour sa représentation graphique qu'avec le header en haut, le menu à gauche et le contenu à droite, sans autre alternative même si celle-ci est pertinente par rapport au contexte du site et justifié par une navigation dans la page et le flux logique et cohérente, conformément aux items WCAG 6.1 et 9.4.

(Ce qui est amusant c'est que l'une des références citées en appui de cet item et qui n'est pas n'importe qui puisqu'il s'agit d'eric Meyer, utilise une structure en violation de cette règle) Smiley lol

A ce détail près, (et quelques autres moins graves) qui n'en est pas un, puisqu'il rends particulièrement délicate l'application "stricte" de la méthode accessiweb dés lors que le desing dépasse le modèle header-deux-colonnes-footer, le reste est de bonne facture et sera un support précieux, notamment pour l'apprentissage.

Jean-pierre
Modifié par jpv (21 Oct 2005 - 02:11)
Administrateur
J'ai pris un peu de temps hier soir pour parcourir ce guide.
Même s'il y'a peut-être un ou deux points à discussion (il y'en aura toujours), je pense que ce guide est vraiment un travail louable.

Chaque fiche de contrôle apporte vraiment un plus par rapport à tout ce qui existait avant, en proposant des bons et mauvais exemples, des bénéfices engendrés pour le visiteur et le concepteur, les exemples de rendus sous Jaws (en mp3), sous Lynx, etc.

Un excellent document de travail !
Modifié par Raphael (21 Oct 2005 - 10:05)
Bonjour,

Tout à fait d'accord et les deux ou trois points à discuter sont d'autant plus "dommage" que la base est excellente Smiley smile

Jean-pierre
Vite la suite qu'il n'y ait plus de liens manquant dans "Autres fiches à consulter"

Ca surprend quand on tombe sur ça dans la première fiche qu'on consulte au hasard...

Encore un peu et j'envoyais un mail "y a une erreur là" Smiley biggol
Bonjour, en tant qu'expert accessiweb je me permet de répondre:

jpv a écrit :

nouveau guide d'application de la méthode accessiweb[/url], lié au label du même nom.


Ce n'est pas lié directement au label c'est lié à l'utilisation des critères

jpv a écrit :

Les experts accessiweb ont notamment conservés des interprétations très discutables de certains items du WCAG


Le guide n'etait pas destiné à voir les critères évoluer c'est donc normal que rien n'est changé, par contre une gros travail a été fait cet été notamment entre les personnes d'accessiweb et moi même sur les critères pour les faire évoluer dans le cadre de l'évolution du référentiel ADAE.

Concernant le point 10.3, le problème est pour les personnes ayant une déficience visuelle partielle qui utilise une synthèse vocale qui ne voit pas le meme chose que ce qu'elles ententent. Techniquement, je ne vois pas ou le probleme que ce soit avec du positionnement absolut ou en float pour respecter ce critère, hormis éventuellement le fait d'avoir la zone de contenu en premier je ne vois pas du tout l'utilité d'avoir mes blocs dans le code dans un ordre différent de celui de l'affichage.
Modifié par goetsu (24 Oct 2005 - 10:15)
goetsu a écrit :

les personnes ayant une déficience visuelle partielle qui utilise une synthèse vocale qui ne voit pas le meme chose que ce qu'elles ententent.


En prenant une lecture de gauche à droite sur un site ayant comme configuration menu-->contenu-->menu, j'ai toujours la question de l'accès au footer qui revient.

Je m'imagine un second menu de plusieurs items qui obligerait à de multiples manipulation de la touche tab pour accéder à une information même secondaire (footer) alors qu'elle est visualisé par l'internaute comme étant aprés le contenu mais lu aprés le menu.


On facilite l'acces aux menus et au contenu mais pas au footer (ou pied de page) dans le sens ou dans le flux c'est toujours le dernier et n'as pas d'accès rapide comme peuvent avoir le contenu et les menus.

Même si l'on prends en compte que ce sont généralement "des informations annexes" elle ont quand même ce statut "d'information" qui font qu'elles doivent être accessible le plus facilement possible.

Concrétement cela pourrais se faire par un choix en fin de contenu.

-informations annexes du site (footer)
-menu suivant

Peut être que le problème ne se pose pas et que ce n'est pas une chose que les utilisateurs concernés demandent mais je me suis toujours demandé si cela ne pouvais pas amener un plus sans pour cela amener une gène.
Modifié par knarf (24 Oct 2005 - 14:14)
tout depend de ta charte si ton footer s'etend sur toute la largueur de tes 3 colonnes il est bien apres dans le flux et dans le mode graphique en sens de lecture de gauche vers le droite, si il est juste en dessous du contenu rien ne t empeche de le mettre avant la colonne de droite.

Enfin pour ma, sur un site ayant un menu de navigation répartie sur deux colonnes j'ai fait ce que tu suggère, des menu raccourcis pour passer d'une colonne à l'autre et inversement ou aller au contenu en plus de menu de raccourci habituelle en haut de code voir le code de http://www.apf.asso.fr

a+
Bonjour,

@Goetsu :

a écrit :
implementation : ... Il faut veiller à ce 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...


Ce passage pose problème car il définis la règle suivante : un élément précédent (dans le flux) est toujours situé à gauche de l'élément qui le suis.
Ou plus exactment "au dessus ou à gauche".

Cette règle étant fondé en partie sur le "sens de lecture" de "gauche à droite".

Ce qui fait que l'on se retrouve exactement avec la description de l'utilisation d'une table de mise en forme.

Plus exactement on se retrouve avec les contraintes d'une table de mise en forme sans les avantages de CSS qui permet, par la mise à disposition d'un flux ordonné, d'offrir une alternative de lecture si nécessaire et de se libérer totalement de la contrainte de l'effet de linéarisation.


a écrit :
Techniquement, je ne vois pas ou le probleme que ce soit avec du positionnement absolut ou en float pour respecter ce critère, hormis éventuellement le fait d'avoir la zone de contenu en premier je ne vois pas du tout l'utilité d'avoir mes blocs dans le code dans un ordre différent de celui de l'affichage.


Il y à des quantités de design qui deviennent impossible avec ce critère.
La raison en est que ce critère s'appuie sur une vision du wiewport comme un "plan" alors que les designers le travaille (avec raison d'ailleurs) comme un "espace".

En rélaité, ce que propose cet item c'est de contraindre la mise en page CSS à simuler une mise en page par tableaux, ce qui quand même un comble.

On peut imaginer pleins de situations où des éléments précedents (dans le flux) se retrouve à droite, en bas, au centre, au mileu ou intercalé entre deux éléments suivants, sans que cela soit une gène en terme d'utilisation et d'accessibilité.

Tu vas sans doute me dire, ben si justement pour ceux qui utilisent une synthèse vocale en complément d'une lecture normale.

Mais, pour ceux là, si les contraintes de design sont trop importantes, ils auront recours à la lecture du flux, ce qui est conforme aux recommandations du WCAG.

Sauf à considérer que la représentation graphique d'un site web est normée sur un modèle où le contenu doit s'afficher "de gauche à droite" sous forme de colonnes verticales et de lignes horizontales.
Grosso modo le modèle "blog" et "tableau de mise en page" ou les modèles d'inititations CSS genre "header-colonne-footer", modèle issus d'une perception de "page à l'écran" qui est très restrictive et ne correspond pas du tout à la nature du média où le wiewport est un "espace" sans dimension.

L'autre considération est que cette item du guide accessiweb interdis de fait la propriété CSS float:right, dont le but est justement de repositionner à droite un contenu "précédent" dans le flux.

Il en va de même des repositionnement en absolu.
Par exemple un lien graphique (petite croix) de fermeture d'une fausse popup, placé en dernier dans le flux du contener pour d'évidentes raisons d'ergonomie du flux et qu'on repositionne en haut à droite du contener, pour d'aussi évidentes raisons d'ergonomie graphique.

Exemple tout à fait transposable aux grandes structures d'une représentation graphique dés lors que l'on sort de la camisole mentale du modèle de "page à l'écran".

D'autre part, il n'y à rien dans les WCAG qui puisses venir appuyer cet item, c'est tout le contraire même.

Ce qui est très dommage, c'est qu'en rréalité, cet item rends la méthode accessiweb applicable uniquement sur des sites dont la représentation graphique est normée (gauche-droite sur un modèle de table de mises en page simulée en CSS).

Autrement dit, pour satisfaire un cas limite (utilisation combiné d'un lecteur vocal et d'une lecture visuelle) pour laquelle il y à une alternative par la lecture du flux, on sacrifie des pans entiers du design web.

Jean-pierre
pour l'exemple de float:right je suis en partie d'accord meme si rien n'empeche de faire dans le cas ou je veux avoir mon element a à droite de mon element b:

element b (en float left) - element a

dans le cas d'un positionnement absolut je ne vois pas qu'est ce qui empeche de mettre dans le code la fermture de pop-up au debut

Meme si au fond je suis de ton avis, ce critère est en effet critiquable/améliorable rien n'empeche de le mettre en oeuvre
Bonjour,

a écrit :
element b (en float left) - element a

Oui, si et seulement si le contexte si prête.... Smiley smile

a écrit :
Meme si au fond je suis de ton avis, ce critère est en effet critiquable/améliorable rien n'empeche de le mettre en oeuvre


Le simple fait que si je le mets à la fin du contener pop-up, ben l'utilisateur du flux, particulièrement avec un screen reader, n'à pas besoin de "remonter" chercher le lien de fermeture.... Smiley smile

a écrit :
Meme si au fond je suis de ton avis, ce critère est en effet critiquable/améliorable rien n'empeche de le mettre en oeuvre


Le soucis c'est que doit-on faire quand on ne peut pas alors même qu'on s'est assuré de la conformité WCAG, dans la perspective d'une labelisation accessiweb.

Jean-pierre
Bonjour à tous,

Une chose que je n'avais pas remarqué et je viens de m'en apercevoir en regardant le point litigieux dont parle jpv, les liens correspondants aux recommandations du WCAG sont exclusivement en anglais décidemment aucun effort n'est fait dans ce domaine cela n'enlève rien à la qualité du travail effectué mais je trouve cela bien dommage pour un site parlant d'accessibilité car cette info existe egalement en français.

D'accord la fiche d'accessiweb est en français mais la recommandation ce n'est pas la même chose puisque cette fiche découle de cette recommandation alors pourquoi ne pas mettre les 2 (en) et (fr).

traduction sur la-grange.net

Ca fait moins classe le français quand on parle d'accessibilité?

La traduction n'est pas assez bien pour être utilisée?

EDIT:
Le lien en français n'est même pas donné à titre indicatif dans les références.
Modifié par knarf (07 Nov 2005 - 12:26)
je leur fait parvenir la remarque mais cela vient peut etre que la française "officiel" reconnu par le wai se trouve sur internet.gouv.fr qui vient de changer et qui n'a pas encore mis d'accès à ces archives mis à jour
Bonjour à tous,

Pour Knarf et suite au message de Goetsu : les documents de référence sont seulement les documents originaux, donc en anglais. D'ailleurs c'est, en principe, toujours précisé dans les traductions elles-mêmes que le seul document de référence est le document original. Je trouve ça dommage moi aussi, mais bon ...

Pour Felipe : merci de citer la ressource.

Cordialement,
Bonjour à tous,

je me fait un peu l'avocat du diable car personnellement, dans ce cas là la traduction je sais ou la trouver, mais n'est il pas possible de spécifier à titre indicatif dans les références de fin de fiche qu'il existe une version française, mais qui ne peux pas être pris comme document référence.
Sujet clos
Aller à