Grogne sur l’accessibilité

Grogne sur l’accessibilité (le 29 avril 2016)

Un monstre coup de grogne d’un développeur concernant l’accessibilité a fait un bruit certain, la newsletter Opquast en a parlé et je vais rebondir dessus.

Remettons-tous dans l’ordre. Un article explique certains problèmes des design patterns sur des utilisateurs clavier. Voici l’article en question : Danger! ARIA tabs.

Je passe sur le côté maladroit de certaines formulations et volontairement trollesque de cet article. Je passe aussi sur le code donné en exemple, qui me semble insuffisant (comme indiqué dans ce commentaire).

Il y a par contre un problème réel (entre autres) qui mérite d’en parler (que je n’avais pas compris au début) : l’utilisateur clavier n’est pas habitué à ce qu’on lui propose ces design patterns, et souvent il est perdu (par exemple, il ne sait pas qu’il peut utiliser les flèches gauche et droite pour afficher les onglets). Ça c’est un souci réel.

Et en guise de propos, le classique « ça dépend ». Sauf que le coup de grogne mentionné plus haut est monté, et je ne suis pas loin de donner bien raison à ce développeur. Étant moi-même impliqué à développer des plugins accessibles que je déploie massivement (à peu près tous les sites que je fais les utilisent), je ne peux clairement pas entendre un « ah bin, ça dépend, et il va falloir jeter ce que vous avez fait ». Même pas en rêve.

Là je serais du genre à répondre : « sérieux les gamins, vous êtes gentils, mais je respecte vos standards, j’y contribue, j’ai des dizaines et des dizaines de sites en prod, j’ai pas le temps ni même la possibilité de faire dans le détail, bordel ! » (et encore, je suis resté poli). Pire, ce genre de naufrage peut ruiner une chiée d’efforts et de motivation. La cause de l’accessibilité n’a me semble-t-il pas besoin de ça.

Par contre, ce que je peux entendre et je regrette de ne pas l’avoir lu, c’est « continuons avec ces standards, mais améliorons-les en pratique, soyons constructifs », ce qu’Aurélien Lévy (qui m’aide beaucoup sur ces plugins) fait déjà très bien, régulièrement, on va plus loin que ce que les standards proposent pour faire mieux en pratique. On sait très bien que ce n’est pas parfait, mais il vaut mieux faire quelque chose que rien du tout.

Franchement, ne serait-il pas plus simple de partir de ces standards (qui me semblent plutôt bons), de les améliorer et d’éduquer ou d’aider l’utilisateur ?

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1691

12 commentaires

Posté par Sophie Schuermans le 29/04/2016 à 12:07:22
Bonjour Nicolas,

Je comprends ton coup de grogne et ton besoin d'avoir des recommandations claires.
A mon avis les onglets sont sont le module le plus complexe à rendre vraiment accessible aux utilisateurs qui naviguent au clavier et avec un lecteur d'écran. Nous avons très longtemps hésité à conseiller à nos clients de suivre le design pattern pour les onglets et nous n'avons commencé à le faire que quand nous avons eu une implémentation correcte à leur proposer (ton plugin d'onglets accessibles)

Je pense que les deux implémentations, avec ou sans ARIA, peuvent se défendre pour les onglets:
- soit on implémente les onglets entièrement en suivant le design pattern (attributs ARIA et interaction au clavier),
- soit on implémente sans ARIA et les onglets fonctionnent comme une table des matières suivie de blocs de contenu.

Ce qu'il faut éviter c'est de faire des implémentations partielles du design pattern parce qu'alors le comportement du widget n'est plus prévisible. Les deux solutions ont chacune leurs défauts et dans tous les cas les onglets resteront un module relativement complexe à gérer pour un utilisateur qui navigue au clavier, avec ou sans lecteur d'écran.

L'article de Simply Accessible est intéressant car c'est un retour d'expérience qui confirme que les onglets avec ARIA restent difficiles à comprendre pour les utilisateurs. C'est un rappel qu'ARIA ne fonctionne pas forcément comme un coup de baguette magique, même si on aimerait bien que ce soit le cas.
Nous pouvons décider chacun en connaissance de cause d'utiliser ou non cette implémentation du design pattern, et d'utiliser ou non des onglets comme manière de présenter l'info.

Au bureau nous utilisons régulièrement tes plugins comme exemples lors de formations, dans des rapports d'audit ou quand nos clients nous demandent de bons exemples. Donc personnellement je t'encourage à continuer à les maintenir .
Posté par Nico le 29/04/2016 à 12:12:32
Déjà merci pour ce commentaire, et pour l'encouragement, ça fait du bien. (ça c'est dit (sourire) )

