Rendre un élément focus-able OU insérer un input ?

Bonjour,

Mon problème est visible par exemple ici : http://chasseautresor-ng.0707a.net/jol_stock/Chasse_96.html

Dans la version actuelle, toutes les cases des grilles sont des

<td><input type="text" oninput="f()"></td>

Bon... à l'usage... les utilisateurs aimeraient plus de facilités d'édition... soit!
Je vais écrire du javascript supplémentaire.

Maintenant, tant que j'y suis, je me demandais si, sur le plan général de l'accessibilité, propreté du code html, simplicité du code css... je n'aurais pas avantage à simplifier le code html en virant l'input, soit, dans le principe

<td onclick="oc()" onkeypressed="kp()"></td>

Bon, je crois comprendre qu'en fonction des navigateurs, tous les éléments ne sont pas nécessairement focus-able.
Mais je crois qu'il m'est possible de les rendre focus-able en affectant un role et un tabindex à chaque td, soit

<td role="button" tabindex="x" onclick="oc()" onkeypressed="kp"></td>

Avec X=une valeur numérique adaptée bien sûr.

Qu'en pensez-vous ?
Modifié par aCOSwt (08 Jul 2014 - 12:28)

Bonsoir,

Pour donner un avis vraiment pertinent jusqu'au bout, il faudrait que tu mettes en lignes plusieurs versions différentes de la page. Sans démonstration testable, c'est très difficile de dire si tel ou tel balisage sera mieux ou moins bien pour un lecteur d'écran ou une autre aide technique par exemple.

Par rapport à ce que tu dis, c'est globalement juste mais quelques précisions manquent :

Effectivement, les cellules de tableau <td> ne sont par défaut pas focusables et ajouter un tabindex permet de les rendre focusable. En revanche, sauf cas exceptionnels, la valeur d'un tabindex doit toujours être soit 0 ou soit -1 si elle est indiquée; 0 indique que l'élément est focusable, et -1 qu'il ne l'est pas. Si tu mets une autre valeur que 0 ou -1, tu risques de perturber totalement la navigation au clavier et c'est bien la pire chose que tu puisses faire pour l'accessibilité.

Tu as aussi raison sur l'attribut role, mais attention: tu proposes button, alors que de toute évidence ce sont et ça va rester des zones destinées à recevoir du texte entré par l'utilisateur, que tu choisisses d'utiliser <input> ou non. En conséquence la seule valeur justifiable est très logiquement textbox.

Maintenant, après avoir exposé les réponses techniquement et politiquement correctes, voici mon avis personnel :

ARIA c'est très bien, mais si tu arrives à faire quelque chose qui est accessible sans en utiliser, c'est encore mieux. ARIA est un outil extrêmement puissant, mais sa très grande puissance fait aussi que ce soit très facile de faire des erreurs qui peuvent te coûter cher sur l'accessibilité perçue au final. A redéfinir des éléments non standards, tu vas notamment être obligé de simuler en javascript les comportements clavier/souris qui sont normalement implicitement gérés par le navigateur si tu avais utilisé un élément standard. Et faire des scripts qui se comportent de manière correcte au clavier, c'est très difficile. Jusqu'à maintenant, pour te dire franchement, je peux compter le nombre de sites qui l'ont vraiment fait correctement jusqu' au bout sur les doigts d'une seule main (dont mon propre jeu même s'il est graphiquement moche; mais j'assume)

Donc si tu peux garder tes <input>, je pense que ce serait mieux pour tout le monde.

