1174 sujets

Accessibilité du Web

Bonjour à toutes et tous Smiley smile

Pour éviter la dispersion et la redondance de questions ou remarques et puisque nous avons la chance d'avoir à nos côtés au moins deux auteurs du document, je vous propose d'utiliser un sujet unique pour toutes les remarques et questions concernant le projet de nouveau référentiel pour l'administration.

Si nécessaire, nous pourrons établir une liste claire de toutes les remarques et la faire parvenir par la voie officielle définie avant l'échéance.

Récupération du premier échange : "RGAA : point de contrôle 1.2 ?!?"

zamoy a écrit :
Bonjour à tous,

En quoi consiste exactement le point de contrôle 1.2 des tests web du RGAA? Quelqu'un peut-il me traduire ça... en français?!?

"1.2.1 : doublement des zones cliquables côté serveur"
"1.2.2 : accès aux liens textuels doublant les zones cliquables côté serveur"

J'ai beau retourner ça dans tous les sens, je ne comprends pas un traitre mot de ces 2 phrases...

Et vous?


Christian Le Bouler a écrit :
Salut,

ce serait bien que tu mettes un lien Smiley cligne


zamoy a écrit :
http://www.rgaa.referentiels.modernisation.gouv.fr/index.php/front/web/points_de_controle/tous_les_tests_web


Christian Le Bouler a écrit :


Je suppose que cela concerne les images map par exemple. Comme indiqué dans l'explication, celles ci suppose Un agent utilisateur graphique + un dispositif de pointage type souris donc comme telles elles ne peuvent suffire en terme d'accessibilité.

J'ai d'ailleurs déjà vu ce genre de dispositif dans certains site :

image map carte de france avec click possible sur chaque département et conjointement liste des départements en texte et en ordre alphabétique.


jpv a écrit :
Bonjour,

Je suppose que cela concerne les images map


Cela concerne exactement les images map coté serveur.

Ce type d'image map, hérité de Html 3.2, reporte la gestion des zones cliquable sur le serveur.

On identifie une image map coté serveur par l'attribut ismap et, surtout le fait qu'il n'y à pas de liste d'area shape !.

Ce sont les coordonnées du pointeur qui sont renvoyées au serveur et servent à identifier la zone visée.

Du coup les aides techniques n'ont aucune chance de pouvoir récupérer la liste des alternatives aux zones cliquables.

Les deux tests visent à s'assurer qu'il existe, au titre d'alternative, une liste de liens équivalente aux zones cliquables immédiatement après l'image-map.

Cela étant, cette technique des images map coté serveur est désuète, personnellement la dernière que j'ai rencontré c'était au début des années 2000.

W.C.A.G 1.0 - Html techniques - 7.4.4 Server-side image maps (en)

Jean-Pierre

Laurent Denis a écrit :
Pour compléter l'explication de Jean-Pierre: dans la pratique, le RGAA (comme d'autres méthodes d'accessibilité), oblige à employer systématiquement des images map côté client par défaut, qui elles, peuvent être rendues accessibles. Voir le Test 9.1.1 Accessibilité des images avec zones cliquables côté serveur

Modifié par dominique (16 May 2007 - 11:12)
Bonjour,

A propos du point de contrôle 3.6

dans l'exemple présenté :

<p>Ingrédients :</p>
<ul>
   <li>farine</li>
   <li>oeufs</li>
   <li>lait</li>
</ul>

<p>Préparation :</p>
<ol>
   <li>verser la farine dans un saladier</li>
   <li>y casser les oeufs</li>
   <li>incorporer progressivement le lait en mélangeant</li>
</ol>


Je pense qu'il aurait été préférable d'annoncer les listes par un <hn> et non un <p>.
Modifié par Christian Le Bouler (16 May 2007 - 16:29)
Christian Le Bouler a écrit :

Je pense qu'il aurait été préférable d'annoncer les listes par un <hn> et non un <p>.


Dans la pratique, ce sera souvent le cas en effet, mais pas toujours: il suffit d'avoir épuisé les niveaux de titrage h6 compris. En outre, dans l'exemple, faute de contexte complet, le niveau de titrage ne peut être déterminé...

Mais cela dit... Pourquoi pas ? Smiley cligne
Modifié par Laurent Denis (16 May 2007 - 18:08)
Laurent Denis a écrit :
il suffit d'avoir épuisé les niveaux de titrage h6 compris