Je me demande si on ne pourrait pas améliorer ces plugins (avec ou sans ARIA) en proposant de l'aide (avec une infobulle, ou je-ne-sais-quelle solution) ?
Posté par Gaël Poupard le 29/04/2016 à 14:35:10
Je suis bien d'accord avec toi.

J'admets avoir du mal à comprendre ce coup de gueule. Les spécifications sont des indications de comment les choses DEVRAIENT fonctionner, et heureusement elles évoluent, heureusement elles ne sont pas gravées dans le marbre, heureusement parfois on en jette.

Il est normal qu'un modèle proposé ne fonctionne pas. C'est même quasiment la base, sachant par exemple que les navigateurs attendent qu'une spécification soit validée avant de l'implémenter (les CSS grid, si vous nous regardez).

Et je trouve que c'est taper bien fort sur l'accessibilité que de brailler sur un motif de conception ARIA impraticable, quand je vois la tartine de couches techniques qu'un développeur front doit ajouter pour que son ES6 soit fonctionnel.

Les choses évoluent et finissent par ne plus être pertinentes — parfois même avant d'être utilisables partout (les CSS columns, si vous nous regardez).

Combien de sites mis en prod avec un jQuery qui ne marche plus de nos jours, avec MooTools ou d'autres vieilleries ? Avec des choses inutilisables et incomprises, par exemple des onglets sans aucune prise en compte de l'accessibilité ?

Peu importe que les choses changent et que le modèle de conception ne soit pas parfait, utilisez-le. C'est votre taf. Ne sautez pas sur un détail pour vous dédouaner d'un truc inaccessible.

Si vous vous souciez vraiment jusqu'au bout de vos utilisateurs, testez dans toutes les configurations imaginables, et trouvez de véritables utilisateurs pour tester. Et pourquoi pas payer un pro pour auditer ou tester ? Faites votre taf, bon sang.

Le coup de gueule de la fin : je trouve indécent d'entendre des développeurs se plaindre du manque de support des motifs de conception ARIA quand je me souviens la bataille que ce fut de faire lire les spécifications HTML et de faire respecter des standards. Et je rencontre encore beaucoup de professionnels qui ne savent pas valider une page HTML.

Alors pitié, commençons par le début.
Posté par Gaël Poupard le 29/04/2016 à 14:39:17
Au fait, j'en rajoute une couche pour te remercier de ton incroyable travail avec tes plugins.

Quand tu évoques les sites qu'on a mis en production et qu'on a pas la capacité ou l'envie de mettre à jour, et bien les sites que je mets en production avec tes plugins me font moins peur : ils ont un degré de qualité rare grâce à eux, et même si un jour ils seront obsolètes, même si les motifs de conception ne sont pas parfaits, l'effort est fait et je n'ai aucun problème à laisser ces sites en production.

Merci Nico pour tes scripts (sourire)
Posté par Nico le 29/04/2016 à 14:48:00
Gaël : C'est un peu un problème (je trouve) de l'accessibilité. Grosso merdo, c'est assez peu déployé (faut être honnête, y a une majorité de sites inaccessibles), et j'ai l'impression que le peu qui est fait « un peu plus loin que le début » (pour reprendre tes propos) se fait systématiquement mettre des bâtons dans les roues… comparé à JS ou CSS, c'est proprement hallucinant.

