Accesskey à une touche avec JavaScript : acceptable ?

Bonsoir par ici, bonsoir par là,

Ça fait longtemps que j’y penses, mais c’est la première fois que je pose la question. Je trouve que les accesskey portent mal leur nom, parce qu’elles ne sont pas très accessibles (excepté sous Konqueror). Je me demandais si c’est une pratique déjà existante ou acceptable, d’utiliser JavaScript pour qu’une page réponde aux accesskey en utilisant seulement la touche d’accès toute seule.

Par exemple si une accesskey est A, alors au lieu de faire Shit+Alt+A (Chrome et Firefox), un simple appui sur A suffirait, ou éventuellement comme sous Konqueror, Ctrl puis A (successivement, pas simultanément), ce qui est déjà plus accessible.

Cela pourrait se faire sans interférence avec la méthode native du navigateur.

Ça se fait déjà ? Si ça ne se fait pas vraiment, cela pourrait-il être jugé acceptable ?

En marge et en rapport, je me demandais aussi, si depuis le temps un standard est apparu, concernant le comment faire afficher la liste des accesskey et leurs cibles.

-- Édit --

Une variante qui me trotte dans la tête depuis longtemps, est une touche qui ferait s’afficher un menu des accesskey en surimpression sur la page. Par exemple un appui sur Ctrl afficherait la liste, ensuite on peut naviguer dans la liste avec les touches curseurs du clavier, comme dans un SELECT, ou appuyer sur la touche correspondante, également indiquée dans la liste. Encore mieux, ce menu pourrait ne s’afficher qu’après un délais, pour ne pas qu’il s’affiche inopinément à chaque fois alors qu’un Ctrl puis lettre est sur le point d’être entrée directement.

J’attends d’avoir des avis, et ensuite je fais un test dans une page mentionnée dans un autre sujet.
Modifié par hibou57 (03 May 2015 - 02:04)

La touche Ctrl, c’est une mauvaise idée, parce que je viens d’apprendre qu’elle est utilisée dans les lecteurs d’écran pour arrêter la lecture. Elle est même surnommée la touche «Ta gueule», c’est vrai ça ? La touche restante, Alt, ne peut pas convenir, parce qu’un appui sur Alt ouvre généralement la barre de menu.
Modifié par hibou57 (03 May 2015 - 11:26)

Salut,

Pour les accesskey à l'ancienne avec Alt+lettre, tu as sûrement dû voir passer le fameux article d'alsa qui en parlait, avec le titre approximatif « accesskey, le grand échec de la'ccessibilité ». Tu as tout à fait raison, ces raccourcis ne sont ni pratiques ni réellement utilisés.

L'idée des raccourcis à une touche n'est pas nouvelle. Twitter le fait déjà depuis un bon moment avec par exemple K et L pour passer au twitt précédent/suivant, R pour retwitt, etc. D'autres réseaux sociaux ont plus ou moins copié.

Ca peut être à la fois excellent ou totalement inutile et inefficace, tout dépend comment tu vois les choses.

C'est très bien pour ceux qui n'utilisent pas de lecteur d'écran et qui ne veulent/peuvent pas utiliser la souris. Tout simplement, ça fonctionne.

Maintenant, il faut se souvenir que, dans le cas des lecteurs d'écran, la plupart des touches normales sont utilisées pour d'autres fonctions dans le cadre de ce qu'on appelle la navigation en curseur virtuel, le mode document, ou parfois la navigation rapide. Par exemple la touche H permet de passer au titre suivant, et F pour aller au champ de formulaire suivant.

En règle générale, le lecteur d'écran absorbe les touches et javascript ne voit alors absolument pas passer les appuis (même pas de keydown ou de keypress déclenché), mais il peut aussi parfois arriver que et l'action du lecteur d'écran et l'action prévue par le concepteur web se déclenchent simultanément; inutile de dire que c'est particulièrement perturbant et rapidement énervant. Donc dans ce cas ça ne fonctionne pas et c'est même à éviter.

