Contenus dynamiques accessibles

Bonjour,

Je me posais une question pourquoi les contenus dynamiques doivent-ils être accessibles alors que pour les personnes aveugles le JS sur un site ne sera pas aperçu ?

J'aimerais également savoir également que signifie un agent utilisateur ?

Voici où je l'ai trouvé :
[#b]
8.5.[Scripts] 5 : Absence de changements de contexte suite à une action de l'utilisateur sans validation explicite ou information préalable

Procédure de test

1.Si du code javascript est utilisé dans la page, poursuivre le test, sinon le test est non applicable.

2.Si le code javascript entraine un changement de contexte (changement d'agent utilisateur, déplacement du focus, mise à jour ou génération de contenu qui change le sens d'une page, validation de formulaire) dans la page après une action de l'utilisateur, poursuivre le test, sinon le test est non applicable.

3.Si l'utilisateur est averti préalablement du type de changement de contexte que peuvent entraîner ces actions par au moins une des solutions suivantes :
o de façon textuelle,
o par la mise à disposition d'un bouton de validation (input type image, submit, button) validant explicitement le changement de contexte
o par la mise à disposition d'un lien activable au clavier et à la souris (et non à la prise de focus sur l'élément) validant explicitement le changement de contexte,
le test est validé, sinon le test est invalidé

Merci
Modifié par laetitia79 (04 Nov 2010 - 14:05)

Bonjour,

laetitia79 a écrit :
Je me posais une question pourquoi les contenus dynamiques doivent-ils être accessibles alors que pour les personnes aveugles le JS sur un site ne sera pas aperçu ?

En fait un lecteur d'écran (type de logiciel utilisé par les aveugles ou certains malvoyants pour utiliser un ordinateur) est un logiciel qui va «lire» ce que présentent les autres logiciels: navigateur web, gestionnaire de fichiers, traitement de texte, etc.

Donc un lecteur d'écran est utilisé avec un navigateur web classique, en général Internet Explorer ou Firefox sur Windows, ou Safari sur Mac. Ce navigateur web va interpréter le JavaScript normalement. (Sauf pour les utilisateurs qui ont désactivé JavaScript, mais ce n'est pas le cas pour la plupart.)

Ça veut dire que pour qu'un site soit accessible, le JavaScript doit être accessible aussi.
Pour préciser, ce n'est pas le code JavaScript lui-même qui est perçu par l'utilisateur, que ce dernier soit aveugle ou non. Par contre, on utilise en général JavaScript pour modifier le DOM, c'est à dire la représentation du document Web dans la logique du navigateur. Le DOM est construit à partir du code HTML de départ, que le navigateur interprète, et aussi par les ajouts et modifications que les scripts JavaScript peuvent faire à divers moments.

laetitia79 a écrit :
J'aimerais également savoir également que signifie un agent utilisateur ?

La notion d'Agent Utilisateur est utilisée dans les standards du Web pour désigner les logiciels qui exploitent et restitue les documents web: navigateurs, lecteurs d'écran, robots d'indexation, etc.
Plus d'infos ici: http://fr.wikipedia.org/wiki/User-Agent
Modifié par Florent V. (04 Nov 2010 - 14:54)

Merci beaucoup

Bonjour,

comme l'a expliqué Florent, un lecteur d'écran s'appuie sur ce que lui communique le navigateur web. Si tu rajoutes des liens, modifie du texte, etc au chargement de la page en JS alors le lecteur d'écran tout comme le navigateur web afficheront/liront ces liens, ce texte etc. Si JS est désactivé alors aucun des deux ne le fait bien entendu.
La proportion de JS activé chez les non-voyants serait ... majoritaire. Les 3/4 mais peut-être que la réalité est 50 ou 90% ... Il faut le prendre en compte, en résumé

Jusqu'à présent (en 2010 avant que ARIA se généralise), si un non-voyant a lu la moitié d'une page et que JS modifie le début de la page, le non-voyant n'en saura rien. Il faut donc qu'il soit prévenu ou que la partie modifiée se trouve après.
Une liste de choix qui entraîne le chargement d'une nouvelle page dès qu'on sort de cette liste est par exemple déroutante pour un non-voyant. Moi je vais bien voir que la page est blanche, qu'une nouvelle se charge et qu'il faut que j'attende mais le non-voyant constatera que sa lecture s'est interrompue, qu'il n'y a plus rien sans repère visuel pour savoir ce qu'il se passe. Les fenêtres modales en début de code HTML c'est pareil: le lecteur d'écran va continuer à lire la page sans se soucier d'un div en position absolue visuellement par dessus les autres ... à moins que le focus ne soit placé sur cette "fausse pop-up" PUIS empêcher de pouvoir lire autre chose que cette fen. modale PUIS en en sortant remettre le focus là où la lecture s'était interrompue sans quoi la lecture reprend du début ou de la fin selon l'endroit du code où elle est. Beaucoup de choses à gérer mais il y a une bonne raison à cela
Modifié par Felipe (04 Nov 2010 - 15:44)

