Accessibilité d'une application web - javascript

Bonjour,

Je travaille pour le compte d'un client qui souhaite augmenter son niveau d'accessibilité. Mais ce sujet est nouveau pour moi et je n'en maitrise pas toutes les subtilités.
Par exemple, dans mes spécifications j'ai "Si l’on désactive le Javascript, la navigation dans les pages devient impossible".
Quelqu'un pourrait m'expliquer ce que veux dire cette phrase?

Je souhaite apprendre beaucoup sur l'accessibilité pendant ce projet donc je suis prêt à échanger sur ce sujet!

Merci d'avance pour vos réponses,
Vince

Re-post car ma question était mal posé : j'ai désactivé javascript et l'application me prévient qu'elle est bloquée car javascript n'est pas activé, je ne peux donc rien faire.
Question : comment faire pour que palier à ce problème? Je suppose remplacer tous les mécanismes javascript par d'autres mécanismes. Quelqu'un pourrait être plus précis que moi?
Par exemple, traiter les formulaires par des submit au lieu de onclick=""?

Deuxième point : "Les attributs nécessaires à l’utilisation de frames ne sont pas renseignés" c'est à dire n'oublier aucune balise de formulaire html?

J'attend vos commentaires,
Vince

Bonjour,

Pour le JavaScript, vu le message d'erreur, il est fort possible qu'il faudra repensser toute l'application avec à l'esprit l'utilisation de JavaScript non intrusif. Ca sera long, mais c'est un mal nécessaire.

