Aller au contenu

WCAGmire

Par Adrian Roselli

Conférence (50 mn) :
Langue :
Anglais
Sous-titres :
Français

Le sujet

The Web Content Accessibility Guidelines, or WCAG, can be a bit of a quagmire (hence this talk title) for those who do not work in it every day. The language is difficult, the examples may not match what you are doing, and the solutions are unclear. Once developers and designers fold in their own preferences and expectations, getting everyone to agree on even one rule can get tricky. And, for fun, add the known loopholes, shifting definitions, and gaps, and performing a WCAG review can feel like you are lost in a dark bog in the middle of the night. This talk explores some of these issues and tries to help with a way out.

Présenté par

Transcription

Bonjour, je m'appelle Adrian Roselli. Les seuls mots de français que je connais...

[Applaudissements de la salle]

Tu es bourré !

[Rires dans la salle]

J'ai un code QR ici pour suivre les diapos, c'est un PDF de 5Mo. Mais c’est peut-être plus facile à suivre. Je ne sais pas. Si vous ne pouvez pas le scanner, c’est rosel.li/parisweb.

Merci de participer aujourd'hui. Je sais que vous avez ces présentations à thème de bourbier. Donc je suis ravi que vous participiez à ma présentation.
J’essaie de définir l’ambiance avec cette image. Il s'agit d'un lieu au sol mou, où il y a des marécages, quelques vieux arbres sont tombés, le ciel est bleu, avec quelques nuages. Et en fond de paysage, il y a une forêt d’arbres verts.
C'est un bourbier. La boue, c'est ce qui vous donne cet indice. Sur ces diapos, j'ai mis une traduction vers le français, avec une traduction automatique, elle est épouvantable. La bonne nouvelle, c'est que si je dis une blague, je vais imaginer que vous êtes en train de rire à cause de ma blague, alors que vous vous moquez probablement de la traduction automatique. Voilà ma diapo égocentrée, juste pour montrer que j'ai des antécédents dans ce domaine. Je veux que mes arguments se défendent d’eux-mêmes. Mais j'ai fait des choses. Evolt.org est quelque chose que j’ai fait il y a longtemps, avec ce gars là-bas qui a l'air très décontracté. Mon premier livre a été rédigé avec Molly Holzschlag, qui a été mentionnée précédemment. Par chance, elle a participé en tant qu’auteur à mon premier livre. Elle ne savait pas qui j'étais, elle ne l'a pas su pendant dix ans, ce qui, en ce qui me concerne, est tout à fait justifié.

Voilà quatre développeurs qui sont dans un bourbier. Deux utilisent des ordinateurs portables, deux autres des tablettes. Et c'est ce que j’appellerai un « Wcag-mire ». Je ne suis même pas capable de prononcer ma propre blague dans ma propre langue.

[Rires dans la salle]

C'est un jeu de mot avec cagmire, qui veut dire bourbier en anglais. Ces recommandations pour l’accessibilité des contenu web sont la base de l’accessibilité, le minimum d'accessibilité. Elles ne garantissent pas la vraie accessibilité. Ce sont des règles de base, écrites pour des humains, elles sont molles, imprécises, basées sur des attentes, le contexte, l'expérience, et tant de choses de plus qui peuvent être différentes pour les personnes qui font le travail, et parmi votre public.

WCAG essaie d'être suffisamment souples pour fonctionner partout, avec toutes les technologies actuelles et futures. Nous avons une idée de la manière dont les technologies futures peuvent nous surprendre ou nous préoccuper. Quand on utilise WCAG, c'est un peu comme aller se promener dans un bourbier. En effet, si vous vous aventurez dans un marécage, ce bourbier, vous verrez que vous n'êtes pas le/la seule à vous y trouver. Des experts et des novices seront également embourbés avec vous.

Certains y sont embourbés depuis des décennies, 20 ans ou plus !

L'idée, c'est de cartographier. Et cette carte est une métaphore simplifiée pour ce qui est un processus complexe. Chaque équipe qui utilise cette cartographie vient avec un input différent. Vous avez le design, le développement, la recherche, les droits d'auteur, la législation, l’assurance qualité (QA) et bien d’autres choses. Tout cela arrive avec des biais dans leurs idées préconçues, leurs outils, leurs descriptions de poste, leurs compétences, leurs aptitudes et bien plus encore. Cette méthode, que vous avez en bas à gauche, c'est WCAG. Ils vont tous utiliser ce qu'ils savent et devront s'en sortir. On espère qu'ils travaillent ensemble, à l'idéal. L'output réel devrait être un produit, peut-être le lancement d'un nouveau produit, mais c'est quelque chose de concret de cette sorte. Ça peut être fait de Vpats ou d’ACRS. Le nom correspond au résultat réel, à la déclaration juridique, aux autres résultats pour les utilisateurs, ce qui est votre objectif, je pense, aux résultats pour les utilisateurs, aux efforts de marketing, et probablement à un tas d'autres choses.