Y a pas une coordination implé/specs/retour d'expérience ?
Posté par Nico le 29/04/2016 à 14:49:58
Je vois le 2e commentaire, merci, ça fait du bien de lire ça (sourire)
Posté par Pascal @eQRoeil le 02/05/2016 à 9:52:05
Salut Nico, salut Gaël,

vous faites tous les deux du super boulot pour promouvoir l'accessibilité et plus important encore offrir des solutions pour la faire progresser, Gaël avec a11y.css https://github.com/ffoodd/a11y.css/ et Nico avec les plugins accessibles http://a11y.nicolas-hoffmann.net/ merci, merci, continuez ce super boulot.

En revanche, j'ai l'impression que vous êtes un peu éloigné de la réalité...

Je reprends quelques morceaux de la discussion sut Twitter au sujet des tabs ARIA :

> then how are well-meaning web devs supposed to make things accessible if supposed best practices don’t work?

> I just shipped a site where I tried to do my best. And now you tell me I was wrong?

> I don’t think my client, who has been threatened with an a11y lawsuit, will accept “It depends”

Je vois moi un dev qui fait de son mieux pour implémenter des tabs avec ARIA
Et qui ne découvre pas ARIA et l'accessibilité pour son dernier projet, plus loin :

> I totally agree. I actually appreciate your article. Thank you for writing it.
> I just wish it didn’t negate every other article I’ve read about making tabs accessible over the past six years. It’s frustrating

>> Did you test your work with users? Even a small group can shed light on things we wouldn’t consider otherwise.

> if I had a client who was willing to pay for that, I would

Je comprends parfaitement la frustration de ce dev

Pour en ajouter un peu plus :

Depuis 6 ans que je fais ce job, JAMAIS un client ne m'a parlé d'accessibilité, que ce soit en direct, en sous(-sous)-traitant, en mission chez un client non web, ou en agence (web) (pas besoin de donner les réponses à son évocation...)
JAMAIS je n'ai bossé sur un projet pour lequel des tests utilisateurs étaient présents ; alors tests utilisateurs avec AT...

(Peut-être suis-je une exception, que j'ai joué de malchance, que dans quelque mois tous les projets sur lesquels je vais bosser devront prendre en compte l'accessibilité...)

Et j'essaie de faire de mon mieux pour que mon travail ne soit pas discriminant... par conviction personnelle, mais je vous assure que c'est frustrant, difficile à ajouter dans des plannings et budgets (plus que) serrés.
Je ne parle pas, évidemment, de liens vs bouton pour le clic ou de labels pour les formulaires mais de tabs ou de navigations/interactions complexes dans du svg par exemple.

Vous avez la chance d'avoir des soutiens, des experts, des testeurs qui vous permettent d'améliorer vos outils et vous en faites profiter la communauté, c'est génial.
Mais n'oubliez pas que vous êtes des privilégiés, simplement pour cette raison (et si en plus vos employeurs, clients, entendent que rendre un site accessible est nécessaire vous l'êtes encore plus)


Gaël,

> Si vous vous souciez vraiment jusqu'au bout de vos utilisateurs, testez dans toutes les configurations imaginables, et trouvez de véritables utilisateurs pour tester. Et pourquoi pas payer un pro pour auditer ou tester ? Faites votre taf, bon sang.

Ceci est irréaliste de mon point de vue, vraiment...

> Le coup de gueule de la fin : je trouve indécent d'entendre des développeurs se plaindre du manque de support des motifs de conception ARIA

N'oublie pas qu'un dev qui se plaint du manque de support :

- a décidé de rendre son code accessible (peut-être de son propre chef)
- a fait des recherches pour comprendre / mettre en place
- a testé le support, justement...

C'est quel pourcentage de notre communauté ?

Quand tu fais de ton mieux avec les moyens que tu as, sans pouvoir tester sur toutes les AT (différents OS, AT payantes), en espérant que tu n'ai pas fait plus de mal que de bien et en essayant de faire ça sans que ce soit prévu dans le temps/budget, putain oui c'est frustrant de lire qu'une implémentation ARIA ne fonctionne pas...

