Conformité et accessibilité, l’amour vache (a11y)

Au commencement était le pourcentage

Lors d’une conférence que nous avons faite récemment à Paris Web1 avec Olivier Keul, nous évoquions l’importance parfois démesurée que pouvait prendre le pourcentage de conformité aux WCAG (Web Content Accessibility Guidelines) aux yeux de certains professionnels du Web.

Encore beaucoup de personnes le voient comme le Graal ; le sceau du 100 % comme unique objectif à atteindre. Une sorte de pompon à attraper sur le manège de l’accessibilité qui, une fois en main, garantirait une accessibilité totale, pour une durée indéterminée et surtout, les protégerait juridiquement contre toute menace de procès aux États-Unis.

La conformité aux WCAG comme seule appréciation de l’accessibilité

La conformité aux WCAG est-elle un bon indice de l’accessibilité d’un site ?
Est-elle le seul KPI (Key Performance Indicator ou indicateur clé de performance) qui reflète le niveau d’accessibilité du site audité ?

Est-ce qu’entreprendre une démarche de mise en conformité aux WCAG est suffisant pour garantir l’accès à l’information et aux fonctionnalités de votre site aux personnes handicapées, et pour les grands groupes concernés, mettre un arrêt aux menaces de procès et aux transactions qui en découlent ?

Essayons de voir comment nous pouvons utiliser au mieux les WCAG, ses forces et ses faiblesses, pour atteindre l’objectif qui devrait être celui de nous tous : rendre les sites consultables et utilisables à tout le monde.

L’audit de conformité

Rappelons pour commencer ce qu’est un audit de conformité : une mesure du respect de l’adhésion à des règles d’un référentiel, sur un nombre défini de pages, à un instant T.

Le référentiel dont il sera question tout au long de cet article sont les WCAG 2.1 au niveau AA (en anglais) et petite précision, quand il est dit « sites », cela englobe les sites web et les applications natives.

Cet audit est donc réalisé par une ou plusieurs personnes, souvent avec l’aide de certains outils automatisés pour gagner du temps mais la grande majorité des vérifications ne sont pas automatisables et sont donc manuelles.
Or l’interprétation de certains critères des WCAG ou de leurs tests peut également varier selon les personnes qui réalisent l’audit.

Enfin, le mode de calcul du pourcentage de conformité n’étant pas normalisé à ce jour dans les WCAG, il est possible d’avoir à partir d’une même évaluation des indicateurs de conformité différents en fonction du mode de calcul.

Bref vous l’aurez compris, un même site n’aura pas exactement le même taux de conformité selon que l’audit sera réalisé par deux cabinets différents, voire même deux personnes différentes dans un même cabinet.

Mais alors, l’accessibilité c’est quoi ?

Quand on parle d’accessibilité d’un site ou d’accessibilité web, il faut généralement comprendre « l’utilisabilité pour certaines personnes handicapées » de ce site.

Il existe une infinité de situations de handicap faites de déficiences (cognitives, motrices, sensorielles), d’expériences et d’habitudes personnelles, de solutions matérielles et logicielles (les technologies d’assistance ou TA) avec des paramétrages différents. Ces situations de handicap peuvent être permanentes, évolutives ou temporaires.

Nous allons donc nous intéresser principalement aux usages et trouver des solutions pour lever les freins que peuvent rencontrer certaines personnes handicapées afin de leur permettre d’accéder comme tout le monde aux contenus et aux fonctionnalités d’un site.

Reste un malentendu pour certaines personnes : il n’existe pas aujourd’hui une note, un score ou même une certification qui garantirait l’accessibilité à 100 % d’un site. Et parce qu’il y a une infinité d’usages due à tous ces paramètres que nous venons d’évoquer, une accessibilité à 100 % n’existe tout simplement pas. On prend souvent l’exemple du site « 100 % sécurisé » qu’aucun expert en sécurité ne se risquerait de garantir.

Il est toutefois possible de mesurer l’effort qui a été fait pour qu’un site respecte les critères des WCAG : c’est le pourcentage de conformité qui sera produit à l’issue d’un audit de conformité. Il est bon de rappeler qu’un audit est effectué sur un échantillon de pages (donc pas sur la totalité du site) et à un instant T, ce qui veut dire qu’à la prochaine mise à jour ou nouvelle contribution, ce pourcentage peut ne plus être le même.