Oh, j’ai passé une diapo, non ?

Pour tout projet composé de différentes équipes, on commence de différents endroits. Comme je l’ai déjà indiqué, les designers devraient commencer après les chercheurs, mais avant les développeurs, par exemple, mais ce n'est pas toujours le cas. Ils essaient tous d'arriver au même lieu final, comme je l’ai déjà mentionné. Aux États-Unis, par exemple, la plupart des organisations n'ont commencé à faire attention à tout ceci qu'à cause de procès en justice ou de menaces de procès. Cela signifie qu’ils n'ont pas fait attention jusqu'à ce qu'ils soient poursuivis en justice et que cela leur coûte de l'argent. Merci les États-Unis !

[Rires dans la salle]

La façon dont vous ou votre équipe abordez les WCAG est donc quelque peu sous votre contrôle, seulement quelque peu sous votre contrôle. Vous avez cette carte, sous la forme des documents d’accompagnement du W3C, et vous avez aussi les techniques, qui sont aussi des ressources du W3C. Mais tout le monde ne sait pas lire une carte. Certaines personnes ne penseront pas que la carte indique le meilleur chemin, ni même le chemin le plus sûr ou le plus rapide, comme nous l'avons appris maintes et maintes fois. D'autres ignorent totalement la carte, n'y prêtent aucune attention. Je vais donc passer en revue quelques-uns des points sur lesquels les WCAG peuvent nous égarer, nous embrouiller, permettre à certaines personnes de prendre des raccourcis, de faire le travail le plus facile, et où ils embrouillent généralement beaucoup d'autres personnes. Ceci va être assez technique, je m'excuse à l'avance.

Commençons par le premier critère de succès, le 1.1.1, contenu non textuel. Il est de niveau A, ce qui signifie qu’il est couvert par pratiquement toutes les lois ou politiques qui font référence aux WCAG. C’est vraiment la base. Le texte officiel est : « Tout contenu non textuel présenté à l’utilisateur a un équivalent textuel qui remplit une fonction équivalente sauf dans les situations énumérées ci-dessous ».

Je vais passer sur l'essentiel des exceptions.

Le défi pour les personnes qui testent WCAG est ici d'identifier si le texte alternatif décrit suffisamment quelque chose. L’initiative pour l’accessibilité du web propose un arbre décisionnel pour orienter les auteurs et les testeurs à travers un processus simple qui les aidera à identifier un texte alternatif utile pour les images.

Je vais parler seulement de la partie qui traite des images qui donnent un sens à la page ou au contexte actuel. Cela concerne les graphiques, les visualisations complexes, le contenu redondant et les images ou photos simples. Je vais me concentrer sur les images simples. C'est pourquoi je continue à réduire les choses au concept le plus simple qui soit. Mais c'est là où on tombe sur tous les désaccords.

En tant qu'auteur, vous devez faire un équilibre entre avoir trop ou pas assez de texte, décider ce qui doit être décrit dans l'image et ce qui peut être ignoré. Vous devez également garder à l'esprit la manière dont cette image sera réutilisée, car tout le monde sait que les images sont souvent réutilisées, que nous le voulions ou non. La plupart des outils de vérification automatiques signaleront une image dont l'attribut alt est vide et demanderont à un humain de l'examiner.

Ils n'ont aucune idée du contenu, du contexte, ou même du public de cette image. De même, ces outils utilisent la vision par ordinateur, que nous appelons parfois l'intelligence artificielle, IA. Et ces outils ne connaissent pas non plus le contexte. Les utiliser pour générer des textes alternatifs peut être un problème en soi, quoi qu'en disent leurs vendeurs, bien sûr.

On en revient à l'image que j’ai décrite en début de présentation, avec un marécage, avec des troncs d'arbres morts couchés devant. Et derrière, une forêt. Il y a un ciel bleu avec des nuages. J'ai mis cette image dans un outil de génération de texte alternatif. Et ça m'a dit que c'est une image avec des arbres, un ciel bleu et un fleuve. Ce n'est pas mauvais. Cela ne fournit pas ce que je voulais vous transmettre en tant qu’auditoire dans le contexte de ma présentation, mais j’ai tenté ma chance. Powerpoint, que j’utilise pour cette présentation, m'a proposé un étang entouré d'herbe. Ce n'est pas génial mais pas complètement faux. J'ai utilisé un autre outil, appelé « Clip Interogator », qu'on utilise pour écrire une invite pour générer de nouvelles images. Sa description : « un troupeau d'éléphants traversant un champ verdoyant ».

[Rires dans la salle]

