Les critères d'accessibilité d'un site

[Monique]

Bonjour,

Si j'apprécie le travail effectué par le groupe Accessiweb, je ne comprends pas les choix "techniques" pour la réalisation du site.

Un tel site ne devrait-il pas être exemplaire sur le plan du respect des règles d'accessibilité ?

La présentation est claire et aérée à l'affichage avec un navigateur graphique. Par contre, les tableaux imbriqués ne doivent pas faciliter la lecture avec un navigateur texte ou vocal.

Et pourtant, au vu de la simplicité des pages, je pense que le couple (x)html/css serait utilisable sans difficulté.

La prochaine étape ?

L'annonce de Trophées Accessiweb (un concours de création de site accessible organisé par Accessiweb) a été suivie par un débat sur les critères d'accessibilité.

Pour donner à chacun des deux sujets l'importance qu'il mérite, j'ai scindé la discussion (avec l'accord de yobiwan)

Modifié 4 Février 2004 par Monique

[yobiwan]

"Un tel site ne devrait-il pas être exemplaire sur le plan du respect des règles d'accessibilité"

Pourriez vous m'aider à relever ces fautes d'accessibilité ?

Ce site a été réalisé en englobant l'ensemble des recommandation d'accessibilité diffusées par WAI. WAI émet des recommandations et ne rejette que très peu de solutions techniques.