> Je me demande si on ne pourrait pas améliorer ces plugins (avec ou sans ARIA) en proposant de l'aide (avec une infobulle, ou je-ne-sais-quelle solution) ?

Offrir une alternative "clean" (sans tabs / accordions etc.) si l'utilisateur le souhaite ?

J'aimerais avoir l'info "hey, je suis une AT, me file pas ton js et file moi un truc simple"
je serais sûr de faire mieux et d'attendre sereinement : https://specs.webplatform.org/common-panel/bkardell/gh-pages/
http://radar.oreilly.com/2015/11/panels-and-panel-sets.html
https://bkardell.github.io/common-panel/prototype/panelset-element.html

le temps que ce soit discuté, implémenté dans les navigateurs puis les AT... je serais serein pendant 5 ou 10 ans...

> [...] se fait systématiquement mettre des bâtons dans les roues… comparé à JS ou CSS, c'est proprement hallucinant.

Hallucinant, oui, mais réel et malheureusement pour longtemps encore (à mon avis)

---

Vous faites avancer les choses dans le bon sens, merci encore, mais gardez à l'esprit que notre communauté est diverse, et que malheureusement quasiment tous les acteurs se soucient plus d'autre chose que de l'a11y : clients, navigateurs, devs tous préfèrent ce qui est nouveau, ce qui brille.

J'espère ne pas vous décourager, moi je ne décourage pas et continuerai à faire de mon mieux tout en sachant que je laisserais toujours certains de côté, en espérant simplement réduire ce nombre au minimum.

Pascal



Posté par Gaël Poupard le 02/05/2016 à 10:40:07
Merci Pascal pour ce super retour, ça fait du bien (sourire)