Peinture matte plate dans le style du film Crude, inspirée par William Trost Richards, Meteor Impact. Ça continue et ça devient de pire en pire. On ne peut pas toujours faire confiance à ces outils d'automatisation pour faire ce que vous voulez.

Et maintenant, je vais passer à un autre sujet, car je m'en sers comme excuse pour ne pas tomber dans les escaliers. Cela me donne soif.

Ce passage en revue de 1.1.1 montre qu'il est difficile de satisfaire un critère de succès quand cela dépend complètement du contexte.

Examinons-en un où le défi ne vient pas du public, mais du critère de succès lui-même. Quand WCAG 2.0 est devenu une recommandation en 2008, ceci en faisait partie, ça fait longtemps que ça en fait partie. 2.4.7, visibilité du focus, niveau AA. Le texte officiel, le texte normatif est : « Toute interface utilisable au clavier comporte un mode de fonctionnement où le focus est visible. »

Ceci avait pour objectif de prendre en compte les personnes qui se perdent sur une page, en particulier, celles qui se servent d’un clavier ou d’une sorte de proxy pour un clavier. Mais que veut dire « visible »? Voici un bouton avant le focus clavier, à gauche, et à droite après le focus clavier.

Je pense que nous sommes tous d'accord pour dire que c'est visible, ça répond au critère : il est entouré de jaune, beaucoup de contraste par rapport au noir environnant, c'est lumineux. Cela semble assez clair. Je ne sais pas si vous voyez avec la projection. Cela semble très clair.

Le second exemple montre aussi un bouton avec un focus clavier, à droite. Ce n'est pas évident, pas autant que le précédent. Mais il satisfait au critère. Il a l'air presque identique à celui de gauche, ce n'est pas un style de focus très convaincant. Mais c'est validé.

Ce troisième exemple montre également un état de focus, sur le bouton à droite. Je ne sais pas si vous le voyez, mais il y a un changement de bordure, si je zoome dessus... [Rires dans la salle] Et je fais preuve de générosité en lui donnant autant de différence !

Ça passe aussi, parce que le critère 2.4.7 ne dit pas dans quelle mesure l’indicateur doit être visible. Un seul pixel aurait suffi, même si c'est affreux ! Si quelqu'un vient vous voir et vous dit : « j'ai fait un changement de 1 pixel », vous pouvez le gifler et venir me blâmer. [Rires dans la salle]

Je ne serai plus là quand la police viendra vous chercher !

D’accord, allons un peu plus loin. Je suis en train de développer un peu le thème.

Les WCAG 2.1 sont arrivées en 2018, soit une décennie plus tard. Et elles ont introduit un nouveau critère de succès pour combler cette lacune, le critère 1.4.11, Contraste du contenu non textuel, également de niveau AA.

Voici le texte normatif, la première partie sur laquelle je souhaite m’attarder. « La présentation visuelle des éléments suivants a un rapport de contraste d’au moins 3:1 avec la ou les couleurs adjacentes : »

Et je vais m’attarder sur cette première puce que j’ai mise en surbrillance, puisque ça marche pour l’exemple que j’utilise : « Composants d’interface utilisateur :
informations visuelles nécessaires à l’identification des composants et des états de l’interface utilisateur, à l’exception des composants inactifs ou lorsque l’apparence du composant est déterminée par l’agent utilisateur et non modifiée par l’auteur ». 

C'est beaucoup de lecture, je comprends.

On parlait d'un indicateur de focus visible. Cela parle d’états et le focus est un état. Donc c’est applicable ici. Voici le bouton dont on parlait à l'origine. C’est inversé, c’est en surbrillance, c’est jaune. Le rapport de contraste est de 19.6 pour 1 avec le noir. Ça passe, Ça passe, avec un ratio de plus de 9 par rapport au gris d'à côté. Par rapport au noir, on est très bien.

Ce deuxième exemple, avec l'ombre, ça passe, avec un rapport de contraste de 3,5 pour 1, ça passe tout juste tout juste !

Voici à nouveau notre troisième exemple. Il ne répond pas au critère de succès, il n'y a pas le critère du rapport de contraste de plus de 3 pour 1. Maintenant, si on augmente le contraste, on a quelque chose qui passe, qui a un rapport de contraste de 3 pour 1, par rapport à l’arrière-plan. 3 pour 1 est donc le strict minimum. Par contre, il n'y a pas le rapport de contraste par rapport à la bordure originale, ce qui veut dire qu’il n’a pas un rapport de contraste de 3 pour 1 par rapport à l’autre bouton de gauche. Mais cela ne concerne pas le critère 1.4.11. Le 1.4.11 ne regarde pas le contraste par rapport aux états mais par rapport à l’arrière-plan de la page. Et il est valide ici.