Les tableaux ne sont pas du tout proscrits si ils sont construits pour être accessibles (summary, linéarisation des l'information ..).

Via votre remarque, je pense que la question sous jacente est pourquoi ne pas avoir utiliser un positionnement full CSS ?

Je n'aurais qu'une réponse :

Cette solution n'est pas acceptable d'un point de vue accessibilité aujourd'hui. Appliqué une feuille de style, très gros caractères / font de couleur, et le positionnement full CSS explose, les calques se superposent et l'inforamtion devient totalemnt illisible.

[Monique]

Je n'aurais qu'une réponse :

Cette solution n'est pas acceptable d'un point de vue accessibilité aujourd'hui. Appliqué une feuille de style, très gros caractères / font de couleur, et le positionnement full CSS explose, les calques se superposent et l'inforamtion devient totalemnt illisible.

Ma première réaction serait : pas d'accord.

Mais ce serait trop simple et inutile.

Je vais donc prendre le temps d'analyser une page plus en profondeur pour pouvoir vous donner une réponse argumentée, dans un sens ou dans l'autre

[yobiwan]

Je serais ravi d'avoir tord , mais le retour des utilisateurs me rend malheusement triste du résulat obtenu

[Guest exabs]

Et bien, voila une sacrée pierre dans la mare !

Depuis le temps que l'on nous rabache sur ce forum que les tableaux sont destinés à des données tabulaires et que les webmasters les utilisant pour la mise en page sont "méchants", que le css est la solution suprême et tellement simple à mettre en place !

[yobiwan]

Attention à ne pas prendre mes propos au pied de la lettre et considérer que le positionnement CSS est une erreur.

Pour moi aujoud'hui la solution n'est ni de faire des tableaux à 100% ni de faire du FULL CSS, mais bien de trouver des solutions mixtes.

[Loupilo]

J'ai dis à peu près ce qu'a dit Monique, en argumentant et en fournissant les liens prouvant que ce site n'était pas accessible, je me suis embeté, et il a été supprimé .

J'avoue que je comprends pas et que c'ets vraiment nul mais je recommencerai pas ce message En tout cas, je disais en substance que l'utilisation des "<table>" était le contraire d'un site accessible et pronant l'accessibilité :!:

[yobiwan]

Quel site n'est pas accessible ?

[Loupilo]

h**p://www.accessiweb.org ...

Je ne voulais pas dire qu'on ne pouvait y accéder, je voulais signifier que sa syntaxe est très mauvaise et ne permet pas aux navigateurs spéciaux d'y accéder, du fait du regorgement des balises <table>.

Ors c'ets un comble de la part d'un site pronant l'accessibilité

[Monique]

Bonjour,

Après un premier regard sur la page Au quotidien

- ni le code html, ni les feuilles de style ne sont valides

- la page est construite avec un grand nombre de tableaux imbriqués

- le validateur acces-pour-tous signale

Priorité 1 : Il y a 1 erreur et 23 avertissements

Priorité 2 : Il y a 42 erreurs et 3 avertissements

Priorité 3 : Il y a 1 erreur et 1 avertissement

- le validateur Bobby ne donne pas non plus un bon résultat

Un site accessible doit l'être pour tous, quelque soit le matériel utilisé (plate-forme, logiciel...), quelque soit les obstacles humains (âge, handicap visuel, moteur...).

Une des premières conditions c'est d'écrire un code valide, ensuite de respecter les différents points listés par le WAI.

Une lecture intéressante, le compte rendu de Tristan Nitot du Séminaire Accessiweb

[Steph. K.]

Bonjour tout le monde,

Je suis l'auteur du site acces-pour-tous.net et ne suis pas complètement d'accord avec certains points avancés lors de cette discussion.

Il est possible de faire du full css et d'agrandir les textes sans que la page ne soit trop dégradée. Mieux qu'une longue argumentation je vous invite à visiter mon site et d'agrandir les textes, le menu (largeur fixée en em) pousse le corps de la page mais sans barre de défilement horizontale et sans géner outre mesure la lecture de la page. Celle-ci est valide XHTML 1.0 strict ainsi que la feuille de style.

Les tableaux tout en n'étant pas formellement interdits sont toutefois déconseillés. Je reconnais que ce point peut entraîner de longues discussions étant donné que les textes de référence ne sont toujours d'une clarté suffisante.

5.3 N'utilisez pas de tableaux pour la mise en page à moins que le tableau garde un sens une fois linéarisé. Sinon, si le tableau n'est pas compréhensible, fournissez un équivalent alternatif (qui peut être une version linéarisée).

et

3.3 Utilisez des feuilles de styles pour contrôlez la mise en page et la présentation.

Les 2 extraits précédents viennent de la page suivante :

check liste des points de controle

Par ailleurs je relève quelques autres points tels que la non identification des liens visités, la présence d'une barre de défilement horizontale en 640 par 480, un codage désuet et transitional, qui plus est avec de nombreuses erreurs

Validateur html, des balises dépréciées qui seraient avantageusement remplacées par les équivalents en css.

Loin de moi l'idée de polémiquer gratuitement mais je pense aussi que les sites traitant d'accessibilité se doivent d'être le plus proche possible de la perfection, c'est pourquoi je reste disponible (jusqu'au 5 février 16h après je parts bosser loin d'internet) afin de développer les points abordés.

[Pixame]

Un peu hors sujet :

Cette histoire d'affichage en gros caractères qui déformeraient les pages web m'a amené à tester sur quelques sites... et donc bien entendu sur Webmaster-Hub. Il se trouve que la modification de la taille du texte est sans effet sur le Hub... le Hub n'aimerait-il pas les myopes ;-)

Sinon, je trouve ce débat intéressant : moi qui pensait que le web se faisait envahir par une pensée unique dont les maitres mots étaient accessibilité, xhtml, et full css, et bien je constate avec "amusement" que finalement, cette pensée n'est peut-être pas si unique que cela :-)

[Monique]

Je regrette aussi que les conditions d'utilisation des tableaux ne soient pas suffisamment précises.

En travaillant selon les spécifications (x)html strict, le contenu et la mise en forme seront séparés.

Le contenu de la page sera "organisé" de manière logique et naturelle, en utilisant les balises adéquates : hx pour les titres, p pour les paragraphes, ul pour les listes... et table pour les tableaux de données (et non pour la mise en page)

[Monique]

Il se trouve que la modification de la taille du texte est sans effet sur le Hub... le Hub n'aimerait-il pas les myopes ;-)

Ce qui me fait dire que tu utilises IE comme navigateur

Les tailles de police sont exprimées en px et la modification de la taille du texte est inopérante avec IE (par contre, je peux agrandir ou diminuer le texte sans problème avec Mozilla...)

Les forums Invision ont beaucoup de qualités, y compris un effort vers un code valide, mais sur le plan de l'accessibilité, il y a beaucoup à faire

Sinon, je trouve ce débat intéressant : moi qui pensait que le web se faisait envahir par une pensée unique dont les maitres mots étaient accessibilité, xhtml, et full css, et bien je constate avec "amusement" que finalement, cette pensée n'est peut-être pas si unique que cela :-)

Que veux-tu dire par pensée unique ?

[Pixame]

J'utilise effectivement IE... comme 95% des internautes et donc j'imagine comme 95% des myopes ;-)