En terme d'accessibilité pure, pour moi qui suis un utilisateur de lecteur d'écran, il y a deux choses que tu peux faire pour faire mieux :
1. Ajouter des en-têtes de ligne et de colonnes <th> avec des coordonnées: 1, 2, 3, ... A, B, C, ... par exemple. Pour le moment les validateurs d'accessibilité devraient tiquer, car les cellules d'en-tête sont un prérequis pour tout tableau qui n'est pas purement présentationel, et ici on a bien un tableau de données/fonctionnel (donc ne supprime surtout pas ton tableau, il est très important et utile)
2. N'étant pas en mesure de fournir un <label> pour chaque <input>, ce qui est normalement la règle, ce serait bien de mettre un attribut title à chacun des <input>. Les informations les plus utiles que tu puisses fournir seront sans doute les coordonnées de la case ainsi que les indices auxquels la case se rapporte; ça dépend du jeu. En tout cas, le <label> est une obligation et si elle ne peut pas être remplie, l'attribut title s'y substitue. Au cas où tu optes pour de l'ARIA au lieu des input, les attributs aria-label/aria-labelledby remplissent ce même rôle.
3. J'ai bien l'impression que c'est un genre de mot croisé. Y a-t-il des cases noires ? Si oui, je ne suis pas en mesure de les percevoir avec mon lecteur d'écran. IL faut trouver une solution. Une idée pourrait être de mettre l'input en readonly, et d'indiquer « case noire » dans le title. IL faut que la case reste focusable car sinon, la navigation n'est plus régulière dans la grille et on peut simplement rater l'information sans comprendre leur emplacement.

Par contre, j'ai encore des suggestions de l'ordre de la facilité d'utilisation à faire. A mon avis, tu gagnerais
beaucoup à les implémenter :
1. Pouvoir naviguer dans la grille avec les touches fléchées
2. La saisie d'une lettre fait passer automatiquement à la case suivante; la case suivante est à déterminer adéquatement en fonction de la logique du jeu (donc ça peut être horizontal, vertical, en diagonale, ou n'importe quoi d'autre tant que la séquence de cases parcourues fait sens)
3. Similairement au point 2, backspace efface la lettre puis place automatiquement sur la case précédente
4. Toujours selon la même logique, DEL efface la lettre dans la case en cours et reste dans cette case
5. Quand on appuie sur une lettre, si la case est déjà remplie, remplacer puis passer à la case suivante au lieu de ne rien faire
6. J'avoue ne pas avoir testé, mais quand on remplit les cases à côté des indices, le report est-il automatique dans la grille ? et est-ce que ceci fonctionne pareillement dans les deux sens ?


Je crois que cette fois c'est tout, j'espère que ce post sera utile. Merci de m'avoir lu jusqu'au bout.

Quoi qu'il en soit, ça fait plaisir de voir des jeux en HTML5 qui sont déjà pas si mal au niveau accessibilité. Ca change de ce satané flash.
Modifié par QuentinC (08 Jul 2014 - 18:04)

Bonsoir QuentinC et d'abord merci pour ta réponse... criconstanciée.

QuentinC a écrit :
sauf cas exceptionnels, la valeur d'un tabindex doit toujours être soit 0 ou soit -1 si elle est indiquée; ... Si tu mets une autre valeur que 0 ou -1, tu risques de perturber totalement la navigation au clavier et c'est bien la pire chose que tu puisses faire pour l'accessibilité.

eeeek! ça... je l'avais bien zappé! Merci

QuentinC a écrit :
Tu as aussi raison sur l'attribut role, mais attention: tu proposes button, alors que de toute évidence ce sont et ça va rester des zones destinées à recevoir du texte entré par l'utilisateur, que tu choisisses d'utiliser &lt;input&gt; ou non. En conséquence la seule valeur justifiable est très logiquement textbox.

Bon... je n'ai pas bien vu de différence au niveau fonctionnel mais du toutes façons, tu as raison, c'est plus pertinent et plus cohérent de toutes façons.

QuentinC a écrit :

A redéfinir des éléments non standards, tu vas notamment être obligé de simuler en javascript les comportements clavier/souris qui sont normalement implicitement gérés par le navigateur si tu avais utilisé un élément standard.

Tu as bougrement raison. J'ai connu cela il y a 30 ans avec ma première interface semi-graphique sous Unix avec la bibliothèque curses...
Si tu veux faire quelque chose de propre, il faut gérer le curseur. Et dès que tu gères le curseur il faut... tout écrire !

QuentinC a écrit :
...dont mon propre jeu...