IL existe un moyen de faire en sorte que ces touches prennent le dessus et que les fonctions de navigation du lecteur d'écran soient complètement inhibées, c'est ce qu'on appelle le mode application. Avec ARIA tu peux forcer le navigateur et le lecteur d'écran à passer dans ce mode au lieu du mode document qui est par défaut. Mais, étant donné que tu supprimes totalement les fonctionnalités du lecteur d'écran dans ce cas, tu as intérêt à t'assurer que ton application soit d'une accessibilité irréprochable, et que les fonctions de navigation de base du lecteur d'écran n'aient pas d'utilité. Le moindre bug ou incohérence dans ta gestion du clavier et du focus peut rendre ton application complètement inutilisable.

Beaucoup trop de sites forcent ce mode application sans avoir compris tout ce que ça implique. A mon grand désarroi, il est mal utilisé 99.9% du temps, simplement parce que ceux qui l'ont activé n'en ont pas mesuré les conséquences, ou ne savnt même pas de quoi ils parlent. Selon moi, très peu de sites ont réussi à faire quelque chose de bien avec ce mode. Outre mon propre site de jeux spécialement adapté, je ne peux guère que te citer le nouveau Google Docs de fin 2014 (ce n'est pas pour caresser Google dans le sens du poil, leur solution est critiquable pour plein d'autres raisons, mais il faut quand même avouer qu'ils ont fait fort)

Si tu veux en savoir plus sur le mode application, j'ai écrit un article à ce sujet sur mon site web personnel: http://quentinc.net/aria-role-application

Pour en revenir aux raccourcis clavier dont il était question au début de ton message, soit tu le fais en étant conscient que pour un lecteur d'écran ça ne sert strictement à rien voire rentre parfois en conflit, soit tu passes en mode application et alors là tu feras très probablement de la guigne, à moins d'être vraiment très bon et de tester intensivement ce que ça donne avec un lecteur d'écran; chose que (quasiment) personne ne fait de toute façon, ou en tout cas de loin pas assez ou pas avec suffisament de sérieux.

Quant à Ctrl spécifiquement, effectivement, elle permet de faire taire la synthèse vocale. Par contre c'est bien la première fois que je trouve cette appellation « touche tagueule », même si il nous est tous téjà arrivé à nous autres d'appuyer frénétiquement dessus en insultant son ordinateur quand il ne veut pas se taire assez vite. Plus généralement, j'éviterais toutes les touches à bascule donc Shift, Alt, la touche windows, la touche option sur mac, et aussi insert parce qu'insert est utilisée comme touche à bascule pour accéder à certaines fonctions des lecteurs d'écran Jaws et NVDA.

En résumé, donc, soit ces touches que tu veux mettre en place font partie d'une expérience applicative poussée et tu travaille dur pour avoir une gestion clavier et focus absolument irréprochable, soit ça ne vaut pas la peine, ou du moins pas pour le public lecteur d'écran que tu croyais prioritairement viser. Ca peut malgré tout avoir une utilité pour les gens bien voyants qui sont empêchés d'utiliser un dispositif de pointage.

Voilà...

Re-Bonjour,

D’abord merci pour ton long message.

Je vais à nouveau oublier les accesskey, c’est encore trop imprévisible. Je m’y étais déjà intéressé il y a quelques années, je les avais abandonné à cette époque, pour la même raison, et je pensais que peut-être les choses avaient changé depuis, mais finalement non.

Pour ce qui est des applications web, je suis d’accord avec ce que tu en dis, que l’expression est utilisée abusivement. Cependant, je dois avouer que si je repasse sur Alsacréations, c’est parce que HTML5 s’installe et que HTML5 m’intéresse pour les interfaces utilisateurs. Mais je préfère parler d’interface utilisateur HTML, plutôt que de parler d’application web ; ça n’a pas la même signification.

Je me pose la question de l’accessibilité, pas seulement pour les lecteurs d’écran, que je ne connais pas, comme je n’en utilise pas ; je me pose ces questions en fait pour tout le monde en même temps. Je trouve que la souris n’est pas pratique en général, et que les raccourcis claviers classiques sont trop acrobatiques, à tel point que parfois ça peut abimer les mains et provoquer des inflammations.

D’après ce que tu dis, je crois comprendre que si je ne fait rien qui bloque les technologies d’assistance, alors ça ne devrait pas poser de problème. Si c’est bien le cas, alors c’est déjà bon à savoir, et par exemple je peux faire un menu déclenché par une touche, qui permet de se passer de la souris, sans que ça n’interfère avec les lecteurs d’écran, parce que c’est le lecteur d’écran qui décidera s’il intercepte la touche ou pas. Il suffit de faire comme s’il n’était pas là, ce qui équivaut à la laisser décider, c’est le plus simple.

Je crois que si je pouvais prendre connaissance de seulement un ou deux raccourcis standards pour par exemple afficher un menu contextuel, déplacer le focus de manière plus souple, comme par exemple le déplacer vers le haut, vers le bas, la droite, la gauche, ce serait déjà beaucoup.

Pour en revenir aux accesskey, après avoir ouvert ce sujet, entre temps j’ai vu une vidéo qui explique comment fonctionne un lecteur d’écran, et il disait que les niveaux de titre sont la première chose qui permet de naviguer facilement dans une page. Ça va dans la même sens que ce que tu dis, quand tu parle de la touche «H».

Ça tombe bien, parce que dans un autre sujet, quand je parlais d’abandonner les éléments DETAILS et SUMMARY, je pensais justement les remplacer par quelque chose qui ouvre et ferme les sections, sur la base de leur titre (je parle des heading en début de section).

Je vais essayer de faire ça, sans rien faire qui risquerait d’interférer avec les lecteurs d’écran.

Il faudrait que je trouve quelque chose qui parle de ce qu’on peut faire avec le clavier, en étant sûr de ne pas poser de problèmes.

Ben, pour reprendre l'exemple de twitter qui instaure entres autres les touches K et L, non, ils ne me causent pas de problème; mais je ne peux pas les utiliser non plus.

Je ne sais pas quel public ils visaient en proposant ces raccourcis; s'ils visaient les lecteurs d'écran, en tout cas, ils ont perdu, ça n'est d'aucune utilité.

Du coup dans cet exemple précis j'ai personnellement du mal à voir qui en profite vraiment: si tu as des yeux et des mains valides, alors tu utilises très probablement soit une souris soit un écran tactile et donc tu n'as pas ou peu besoin de ces touches. A l'opposé, si tu es bien voyant mais avec des mains invalides, tu n'as à mon avis probablement pas plus de facilité à te servir d'un clavier (y compris un clavier visuel) que d'un dispositif de pointage.

L’accès depuis le clavier, peut être plus rapide ou plus confortable que l’accès avec un dispositif de pointage.

Mais ce qui est important ici, c’est surtout que tu confirme que ça ne pose pas de problème, alors je le note.
Modifié par hibou57 (04 May 2015 - 00:32)

a écrit :
Mais ce qui est important ici, c’est surtout que tu confirme que ça ne pose pas de problème, alors je le note.

Comme je te l'ai déjà dit, ça ne me pose pas de problème, mais je ne peux pas m'en servir non plus.

Fais tout de même attention à certaines touches stratégiques qui sont toujours transmises, lecteur d'écran ou non: Ctrl, Shift, Alt, Tab, Enter, Espace, Escape, Home, End, les flèches, DEL, Capslock peuvent potentiellement poser problème.

Bonjour,

hibou57 a écrit :
par exemple je peux faire un menu déclenché par une touche, qui permet de se passer de la souris, sans que ça n’interfère avec les lecteurs d’écran, parce que c’est le lecteur d’écran qui décidera s’il intercepte la touche ou pas. Il suffit de faire comme s’il n’était pas là, ce qui équivaut à la laisser décider, c’est le plus simple.

Je crois que si je pouvais prendre connaissance de seulement un ou deux raccourcis standards pour par exemple afficher un menu contextuel, déplacer le focus de manière plus souple, comme par exemple le déplacer vers le haut, vers le bas, la droite, la gauche, ce serait déjà beaucoup.
(...)
Il faudrait que je trouve quelque chose qui parle de ce qu’on peut faire avec le clavier, en étant sûr de ne pas poser de problèmes.

Les design patterns d'ARIA correspondent à ça je pense, encore qu'il n'y ait pas la notion de menu contextuel, juste de menu. Pour chaque composant est fixé les combinaisons de touche à utiliser (dans un calendrier, PageDown ça va être le mois et pas autre chose - au pif, c'est peut-être la semaine - et dans un Tabpanel, la touche Fin va sélectionner le dernier onglet, etc
La touche de base reste la Tabulation pour naviguer de lien en lien (et champs de formulaire) mais aussi de composant ARIA en composant ARIA et à l'intérieur de ceci c'est bien plus "riche" que juste la tabulation, espace et entrée.

Les raccourcis pour Twitter : J et K je pense que c'est repris de l'éditeur vim (et sûrement d'autres). H J K L permettent de déplacer le curseur ( et :q! est LA combinaison à apprendre en premier, pour sortir de ce truuuc ). C'est pratique visuellement pour suivre où t'en es de ta lecture mais snirf quand tu remontes 12H de tweets c'est bien trop lent. Je ne me sers que de G suivi de H pour charger les nouveaux tweets.

tu n'aurais du toucher "ctrl"...


------------------------
Housse Sony Xperia Z4
Modifié par fraiss2 (12 May 2015 - 09:02)

Re-bonsoir les gens,

Felipe a écrit :
La touche de base reste la Tabulation pour naviguer de lien en lien (et champs de formulaire) mais aussi de composant ARIA en composant ARIA et à l'intérieur de ceci c'est bien plus "riche" que juste la tabulation, espace et entrée.

Je ne suis pas sûr d’avoir vraiment compris ce qui est plus riche. Il y a des touches en plus, et pas seulement la tabulation, ou on peut naviguer dans plus de choses avec la tabulation ?

Bonsoir Monsieur Quentin,

QuentinC a écrit :
Fais tout de même attention à certaines touches stratégiques qui sont toujours transmises, lecteur d'écran ou non: Ctrl, Shift, Alt, Tab, Enter, Espace, Escape, Home, End, les flèches, DEL, Capslock peuvent potentiellement poser problème.

Je ne sais pas si tu peux le tester, mais j’ai justement un cas où je modifie la réponse du clavier. Comme précédemment, c’est une ébauche, mais pour une autre chose que précédemment.

C’est sur la page http://test.rasama.org/colour-pal-1/

En arrivant sur la page, faire Tab * 2 pour arriver au premier contrôle qui font comme des boutons de déplacement. Un appuie sur une touche fléchée du clavier, effectue la même action que le bouton correspondant, mais aussi déplace le focus sur le bouton correspondant. Par exemple si le focus est sur le bouton qui fait déplacer le pseudo-curseur vers la gauche, et qu’un appuie sur la touche flèche-haut du clavier survient, le pseudo-curseur est déplacé vers le haut, et le focus est donné au bouton correspondant.

Ce n’est pas trop perturbant ce déplacement de focus ? Si ça ne pose pas de problème, je me servirai de cette méthode ailleurs.

Une chose qui m’ennuie, c’est que je voudrais dans d’autres cas, utiliser les touches de curseur du clavier, pour déplacer le focus d’un élément à un autre. C’est parce que je trouve la tabulation trop limitée tout en trouvant important la manipulation du focus, que je voudrais enrichir de cette manière.

En parlant de raccourcis à une touche, les lecteurs d’écran et les smartphones reconnaissent-ils la touche F1 pour l’aide ?
Modifié par hibou57 (08 May 2015 - 21:47)

Felipe a écrit :
Les design patterns d'ARIA correspondent à ça je pense, encore qu'il n'y ait pas la notion de menu contextuel, juste de menu.

Il y a au moins ça, en HTML 5.1 : 4.11.5 Context menus (w3.org).

Ça parle malheureusement de clique-droit, mais rien n’interdit que ce soit déclenché par une touche. Sous Windows, il y avait une touche du clavier pour ouvrir un menu contextuel.

Ce que j’aimerais, c’est quelque chose qui ouvre un menu contextuel et/ou une aide, dont la cible serait l’élément ayant le focus, et ce menu contextuel et/ou cette aide, s’ouvrirait avec une seule touche. Cette seule possibilité, ouvrirait beaucoup de portes.

-- Édit --

Sous Ubuntu, c’est soit Shift-F10 (le cas pour moi), soit Ctrl-F10 ou Alt-Espace (pour d’autres gens). Je sais qu’il y a un raccourci sous Windows et même une touche spéciale pour certains claviers, ça doit bien exister sur Mac aussi. J’aurais préféré que ce soit une touche unique, mais c’est une assez bonne nouvelle quand-même, j’ai testé que sous Opera Blink et Firefox, Shift-F10 ouvre bien un menu contextuel pour l’élément qui a le focus, si un élément a le focus, sinon le menu contextuel de la page entière. Je vais faire des essais et j’en reparlerai. Ça peut être super utile pour économiser des éléments sur la page et ne les afficher que ponctuellement sur demande, en fonction du contexte, ce dernier point étant important pour être économe avec ce qu’on met dans le menu.

Reste à savoir si les lecteurs d’écran ont une fonction correspondante, et idem pour les appareils sans pointage/souris.

--- Édit 2 ---

Ça n’est supporté par aucun navigateur excepté Firefox, et par ce dernier, même pas correctement.

Quelqu’un a fait une page de test : http://demos.mattwest.io/context-menu/

Ça ne fonctionne pas avec Opera Blink, et avec Firefox, ça ne fonctionne qu’avec un clique-droit de la souris, et la combinaison touches Shift-F10, n’affiche que le menu contextuel normal, sans les ajouts. Puis une autre erreur importante dans le support de Firefox, et qu’il affiche par défaut les éléments du menu contextuel définis par la page, en plus ceux par défauts. Si ça ne change pas, ça va faire des menus illisibles parce que trop surchargés (en plus d’être inutilisables dans beaucoup de cas). D’ailleurs la documentation de HTML 5.1 suggère bien de ne pas afficher par défaut, les éléments du menu contextuel par défaut, et de les afficher à la demande de l’utilisateur, seulement.

Pour le support quasiment absent, voir http://caniuse.com/#feat=menu , et c’est déprimant .
Modifié par hibou57 (09 May 2015 - 14:28)

La touche unique qui permet d'ouvrir un menu contextuel sous windows, c'est la touche application. Pour le moment il faut l'intercepter explicitement, oncontextmenu ne marche pas. Le code de touche correspondant est 0x5D (93), spécifié dans le fichier winuser.h présent avec tout bon compilateur C/C++ pour windows.

La chose intéressante à noter ici, c'est que si tu fais un menu contextuel dans les règles de l'art selon ARIA, ça fonctionne superbement bien avec les lecteurs d'écran, en tout cas sous windows avec Jaws ou NVDA et IE9+ ou firefox. Je l'ai déjà expérimenté et appliqué dans plusieurs projets. Attention toutefois à fournir un menu qui suive ARIA à la lettre sans quoi tu mettras à coup sûr l'utilisateur en difficulté.

La chose à faire gaffe de manière générale c'est que si tu crées ton propre menu contextuel, alors l'utilisateur n'a plus accès à celui par défaut du navigateur. A toi de concevoir ton application de sorte que soit le menu par défaut devienne totalement inutile (pour moi il est déjà de base totalement inutile mais ce n'est pas le cas pour tout le monde), soit qu'il puisse être appelé par une combinaison alternative, p.ex. Maj+clic droit, Maj et/ou Ctrl+App, Ctrl+Maj+F10. Les entrées du menu contextuel par défaut copier/couper/coller sont potentiellement les plus problématiques puisqu'il n'existe à ce jour pas de façon de les remplacer ou les invoquer par JavaScript de manière fiable et systématique (que ce soit avec IE, firefox ou chrome, la'ccès au presse-papiers est toujours un problème).