Par "pensée unique" je faisait référence à la tendance actuelle qui place l'accessibilité sur un piedestal et qui prend comme premier et presque comme unique critère d'appréciation le respect de normes qui ne sont avant tout que des recommandations... et ne doivent rester à mes yeux que des recommendations... Tendance qui tend à dire que toute personne ne les respectant pas à forcément tort...

Et ce qui m'a amené à faire cette petite remarque (qui ne recherche surtout pas la polémique et qui de plus était notoirement hors sujet) était le fait de voir que même au sein de ceux qui sont "en campagne pour des sites conformes aux standards et accessibles..." et qui accordent "trophées" aux meilleurs d'entre eux peuvent avoir des avis divergents et se reprocher mutuellement d'avoir des sites qui ne sont pas "totalement" conforme.

Bref cela m'a amusé et m'a rappelé mon DESS de droit ou certains étudiants prenaient énormément de plaisir à pinailler sur le choix entre une virgule et un point-virgule au lieu de s'attacher à la signification et à la portée réelle du texte... Déjà à l'époque ces petits débats m'amusaient profondément :-)

Edit: au passage la home du Hub n'est pas valide, elle a 7 erreurs ;-)

Modifié 3 Février 2004 par NT Koncept

[Guest PierreThierry]

Pourriez vous m'aider à relever ces fautes d'accessibilité ?

On peut, mais cela me fait poser une question : êtes-vous crédible pour décerner un prix dans un domaine où vous n'êtes pas en mesure d'évaluer votre propre travail ; comment serez-vous à même de juger le travail des candidats si vous n'avez pas su le faire pour le votre ?

Ce site a été réalisé en englobant  l'ensemble des recommandation d'accessibilité diffusées par WAI.

C'est faux, les pages échouent même à des tests automatisables sur la recommandation WAI niveau 1. Je note au passage qu'elles ne passent même pas la validation de syntaxe.