Un lien ?

QuentinC a écrit :
Donc si tu peux garder tes &lt;input&gt;, je pense que ce serait mieux pour tout le monde.

Je le crois aussi, il y a juste un truc qui m'ennuie dans ce cas et c'est justement... la gestion du curseur.
Car en fait dans la zone de texte de 1 caractère, il y a formellement deux positions de curseur possibles en fonction de là où on clique. Avant le caractère ou après le caractère.
Et, qui plus est, le curseur avant le caractère n'est évidemment pas le curseur après le caractère de la zone de texte précédente, ce qui, dans une perspective d'édition globale d'une ligne de la grille n'est pas... tip top.

QuentinC a écrit :
moi qui suis un utilisateur de lecteur d'écran

Tu veux dire des trucs genre espeak, festival... ?
Cela m'intéresse diablement car... tu as vu le genre de jeux... cela te donne une idée de la moyenne d'âge de nos visiteurs et contributeurs... et donc... de leurs capacités visuelles.
Je suis par ailleurs après travailler à un format A3 de la version imprimable...

QuentinC a écrit :
3. J'ai bien l'impression que c'est un genre de mot croisé. Y a-t-il des cases noires ? Si oui, je ne suis pas en mesure de les percevoir avec mon lecteur d'écran.

Yop! Ce n'est pas vraiment un mot-croisé car il n'y a pas de notion de verticale mais oui, il y a des cases noires qui, pour l'heure, sont des

<td>&nbsp;<td>

avec un background-color gris foncé. Relativement à la grille de texte (celle de droite) c'est d'ailleur effectivement cela que c'est : Une espace.

QuentinC a écrit :
IL faut trouver une solution. Une idée pourrait être de mettre l'input en readonly, et d'indiquer « case noire » dans le title. IL faut que la case reste focusable car sinon, la navigation n'est plus régulière dans la grille et on peut simplement rater l'information sans comprendre leur emplacement.

Ha bhé... ça par contre... je n'avais pas prévu de les rendre focusables.
Veux-tu dire que si les cases noires ne sont pas focusables et que, par exemple, je passe de case en case sur la grille de texte au moyen de la flêche droite, un truc style "O[CaseNoire]RAGE" serait épelé O R A G E et non O espace R A G E ?
Si c'est ce genre de truc auquel tu penses alors... oui! Tu as définitivement raison. C'est très dommageable.
Il faut effectivement que je trouve une solution à cela.

QuentinC a écrit :
1. Pouvoir naviguer dans la grille avec les touches fléchées

Yop! C'est dans le pipe.

QuentinC a écrit :
2. La saisie d'une lettre fait passer automatiquement à la case suivante;

Yop! C'est dans le pipe.

QuentinC a écrit :
3. Similairement au point 2, backspace efface la lettre puis place automatiquement sur la case précédente

Yop! C'est dans le pipe.

QuentinC a écrit :
4. Toujours selon la même logique, DEL efface la lettre dans la case en cours et reste dans cette case

Ah ! ça... ce n'était pas prévu... mais... c'est pas con!

QuentinC a écrit :
6. J'avoue ne pas avoir testé, mais quand on remplit les cases à côté des indices, le report est-il automatique dans la grille ? et est-ce que ceci fonctionne pareillement dans les deux sens ?

Oui, le report est automatique dans les deux sens.
C'est d'ailleurs l'avantage principal de la version en ligne par rapport à la version papier.

QuentinC a écrit :
j'espère que ce post sera utile. Merci de m'avoir lu jusqu'au bout.

Tu parles! C'est moi qui dit merci oui! Et deux fois!
Penses STP à me communiquer un lien vers ton site de jeu... je sens que je peux encore apprendre encore beaucoup plus.

aCOSwt a écrit :

eeeek! ça... je l'avais bien zappé! Merci