Maintenant, si on revient à notre auteur qui veut faire le strict minimum, ils ont fait en sorte qu'une toute petite partie du bouton ait un contraste suffisant. Ils peuvent indiquer qu’ils respectent le critère et ils n’utilisent pas un seul pixel. Cette bordure tout à droite suffit, ce n'est pas génial pour l'utilisateur, mais ça répond aux critères WCAG.

Au moment de cette présentation, WCAG 2.2 n'est pas encore sorti. Dans mon script de présentation, j’ai écrit que les WCAG 2.2 venaient de sortir. Je l'avais écrit il y a un mois, j’étais optimiste.

[Rire dans la salle]

Il y a un critère de succès pour régler cette lacune avec les 2 critères de succès que nous venons de traiter.

Malheureusement, il est au niveau AAA, comme vous pouvez le constater et comme nous allons le voir.

Le texte normatif utilise plus de mots, mais il est plus explicite :
« Lorsque l'indicateur du focus clavier est visible, une zone de l'indicateur focalisé répond à tous les critères suivants.»
Puis, il donne les deux exigences. Tout d’abord, il est au moins aussi large que la zone d'un périmètre de 2 pixels CSS d'épaisseur du composant ou sous composant sans focus. Amusant !

Ensuite, la seconde exigence est : a un rapport de contraste d'au moins 3 pour 1 entre les mêmes pixels dans les états en focus ou sans focus. Cool !
Alors, il y a une exception intégrée pour les navigateurs par défaut, ce qui signifie que si vous ne changez rien, vous obtenez une validation automatique du critère.
Ouais !

Mais l’idée est que ce nouveau critère de succès permet de combler deux lacunes dont nous avons parlé jusqu’à présent. Il y a, bien sûr, un inconvénient de taille, le critère 2.4.13, apparence du focus, est au niveau triple A, ce qui veut dire qu’il n’est requis par aucune loi, par aucune politique. Ça n’a même pas été encore finalisé et ça a déjà changé plusieurs fois depuis qu’il a été proposé. Je pense que celui-ci est assez stable, mais peu importe. Dans toute ma carrière, j'ai dû travailler sur trois projets qui voulaient le triple A. Et l’un d’entre eux l'a abandonné en cours de route.

Voilà à nouveau le bouton d'origine. Nous avons vu que le contraste est bon, mais il faut le comparer au même pixel, dans l'état sans focus. Il s’avère que la bordure et l’arrière-plan font tous deux l'affaire, donc c’est bon. Ce bouton est gagnant. Encore une fois, ce n'est peut-être pas joli, mais ça marche. Maintenant, il faut regarder la zone du focus, ce qui veut dire qu’il faut faire des maths. C'est une des raisons pour lesquelles ce critère de succès est passé en triple A. Puisque j’ai changé la couleur d’arrière-plan et qu’il y a un rapport de contraste de 9.1 pour 1 avec les pixels sans focus,, toute la zone compte, je n’ai pas à faire de maths ici. Je suis bon. C’est facile.

Ce deuxième exemple, qui répond également à 2.4.7 et 2.4.11 ne passe pas. L'ombre portée n'affecte qu'une rangée de pixels, ce qui m'oblige à faire quelques calculs. Je vais faire le calcul à haute voix pour vous. Je suis désolé, mais j'ai fait beaucoup d'efforts pour m'assurer que je ne me trompais pas dans les calculs.

Et je voudrais me vanter un peu, mais pas vraiment.

Le bouton est de 87 pixels sur 44. Il a une bordure d’un rayon de huit pixels. avec un périmètre de 249 pixels. Multiplié par deux, ça fait 518. Et nous devons nous assurer qu'au moins autant de pixels ont un rapport de contraste de 3 pour 1. Vous comprenez pourquoi on n’aime pas ce critère de succès ? Nous pouvons donc gérer cela en décalant notre ombre portée de quelques pixels.

Et lorsque je fais cela, ça passe. Là, j'ai simplement fait défiler l'ombre un petit peu vers le bas. C'était un rectangle arrondi, ce qui signifie que le calcul était assez simple. Vous avez une formule dans le document des techniques. Si le bouton est un cercle, une étoile, quelque chose d'irrégulier, c'est plus difficile.

Vous vous rappelez ce bouton affreux que je vous ai montré juste avant, il est valide aussi, parce que j'ai dessiné un contour autour, et j’ai fait en sorte qu’il y a pile le bon nombre de pixels pour avoir le triple A ! Souvenez-vous, triple A veut dire que personne ne va le faire.
Ok, critère 2.4.11.
WCAG 2.2 a une autre proposition de critère de succès qui arrive un peu de travers.
Je l’inclus parce que je pense que c’est pertinent.