Ou bien d'avoir épuisé les niveaux de titrages disponible, pour le rédacteur, avec l'outil CMS utilisé.
Florent V. a écrit :

Ou bien d'avoir épuisé les niveaux de titrages disponible, pour le rédacteur, avec l'outil CMS utilisé.
Ouaip, souvent h3 d'ailleurs.
Ce qui motive, entre autre, ma remarque c'est que dans une lecture linéaire du référentiel le point précérent, le 3.5 donc, traite justement de la question de l'utilisation de la hiérarchie des titres. Ce serait mieux je trouve que le point suivant mette cela en oeuvre in concreto.

Mais certes le référentiel n'est peut être pas fait pour s'arrêter à une simple lecture linéaire.

Remarque annexe, et sans vouloir lancer un débat de plus, j'ai tendance à penser que si on en arrive à épuiser toute la hiérarchie des titres alors on doit se poser la question de l'accessibilité cognitive du document. Car il y a un vrai risque je crains.
Modifié par Christian Le Bouler (16 May 2007 - 18:29)
Florent V. a écrit :

Ou bien d'avoir épuisé les niveaux de titrages disponible, pour le rédacteur, avec l'outil CMS utilisé.


Oui mais dans ce cas et en toute cohérence il faudrait se poser la question du cms utilisé.
je ne suis pas contre mais il ne faut pas tomber dans l'effet inverse et perdre de vu le but de l'exemple
goetsu a écrit :
je ne suis pas contre mais il ne faut pas tomber dans l'effet inverse et perdre de vu le but de l'exemple


Oui, oui, c'était juste une remarque de casse pied patenté en fait Smiley langue
Bonjour à tous,

Ma question concerne le point de contrôle 9.5 .( http://www.rgaa.referentiels.modernisation.gouv.fr/index.php/front/web/points_de_controle/9_5 )

On sait pertinement que les raccourcis clavier sont un echec ( http://blog.alsacreations.com/2005/09/27/191-accesskey-le-grand-echec-de-laccessibilite-du-web et http://openweb.eu.org/articles/accesskey_essai_non_transforme/ )

Pourquoi font-ils donc partie du référentiel?!?

Votre avis?
Modifié par zamoy (07 Jun 2007 - 17:59)
je t'invite à poser la question sur le forum :
http://rgaa.planete-accessibilite.com/

mes voilà déjà quelques points: les tests associés ne sont que recommandés et recommandés que pour la liste présente dans le pc et il est dit explicitement dans le PC qu'il vaut mieux les éviter mais comme certains les utilise déjà ont ne va pas les obliger à les enlever
Bonjour,

ma question concerne les tableaux de données, en particulier les éléments thead, tfoot et tbody.

Au niveau XHTML il est spécifié que les éléments doivent apparaître dans l'ordre suivant:
- thead, tfoot, tbody

Dans les recommandations uwem, un ordre logique est préconisé (Test 12.3_HTML_09), donc en opposition avec le XHTML 1.0 strict

Dans la directive 5, point 5.2 les éléments thead, tfoot et tbody sont conseillés pour structurer un tableau de données. Aucune recommandation n'est donnée sur leur ordre d'apparition, ni d'exemple utilisant tfoot.

Sachant que certains lecteurs d'écrans vont présenter l'ordre d'apparition des éléments (donc tfoot avant tbody si on suit XHTML 1.0), quel est la position à adopter dans ce cas?
ce point n'a pas été repris de uwem parce qu'il n'a aucune incidence au niveau de la lecture d'un tableau de donnée par les lecteurs d'écran .

Par ailleurs UWEM ne va pas contre les le xhtml stricte, ils disent que l'ordre doit être logique mais ils ne donnent pas celui ci (la liste dans le test est la liste des éléments rentrant dans le champ d'application et non l'ordre logique dont parle le test).

Par contre si le RGAA n'oblige pas à utiliser thead, tfoot et tbody, le RGAA oblige à la validité du DOM par rapport à la DTD déclarée donc je ne pourrais pas faire thead tbody tfoot
Modifié par goetsu (25 Jun 2007 - 19:27)
goetsu a écrit :
donc je ne pourrais pas faire thead tbody tfoot

En attendant (X)HTML 5. Smiley cligne
Bonjour,

Juste un point de précision sur la réponse d'Aurélien :

Les éléments thead, tfoot et tbody sont spécifiques au média print : ils permettent de répéter les en-têtes et le pied de tableau suite à une rupture de page.

Jean-Pierre