Javascript, display et accessibilité

(reprise du message précédent)

a écrit :
J'ai bien essayé Jaws, mais quand on ne le connait pas et qu'on n'a pas l'habitude de ce mode de navigation, et surtout aucune notion de ce que ça peut
être de ne pas voir, c'est pas facile

Pour éviter d'être tenté, éteins ton écran. Mets la voix à une vitesse lente. C'est sûr que c'est une histoire d'habitude que d'être guidé à la voix et ce n'est effectivement pas facile.

P.S. Pardonnez-moi pour les fautes mais je viens de constater avec désarroi que le champ de réponse ne fonctionne plus avec IE6 + jaws 7.10 sur ma vieille machine. Quelque chose a été modifié récemment sur le forum ?

QuentinC a écrit :
- L'autre avec la page laurem ipsum ne marche pas du tout. J'ai beau cliquer sur les liens, rien ne se passe.

Si tu lis le lorem ipsum c'est bon car il est caché, ce qui est perturbant pour toi ce sont les liens qui ne mènent nulle part mais là je ne sais plus trop quoi faire car ils servent à afficher le texte… Ils sont nécessaires pour les personnes naviguant au clavier.

Merci pour le compte-rendu

a écrit :

Si tu lis le lorem ipsum c'est bon car il est caché,

Le but n'était pas de le cacher à tout le monde y compris les revues d'écran ?
Je croyais justement que le but du test était de...

a écrit :
ce qui est perturbant pour toi ce sont les liens qui ne mènent nulle part

... et surtout qui ne font rien d'autre. Règle d'or selon QuentinC : un lien doit forcément faire quelque chose de concret. sinon, il n'a pas à être là un point c'est tout.
Réflexion que pourrait faire un utilisateur lambda : « je peux cliquer ici mais ça fait rien, c'est nul ce site il ne marche pas, je vais aller voir ailleurs ».

Comme je pensais que les lecteurs d'écran avaient des problèmes avec les display:none, j'avais utilisé cette technique pour que le contenu soit lisible pour tous. L'exemple n'était peut-être pas très heureux.
Modifié par Patidou (08 Dec 2008 - 22:21)

QuentinC a écrit :

Le but n'était pas de le cacher à tout le monde y compris les revues d'écran ?
Je croyais justement que le but du test était de...

C'était effectivement le but de ma demande, mais Patidou a fait son script dans un esprit légèrement différent.

a écrit :

Si tu lis le lorem ipsum c'est bon car il est caché, ce qui est perturbant pour toi ce sont les liens qui ne mènent nulle part mais là je ne sais plus trop quoi faire car ils servent à afficher le texte… Ils sont nécessaires pour les personnes naviguant au clavier. sweatdrop

a écrit :

... et surtout qui ne font rien d'autre. Règle d'or selon QuentinC : un lien doit forcément faire quelque chose de concret. sinon, il n'a pas à être là un point c'est tout.
Réflexion que pourrait faire un utilisateur lambda : « je peux cliquer ici mais ça fait rien, c'est nul ce site il ne marche pas, je vais aller voir ailleurs ».

Bons points... Je viens de réaliser que mes <h3>, puisqu'ils ne sont pas des liens, ne sont pas accessibles au clavier (ou alors j'ai pas trouvé comment)... je vais regarder ça.

a écrit :
Comme je pensais que les lecteurs d'écran avaient des problèmes avec les display:none, j'avais utilisé cette technique pour que le contenu soit lisible
pour tous. L'exemple n'était peut-être pas très heureux.

Ca dépend de ce qu'on veut. Les deux techniques peuvent être employées mais pas indifféremment. Elles sont toutes les deux utiles. Chacune des deux s'applique cependant à des besoins précis qu'il faut pouvoir déterminer...
- Si on veut masquer le contenu à tout le monde quelque soit le média de représentation de l'information (y compris les lecteurs d'écran), on joue avec display
- Si on veut masquer une information à tous les médias représentant le contenu de manière visuelle, mais qu'on veut le conserver pour tous les autres *, on joue avec les combines CSS pour expédier le contenu hors de la zone affichable, mais surtout pas display.

* quand je dis tous les autres, cela ne s'applique pas uniquement aux revues d'écran mais également aux afficheurs braille ou à tout autre moyen permettant de représenter de l'information sous forme non purement visuelle. Je n'en connais pas d'autre mais il en existe probablement (j'avoue mon ignorance à propos de problèmes méconnus et/ou autres handicaps physiques).

N.B. LE comportement de visibility est le même que display sur ce plan

a écrit :
Bons points... Je viens de réaliser que mes <h3>, puisqu'ils ne sont pas des liens, ne sont pas accessibles au clavier (ou alors j'ai pas trouvé comment)...
je vais regarder ça.