Critère de succès 2.4.11, le focus n'est pas obscurci, minimum. Niveau double A. Il suppose que la visibilité du focus est traitée ailleurs. IL suppose juste que vous maîtrisez. Tout est sous contrôle, ce n’est pas la peine de s’inquiéter. Tout ce dont ce critère se préoccupe est que ça ne doit pas être totalement caché. Il y a une autre question : est-ce que l'indicateur du focus fait partie du composant ? La question se pose déjà. Après tout, le composant peut être masqué jusqu'à ce qu'il reçoive le focus. Maintenant, vous avez mis un dialogue au-dessus de vos boutons affreux, que nous avons vus précédemment. C’est le bouton qui passait à peine tout à l'heure. Si quelque chose comme une boîte de dialogue apparaît devant. Là, si c’est est complètement bloqué, il y a un problème. Et s'il y a un pixel visible, ça passe. Et j'ai été généreux en permettant qu’une colonne de pixels soit visible. Donc c’est valide.

Et maintenant, vous avez des échanges avec des personnes qui font des tests de conformité aux WCAG. Qu'est-ce que le focus ? N’est-ce pas ? C'est une question que vous ne voulez pas avoir à vous poser. Mais le problème est qu’on a jusqu’à présent quatre critères de succès qui le définissent de façons légèrement différentes. Le critère 2.4.7 parle de l’utilisabilité au clavier. Le critère 1.4.11 parle juste des composants d’interface utilisateur et d'états, mais pas explicitement de focus ou n’explique pas ce qu’est le Focus. Le critère 2.4.11 parle du focus clavier. Je vous mets au défi de le trouver, de le définir. Le critère 2.4.11 traite de quand le composant reçoit le focus clavier. Je pense donc que les personnes qui font des évaluations de conformité aux WCAG se posent beaucoup de questions concernant ce vocabulaire dont je viens de parler, mais également du vocabulaire qui vient des documents techniques. Et ils consultent même l’ACT, la norme de tests automatisés, pour voir si elle leur donne aussi des indices. Je note que le critère 2.4.13 reste en dehors de ce combat.

Pensez au lien d’évitement qui vous amène directement au premier en-tête de la page. Est-ce que les WCAG exigent que cet en-tête ait un état focusé, encore un plus un état de focus visible ? Est-ce que la destination utilisable au clavier, si je peux tabuler de cet élément jusqu'au prochain élément tabulable de la page ? Le fait d’avoir le focus et de faire défiler la page à une position donnée signifie-t-il qu’il s’agit d’un composant d'interface utilisateur ? WCAG est silencieux sur les cibles de liens, cela a posé un certain désarroi aux personnes avec qui je travaille. Qu'est-ce qu'on fait si la page met tout de suite le focus sur un dialogue qui a un rôle window si bien qu’il ne prend pas le focus sur lui-même ? WCAG ne dit rien sur le focus déterminé par un programme informatique. Encore une fois, cela dépend de la façon dont vous le lisez, des documents techniques, des arguments de la liste de diffusion que vous vous donnez la peine de lire.

C’est une conversation similaire autour des contrastes. Je fais exprès de lancer quelque chose de difficile. On sait tous que la formule des contrastes des WCAG n'est pas idéale, elle pourrait être améliorée. Par exemple, sur la couleur orange. Toute cette discussion est embrouillée par le texte normatif, officiel, et la façon dont la couleur est définie dans les documents techniques. C'est pourquoi certaines personnes ont très envie de voir l'algorithme de contrastes proposé dans WCAG 3, mais c'est encore en projet, on ne va pas en parler ici, même si c’est passionnant.

On passe beaucoup de temps à s’enliser dans les détails sur le focus traité par les WCAG, ou du moins, je viens de passer beaucoup de temps à en parler. Quand on décortique les textes officiels, cela fait apparaître des désaccords. Mais la couleur devrait être plus facile à comprendre, sauf que ce n'est pas le cas.

Le critère de succès 1.4.1, utilisation de la couleur, est de niveau A, tout le monde doit donc le respecter.

Le texte officiel dit :
« La couleur n’est pas utilisée comme la seule façon de véhiculer de l’information, d’indiquer une action, de solliciter une réponse ou de distinguer un élément visuel. »
Ça peut être relativement simple à faire. Dessiner des bordures, ajouter des icônes, espacer un élément pour que la mise en page montre qu'il est différent du reste, tout cela ne repose pas uniquement sur la couleur. Vous êtes Bons. Le soulignement est le moyen le plus simple d'indiquer un lien, par exemple. C’est souligné, Ici, c'est clair, on voit clairement qu’il y a un lien. Mais certains auteurs trouvent que le soulignement crée trop d'encombrement visuel. Je pense qu'ils ont tort. D'après mon expérience, le gras est une solution de repli couramment utilisée par de nombreux concepteurs, que je présente dans ce paragraphe. Le problème, c'est que vous ne pouvez jamais utiliser de texte en gras dans votre texte narratif, où que ce soit, ce qui limite votre marge de manœuvre.