En ce qui concerne l'aide, tu peux intercepter F1. Je crois qu'il existe un évènement onhelp mais je n'ai aucune idée de sa compatibilité. L'action par défaut de F1 ouvre l'aide générale du navigateur donc ça peut se remplacer sans grands soucis à mon avis, je ne pense pas qu'on ait besoin de l'aide générale d'IE ou de firefox tous les jours.

A noter que Ctrl+F1 et/ou Maj+F1 sont normalement en principe réservés pour ouvrir des info-bulles fermables avec escape; si ton application en a, il serait de bon ton de pouvoir les invoquer avec ces raccourcis.
Modifié par QuentinC (09 May 2015 - 17:56)

QuentinC a écrit :
La chose intéressante à noter ici, c'est que si tu fais un menu contextuel dans les règles de l'art selon ARIA,

Si tu parlais de l’exemple sur la page http://demos.mattwest.io/context-menu/ , ce n’est pas chez moi.

a écrit :
Si tu parlais de l’exemple sur la page
http://demos.mattwest.io/context-menu/
, ce n’est pas chez moi.

Non, comme tu l'as bien vu toi-même, cet exemple ne marche que sur firefox et qu'à moitié, uniquement avec la souris. De plus il n'y a absolument pas d'ARIA dans le code, c'est un système complètement indépendant. Cela dit, en simulant un clic droit, le menu qui apparaît est tout à fait accessible.


