1154 sujets

Accessibilité du Web

Pages :
(reprise du message précédent)

eric1725 a écrit :
Je veux dire, si vous souhaitez cacher des éléments de type "Aller au contenu" ou "...au menu" via accesskey aux personnes voyantes soit des éléments de navigation qui n'ont pas trop d'intérêt pour eux, ce n'est pas exploitable ?


Houlà malheureux, surtout pas !
Le web n'est pas séparé entre valides voyants sans troubles moteurs ou cognitifs d'une part, et non voyants utilisateurs de lecteurs d'écran !

Les liens d'évitement sont utiles pour les non-voyants, mais pas indispensables, car ceux-ci disposent de moyens de navigation rapide plus élaborés : naviguer dans l'architecture des titres de la page (attention donc à ce qu'elle soit cohérente !), et naviguer de lien en lien, entre autres.

Par contre, un handicapé moteur dont la seule manière de naviguer est de sauter de lien en lien grâce à l'utilisation d'un dispositif de pointage adapté (plus ou moins) à son handicap... les liens d'évitement lui sont très utiles. OR, IL A BESOIN DE LES VOIR (et même de les voir clairement).


Après, à chacun de définir s'il compte mettre ce moyen en oeuvre, ou se contenter de liens d'évitement accessibles uniquement aux non-voyants, voire ne pas en mettre du tout. Mais on ne peut pas affirmer que ces liens devraient être cachés car uniquement destinés à un public de non-voyants.
Mais si un expert en accessibilité (ce que je suis loin d'être) veut corriger mes affirmations ci-dessus, ça peut être bien. J'ai peut-être proféré quelques bêtises. Smiley lol
Tiens, j'oubliais une alternative au text-indent : faire un span (comme pour le display: none et le positionner en absolu en dehors de la zone visible. C'est un peu le principe du text-indent, mais réalisé différement, et sans les problèmes de bordure sur toute la largeur de la page lors du clic il me semble.

Par contre, mêmes réserves que précédemment sur l'accessibilité de la méthode : c'est beaucoup mieux que le display: none, mais c'est moins bien que l'image avec attribut alt.
eric1725 a écrit :
ok, j'avais dit que ma question était idiote ! lol

Bon c'est clair...

Sur le fond de la question : oui, on peut utiliser ces techniques (pas celle du display:none, les autres) pour cacher aux voyants des liens d'évitement. Il faut juste être conscient de l'intérêt des liens d'évitement pour les voyants, qu'ils souffrent d'un handicap tel que ce dispositif leur facilite la navigation sur le site, ou qu'ils préfèrent naviguer au clavier plutôt qu'à la souris. On peut même estimer que, si ces liens sont correctement mis en valeur, ils peuvent également intéresser les voyants navigant à la souris. Smiley cligne
Mpop

Je comprends parfaitement
euh, bon, cette fichue sclérose en plaques m'a paralysé ma main droite. J'ai du m'habituer à utiliser la souris à gauche. Je ne sais pas combien de temps je vais tenir...
Mais quels sont donc ces fameux dispositifs ??? Tu parles du capteur près de la joue qui, enclenché, amène une sorte de trackball au menton d'une personne, par exemple tétraplégique, et qui va lui permettre de surfer ? Ou d'autre chose parce que mis-à-part ça, je ne sais pas ce qui existe et ça m'intéresse vachement au cas où...
Smiley smile
mpop a écrit :
Au final, et même si ça ne répond pas à tous les besoins (en particulier les roll-overs en CSS, ou tout simplement une meilleure indépendance du contenu HTML et du style graphique), la solution la plus accessible et la plus robuste est celle de l'image de contenu dans le HTML, avec attribut alt correctement renseigné.

Enfin il me semble... Smiley confus
Tout à fait d'accord. C'est d'ailleurs la seule solution qui ne passe pas par un "hack", ce qui plaide en sa faveur. Smiley cligne

Ceci dit, comme tu le dis, ça ne règle pas le problème de la séparation du contenu et de la présentation, et ça ne permet pas de faire des effets de roll-overs en n'utilisant qu'une seule image...
eric1725 a écrit :
Mais quels sont donc ces fameux dispositifs ??? Tu parles du capteur près de la joue qui, enclenché, amène une sorte de trackball au menton d'une personne, par exemple tétraplégique, et qui va lui permettre de surfer ? Ou d'autre chose parce que mis-à-part ça, je ne sais pas ce qui existe et ça m'intéresse vachement au cas où...

Je n'ai pas étudié la question et j'en ai une idée très vague. Je sais juste que ça existe (même si, comparé aux technologies d'assistance pour les non-voyants, c'est moins développé/médiatisé). Il me semble que jpv (modérateur sur ces forums) connait bien le sujet. Pour ma part, je ne saurais pas trop vers quoi t'orienter.
J'ai une question idiote :

Si le display: none est déconseillé pour cacher des éléments pour les personnes non handicapée, a quoi peut-il bien servir.. ?

Promis je retourne dans mon placard Smiley biggol ..
La propriété diplay : none peut être utilisée pour une feuille de style d'impression, par exemple, afin de ne pas imprimer un élément ...
Smiley cligne
Modérateur
Neovov a écrit :
Bah à ce moment là pourquoi c'est pas print: none; Smiley lol ?


Bien parce que display:none peut être utilisé pour masquer des éléments lors de l'impression, mais également sur différents types de média.

De plus, certains scripts (Javascript) peuvent utiliser le display:none pour masquer/afficher des éléments selon les actions de l'utilisateur.
Je sais Tony Monast, mais la ou je voulais en venir c'est que display: none doit être évité pour cacher des informations a une personne "normale", je me demandais alors le but d'un display: none...

Ok certains script JS peuvent s'en servir, mais niveau accessibilité ?
Neovov a écrit :
Ok certains script JS peuvent s'en servir, mais niveau accessibilité ?

Ben non, niveau accessibilité -- et au moins dans la pratique -- le display:none ne sert à rien.
mpop a écrit :

Je n'ai pas étudié la question et j'en ai une idée très vague. Je sais juste que ça existe (même si, comparé aux technologies d'assistance pour les non-voyants, c'est moins développé/médiatisé). Il me semble que jpv (modérateur sur ces forums) connait bien le sujet. Pour ma part, je ne saurais pas trop vers quoi t'orienter.



Un ami atteint de sep primaire utilise ce dispositif depuis sa voiturette électrique. Il y a tout d'abord un capteur situé près de sa joue, une pression dessus et un bras articulé vient positionner une sorte de trackball au niveau du menton. Par diverses manœuvres du menton, il va pouvoir surfer sur le net. Bien entendu, il utilise le clavier virtuel pour écrire.

Seul hic, le clic qui est pénible (Pierre doit faire un geste pas possible de la machoire) d'où mon idée du javascript onmouseover à retardement que Quentin m'aidait à mettre au point mais ça n'a pas trop plu ici...

Pour le reste, un petit écran situé sur les accoudoir de la voturette va lui permettre de gérer toute la domotique de sa maison depuis l'éclairage jusqu'au chauffage en passant par la t v, chaine hi-fi etc...

Je vous assure que c'est très impressionnant.



Eric Smiley smile
mpop a écrit :
Mais si un expert en accessibilité (ce que je suis loin d'être) veut corriger mes affirmations ci-dessus, ça peut être bien. J'ai peut-être proféré quelques bêtises. Smiley lol


Je confirme l'ensemble de tes remarques, notamment celle qui consiste à utiliser un span positionné en absolue en dehors du wiewport.
Cette technique à été popularisé par Paul Bohman dans cet article :
Invisible Content Just for Screen Reader Users (en).

Elle est effectivement préférable au text-indent pour des raisons évidentes d'ergonomie au niveau de la prise de focus.

Au sujet des aides pour les handicaps moteurs :
mpop a écrit :

Je n'ai pas étudié la question et j'en ai une idée très vague. Je sais juste que ça existe (même si, comparé aux technologies d'assistance pour les non-voyants, c'est moins développé/médiatisé).


Ces aides ont la particularité d'être extraordinairement variées et souvent adaptées au cas par cas, ce qui nous les rends pariculièrement difficiles à prendre en charge.

Le champs de ces aides va de rien du tout, utilisation du clavier à l'aide de stick (head-stick, mouth-stick, noise-stick...) à des systèmes complexes electro-pneumatique (contrôle par le souffle) ou par capteurs interposés (contrôle par le mouvements retinien...).

Cela s'accompagne souvent par l'utilisation conjointe de périphérique adapté comme les dispositifs de pointage à pression temporisée, souris anti-tremblement, clavier monomanuel, convexe ou concave ou à touches géantes...

Ce qu'il faut en retenir c'est que ces aides sont généralement adaptés au cas par cas avec souvent une bonne dose de bricolage, notamment dans le cas de polyhandicapés.

Cette immense diversité doit nous pousser à deux choses :

Privilégier les adaptations simples, c'est à dire celles dont nous somme certains qu'elles vont fonctionner pour tout le monde.
Là il n'y à pas de mystère elles sont très réduites : Liens de navigation interne visibles, carte du site, éléments d'interface (formulaire) bien construits et simple à utiliser, surface des zones cliquable "suffisantes", focus identifiable.

Pour ces publics il est difficile de faire mieux et nous n'avons pas beaucoup plus de réponses à apporter.

En revanche, dés lors que nous pouvons contrôler le profil utilisateur, par exemple pour des applications intranet, alors le problème est inversé et il est possible de tout inventer, notamment au travers de javascript comme le dispositif que proposait eric :

eric1725 a écrit :

Seul hic, le clic qui est pénible (Pierre doit faire un geste pas possible de la machoire) d'où mon idée du javascript onmouseover à retardement que Quentin m'aidait à mettre au point mais ça n'a pas trop plu ici...


Ce n'est pas que cela ne nous à pas plus mais simplement (voir mes remarques et celles de laurent) que ce dispositif règle le problème de Pierre mais va en causer d'autres à Paul ou Jacques simplement parce que leur dispositif ne va pas y être adapté.

Le principe de focus séquencé est déjà utilisés notamment au travers de dispositifs comme confort de lecture ou labelvue, c'est très bien mais ça résoud qu'UN cas parmis des centaines d'autres situations.

Ca ne peut être envisagé, comme le soulignait Laurent, que comme une solution de type utilisateur, ou pour un applicatif web pour lequel nous contrôlons le profil utilisateur.

Jean-pierre
Modifié par jpv (27 Nov 2006 - 01:08)
Pages :