Le critère 1.4.1 a une technique suffisante, la G183 qui parle du rapport de contraste et l'exprime sous la forme d'une luminance relative. Il s'agit donc maintenant de redéfinir un peu ce qu'est le contraste. C'est dans un document technique, le document comprendre les WCAG, pas dans un texte officiel. Le problème est que cette technique ne fonctionnerait jamais pour les personnes utilisant un appareil tactile ou uniquement le clavier, car elle comporte un qualificatif d'état de survol. Si vous utilisez juste le tactile ou vous tabulez à l’aide de votre clavier, il n’y a pas d’état de survol. Il y a un focus ou non. La technique G183 définit la couleur comme une combinaison de teintes de saturation et de luminance. Mais F73, qui est une technique d’échec, modifie un peu cette définition. Par exemple, il est dit que le rouge et le rose sont de la même couleur, la teinte, mais qu'ils ont une luminosité différente, ce qui n'est pas une couleur. Ainsi, le rouge et le rose répondraient à l'exigence de ne pas être distingués uniquement par la teinte puisqu'ils diffèrent par la luminosité, ce qui n'est pas une couleur, pour autant que la différence de contraste de luminosité soit de trois pour un ou plus. Nous avons donc un document technique qui contient un grand nombre de déclarations parenthétiques pour tenter de réduire la confusion qu'il crée en redéfinissant la couleur différemment d'un autre document technique.

C'est un défi que je rencontre régulièrement avec les personnes qui testent WCAG.

Ce lien est valide. Il a un rapport de contraste de 3.1 par rapport au texte environnant. Est-ce qu’il y a quelqu'un qui ne peut pas voir le lien dans ce paragraphe ? OK.
C'est le cas si vous êtes au fond de la salle.

Prenons les choses à l’envers.

Là, il y a également un lien. Mais il n'y a pas d'élément souligné, pas d'autre indice visuel. Il est également de la même couleur que le texte environnant. Mais ce lien n'échoue pas au critère de succès.

C’est pas cool, les WCAG ?

Ça n'échoue, mais ne passe pas non plus. Ce critère de succès ne s'applique pas car il n'y a pas de changement de couleur. Ça craint pour tout le monde. Il n'entre pas dans le champ d'application des WCAG. [Rires dans la salle]

1.4.10, redistribution. C’est mon dernier exemple. J'espère que vous êtes toutes et tous encore attentifs.

Le critère 1.4.10, redistribution, a été introduit dans les WCAG 2.1. Il a pour objectif de traiter l’utilisation des appareils mobiles, puisque le mobile n'existait pas quand les WCAG ont été publiées.

Voici le texte :
« Le contenu peut être présenté sans perte d’information ou de fonctionnalité et sans nécessité de défilement dans les deux dimensions pour un contenu à défilement vertical avec une largeur équivalente à 320 pixels CSS. Un contenu à défilement horizontal avec une hauteur équivalente à 256 pixels CSS. Il y a une exception. pour les parties du contenu dont l’utilisation ou la compréhension nécessite une mise en page en deux dimensions.
Voici l’exception. Je vais me concentrer sur ce point pour illustrer le problème.

Le tableau est un exemple simple. Les lignes et les colonnes sont des contenus bidimensionnels. On a besoin de cela pour que le contenu ait du sens. C'est une bonne chose si vous essayez d'utiliser des propriétés d'affichage. Ça va tout perturber sur Safari. C'est super Safari.

Dans mon exemple il y a une barre de défilement en bas du tableau. La fenêtre, ce faux port de visualisation que j'ai mis en place à l'aide des outils de développement de Firefox, affiche une fenêtre de 320 par 256.

Ainsi, le tableau défile de gauche à droite et seulement le tableau. Ça fait exactement ce que nous voulons. Le problème avec le critère de succès est le texte où il est dit équivalent à 320 pixels ou équivalent à 256 pixels, parce qu'il ne s'agit pas de la largeur ou de la hauteur jusqu'à ces valeurs.

Il s'agit strictement de ces valeurs, exactement de ces valeurs.

Quand je fais pivoter mon appareil, le critère de succès ne s'applique plus et c’est très bien.

Le critère de succès est non applicable, il est ni validé ni invalidé. Il n’est juste plus applicable.

Ce qui se passe, c'est que le tableau ne défile plus tout seul et qu’il fait défiler toute la page.

Maintenant, vous pourriez trouver un auteur particulièrement mal intentionné qui écrive ce genre de CSS. Il s'agit d'une requête media querry qui recherche un port d'affichage d’exactement 320 x 256 pixels. Exactement. Et il permet de faire défiler le conteneur du tableau. Pour toute autre dimension, en revanche, il ne serait pas validé. Voilà l’exemple avec 321 pixels mais encore à 256. Et le voilà à 257 pixels. WCAG permet cela. Je crois que ça n'était pas le but recherché. Mais ce sont les lacunes dont je voulais parler.
Oh, j'ai un autre exemple.