Mais cela ne garantira pas que le site soit parfois difficile, voire impossible à consulter par des personnes handicapées dans certains contextes. Ces points bloquants ou même très gênants peuvent être dus à une application stricto-sensu des critères de succès des WCAG sans considération pour l’expérience utilisateur (UX) des usagers, mais aussi à des problèmes purement d’UX, rédactionnels ou de performances.

Avant de regarder certains points de conformité qui posent des problèmes d’accessibilité, une précision encore sur la conformité aux WCAG.

La conformité aux WCAG et la loi américaine

À ma connaissance, il n’y a jamais eu de procès aux États-Unis (ou même une seule transaction) due à une non-conformité aux WCAG.

C’est sur une base de discrimination (qui tombe sous le coup du Americans with Disabilities Act (en anglais) ou ADA) due à une accessibilité insuffisante ou inexistante d’un site que naissent les litiges.

Et pour cause, aux États-Unis la loi ne pénalise pas la non-conformité aux WCAG. C’est l’inaccessibilité ou plus particulièrement l’incompatibilité des sites avec les technologies d’assistance qui est le déclencheur des procédures aux États-Unis2.

En : « For private businesses, the answer is […]: they’re not required by law to comply with any specific standard like WCAG, but their websites do have to be accessible. »

Fr : « Pour les entreprises privées, la réponse est […] : elles ne sont pas tenues par la loi de se conformer à des normes spécifiques comme les WCAG, mais leurs sites web doivent être accessibles. »

Source : Is There a Legal Requirement to Implement WCAG? (en anglais)

Dans les faits, ce sont les tribunaux qui recommandent aux sites privés de suivre les recommandations des WCAG au niveau AA.

En : « While the DOJ’s current position leaves organizations with some flexibility on how they will make their websites accessible, the practical result is the same for most organizations: the best strategy for building a website accessible to everyone—and for avoiding a lawsuit—is to ensure it complies with WCAG (2.x) AA success criteria. »

Fr : « Bien que la position actuelle du Department of Justice [Ministère de la Justice] laisse aux entreprises une certaine flexibilité sur la façon dont elles doivent rendre leurs sites web accessibles, dans les faits le résultat est le même pour la plupart d’entre elles : la meilleure stratégie pour créer un site web accessible à tous – et pour éviter un procès – est de s’assurer qu’il soit conforme aux […] WCAG (2.x) AA. »

Source : DOJ Reaffirms Position that ADA Applies to Websites (en anglais)

En : « WCAG 2.0 and its successor, WCAG 2.1, are consistently identified and upheld as providing an acceptable level of accessibility, cited by plaintiffs and in rulings. This means that while the ADA doesn’t yet specify WCAG as a formal standard under the law, the courts are upholding that compliance with WCAG provides reasonable accessibility. »

Fr : « Les WCAG 2.0 et leur version mise à jour WCAG 2.1 sont systématiquement citées et confirmées comme offrant un niveau d’accessibilité acceptable par les plaignants et lors des décisions de justice. Cela signifie que même si l’ADA ne spécifie pas encore les WCAG comme norme officielle en vertu de la loi, les tribunaux soutiennent que le respect des WCAG offre une accessibilité raisonnable. »

Source : Is There a Legal Requirement to Implement WCAG? (en anglais)

Il est intéressant toutefois de noter que les manquements d’accessibilité évoqués (quand ils sont publiés3) n’existeraient pas dans l’immense majorité des cas s’il y avait eu une démarche de mise en conformité aux WCAG. Suivre les recommandations des WCAG au niveau AA aurait réduit considérablement les risques de procès, c’est incontestable.

Mais nous sommes (presque tous) d’accords sur un point : ça n’est pas la conformité que nous visons mais bien l’accessibilité maximum d’un site.

Les WCAG, un outil imparfait

Pour obtenir l’accessibilité maximum d’un site, c’est déjà une conformité à 100 % au niveau AAA qui devrait être visée. Or c’est le niveau AA qui est recommandé par le W3C et qui a été celui retenu par la grande majorité des pays qui ont souhaité légiférer sur l’accessibilité numérique.