Pour les frames, je ne suis pas sûre de comprendre le "message d'erreur" (d'où viens t'il d'ailleurs) mais en général les frames sont plus que déconseillées vis-à-vis de l'accessibilité.

Bonjour et bienvenue,

pour ce qui est de JS, ce serait chouette que ton site (application ?) fonctionne sans. Mais si ton environnement de travail est maîtrisé (cas d'un intranet) et que tu es certain que JS est activé sur tous les postes utilisateurs alors ce n'est pas indispensable. C'est la nouvelle donne des WCAG 2.0.
Mais si c'est pour de la navigation, mettre des liens href="" n'est en général pas super compliqué et plutôt une bonne idée.

frames> ça doit avoir un rapport avec l'attribut title de l'élément frame http://www.accessiweb.org/fr/guide_accessiweb/guide-accessiweb-fiche-2-2.html#comprendre
Aucun rapport avec un formulaire a priori à moins que tu aies un formulaire dans une frame ?

a écrit :
Par exemple, traiter les formulaires par des submit au lieu de onclick=""?

Traiter un formulaire avec onclick sur le bouton de soumission n'est jamais une bonne idée. Il faut toujours utiliser l'évènement onsubmit, jamais onclick dans ce cas précis.

a écrit :
Deuxième point : "Les attributs nécessaires à l’utilisation de frames ne sont pas renseignés" c'est à dire n'oublier aucune balise de formulaire html?

Rien à voir avec les formulaires du tout. Pour rendre des frames accessibles, il faut :
- Qu'elles soient clairement organisés et bien "découpées", c'est-à-dire qu'il soit aisément possible de savoir quel est le but de / à quoi sert chaque frame. Y compris pour les iframes, même avec contenteditable=true. Il faudrait idéalement que le début d'une frame coincide avec le début logique de quelque chose d'important dans l'application, si tu vois ce que je veux dire. Donc une frame de navigation et une frame de contenu est parfaitement faisable.
- Mettre un titre à chaque frame pour en indiquer son rôle, cf. attribut title.
- Se limiter à maximum 3 ou 4 frames, voire exceptionnellement 5, sinon l'organisation du tout devient difficile à percevoir. On perd en cohérence et en simplicité. Je suis déjà tombé sur des sites avec 10 frames ou plus... l'horreur

Si cela est fait correctement et que tout es clair et pratique à utiliser, les frames sont alors plus ou moins accessibles.
Rappel : avec jaws, on peut naviguer d'une frame à l'autre avec la touche M

Mais d'un point de vue plus général, les frames sont déconseillées la plupart du temps, pour le référencement notamment. Donc honnêtement, je les supprimerais.

Tout d'abord merci pour vos réponses très intéressantes, je vais bien étudier tout ce que vous m'avez conseillé!

Le message "Les attributs nécessaires à l’utilisation de frames ne sont pas renseignés", n'est pas un message d'erreur, c'est une remarque que mon client a eu lorsqu'il a fait expertiser son site pour l'accessibilité.

Pour les frames j'ai "si possible ne pas les utiliser de frames, sinon expliciter le nom des frames à travers le name, voir le title si besoin.", je vais voir ce que je peux faire, je ne suis pas encore rentré dans le code.

@+

Et les messages sont pas plus détaillés que ça ?
Quelle était la méthodologie de l'audit d'accessibilité ? S'il utilisait le référentiel Accessiweb et ses critères, le lien que j'ai précédemment donné te permettra de consulter les quelques 90 autres critères classés en 14 catégories. Quand ça te semble obscur, un petit tour dans le guide Accessiweb et tu retrouves rapidement de quoi parlaient exactement le critère et le test qui a échoué avec des détails sur les personnes impactées, la manière utilisée pour tester et des solutions.
Modifié par Felipe (20 Oct 2009 - 17:00)

Bonjour,

Si une évaluation experte de l'accessibilité a été faite, elle mentionne obligatoirement la méthode d'application utilisée et le cas échéant sa version. Par exemple, comme il s'agit peut-être d'Accessiweb ici : Accessiweb 1.0 (dit aussi abusivement référentiel ADAE) ou Accessiweb 1.1.

Si l'évaluation a été faite (curieusement) selon Accessiweb1.0, même si ce référentiel reste théoriquement applicable, il est prudent de se référer à cette table de correspondance pour identifier les critères propres à cette version qui n'ont plus court dans la version actuelle, étant en dehors de exigences de la norme d'accessibilité internationale WCAG. Par exemple, le recours à l'attribut NAME des FRAME est inopérant pour répondre aux exigences WCAG.

Si l'évaluation ne se réfère à aucune méthode d'application (que ce soit accessiweb, RGAA, Anysurfer, UWEM, etc.) ou qu'elle ne fait qu'évoquer le respect de WCAG... Disons qu'il faut alors l'aborder avec une très très grande prudence.

Bonjour à tous,

Laurent Denis a écrit :
Si l'évaluation ne se réfère à aucune méthode d'application (que ce soit accessiweb, RGAA, Anysurfer, UWEM, etc.) ou qu'elle ne fait qu'évoquer le respect de WCAG... Disons qu'il faut alors l'aborder avec une très très grande prudence.

C'est surtout le choix du prestataire qu'il faut aborder avec une très très grande prudence.
Mon ancien employeur m'avait demandé de faire un audit accessibilité du site du Com*****riat à l'En**gie At***que (j'ai effacé quelques lettres par souci de discrétion ). Charge de travail pour cette tâche : 0,25 jour.
J'ai demandé si c'était bien sérieux, on m'a dit oui, j'ai donné ma démission à la place de rendre un audit

Ericf, c'est sur que 0.25 jours c'est un peu abusé, c'est du foutage de gueule!!
Moi de ce côté là je suis tranquille j'ai tout le temps dont j'ai besoin (pas trop quand même .

Quand à l'audit d'accessibilité, en fait c'est la MOA de mon client qui l'a réalisé, je ne sais sur quelle norme ils se sont basé, mais le rapport que j'ai est assez sommaire, juste quelques remarques dans un mail... (sont pas forts en doc), comme d'habitude, je vais devoir faire la moitié de leur boulot

0,25 jours = 2h... ça permet déjà de se faire une première idée. Si un site est pourri, ça se voit tout de suite.

Par contre évidemment, un truc détaillé page par page c'est clairement pas faisable.

Alors là j'ai mis la main sur quelque chose de très intéressant, une doc complète avec la norme WCAG1.0, elle était cachée!
Les spécifications sont donc plus claires à présent!

Oui, c'est déjà un grand pas. Un site conforme à WCAG1.0 le sera aussi à WCAG2.0, c'est à dire qu'il sera accessible. En revanche, il sera plus compliqué et coûteux à réaliser, avec diverses choses inutiles dedans.

N'hésites pas à avoir l'oeil collé sur le différentiel WCAG1.0 / WCAG2.0.
Modifié par Laurent Denis (25 Oct 2009 - 08:42)

Je reviens à la charge!
Dans notre application nous avons des textes en gris foncé sur un fond gris clair, ce qui n'est pas très approprié pour une lisibilité maximum.
Quelqu'un connaitrait une couleur de texte qui ne fasse pas trop moche sur du gris??
Il faut aussi que je réfléchisse à une couleur pour les liens car actuellement les textes et les liens sont de la même couleur donc il faudrait les différencier.

Vince84 a écrit :
Dans notre application nous avons des textes en gris foncé sur un fond gris clair, ce qui n'est pas très approprié pour une lisibilité maximum.

À voir. Quel est le coefficient de contraste (contrast ratio) en utilisant l'algorithme des WCAG 2? Tu peux par exemple tester ça ici:
http://snook.ca/technical/colour_contrast/colour.html
Pour du texte de taille normale, un minimum de 4.5 est demandé. On notera que les contrastes les plus forts (noir sur blanc par exemple) ne sont pas forcément les meilleurs, car ils posent problème à certains (les dyslexiques notamment).

Vince84 a écrit :
Quelqu'un connaitrait une couleur de texte qui ne fasse pas trop moche sur du gris??

Du noir.

Vince84 a écrit :
Il faut aussi que je réfléchisse à une couleur pour les liens car actuellement les textes et les liens sont de la même couleur donc il faudrait les différencier.

Du bleu.

Tiens j'ai une "spécification" douteuse à vous montrer, si quelqu'un a une idée sur ce que ça veut dire :
je cite : Ajouter un titre H1 si non présent par exemple avec le texte "mot".
Je précise qu'il n'y a pas de contexte autour de cette phrase, elle fait partie d'une liste de spécifications.
??