Les tableaux ne sont pas du tout proscrits si ils sont construits pour être accessibles (summary, linéarisation des l'information ..).

Nuance : ils ne sont pas proscrits si l'usage des CSS n'est pas possible. Or, pour votre site, je ne vois pas en quoi c'est le cas.

un positionnement full CSS [...] n'est pas acceptable d'un point de vue accessibilité aujourd'hui. Appliqué une feuille de style, très gros caractères / font de couleur, et le positionnement full CSS explose, les calques se superposent et l'inforamtion devient totalemnt illisible.

Je vais me permettre d'être un peu violent dans mes propos : cette affiramtion démontre une relative incompétence dans le domaine des CSS. Effectivement, certains utilisations des CSS, notamment, et surtout, l'utilisation d'unité non relatives, est terriblement sensible aux modifications de polices. Mais il n'empêche qu'il est possible de construire des feuilles de styles qui y sont parfaitement adaptées.

Je suis donc, au final, très dubitatif quant à l'initiative AccessiWeb. Votre site ne respecte pas les plus élémentaires règles techniques du Web, ne respecte pas les recommandations du W3C quant à l'accessibilité, et va néanmoins décerner des prix sur ces mêmes critères. Pour autant, l'idée en elle-même est excellente, et va tout à fait dans le bon sens : toucher les étudiants, alors même qu'ils sont en train de se former aux métiers de Web, est primordial. C'est à la source qu'il faut chasser les mauvais élèves du Web, et apprendre les bonnes pratiques.

Le problème, c'est que l'initiative AccessiWeb semble manquer des compétences techniques nécessaires à son ambition. Sur ce point, je suis persuadé qu'il devrait être possible de recruter un certain nombre de personnes qui seraient parfaitement enchantées de participer, et qui ont une solide connaissance des recommandations techniques sous-jacentes, que sont HTML, XHTML, WAI ou CSS. J'en serais le premier, sinon je ne serais qu'un stérile donneur de leçons, et je gage pouvoir en trouver deux ou trois autres, qui gravitent comme moi dans le milieu du logiciel libre.

[Monique]

Par "pensée unique" je faisait référence à la tendance actuelle qui place l'accessibilité sur un piedestal et qui prend comme premier et presque comme unique critère d'appréciation le respect de normes qui ne sont avant tout que des recommandations... et ne doivent rester à mes yeux que des recommendations... Tendance qui tend à dire que toute personne ne les respectant pas à forcément tort...

Non, l'accessibilité n'est mise sur un piedestal.

Il s'agit tout simplement que le Web soit ce que Tim Berners-Lee, son inventeur, a voulu

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Et je citerai aussi Tristan Nitot (dont je parle souvent ici)

A terme, je vois disparaitre la notion d'accessibilité (et de respect des standards). Parce que ça sera une evidence absolue pour les gens qui feront des sites. Par défaut, un "vrai bon" site sera conforme et accessible (et beau). La bataille des standards et de l'accessibilité sera finie, et nous l'auront gagnée. Mais en attendant, il faut convaincre la communauté de l'accessibilité de l'évidence des standards.

[yobiwan]

Je pense que l'émulation est qqch de très positif et permet de faire avancer l'ensemble des débats.

L'accessibilté n'est certainement pas une science exacte et donc soumis à jugements.

L'utilisateur étant au centre de tels developpement, les avis sont obligatoirement divergents d'une personne à l'autre.

Pour parler d'un sujet que je pense maitriser, le site accessiweb.org, les "erreurs" soulevés dans les différents validateurs sont parfois justes parfois non.

Par exemple, une erreur soulevée dans un des validateurs et le manque de textes explicatifs dans les champs de formulaire.

Ce critère est clairement inutile et les les listes techniques de WAI dans lesquels je suis inscrit l'ont tres clairement exprimé. C'est d'ailleurs une des raisons pour laquelle ce critère disparait totalement des WCAG 2.0 qui sont entrain de voir le jour. J'en avais parlé avec Wendy Chisholm (la responsable de la redaction des WCAG 2.0) quand elle etait venu nous voir chez BrailleNet et elle avait reconnu la gêne pour nombreux utilisateurs que provoquait l'application de cette recommandation.

Pour le choix d'un codage en transitional plutot qu'en strict. Je pense que juger cela, n'amene pas grand chose en fait. Si la personne veut coder en HTML 2.0 c'est son choix point.

Pour le positionnement full CSS, je n'ai pas ma feuille de style gros caractere chez moi, mais j'ai testé l'ensemble des sites cité au taff et aucun ne passe ce test, je referrais le test demain et vous présenterais le resultat.(Zen garden, lycos, openweb ...)

Pour les erreurs de code HTML, je reverifie les problemes et modif ceux qui peuvent l'etre rapidement mais certaines demandent des modifications profondes de l'outil de gestion de contenu de ATALAN qui est aujourd'hui en pleine évolution pour générer du code accessible ce qui est quand fait a 90% j'espere que tous le reconnaitront il n'est pas encore parfait mais si tous les sites etaient accessibles comme accessiweb ... , mais nous avions listé ces fautes et il est prévu de remedier à cela le plus rapidement possible.

Derniere chose :

Pour l'asenceur en 640 480, notre champ etant le 800*600 je concede cette ascenseur.

Pour les liens visités d'une autre couleur, quelle regle d'accessibilité le demande ?

je reste super ouvert pour des retours concernant accessiweb pour le rendre plus accessible encore.

[yobiwan]

Merci a thierry pour ces lecons.

Travaillant sur l'accessiblité depuis pas mal de temps participant activement aux listes techniques de WAI et euroaccessibility j'avoue etre totalement incompétent dans le domaine. Lorsque je demande quelles sont les erreurs d'accessibilité sur nos pages ca n'est pas que je ne sache pas juger de notre travail mais simplement que je n'ai absolument pas la prétention d'etre parfait et d'avoir manqué des fautes me parait possible bien sur.

Pour positionnement full CSS je suis ouvert pour vous démontrer tres clairement les problèmes sous jacents. Je l'ai montré a Tristan NITOT il n'y a déjà qq semaines il doit me faire un retour avec la solution si il la trouve. je l'attends.

Pour info, la seule faute de P1 qui ne passe pas aux validateurs c'est la non utlisation des TH pour les tabealux de données --> nous n'avons pas de tableaux de données.

en tout cas merci de me montrer la limite de mes compétences techniques et de mon ambition au dela de celles ci.

[Monique]

Pour les liens visités d'une autre couleur, quelle regle d'accessibilité le demande ?

Je pense que le tort qu'on a trop souvent (même moi, parfois) c'est de donner un sens trop restrictif au mot "accessibilité" et qu'il faut au contraire le prendre dans le sens beaucoup plus général que lui a donné Tim Berners-Lee.

Une mise en forme différente pour les liens déjà visités (couleurs pour les voyants, type de police ou sous-lignement pour les non-voyants, par exemple) est un confort supplémentaire pour le visiteur et aide plus particulièrement ceux qui ont une moins bonne mémoire.

[yobiwan]

Nous allons réfléchir à la meileure soltution visuelle pour appliquer cette demande dès que possible. (choix de couleur, choix de soulignement ...)

Merci pour ce retour utilisateur.

Yoan

[yobiwan]

Bien, je viens de decortiquer le rapport de Access pour Tous sur la page au quotidien :

1 erreur de niveau 1 :

" Identifiez les entêtes <th> des tableaux de données. Vérifiez que vous n'utilisez pas les 16 tableaux présents sur votre page à des fins de présentation."

Comme je l'expliquais nous avons fait le choix de coder en tableau tant que nous n'aurons pas trouvé un exemple nous prouvant que le full CSS marche a 100% donc nous n'avons pas de tableaux de données donc ca n'est pas une erreur.

42 erreurs P2 :

"Remplacez l'attribut border déprécié par son équivalent en css.

c'est d'avoir mis un border=0, la non plus ca n'est pas une erreur en HTML 4.01 transitional donc pas de soucis.

Cela me fait poser une question : le validateur ne test pas le type de doctype employé ?

1 erreur de P3 :

"Ne laissez pas les zones de formulaires vide"

Voir un de mes messages précédents sur la validité de ce critère.

Pour les manual checks je ne vois pas d'erreur non plus.

Rapport de Bobby sur cette page :

P1 que des manual checks et la encore pas de soucis je pense.

P2 1 erreur : "Use relative sizing and positioning (% values) rather than absolute (pixels)."

Les valeurs absolue sont utilisées pour du border ou du padding, + largeur générale du tableau. (Notre choix la encore a été de coller au Web d'aujour'dhui en faisant un pas vers le bon sens pour esperre dans l'avenir passer totalement le pas vers du relatif a 100%. Notre choix est que plutot que fixer une regle rigide et absolue, nous effectuons des tests pour vérifier que la page passe sans auune perte d'info avec une config "extremed"? à savoir vérifier que le site passe en 800*600 feuille de style désactivée gros caractere + feuille de style tres gros caractères font noir textes jaunes) Ces tests internes + retour utilisateur nous ont poussé a valider ce critères car aucune perte d'information n'a été revelée.

Pour les manual checks je ne vois pas d'erreur non plus.

P3 : Là, mea culpa j'ai oublié un summary pour un tableau --> je modifie ca dans la journée bien sur.

L'autre c'est comme access pour tous pour les champs de formulaire.

Pour les manual checks je ne vois pas d'erreur.

Juste pour dire donc que cette page a en fait 1 erreur que je vais m'empresser de corriger quand j'arrive au boulot.

Pour les erreurs de HTML valide, comme je l'expliquais nous travaillons à améliorer cela bien sur, je suis certainement au moins autant convaincu que vous tous de la nécéssité de respecter les standards.

Merci en tout cas j'ai relevé une connerie que j'avais fait mais je me repete je ne suis pas parfait et accepte completement de l'aide et les critiques constructives sans aucunes genes si c'est pour faire améliorer l'accessibilité des sites.

[yobiwan]

Bonjour à tous,

vous trouverez à cette adresse trois copié d'écrans avec une CSS malvoyant appliquée sur trois site en 1024 pas 800*600.

Le but n'est pas de voir l'information de maniere indentique (avec une telle feuille de style "extreme" comme celle la) mais bien de ne PAS perdre d'information (l'ascensur horizontal n'est pas une perte d'info pour ce type d'utilisateurs)

La feuille de style que j'ai appliquée m'a été fournie par une personne malvoyante que je connais.

Les sites sont :

Access-pour tous.

CSSzengarden

OpenWeb

Forum Hub

AccessiWeb

Les trois premiers en full CSS

Les deux suivants avec des solutions mixtes (CSS / tableaux)

Je pense que vous comprendrez tous pourquoi je parlais de solution non acceptable d'un point de vue accessibilité pour le moment.

Je serais réellement ravi de pouvoir dire le contraire, mais fort m'est de contasté que des personnes malvoyantes par exemple ayant des config "spécifiques" n'ont pas acces du tout à l'information des sites en Full CSS (ceux que je connais).

Par contre, si la solution est trouvée (et je l'éspère très sincèrement) je ferais le forcing auprès de tous les webmasters que nous formons pour qu'il passent au FULL CSS et je l'imposerais à notre prestataire sur AccessiWeb.

[yobiwan]

http://yosimo.free.fr/css/

avec l'url c'est mieux

[Steph. K.]

Est-ce que ce forum est modéré ? car j'ai fait une réponse hier au soir et je ne la trouve pas... Est-ce une erreur de ma part ou y-a t'il une autre explication ?

Pour les liens visités je confirme simplement ce que Monique a avancé, c'est utile à tout le monde.

Pour ce qui est du codage en HTML 4 transitional, le WAI est très clair et cela me semble primodial. En effet j'espère que de nombreux outils d'aide aux personnes handicapées vont voir le jour (mesdames et messieurs les développeurs du libre, ceci est un appel aux bonnes volontés) et les développeurs n'auront pas d'autre choix que de s'appuyer sur les standards. C'est ce que je fais dans le cadre du développement d'une barre d'outils XUL destinée à faciliter la consultation des sites internet par les personnes mal-voyantes et je peux vous assurer qu'il est beaucoup plus simple d'analyser une page conforme plutôt qu'une codée "avec les pieds".

De plus une page respectant la séparation contenu / présentation est beaucoup plus simple à maintenir et il est également plus simple de fournir des FDS alternatives (impression, fort contraste, couleurs inversées...) afin de répondre aux éventuelles attentes des visiteurs.

Pour les formulaires vides je suis d'accord avec Yobiwan, il en est de même AMHA pour ce qui est de l'imbrication des balises h1 à h6, c'est une erreur au niveau sémantique mais cela ne pose pas de problème au niveau accessibilité.

Pour revenir sur le full css, acces-pour-tous est valide XHTML 1.0 strict, les css sont valides et à ma connaissance le résultat est identique sur tous les navigateurs graphiques quel que soit l'OS.