JE parlais vraiment des menus construits avec ARIA. L'attribut contextmenu ne marche que sur firefox mais pour tous les navigateurs (même IE), l'évènement oncontextmenu fonctionne et tu peux t'en servir pour faire apparaître un menu basé sur ul/li. Pour peu que les ul/li en question soient correctement construits avec ARIA et que la navigation clavier soit bien gérée, le menu est alors tout à fait accessible avec les lecteurs d'écran. Hélas, ordre de difficulté 10 à 1 par rapport à cet exemple.

hibou57 a écrit :
Bonsoir par ici, bonsoir par là,

Ça fait longtemps que j’y penses, mais c’est la première fois que je pose la question. Je trouve que les accesskey portent mal leur nom, parce qu’elles ne sont pas très accessibles (excepté sous Konqueror). Je me demandais si c’est une pratique déjà existante ou acceptable, d’utiliser JavaScript pour qu’une page convention réponde aux accesskey en utilisant seulement la touche d’accès toute seule.

Par exemple si une accesskey est A, alors au lieu de faire Shit+Alt+A (Chrome et Firefox), un simple appui sur A suffirait, ou éventuellement comme sous Konqueror, Ctrl puis A (successivement, pas simultanément), ce qui est déjà plus accessible.

Cela pourrait se faire sans interférence avec la méthode native du navigateur.