Oui, alors ça c'est en effet un problème un peu plus grave. Comme je l'ai dit, les outils comme jaws annoncent "cliquable" lorsqu'on passe sur le titre avec les flèches (curseur virtuel), mais il ne faut pas oublier que certains utilisent jaws et en plus naviguent avec la touche tab pour trouver les liens. Dans un cas extrême ils n'ont même voire pas le choix de naviguer autrement (quelqu'un a un exemple ? et les natel dans tout ça on en est où avec les natels, PDA et autres appareils mobiles ?)
Dans de tels cas, ils le louperaient, évidemment, et ça ce n'est pas acceptable, sauf si on est absolument certain de ce qu'on fait.
Modifié par QuentinC (09 Dec 2008 - 05:25)

a écrit :
Je viens de réaliser que mes <h3>, puisqu'ils ne sont pas des liens, ne sont pas accessibles au clavier (ou alors j'ai pas trouvé comment)...
je vais regarder ça.

La quasi-totalité des navigateurs permettent à n'importe quel élément de recevoir le focus lors de la tabulation si on utilise l'attribut tabindex. Pour éviter le principal souci lié aux tabindex (l'ordre de tabulation est perturbé), on peut utiliser un tabindex="0". Ce qui pourrait donner ici:

<h3 tabindex="0"> Mon titre </h3>

Le support par les navigateurs est plutôt bon. Le seul navigateur qui n'offre aucun support pour ce cas de figure est Safari, mais le bug est corrigé dans les dernières versions de Webkit, donc Safari 4 devrait corriger ça.

Quentin, si tu as le temps de jeter un oeil à cette page de test?
http://web.covertprestige.info/test/50-tabindex-0.html

Il y a un certain nombre d'éléments tels que des SPAN ou paragraphes censés pouvoir recevoir le focus. Seul l'attribut tabindex est utilisé, pas de onclick ou d'évènement en JavaScript.

Florent V. a écrit :
La quasi-totalité des navigateurs permettent à n'importe quel élément de recevoir le focus lors de la tabulation si on utilise l'attribut tabindex. Pour éviter le principal souci lié aux tabindex (l'ordre de tabulation est perturbé), on peut utiliser un tabindex="0". Ce qui pourrait donner ici:

<h3 tabindex="0"> Mon titre </h3>

Intéressant ça... Je vais pouvoir me passer de liens sur les h3 dans ma page de test... Je teste ça ce soir.

a écrit :
La quasi-totalité des navigateurs permettent à n'importe quel élément de recevoir le focus lors de la tabulation si on utilise l'attribut tabindex.
Pour éviter le principal souci lié aux tabindex (l'ordre de tabulation est perturbé), on peut utiliser un tabindex="0".

En parcourant ta page de test avec tab, j'obtiens successivement :

a écrit :

Un lien sans destination
élément span
un paragraphe qui devrait pouvoir recevoir le focus
un paragraphe qui devrait pouvoir recevoir le focus, et dedans un élément span qui devrait pouvoir recevoir le focus aussi
élément span

Ca a donc l'air de plutôt bien marcher. Test effectué avec ma vieille machine JFW7.10 + IE6 et Fx2, ça doit sûrement aussi marcher avec JFW9.0 + IE7 et FX3

Là je dis gg pour avoir déniché cette astuce. A garder sous le coude au cas où, ça pourrait être utile parfois.
Le gros problème des tabindex ordinaires c'est que les éléments normalement focusables qui n'en ont pas ne le sont plus... là en mettant 0 ça semble en effet ne pas dérégler complètement le circuit du focus par défaut.
Faudrait que je refasse un test.
Modifié par QuentinC (10 Dec 2008 - 06:03)

Merci d'avoir testé.

(Faut que je me mette à Jaws, moi...)

QuentinC a écrit :
Le gros problème des tabindex ordinaires c'est que les éléments normalement focusables qui n'en ont pas ne le sont plus... là en mettant 0 ça semble en effet ne pas dérégler complètement le circuit du focus par défaut.

Il me semble que les tabindex positifs arrivent en premier dans l'ordre de tabulation, puis tous les éléments focusables sans tabindex sont listés. Donc les éléments sans tabindex positif ne sont pas hors-circuit, ils viennent juste à la fin. Le comportement que tu décris n'est pas normal et s'il est confirmé c'est un bug.

Pour information, l'utilisation de tabindex="0" est citée dans ARIA 1, une future recommandation de la Web Accessibility Initiative, qui est présentée dans l'article suivant (traduction française): Introduction à WAI ARIA (traduction)

a écrit :

Il me semble que les tabindex positifs arrivent en premier dans l'ordre de tabulation, puis tous les éléments focusables sans tabindex sont listés. Donc
les éléments sans tabindex positif ne sont pas hors-circuit, ils viennent juste à la fin. Le comportement que tu décris n'est pas normal et s'il est confirmé
c'est un bug.

Oui, ça c'est de la théorie. J'ai pourtant bien l'impression que c'est ce qui arrive avec IE... j'ai jamais essayé avec firefox. Il faudrait que je refasse un test.
Modifié par QuentinC (10 Dec 2008 - 06:04)

Florent V. a écrit :

Il me semble que les tabindex positifs arrivent en premier dans l'ordre de tabulation, puis tous les éléments focusables sans tabindex sont listés. Donc les éléments sans tabindex positif ne sont pas hors-circuit, ils viennent juste à la fin. Le comportement que tu décris n'est pas normal et s'il est confirmé c'est un bug.

Hello,

Je viens d'implémenter cette solution sur mon site. Avec des couleurs pour voir le focus et l'activation (je les enlèverai hein) (firefox ne marque pas le focus, du coup on ne voit pas quel élément l'a, c'est chiant).

Ca fonctionne nickel. Mes liens du menu et tout ce qui est au-dessus de mes <h3> prennent le focus avant eux. Donc avec tabindex=0, le flux du document est respecté...

Bon par contre je n'arrive pas à les activer vu que mon script réagit à l'événement click. Je vais essayer d'implémenter la même chose sur l'événement keyup quand j'aurais vraiment compris la syntaxe de JQuery qui est parfois un peu obscure (comment on crée et utilise une fonction maison ? mais c'est HS ici )

Merci beaucoup à tous les deux, j'apprends beaucoup, là, rien qu'avec ma petite question. Comme quoi l'accessibilité, c'est pas toujours aussi évident que ça en à l'air


EDIT : ah par contre du coup la page n'est plus valide xHTML 1.0 Strict...

a écrit :
"there is no attribute "tabindex"

C'est balot !
Modifié par mistike (10 Dec 2008 - 09:56)

mistike a écrit :
EDIT : ah par contre du coup la page n'est plus valide xHTML 1.0 Strict... "there is no attribute "tabindex"

Ah oui, j'avais pas noté, effectivement l'attribut tabindex n'est utilisable qu'avec les éléments suivants en HTML (si on suit la spécification):
A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA

En HTML 5, par contre, ce sera un attribut global, utilisable sur tout élément. Liste (temporaire car c'est un brouillon) des attributs globaux prévus:
class, contenteditable, contextmenu, dir, draggable, id, hidden, lang, style, tabindex, title

Si un projet utilise tabindex="0" sur des éléments pour lesquels ce n'est pas valide en HTML 4, ça fait partie des informations à documenter (de même que toute invalidité volontaire).

QuentinC a écrit :
P.S. Pardonnez-moi pour les fautes mais je viens de constater avec désarroi que le champ de réponse ne fonctionne plus avec IE6 + jaws 7.10 sur ma vieille machine. Quelque chose a été modifié récemment sur le forum ?

normalement il n'y a pas eu de modification à ce niveau.

a écrit :
normalement il n'y a pas eu de modification à ce niveau.

Curieux, j'ai noté deux choses dernièrement :
1 - Ce que j'entends quand je suis dans le champ de réponse ne me permet plus de saisir du texte correctement. J'entends des bribes mais rien de plus, et j'entends surtout plus rien du tout quand je déplace le curseur.
2 - Je suis obligé d'activer l'option « layout table » pour avoir accès aux tableaux, autrement ignorés automatiquement. Je tiens à avoir des tableaux pour la liste des forums et des sujets, ça améliore grandement la navigation. (Je suis sûr que plus d'un sera dubitatif par cette affirmation, et pourtant... aussi curieux que cela puisse paraître à certains, les tableaux bien utilisés sont extrêmement pratiques)

Quand je dis dernièrement, ça doit faire en gros une semaine. Rien n'a changé sur mon portable équipé de jaws 9.0 + IE7.

Pour éditer ce message j'ai eu recours à une fenêtre du notepad temporaire.
Modifié par QuentinC (11 Dec 2008 - 04:55)

mistike a écrit :

Ca fonctionne nickel. Mes liens du menu et tout ce qui est au-dessus de mes <h3> prennent le focus avant eux. Donc avec tabindex=0, le flux du document est respecté...

Bon par contre je n'arrive pas à les activer vu que mon script réagit à l'événement click. Je vais essayer d'implémenter la même chose sur l'événement keyup

Coucou,

Bon voilà, j'ai implémenté le "clic" sur mes <h3> via l'événement "keypress" de JQuery, sur lequel je teste la touche enfoncée. Si c'est ENTREE ou ESPACE, je déclenche l'événement "click".

C'est magique, JQuery

J'en ai profité pour marquer le focus car sinon, sous FF on ne voyait pas qu'on l'avait.

Merci à tous !

Salut Quentin,

Si tu es toujours à l'écoute de ce fil, j'ai remanié le code de ma page test.

Le but est toujours d'avoir l'entièreté de la page visible même avec les éléments masqués pour les voyants. Ton problème était dans la version précédentes que les liens sur les h3 ne menaient nulle part. Cette fois, les liens ont comme comme référence le div suivant (masquable) avec l'ID qui va bien.

Est-ce que c'est bon pour toi?

Alors maintenant quand je clique sur un H3, le contenu correspondant est alternativement affiché et masqué. Petit bug pas trop grave, le premier clic ne fait rien.