Felipe a écrit :

Jusqu'à présent (en 2010 avant que ARIA se généralise), si un non-voyant a lu la moitié d'une page et que JS modifie le début de la page, le non-voyant n'en saura rien. Il faut donc qu'il soit prévenu ou que la partie modifiée se trouve après.

Bonjour,
quand tu dis "il faut donc qu'il soit prévenu ou ...", est-il donc possible de le prévenir plutôt que de réorganiser les tags de la page ? et dans ce cas, comment le prévenir ?

d'avance merci

Rachel.

Salut,

laetitia79 a écrit :
Je me posais une question pourquoi les contenus dynamiques doivent-ils être accessibles alors que pour les personnes aveugles le JS sur un site ne sera pas aperçu ?

Justement, les logiciels de lecture d'écran peuvent lire le JavaScript. Il est donc important que tout ce qui est géré en JavaScript soit également accessible.

laetitia79 a écrit :
J'aimerais également savoir également que signifie un agent utilisateur ?

Wikipédia est ton ami.

Soit dit en passant, l'accessibilité ne se réduit pas aux aveugles et une personne qui voit bien, mais qui est dyslexique, peut très bien utiliser un logiciel de lecture d'écran.

a écrit :
La proportion de JS activé chez les non-voyants serait ... majoritaire. Les 3/4 mais peut-être que la réalité est 50 ou 90% ... Il faut le prendre en compte,
en résumé

C'est bien plus que ça. Je dirais que c'est 95-98%, dont 90% de gens qui ne savent pas ce qu'est javascript.

a écrit :
Jusqu'à présent (en 2010 avant que ARIA se généralise), si un non-voyant a lu la moitié d'une page et que JS modifie le début de la page, le non-voyant
n'en saura rien. Il faut donc qu'il soit prévenu ou que la partie modifiée se trouve après.

Ca peut être plus compliqué que ça, ça dépend de la façon de lire la page.
Si on est vraiment en cours de lecture, ça peut aussi faire sauter des paragraphes ou avoir d'autres effets pervers... mais c'est assez peu probable sauf pour les contenus hyperactifs.

a écrit :
Une liste de choix qui entraîne le chargement d'une nouvelle page dès qu'on sort de cette liste est par exemple déroutante pour un non-voyant. Moi je vais
bien voir que la page est blanche, qu'une nouvelle se charge et qu'il faut que j'attende mais le non-voyant constatera que sa lecture s'est interrompue,
qu'il n'y a plus rien sans repère visuel pour savoir ce qu'il se passe.

Le plus énervant dans ce cas, c'est de devoir recommencer la lecture au début de la page. Pour le changement de page en lui-même on s'en rend compte facilement grâce au légendaire son "clic" (en tout cas sous IE)

a écrit :
Les fenêtres modales en début de code HTML c'est pareil: le lecteur d'écran va
continuer à lire la page sans se soucier d'un div en position absolue visuellement par dessus les autres ... à moins que le focus ne soit placé sur cette
"fausse pop-up" PUIS empêcher de pouvoir lire autre chose que cette fen. modale PUIS en en sortant remettre le focus là où la lecture s'était interrompue
sans quoi la lecture reprend du début ou de la fin selon l'endroit du code où elle est. Beaucoup de choses à gérer mais il y a une bonne raison à cela

LE cas des fausses boîtes de dialogue est assez complexe. ON a globalement deux choix possibles :
- Soit comme tu l'as dit, on peut la mettre n'importe où dans le DOM mais on doit alors correctement gérer le focus
- Soit on l'insère directement au bon endroit dans le DOM, chose que personne ne fait je ne sais pas au juste pourqoi.
Modifié par QuentinC (05 Nov 2010 - 13:01)

rachel-foucard a écrit :

Bonjour,
quand tu dis "il faut donc qu'il soit prévenu ou ...", est-il donc possible de le prévenir plutôt que de réorganiser les tags de la page ? et dans ce cas, comment le prévenir ?

d'avance merci

Rachel.

Re bonjour,
je vois qu'il y a eu des réponses mais pas sur ma question . Alors je fais un petit up.

Encore merci!

Le seul moyen efficace à ma connaissance, c'est d'utiliser WAI-ARIA. Ça n'est pas une solution pour tous les utilisateurs de lecteur d'écran (en particulier ceux qui ont une vieille version et/ou IE6 ou IE7 comme navigateur associé), mais à l'impossible nul n'est tenu.

merci beaucoup !

merci pour ces info tres utiles !