Alors sans trop rentrer dans les détails techniques, regardons juste quelques cas qui sont conformes aux WCAG 2.1 niveau AA et qui pourtant présentent des problèmes d’accessibilité.

  1. Ce qui me semble être la plus grosse absurdité (ou trou dans la raquette) des WCAG aujourd’hui, c’est qu’en contradiction directe avec le critère de succès 1.4.1 Use of color (en anglais) qui exige qu’une information, une fonction ou un état ne soit pas communiqué exclusivement avec une couleur, la technique (solution facultative qui rend un critère conforme) G183 (en anglais) permet justement d’utiliser une couleur pour différencier un lien dans du texte, sous certaines conditions de contraste.
    Voici des exemples conformes aux WCAG 2.1 AA (en anglais) que je vous invite à tester si vous êtes daltonienne ou daltonien, ou connaissez une personne qui l’est. Je l’ai fait à plusieurs reprises, c’est édifiant et pour preuve, au sein même des personnes qui contribuent aux WCAG, les avis sont très tranchés sur cette tolérance4.
  2. Des liens peuvent ne pas être pas suffisamment explicites (plusieurs « En savoir plus » par ex.) dans un page, cela reste conforme au niveau AA (et même A) quand leur « contexte » est spécifique 2.4.4 Link Purpose (In Context) (en anglais). C’est une exigence de niveau AAA que les liens soient explicites hors contexte 2.4.9: Link Purpose (Link Only) (en anglais). Or pour une personne qui utilise un lecteur d’écran et qui navigue de lien en lien ou via la liste des liens, cela nécessite une certaine gymnastique pour les comprendre5. Accessoirement, pour les voyants, malvoyants et personnes utilisant une loupe/zoom écran sans synthèse vocale, le problème reste le même mais la gymnastique est visuelle.
  3. Des boutons ou éléments d’interface qui sont désactivés (avec un attribut HTML disabled (en anglais)) ne prennent pas le focus à la tabulation (ils restent toutefois vocalisés en lecture linéaire/browse mode avec un lecteur d’écran). De plus, ils n’ont pas à être suffisamment contrastés pour être conformes. Là encore, tout le monde n’est pas complètement satisfait de cette exception au sein des rédacteurs des WCAG6 car dans le cas d’un bouton de soumission de formulaire désactivé par ex., certains utilisateurs aveugles ne comprennent pas pourquoi ils ne trouvent pas de bouton. Par ailleurs, du fait de son contraste souvent très faible, certains utilisateurs peuvent ne pas (ou mal) le percevoir.
  4. Quand des contrastes sont insuffisants sur un site, au lieu de modifier les couleurs qui posent problème, proposer une solution de style switcher (ou sélecteur de styles) qui modifiera certaines couleurs, atteignable par exemple via un bouton avec un pictogramme « œil barré » représentant la déficience visuelle, d’un ratio de contraste de 3 et avec un nom accessible7 uniquement exposé aux TA reste conforme. Technique C29 (en anglais).
    Par ex. :
    Pictogramme de la déficience visuelle.Cette solution ne rend pas un site accessible. C’est une rustine pour gagner quelques points de conformité qui amène plusieurs problèmes : les utilisateurs, à commencer par les premières personnes concernées, peuvent complètement passer à côté de cette fonctionnalité (ne pas percevoir le pictogramme ou ne pas le comprendre). De plus c’est une solution coûteuse à implémenter, qu’il faut maintenir. Faire un vrai travail de fond sur une charte de couleur ou un design système est la solution à privilégier, dans l’intérêt de tous.
  5. Concernant la visibilité du focus lors de la tabulation, il est conforme de laisser l’état de focus natif des navigateurs : technique G149 (en anglais). Or celui-ci diffère d’un navigateur à un autre et il est parfois à peine perceptible voire invisible dans certaines situations comme expliqué dans cet article « Avoid default browser focus styles » (en anglais). À noter que pour un champ de saisie de formulaire, la barre verticale clignotante du curseur est considérée suffisante pour être conforme.
  6. Le critère de succès 1.4.4 Resize text (en anglais) exige que le texte d’une page puisse être agrandi (redimensionné) jusqu’à 200 % sans avoir à utiliser une TA, sans qu’il n’y ait de perte de contenu ou de fonctionnalité. Mais il n’est nulle part exprimé que ce soit un agrandissement exclusivement du texte qui soit conforme ; cela peut être réalisé via le zoom graphique natif d’un navigateur. Or il y a des utilisateurs qui utilisent le grossissement de texte sur desktop comme sur mobile via un paramétrage du navigateur, du système d’exploitation, les deux ou qui cumulent agrandissement de texte et zoom graphique.
    Un utilisateur pourra donc se trouver face à une page dont le texte uniquement est agrandi à 200 % avec du contenu manquant ou rogné, cela restera conforme tant que lors du zoom graphique, aucun contenu ni fonctionnalité ne sera manquant.
  7. L’utilisation exclusivement de l’attribut title pour fournir un nom accessible visible reste conforme à ce jour. Pourtant si l’on ne prend que l’exemple d’un champ de formulaire, un libellé qui ne sera pas tout le temps visible pour tout le monde ne peut pas être considéré comme une solution acceptable. Les personnes utilisant une loupe/zoom écran ne verront que partiellement le tooltip natif de l’attribut title et celles utilisant un écran tactile ou naviguant au clavier ne le verront jamais (sauf avec IE10, IE11 ou Edge).
    Les cas où son utilisation est déconseillée et les rares cas où elle peut être utile sont expliqués en détail dans « Using the HTML title attribute – updated » (en anglais) de Steve Faulkner (The Paciello Group – @stevefaulkner) et plus récemment « The trials and tribulations of the title attribute » (en anglais) de Scott O’Hara (The Paciello Group – @scottohara).
  8. Etc.