Taille de la cible minimum. 2.5.8. C'est introduit dans les WCAG 2.2. On le lit comme suit : la taille de la cible pour les pointeurs d’entrée est d'au moins 24 par 24 pixels CSS. Et il fait la liste des exceptions.

Je m’attarde sur une seule exception, l’exception concernant l’espacement.

Toutes les cibles, les cibles de taille inférieure à 24 pixels sont positionnées de telle sorte que si un cercle de 24 pixels de diamètre est centré sur la boîte de délimitation de chacune d'elles, les cercles n'intersectent pas une autre cible ou le cercle d'une autre cible de taille inférieure à 24 pixels. Hum, cela montre qu’il y a une lacune. C’est bien ça dans WCAG 2.2, c’est que les gens l’ont battu en brèche.

Ils disent même, dans le document, « comprendre les WCAG », qu’il est toujours possible d’avoir une très petite cible, difficile à activer, et satisfaire aux exigences de ce critère de succès à condition qu'il n'y ait pas de cibles adjacentes trop proches.

C'est donc une bonne chose. On reconnaît qu'il y a des limites. Mais ça veut dire aussi que le critère est validé.

C'est une boîte de dialogue me demandant de m’inscrire à une lettre d'information. Vous en avez probablement vu quelques-unes en surfant sur le web.

Le bouton de fermeture, dans le coin en haut à droite, est tout à fait légitime. Je ne sais pas s’il y a un bouton pour fermer. Croyez-moi ! Ça n'est pas superposé à d'autres contrôles. C’est bien. [Rires dans la salle]

J'ai zoomé pour que vous puissiez le voir.

Voilà, c'est ce qu'on ressent, quand on cherche à fermer ces boîtes de dialogue sur le web.

On y est, avec des développeurs sur un sol boueux, qui travaillent sur leurs ordinateurs portables. Ils sont bloqués. [Rires]

J'aime à penser que les choses que j'ai démontrées jusqu'à présent montrent à quel point il est facile d’être bloqués à partir d'une poignée de critères de succès. On est perdus, bloqués. À nouveau, ce n'est pas une liste exhaustive. La difficulté est de reconnaître quand quelqu'un comprend mal les WCAG, face à ceux qui s'en servent comme arme, qui s'en servent comme des abrutis, pour ne faire que le strict minimum, et il y a plein de gens qui veulent faire le strict minimum, qui peuvent être mécontents de devoir faire quoi que ce soit. Certains testeurs veulent invalider le plus de choses possibles. Ils sont à l'affût de la moindre petite infraction potentielle afin de la vendre comme un échec lors d'un audit WCAG.

Il y a de nombreuses motivations différentes, il est difficile de se mettre d’accord au sein d’une équipe. Sans parler des relations avec les parties prenantes, les clients et les fournisseurs. C’est difficile de se mettre d’accord sur ce qui est un échec, sur ce que vous devez faire pour vous conformer aux WCAG. Sans parler de l'accord avec les avocats. Et je dois souvent dialoguer avec les avocats, ce n'est pas évident. Je tiens à vous rappeler que ce qui ne fonctionne pas pour tout le monde est en-dehors du champ d’application des WCAG. Et c'est là que les gens se trompent vraiment.

Pensez à ce lien que je vous ai montré juste avant, qui était de la même couleur que le texte environnant. Cela n'a pas d'importance pour les WCAG. C’est juste une idée terrible.

On voit ici une développeuse qui est adossée à un tas de boue, tout en travaillant sur son ordinateur portable. Elle vous regarde, elle attend que vous lui donniez la réponse.

Je me tourne vers vous, le public, qu'est-ce que vous pouvez faire ?

Je vais aborder certaines des choses que nous pouvons faire.

Je pense que j'ai assez parlé des WCAG.

Je pense que nous sommes tous d'accord.

Il y a des défis qui s'offrent à nous. J'espère que si vous êtes là, c'est parce que vous voulez résoudre des problèmes, vous et votre équipe. Pour cela, il suffit d’écrire. Vous n'avez pas besoin d'être très doués pour l'écriture, vous pouvez être mauvais. Mais il est important d'avoir un document écrit avec des exemples, des lignes directrices internes, des normes. Ça peut être de l'interprétation, une compréhension des WCAG qui a été convenue, une simplification de la langue. Donner des exemples précis en soulignant les exceptions, définir ce qui échoue et pourquoi.

Donc la première étape est de tout documenter. Expliquer ce qui peut prêter à confusion dans les WCAG, pour vous, votre équipe, vos clients, vos commerciaux, vos avocats. Suivez ces cas particuliers.