Ça se fait déjà ? Si ça ne se fait pas vraiment, cela pourrait-il être jugé acceptable ?

En marge et en rapport, je me demandais aussi, si depuis le temps un standard est apparu, concernant le comment faire afficher la liste des accesskey et leurs cibles.

-- Édit --

Une variante qui me trotte dans la tête depuis longtemps, est une touche qui ferait s’afficher un menu des accesskey en surimpression sur la page. Par exemple un appui sur Ctrl afficherait la liste, ensuite on peut naviguer dans la liste avec les touches curseurs du clavier, comme dans un SELECT, ou appuyer sur la touche correspondante, également indiquée dans la liste. Encore mieux, ce menu pourrait ne s’afficher qu’après un délais, pour ne pas qu’il s’affiche inopinément à chaque fois alors qu’un Ctrl puis lettre est sur le point d’être entrée directement.

J’attends d’avoir des avis, et ensuite je fais un test dans une page mentionnée dans un autre sujet.

euh tu vas te planter c'est sur

Isabelle98 a écrit :

euh tu vas te planter c'est sur

Sois sans craintes, dis-en plus
Modifié par hibou57 (14 Jan 2016 - 07:46)

a écrit :
Une variante qui me trotte dans la tête depuis longtemps, est une touche qui ferait s’afficher un menu des accesskey en surimpression sur la page. Par exemple un appui sur Ctrl afficherait la liste, ensuite on peut naviguer dans la liste avec les touches curseurs du clavier, comme dans un SELECT, ou appuyer sur la touche correspondante, également indiquée dans la liste. Encore mieux, ce menu pourrait ne s’afficher qu’après un délais, pour ne pas qu’il s’affiche inopinément à chaque fois alors qu’un
Ctrl puis lettre est sur le point d’être entrée directement.

C'est une très mauvaise idée de déclencher une action avec un appui sur Ctrl seul. Pour un grand nombre de lecteurs d'écran, la touche Ctrl seule permet de faire taire le lecteur d'écran.

En plus, certains utilisateurs utilisent ce qu'on appelle les touches rémanentes. C'est une possibilité offerte par le système d'exploitation pour effectuer des combinaisons de touches en appuyant sur chacune des touches les unes après les autres plutôt que plusieurs en même temps, p.ex. pour faire Ctrl+C, un utilisateur de cette fonction appuie sur Ctrl, la relâche, puis appuie sur C. Si les touches rémanentes sont activées, pas sûr qu'il soit possible de faire apparaître le menu ou alors seulement après un délai plus ou moins inacceptable, car les évènements clavier envoyés aux scripts sont modifiés et/ou absorbés.

5 fois de suite Shift permet d'activer cette fonction sous Windows, donc utiliser Shift à la place de Ctrl, c'est pas mieux.