Arrêtons-nous là mais la liste continue. Si vous souhaitez creuser un peu certains des problèmes que nous venons d’évoquer ici avec des exemples et des pistes de solutions, je vous invite à lire cet article « Taking Accessibility Beyond Compliance » (en anglais) de Dennis Deacon (The Paciello Group – @deconspray), qui rappelle que

En : « Default compliance does not necessarily equate to accessibility. However, accessible designs, code and content will always be compliant, while serving the greatest number of people with varying abilities. »

Fr : « La conformité par défaut n’équivaut pas nécessairement à l’accessibilité. Cependant un design, du code et du contenu accessibles seront toujours conformes, tout en servant le plus grand nombre de personnes, handicapées ou non. »

L’avis de quelques experts sur les WCAG

Voyons justement ce que disent certains experts de l’accessibilité sur ce gap entre conformité et accessibilité. À noter que non-seulement ils utilisent les WCAG au quotidien comme beaucoup d’entre nous mais certains prennent également part à sa rédaction (en anglais).

Karl Groves (Tenon – @karlgroves) disait encore récemment

En : « WCAG (compliance) itself is not the destination, it’s a roadmap »

Fr : « (La conformité aux) WCAG n’est pas une fin en soi (la destination) mais une feuille de route »

Et il rappelle juste après cette remarque du W3C dans « WCAG 2.0 Layers of Guidance (en anglais) » où il est dit

En : « Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas… »

Fr : « Notez que même un contenu qui est conforme au niveau le plus haut (AAA) ne sera pas accessible à toutes les personnes de tout type, niveau ou combinaison de handicaps, plus particulièrement ceux du domaine cognitif de la parole et de l’apprentissage… »

Source : vidéo YouTube « Bad Standards and Worse Practices » (en anglais)

Depuis que cela a été écrit, 17 nouveaux critères de succès (12 au niveau AA) ont été rajoutés aux WCAG8. Ils adressent certains points problématiques pour les utilisations en contexte mobile et pour les personnes ayant des troubles cognitifs ou visuels, mais cette remarque reste vraie.

Alastair Campbell (Nomensa, co-rédacteur des WCAG – @alastc)

En : « If you only consider guidelines, you are getting a very skewed view – you have to consider the UX for people with disabilities. »

Fr : « Si vous ne prenez en compte que les (WCAG), vous n’aurez qu’une vision biaisée (incomplète) – vous devez prendre en compte l’expérience utilisateur des personnes handicapées. »

Toujours dans le même article :

En : « They are not the silver bullet though; you need to use general user-centred design processes to create an effective product for everyone and use the accessibility guidelines to make it a robust interface. »

Fr : « Elles (les WCAG) ne sont pas la solution miracle, vous devez utiliser des principes de design centré-utilisateur pour concevoir un produit efficace pour tout le monde et utiliser (les WCAG) pour en faire une interface robuste. »

Source : « Web accessibility guidelines and how to use them » (en anglais)

David MacDonald (CanAdapt, co-rédacteur des WCAG – @davidmacd)

En : « Standards take time, accuracy, attention to detail, and ***Consensus*** … with all its faults, #WCAG has those things. »

Fr : « (Écrire) des standards demande du temps, de la précision, de l’attention au détail et ***du consensus*** … avec tous leurs défauts, les #WCAG ont tout cela. »

Source : tweet du 16 oct. 2019 (en anglais)

David MacDonald est un des vétérans de l’accessibilité numérique et a écrit un très bon article sur la difficulté de rédiger des critères de succès WCAG : « What are WCAG Success Criteria? » (en anglais)

Patrick H. Lauke (The Paciello Group, co-rédacteur des WCAG – @patrick_h_lauke)