Suivez ces désaccords. Indiquez les références dans les WCAG même, les documents de compréhension des WCAG. Les discussions sur le Github du W3C. Consultez la liste de diffusion du W3C et voyez où les gens se disputent sur ces questions.

Ouvrez des tickets sur les WCAG elles-mêmes. Même si vous vous contentez de poser des questions, postez quelque chose, documentez-le. Cela vous protègera également par la suite. Et tout ce que vous pourrez rassembler devrait être accessible à l'équipe, l’ensemble des équipes, les clients, les commerciaux. Ils ont besoin d’y accéder. Et la façon dont vous l'organisez dépend des outils que vous utilisez, la façon dont vos équipes sont réparties, et je ne vais pas parler du tout de cela.
N'oubliez pas que les WCAG définissent souvent certains mots ou idées. Vous devrez peut-être les réécrire, de préférence dans votre langue maternelle, les WCAG ne sont pas traduites dans toutes les langues. Vous pouvez l'adapter à votre jargon interne. Vous pouvez avoir des noms différents pour les modèles ou les concepts. Définissez le nom des contrôles, des widgets et des modèles. Par exemple, n'appelez pas tout ce qui s'affiche ou se masque un menu déroulant. N’appelez pas tout ce qui se met au-dessus d'un autre contenu un « Pop Up ».

Il me semble que Hidde va parler de cela un peu plus tard, de toute façon. Utilisez les termes des WCAG issus du HTML ou d’ARIA, et définissez ce qu’est un menu ARIA par opposition à un widget disclosure (afficher/masquer). Et clarifiez quand ceux-ci sont circulaires. Quand je dis de normaliser, c'est le titre de la diapo, je parle des normes et des pratiques, la normalisation des tests, en veillant à ce que les gens testent les choses de la même manière, avec les mêmes outils, les mêmes méthodes, les mêmes tactiques. Ayez de la documentation sur l'interprétation des WCAG avec le vocabulaire que vous utilisez. Si vous avez vos propres normes internes, vous pouvez les structurer de manière cohérente, afin de faciliter tout cela. avec des règles de tests cohérentes, et des règles plus explicites pour valider ou invalider, j’espère que la procédure sera un peu simplifiée.

Votre définition de ce qui est fait en interne doit inclure l'accessibilité et cela fait partie de la façon dont vous la normalisez ou la promouvez dans votre organisation.
Il faut, si possible, construire des exemples qui doivent refléter le scénario idéal pour chaque modèle conforme au critère de succès. Ils doivent également refléter les cas particuliers, ceux qui ne se présentent pas souvent mais qui causent des frustrations lorsqu'ils se présentent. Et cela peut être les cas les plus graves ou extrêmes. Pas toujours, mais construisez-en quelques-uns pour savoir à quoi ressemblent les pires scénarios. Trouvez un équilibre entre les exemples minimaux et les exemples complexes, les exemples d'utilisation et les exemples autonomes. Parfois, un problème n'est pas clair tant qu'il n'est pas mis sur une page avec un autre contenu. Vous pouvez peut-être voir comment les gens les utilisent.

Les WCAG ont des lacunes, certaines sont dues à la confusion, d’autres à leurs limites. Dans votre organisation, réfléchissez à la possibilité d’étendre la portée des WCAG afin de combler certaines de ces lacunes.

Encore une fois, le lien qui a la même couleur que le texte environnant n’est pas non conforme aux WCAG. Faites-en peut-être une règle interne. Une partie de vos propres standards internes d’accessibilité vont au-delà de ce que les WCAG disent de faire. Cela fonctionne seulement si vous avez le soutien des échelons supérieurs de votre organisation, de vos chefs.

Mais la confusion qui règne dans les WCAG peut peut-être vous aider à défendre votre cause auprès d'eux. Il s'agit d'un travail d'équipe, bien sûr. Le bourbier des WCAG existera toujours. Mais nous devons accepter que nous pouvons nous enliser en tant qu'individu, qu'équipe, mais on peut s'entraider. Et cela inclut la construction de ponts pour nous-mêmes, nos équipes et nos clients. Je travaille cette métaphore vraiment, vraiment autant que possible.

Comme le montre cette image, on voit un groupe de développeurs assemblant des passerelles en bois sur les parties les plus boueuses du bourbier.

J’ai quelques références de liens à la fin qui sont sur le PDF. Patrick Lauke a une conférence plus complète sur la confusion que peuvent créer les WCAG. Il en fera une plus à jour dans quelques semaines à Toronto. Je me réjouis de vous y voir toutes et tous. Je crois qu’il reste des places.

Et je liste des sites du W3C où vous pouvez trouver plus d’informations.
Merci pour votre attention pour la présentation.