C'est quelque chose qui est vite oublié et qui a rapidement des conséquences désastreuses, car en règle générale dès le moment où il y a un élément doté d'un tabindex positif, il passe en tête de l'ordre de tabulation (on passe d'abord par tous les éléments avec tabindex, puis ensuite tous les éléments sans tabindex). Par conséquent, si on veut mettre des tabindex positifs, on doit le faire sur tous les éléments focusables de la page, même ceux qui le sont par défaut; et évidemment gérer avec exactitude l'ordre du début à la fin sans rien oublier est juste impossible.

a écrit :
Bon... je n'ai pas bien vu de différence au niveau fonctionnel mais du toutes façons, tu as raison, c'est plus pertinent et plus cohérent de toutes façons.

C'est normal que tu ne perçoives pas de différence fonctionnelle, ni même de différence visuelle. ARIA est destiné uniquement aux aides techniques. C'est pour cette raison qu'il est souvent utilisé à mauvais escient d'ailleurs, car il n'apporte rien ni fonctionnellement ni visuellement, et on ne peut constater les problèmes seulement qu'en testant avec les mêmes outils que ceux que nous utilisons tous les jours.

Indiquer le bon rôle est absolument crucial, car si j'arrive sur un élément, que mon lecteur d'écran me dit que c'est un bouton alors que c'est en fait une zone de texte, je vais avoir du mal à comprendre ce qu'il fait réellement, , ou comment interréagir avec.

aCOSwt a écrit :

Tu as bougrement raison. J'ai connu cela il y a 30 ans avec ma première interface semi-graphique sous Unix avec la bibliothèque curses...
Si tu veux faire quelque chose de propre, il faut gérer le curseur. Et dès que tu gères le curseur il faut... tout écrire !

ON peut tout de même y voir une certaine parenté. Ncurse, c'est un peu le CSS de la ligne de commande, quelque part; mais il n'y a pas d'ARIA, pas de moyen d'indiquer la nature de ce sur quoi on se trouve. Du coup ça peut aussi être un problème. On finit par comprendre les cases à cocher, les pseudo-bordures et autres combines ASCII art, mais ça ne suit aucune logique.

En HTML5 si tu n'utilises pas ARIA, ça peut être un peu pareil: si tu me focus sur une combobox bricolée en js, mais que tu ne me dis pas que c'est une combobox, ou si tu ne gères pas le clavier de la façon à laquelle je m'attends, je n'arrive pas à utiliser ton interface.

Sauf qu'on a à disposition un certain nombre de composants standards qui font en principe leur boulot correctement (s'ils ne le font pas, ce n'est plus du ressort du navigateur mais de l'OS), qui ne nécéssitent pas de recourrir à ARIA, et qui devraient être utilisés tant que faire se peut; pas seulement pour l'accessibilité, mais aussi parce que c'est beaucoup plus simple à programmer.

aCOSwt a écrit :

Je le crois aussi, il y a juste un truc qui m'ennuie dans ce cas et c'est justement... la gestion du curseur.
Car en fait dans la zone de texte de 1 caractère, il y a formellement deux positions de curseur possibles en fonction de là où on clique. Avant le caractère ou après le caractère.
Et, qui plus est, le curseur avant le caractère n'est évidemment pas le curseur après le caractère de la zone de texte précédente, ce qui, dans une perspective d'édition globale d'une ligne de la grille n'est pas... tip top.

Très juste. C'est vrai que, pour ce cas précis, c'est assez discutable. ON est peut-être à la limite où il n'est pas facile de trancher pour savoir lequel est le plus simple entre modifier un peu le comportement d'un composant standard, ou faire son propre composant custom.

Pour le coup, j'ai une idée très simple: on pourrait systématiquement sélectionner l'ensemble de la zone à chaque fois qu'elle prend le focus (c'est un comportement courant), et aussi après chaque appui sur une lettre. A partir de là, tu as déjà beaucoup moins à coder manuellement pour gérer DEL, backspace, et le remplacement d'une lettre par une autre.

aCOSwt a écrit :