En : « WCAG is supposed to give us a reasonably objective way of saying whether or not the sites we are building/auditing are “accessible” (to a particular baseline). However, they are only as useful as our understanding and interpretation of the actual guidelines’ normative text. And of course they’re not perfect – with some omissions, handwaving, and straight up loopholes. »

Fr : « Les WCAG sont censées nous donner une indication relativement objective de l’“accessibilité” (à un référentiel précis) des sites que nous construisons/auditons. Néanmoins leur utilité est limitée à la compréhension et à l’interprétation que l’on fait (des textes normatifs) de leurs règles. Et bien sûr, elles ne sont pas parfaites – avec des omissions, des tours de passe-passe et des trous dans la raquette. »

Source : présentation de sa conférence « These Aren’t The SCs You’re Looking For… » (en anglais) qui contient le lien de la présentation en elle-même avec à la fin (slides 85 à 90), de nombreux cas de questionnement et de manquements dans les WCAG.

Balek (Bien Audité mais L’Est Kaput)

Tout cela illustre un point qui a déjà été évoqué : une démarche qui ne consiste à faire qu’un audit de conformité qui sera livré à un client sans accompagnement est inutile. Sachant qu’aucun site ne sera conforme à 100 % par hasard, il y aura toujours une démarche à entreprendre pour rendre le site conforme aux WCAG et au-delà9. Il faudra également s’assurer que le niveau d’accessibilité atteint est maintenu tout au long de la vie du site.

Un audit de conformité est un outil utile et indispensable s’il est suivi d’un accompagnement qui apportera :

  • une analyse et une interprétation expertes des problèmes,
  • ainsi que des recommandations allant parfois au-delà de la conformité, qui seront remontées de façon claires et pragmatiques.

Il servira également, lorsqu’un effort conséquent de mise en accessibilité a été fait, à évaluer la progression du travail effectué mais il ne doit pas être la seule mesure utilisée pour qualifier la démarche.

Conclusion

  • Il faut être conforme aux WCAG mais c’est insuffisant. Il faut faire plus pour rendre un site vraiment accessible au plus grand nombre (suivre certains critères AAA, prendre en compte l’UX, le rédactionnel, etc.) et par conséquent, voir les risques de litiges se réduire considérablement.
  • Il y a des bonnes pratiques, certaines hors conformité, qui peuvent être appliquées. Vous en trouverez par exemple dans ce fil Twitter que j’ai publié pour les 20 ans des WCAG il y a peu.
  • Il est impératif de faire des tests utilisateurs avec des personnes handicapées, ce qui ne vous empêche pas au préalable de naviguer dans votre site uniquement au clavier ou avec un lecteur d’écran pour relever certains points problématiques facilement corrigibles (quick wins).
  • Il faut accompagner le client pour la montée en compétence de tous les membres de l’équipe qui travaillent sur le site, des décideurs aux contributeurs, et les aider à mettre en place des processus qui leur permettront de maintenir ce niveau d’accessibilité.

Notes complémentaires

  1. Vidéo « Y’a pas qu’le ALT dans la vie — Déployer l’accessibilité web à grande échelle » par Olivier Keul et Arnaud Delafosse, Paris Web 2019.
  2. À noter que le nombre de procédures explose depuis 2018 aux États-Unis comme on peut le voir dans le ADA Web accessibility and app lawsuit recap report for 2019 (en anglais).
  3. « …the website had denied equal access to the blind and visually impaired because the website was incompatible with certain screen reader programs […] certain barriers […]: (1) buttons on (XYZ)’s website lacked descriptions necessary for certain screen reader software to analyze, and (2) error messages provided insufficient information. »
    Source : Website ADA Lawsuits and Personal Jurisdiction (en anglais).
  4. Voir la discussion « Technique G183 […] provide loophole resulting in inaccessible content » (en anglais).
  5. Voir l’article de Sylvie Duchateau « Lire les informations de contexte d’un lien avec un lecteur d’écran ».
  6. Voir la discussion « Greyed out submit buttons (conditional upon successful form completion) » (en anglais).
  7. Voir l’article des recommandations accessibilité Orange pour le Web « Le nom accessible en HTML ».
  8. Voir l’article d’Empreinte Digitale « Comprendre les WCAG 2.1 ».
  9. Voir la vidéo de la conférence « Vers l’infini et au delà des référentiels » par Éric Gateau et Aurélien Levy, Paris Web 2016 – (Aurélien Levy sur Twitter :@goetsu).

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter : la personne qui a écrit l'article, les autres participant(e)s à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.