Pour être totalement honnête, moi non plus mes patrons ou clients ne me parlent pas d'accessibilité. Les seuls tests utilisateurs auxquels j'ai accès ont des panels aléatoires non représentatifs (bien ou pas, c'est un autre débat), et les seuls retours d'utilisateurs d'AT que j'ai pu obtenir ces dernières années sont indirects, avec plusieurs intermédiaires pour transmettre un retour. Autant dire que c'est de l'interprétation.

Je pense qu'à peu près tout le monde rencontre les difficultés que tu évoques : ni le client, ni le patron, ni le chef de projet ne veulent en entendre parler ; les techniciens ne s'en soucient généralement pas ; les tests sont chronophages, chers et compliqués à mettre en place.

Je suis dans ce cas, depuis toujours.

Cependant en expliquant autour de moi, en montrant quelques techniques, outils, spécifications, et en récupérant les explications des autres je parviens toujours à faire poindre un semblant d'intérêt chez mes interlocuteurs. au point qu'après quelques mois de travail à mes côtés, la plupart des développeurs avec lesquels j'ai travaillé sont devenus sensibles à mes explications, se sont mis à poser des questions, à partager des outils spécialisés qui les intéressaient. Pas plus tard que ce matin un collègue me montre tota11y, qu'il vient de découvrir et a passé le week-end à jour avec.

C'est une victoire (sourire)

Je ne sais pas si les utilisateurs sont satisfaits de ce que je produis, et je le regrette. Je fais tout ce que je peux pour le savoir, mais c'est bien peu. En revanche je suis à fond tout ce qui parle d'accessibilité, j'ai parcouru tous les référentiels et lus tous les retours auxquels j'ai eu accès. Et j'implémente en respectant l'état de l'art.

Et c'est le cas de tous les développeurs qui fournissent le même effort, non ?

On en revient au sujet de base de ce fil, une personne qui se plaint que l'implémentation parfaite du motif de conception ne soit pas véritablement fonctionnelle partout. Je comprends que c'est frustrant, je suis précisément dans le même cas.

Mais cette frustration semble accrue par la confiance aveugle en la spécification et envers les experts. Et là, je désapprouve.

Ce ne sont que des textes et des hommes. Tous les développeurs géniaux sur tous les langages géniaux du monde reviennent sur leurs avis, finissent par recommander de ne plus suivre telle ou telle bonne pratique — et ça, n'importe quel développeur qui se contente de suivre les tendances devrait le savoir. Jetez un œil à CSS-tricks ou au blog de Paul Irish il y a 5 ans, vous verrez bien l'évolution.

En accessibilité c'est pareil. Les choses ne sont pas figées : les spécifications évoluent, le support des navigateurs et des AT évolue, et avec ça les recommandations, les bonnes et les mauvaises pratiques aussi.

Tout ce qu'on peut faire pour ça, c'est implémenter en respectant l'état de l'art. Profitez des gens qui savent et peuvent tester (ce que fais Nico avec ses plugins, quand tu voies les contributeurs c'est du très lourd).

Pour a11y.css, sache que je n'ai jamais suivi la moindre formation en accessibilité ni mené le moindre audit, je n'ai jamais non plus travaillé sur un projet dont les contraintes la mentionnaient officiellement. Jamais.

Ce qu'il s'est passé, c'est que j'ai fait suinter mon intérêt dans tous les projets auxquels j'ai touchés, je m'en suis servi pour expérimenter les diverses recommandations, j'ai appris en me trompant. Quand je ne savais pas ou ne comprenais, j'allais lire les référentiels concernés. Et a11y.css n'est que le compte-rendu de ces lectures. J'ai démarré a11y.css en travaillant dans une petite agence, la durée moyenne des prestations de créations de site était de 4 jours — et je faisais tout, de la recommandation au développement en passant par le graphisme. C'est dans ce contexte que j'ai créé a11y.css, et plus je m'en servais meilleur il devenait.

Alors je vois bien dans quel contexte professionnel se trouvent la plupart de nos camarades, mais je ne comprends toujours pas l'effervescence autour de ce billet.

Il me semble que c'est dans la nature du web d'évoluer, et je n'entends pas grand monde râler à propos de sa frustration des mauvaises implémentations en HTML ou CSS. Pourtant il y en a pléthore.

J'ai hate de pouvoir en discuter de vive voix ! Sud Web, KiwiParty ?





Posté par Nico le 02/05/2016 à 10:47:48
@Pascal : je mets au point quelques détails, tu vas voir qu'on est dans la même réalité.

> Je vois moi un dev qui fait de son mieux pour implémenter des tabs avec ARIA
> Et qui ne découvre pas ARIA et l'accessibilité pour son dernier projet, plus loin :

C'est justement ça qui est énervant àmha : je suis exactement dans le même cas et je peux avoir la même réaction. Genre tu te casses le cul pour améliorer une goutte dans un océan de merde et pour t'entendre dire : ça dépend, il va falloir faire autrement, perso, ça me met la rage au ventre.

C'est un des gros soucis de l'accessibilité : j'ai la sensation que la cause se saborde souvent elle-même. Quand je vois les délires en CSS et en JS, ça se pose beaucoup moins de questions, et je me dis que ce n'est peut-être pas plus mal (même si ça pique les yeux).

Je peux t'assurer que je me suis bien contenu à la lecture de cet article de Simply Accessible ( => je sais que c'est excessif et que personne n'y est pour rien, mais quand on switche en mode rage, ces considérations sont bien lointaines ).


> Depuis 6 ans que je fais ce job, JAMAIS un client ne m'a parlé d'accessibilité, que ce soit en direct, en sous(-sous)-traitant, en mission chez un client non web, ou en agence (web) (pas besoin de donner les réponses à son évocation...)

Je te rassure, sur mon poste actuel depuis 6 ans, j'ai dû avoir 1 à 2 projets où j'ai eu la demande (pas l'obligation, la demande). Sur près de 100 sites. Je te laisse calculer le pourcentage, c'est pas difficile. (grand sourire)


> JAMAIS je n'ai bossé sur un projet pour lequel des tests utilisateurs étaient présents ; alors tests utilisateurs avec AT...

Moi non plus (rires de sitcom).

Les tests sont fournis par Aurélien Lévy, Sophie Schuermans, Johan Ramon, etc. en gros, les experts qui m'aident bénévolement sur ces plugins. (clin d’oeil)


> Vous faites avancer les choses dans le bon sens, merci encore, mais gardez à l'esprit que notre communauté est diverse, et que malheureusement quasiment tous les acteurs se soucient plus d'autre chose que de l'a11y : clients, navigateurs, devs tous préfèrent ce qui est nouveau, ce qui brille.

Crois-tu que ce soit différent autour de moi ? (sourire)

Comme tu peux voir, mes plugins sont faits avec très peu de moyens (mon temps libre, et le temps libre des experts).

Et encore, j'ai forcé au taf' pour que ça soit fait en composants réutilisables plutôt que de tomber dans le one-shot impossible à maintenir. Rigolo, quand tu sais in fine que je les ai utilisés sans arrêt sur tous les sites que je produis et que c'est en train d'aller plus loin.


> J'espère ne pas vous décourager, moi je ne décourage pas et continuerai à faire de mon mieux tout en sachant que je laisserais toujours certains de côté, en espérant simplement réduire ce nombre au minimum.

Non, je suis un pro des causes difficiles, ça ne me fait pas peur (sourire)

C'est bien pour cela que je me suis lancé sur ces plugins. C'est un peu comme Firefox en son temps quand il a challengé IE : il faut faire mieux AVEC l'accessibilité incluse dedans.

Pour ça que l'approche réutilisable en mode rouleur compresseur me parait plus pertinente que l'approche chirurgien dentaire.

Crois-moi sur parole quand je te dis que je réalise enfin la gageure du propos d’Élie Sloim quand il parle d'améliorer massivement la qualité des sites. 4 ans que je m'y cogne avec ces plugins…
Posté par Lapeze le 02/05/2016 à 14:50:36
Bonjour à tous,

Ton article et les commentaires son intéressants et instructifs. Je travail en se moment sur le développement d'une charte ergonomique et accessible. Le cas de l'onglet à également posé des problèmes.

Lorsque j'ai proposé la version suivant le design pattern ARIA, je me suis fait retoquer par les ergonomes qui m'on clairement fait comprendre que niveau utilisabilité cela n'allait pas du tout.

Nous avons travailler sur une version n'utilisant pas Aria et nous sommes arrivé à une version accessible sans Aria dont l'utilisation au clavier et à la souris convenait parfaitement aux ergonomes.

Il faut accepter le fait que ARIA n'est là que pour rendre un élément accessible pour les personnes utilisant une technologie d'assistance. ARIA n'apporte rien à un utilisateur naviguant simplement au clavier. Les design Pattern ARIA ne prennent pas en compte les attentes des utilisateurs de clavier et c'est un problème qui a été plusieurs fois soulevé.

Enfin, les design Pattern ne sont pas des références absolues. Si vous consultez le W3C ils sont en DRAFT. Ils doivent donc être améliorés et nous pouvons contribuer à cette amélioration.

Nicolas, ton travail est super et très profitable à beaucoup de gens. J'ai repris dans la Charte certain de tes développements (notamment le tooltip qui est vraiment super). Tu as raison de poussé un coup de gueule car ta voix porte certainement un peu plus que d'autres. C'est en amenant le débat que l'on arrivera peut-être à faire bouger les choses et à faire progresser l'accessibilité pour tous.

Merci encore pour ton travail.
Posté par Nico le 02/05/2016 à 16:16:42
Regis: ce travail des ergonomes, y aurait moyen de le rendre public ?
Posté par goetsu le 03/05/2016 à 8:01:06
moi je fais ça en mode oldschool sans aria : http://s.codepen.io/goetsu/debug/NNaKwX
(juste pour démo le code js est bien grato à souhait et pas pluginsé du tout) pour justement montrer qu'on pouvait tout à fait faire qqchose d'accessible sans utilisé ARIA.

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.