Tu veux dire des trucs genre espeak, festival... ?
Cela m'intéresse diablement car... tu as vu le genre de jeux... cela te donne une idée de la moyenne d'âge de nos visiteurs et contributeurs... et donc... de leurs capacités visuelles.
Je suis par ailleurs après travailler à un format A3 de la version imprimable...

Espeak et les autres que tu cites sont des synthèses vocales. ON fait souvent la confusion avec les lecteurs d'écran car ceux-ci utilisent quasiment toujours ceux-là en tant que sortie. Mais un lecteur d'écran peut aussi envoyer, en plus ou à la place de la voix, sa sortie en braille.

Puisque tu es visiblement sous linux, le lecteur d'écran de linux sur le bureau GNOME s'appelle Orca. Je ne le connais que très très mal, mais de ce que j'ai déjà pu tester, il est plutôt nul en face d'un jaws ou d'un NVDA sous windows, ou d'un Voice Over sous mac/iOS.

aCOSwt a écrit :

Yop! Ce n'est pas vraiment un mot-croisé car il n'y a pas de notion de verticale mais oui, il y a des cases noires qui, pour l'heure, sont des

<td> <td>

avec un background-color gris foncé. Relativement à la grille de texte (celle de droite) c'est d'ailleur effectivement cela que c'est : Une espace.

Ha bhé... ça par contre... je n'avais pas prévu de les rendre focusables.
Veux-tu dire que si les cases noires ne sont pas focusables et que, par exemple, je passe de case en case sur la grille de texte au moyen de la flêche droite, un truc style &quot;O[CaseNoire]RAGE&quot; serait épelé O R A G E et non O espace R A G E ?
Si c'est ce genre de truc auquel tu penses alors... oui! Tu as définitivement raison. C'est très dommageable.
Il faut effectivement que je trouve une solution à cela.

Oui. ET en plus si quand on navigue au clavier, on passe tout à coup de C4 à C6 car C5 est une case noire, ce n'est pas sûr que tout le monde tiltt sur ce fait, et ça peut perturber si on navigue dans un premier temps en reconnaissance pour se faire une idée générale de la grille. Ca peut faire bizarre de ne pas avoir le même nombre de flèche droite/gauche à faire pour atteindre les bords latéraux d'une ligne sur l'autre.

a écrit :
Penses STP à me communiquer un lien vers ton site de jeu... je sens que je peux encore apprendre encore beaucoup plus.

Mais avec plaisir ! Par contre, il faut quand même que je te prévienne de certaines choses avant de cliquer :
1 - Ce n'est pas vraiment dans le même genre, il s'agit de jeux de société classiques. Mais c'est aussi très intergénérationnel (je connais quelques personnes de 70 ans et plus qui jouent)
2 - C'est expressément optimisé pour les non-voyants au lecteur d'écran avant tout: que du texte, 0 images, design moche et ultra-minimaliste, CSS buggés. D'ailleurs s'il y a des experts CSS et responsive design dans la place, je prends volontiers vos conseils. J'essaie de m'améliorer dans la mesure du possible mais évidemment, faire du CSS quand on ne voit pas, c'est bien beau mais on ne peut pas savoir si ça marche ou pas.
3 - La partie la plus intéressante n'est bien sûr visible que sous login

Cela étant dit, voilà le lien: http://qcsalon.net/
Enjoy le bordel visuel.

QuentinC a écrit :
JE viens de tester rapidement. Ca ne marche plus sur mon navigateur par défaut IE9, je ne peux rien écrire dans les zones.

Diable! Je viens de regarder sur un vieil IE8... Et... c'est vrai que cela ne fonctionne pas du tout.
En fait le focus ne "tient" pas.
Je crois avoir trouvé un workaround sur internet que je vais demander à valider dans un autre sub-forum car je ne le trouve pas bien beau... (à base de setTimeout)

QuentinC a écrit :
Flèche gauche et droite fonctionnent, mais pas haut et bas.

Oui, haut bas ne sont pas actives sur la grille de texte car la verticalité n'a pas vraiment de sens.
Haut et bas sont actives dans la grille des mots à découvrir car là, une colonne possède un sens en vertical.

QuentinC a écrit :
Les zones d'édition ne sont pas labélisés, ce qui fait qu'absolument rien n'est prononcé en arrivant sur une case vide, et même quand il y a quelque chose je ne peux pas savoir où je me trouve dans la grille. IL faut absolument que tu mettes des labels avec aria-label ou aria-labelledby, et un moyen de se repérer dans la grille comme des coordonnés.

Yop. Ca c'est dans mes cartons mais je cherche un label vraiment parlant.
Car la notion de coordonnées n'a pas vraiment de sens. En fait, je crois qu'il serait plus utile que, dans la grille des mots à découvrir, le système puisse prononcer l'indice puis la position du caractère dans le mot à découvrir correspondant.
Donc... j'ai pas oublié... mais... je cherche le label had-hoc.

QuentinC a écrit :
-Jaws voit bien un tableau, mais on ne peut plus naviguer dedans avec le curseur virtuel avec les touches Ctrl+Alt+Flèches; il doit y avoir une erreur de balisage ou des tableaux imbriqués qui perturbent jaws; ça fonctionnait dans la version avec &lt;input&gt;.
- Quand je vais sur la page, je suis prisonnier, je ne peux plus la quitter. Alt+D pour rejoindre la barre d'adresse ne fonctionne plus; Alt+F4 pour quitter firefox non plus; J'ai essayé Ctrl+F4 et Ctrl+W pour fermer l'onglet et là encore ça ne fonctionne pas non plus; bref, j'ai dû kill firefox.exe pour m'en débarrasser. IL doit y avoir un gros problème dans ta gestion des évènements clavier.

Arrggghhh !!! Je crains que LE gros problème provienne en fait... de la façon dont j'ai cherché à éteindre le comportement de firefox qui, en fonction de certaines options utilisateur affiche immédiatement une quick search box en bas de la fenêtre dès que l'utilisateur tape un caractère.
J'ai donc... banalement et... très innocemment... balancé un preventDefault sur l'événement keydown.
Je crois donc que c'est cela et je ne m'imaginais pas les conséquences... manifestement... désastreuses.... Gee... va falloir que je trouve autre chose... but what ?

QuentinC a écrit :
D'après ce que je sais, il y a très peu de non-voyants qui ont une utilisation quotidienne des bureaux linux.

Allez... on va y croire quand même...
Le développeur de Gentoo qui maintient un des programmes les plus importants est aveugle.
Je ne le savais pas et ai un jour débuggé un truc avec lui. Et bien je ne me suis pas rendu compte de son handicap.
Donc soit il a mis un point un chaîne vraiment efficace, soit il fait beaucoup d'efforts.
Nota : J'ai su depuis qu'il faisait beaucoup d'efforts...

Merci encore. Je vais revoir tous ces trucs.
Modifié par aCOSwt (13 Jul 2014 - 01:22)

aCOSwt a écrit :

Oui, haut bas ne sont pas actives sur la grille de texte car la verticalité n'a pas vraiment de sens.
Haut et bas sont actives dans la grille des mots à découvrir car là, une colonne possède un sens en vertical.

Ah, d'accord. Au temps pour moi, je pensais que la verticalité était aussi importante.

aCOSwt a écrit :

Yop. Ca c'est dans mes cartons mais je cherche un label vraiment parlant.
Car la notion de coordonnées n'a pas vraiment de sens. En fait, je crois qu'il serait plus utile que, dans la grille des mots à découvrir, le système puisse prononcer l'indice puis la position du caractère dans le mot à découvrir correspondant.
Donc... j'ai pas oublié... mais... je cherche le label hadhoc.

Indiquer l'indice dans le label est clairement la bonne idée. Après pour la position, ça dépend; si la verticalité n'a pas vraiment de sens, c'est vrai que les coordonnées sont moins utiles. Du coup on pourrait imaginer des labels du genre "Raphaël en manche tous les matins; 3 sur 5" quand on se trouve sur le 3ème caractère du mot de 5 lettres.

aCOSwt a écrit :

Arrggghhh !!! Je crains que LE gros problème provienne en fait... de la façon dont j'ai cherché à éteindre le comportement de firefox qui, en fonction de certaines options utilisateur affiche immédiatement une quick search box en bas de la fenêtre dès que l'utilisateur tape un caractère.
J'ai donc... banalement et... très innocemment... balancé un preventDefault sur l'événement keydown.
Je crois donc que c'est cela et je ne m'imaginais pas les conséquences... manifestement... désastreuses.... Gee... va falloir que je trouve autre chose... but what ?

Il se pourrait bien que ça soit ça, en effet. A mon avis pour régler ce problème, il faut simplement ne pas être aussi extrêmiste, et n'inhiber que ce qui est vraiment nécessaire. PreventDefault c'est bien mais ça peut aussi être rapidement dangereux s'il est mal utilisé.

A moins de bien savoir ce qu'on fait, il faut vraiment éviter d'intervenir sur le comportement par défaut du clavier dès lors qu'au moins une des touches Alt, ou Win est enfoncée.

ON peut utiliser Ctrl et l'équivalent sous mac pour des raccourcis spécifiques, c'est très très utile, mais à condition de le faire correctement et de ne pas interférer sur des fonctions vitales comme fermer un onglet (donc pas de Ctrl+F4 ou de Ctrl+W).

Par exemple, j'ai souvent ce genre de code chez moi :

function someKeyDown (e) {
e = e || window.event;
var k = e.which || e.keyCode;
if (k==vk.tab || k==vk.enter || k==vk.f5 || k==vk.f12 || k==vk.context || e.altKey) return true;
//suite
}

J'inclus F5 pour refresh et F12 pour outils développement IE dans dans ma liste de touches à ne pas bidouiller, sinon je me fais auto-owned. Pour le reste, tab, enter et la touche menu contextuel (à gauche de Ctrl droite) c'est absolument indispensable de ne pas y toucher.

a écrit :
Allez... on va y croire quand même...
Le développeur de Gentoo qui maintient un des programmes les plus importants est aveugle.
Je ne le savais pas et ai un jour débuggé un truc avec lui. Et bien je ne me suis pas rendu compte de son handicap.
Donc soit il a mis un point un chaîne vraiment efficace, soit il fait beaucoup d'efforts.
Nota : J'ai su depuis qu'il faisait beaucoup d'efforts...

J'ai pas dit qu'il n'y en avait pas, seulement qu'il n'y en a très peu par rapport à la masse d'utilisateurs sous windows et mac.

En fait, linux en ligne de commande sans interface graphique, armé d'un afficheur braille, ça fait plus de 10 ans, peut-être même 15, que c'est parfaitement accessible; et ce grâce au projet BRLTTY.

Allez, tant que j'y suis à abuser de la disponibilité de QuentinC...

Donc, dans mes TD qui contiennent des lettres.
Je vais donc me débrouiller pour que le lecteur d'écran ET annonce l'indice ET annonce la position du caractère dans le mot ET la lettre si il y en a une.

Maintenant... J'ai une assistance validation qui est proposée en option.
Lorsque l'utilisateur l'active, tout caractère déjà entré dans les grilles et erroné sera affiché en rouge et tout caractère qui viendrait à être entré de façon non appropriée sera affiché en rouge.
Tout ce qui est bon restant en bleu.

As-tu une idée pour, en plus de toutes les informations déjà données, faire dire au lecteur d'écran si cépabon ? Trafiquer les aria-labels par javascript ?

aCOSwt a écrit :
Allez, tant que j'y suis à abuser de la disponibilité de QuentinC...

Pas de problème, je suis en vacances pour le moment.

aCOSwt a écrit :

As-tu une idée pour, en plus de toutes les informations déjà données, faire dire au lecteur d'écran si cépabon ? Trafiquer les aria-labels par javascript ?

AVant de trafiquer les labels avec js, essaie d'abord aria-invalid; je ne sais pas si ça fonctionne sur les contrôles custom mais ça vaut la peine d'essayer.