Chez Liberogic, nous travaillons continuellement à l'amélioration de l'accessibilité web. Nous avons récemment publié, sous forme de série, des articles sur les WCAG (Web Content Accessibility Guidelines), les directives d'accessibilité du web, sur la plateforme de partage de connaissances techniques Zenn.
Dans cet article, nous présentons le contexte de la rédaction de ces articles, les réflexions qui les sous-tendent, ainsi qu'un aperçu de chacun d'entre eux.
Dissiper les interrogations autour des WCAG
Au quotidien, lorsque nous réalisons l'intégration et les vérifications de sites web, nous nous heurtons souvent à de nombreux points qui nous laissent perplexes, comme « Comment faut-il interpréter ce critère des WCAG ? » ou « Peut-on affirmer que cette implémentation est conforme ? »
Cette série s'inscrit en partie dans la démarche de restitution nécessaire au maintien et au renouvellement de ma certification internationale en accessibilité, l'IAAP WAS (Web Accessibility Specialist). Mais surtout, nous souhaitons clarifier les points qui posent question dans la pratique et partager ces connaissances de terrain. Cette synthèse m'a également permis de mettre de l'ordre dans mes propres idées.
Atteindre les WCAG est un point de départ, pas une finalité
Le message essentiel de ces articles est le suivant : le respect de l'ensemble des critères WCAG ne garantit pas une accessibilité à 100 %.
Les WCAG constituent un niveau minimal permettant à des utilisateurs variés d'accéder aux contenus. Elles ne représentent, en réalité, qu'un point de départ pour l'accessibilité.
En remplissant mécaniquement une liste de contrôle et en visant uniquement l'objectif de « satisfaire les critères de réussite », on peut passer à côté de la question essentielle : est-ce que cela rend réellement le site plus facile à utiliser pour les utilisateurs ?
C'est pourquoi cet article ne se limite pas à un savoir-faire superficiel du type « il suffit d'implémenter ainsi pour être conforme ». Nous explorons aussi le contexte et l'intention derrière chaque critère : pourquoi il a été établi. Nous pensons qu'en comprenant ces intentions, on acquiert une compréhension plus fondamentale de l'accessibilité.
Liste des articles publiés sur Zenn
Nous avons regroupé, par thème, cinq articles consacrés aux points les plus délicats à mettre en œuvre et à vérifier en pratique. N'hésitez pas à commencer par le sujet qui vous intéresse.
Point délicat WCAG n° 1 : une taille de police en px, est-ce vraiment acceptable ?
Cet article fait le point sur la conformité des tailles en px dans les environnements de navigateurs actuels, et s'interroge sur l'essence d'une « implémentation plus accessible » qui respecte le réglage de taille de texte choisi par l'utilisateur. Lire l'article sur Zenn
Point délicat WCAG n° 2 : plusieurs liens « Voir le détail » enfreignent-ils le critère 2.4.4 (Finalité du lien) ?
Explication de la frontière entre les cas où ces liens sont conformes, lorsqu'un « contexte approprié » est fourni. Nous proposons aussi, pour aller plus loin, une mise en œuvre orientée UX qui améliore l'efficacité des utilisateurs de lecteurs d'écran. Lire l'article sur Zenn
Point délicat WCAG n° 3 : si un lien image n'a pas de texte alternatif, quel critère est concerné ?
Cet article traite des situations complexes où un même problème touche plusieurs critères de réussite (1.1.1, 2.4.4, 4.1.2, etc.). Il explique comment comprendre les relations entre ces critères et comment juger lors des audits, où la confusion est fréquente. Lire l'article sur Zenn
Point de confusion WCAG n°4 : pourquoi un select est-il refusé alors qu'un menu déroulant personnalisé est accepté, alors que l'apparence est identique ? Critère 3.2.2 (à la saisie)
Explication approfondie de la différence entre « modification de paramètres » et « activation » telle que définie par le W3C. Une méthode pour bien juger, sans se laisser piéger par le comportement visuel, en s'appuyant sur la sémantique des éléments et la classification des opérations. Lire l'article sur Zenn
Point de confusion WCAG n°5 : que devient le critère 4.1.1 ? Comment traiter les erreurs de syntaxe HTML ?
Analyse du contexte de la suppression du critère 4.1.1 dans WCAG 2.2 et explication de la manière de répartir les anciennes erreurs de syntaxe, en fonction de leur impact réel, vers d'autres critères (1.3.1 ou 4.1.2), du point de vue de la qualité du site. Lire l'article sur Zenn
Note : les directives WCAG sont très complexes et formulées de manière souvent difficile à comprendre. Les explications et critères de jugement présentés dans chaque article peuvent donc refléter une interprétation personnelle, fondée sur notre expérience pratique. Nous vous invitons à les consulter en parallèle des directives WCAG officielles.
Conclusion
L'accessibilité web ne se résume pas à une mise en conformité ponctuelle ; c'est un travail continu qui demande un suivi régulier.
Nous espérons que ce contenu vous apportera des pistes utiles dans votre quotidien, que vous soyez développeur, designer ou chef de projet, confronté à la mise en œuvre et à la vérification de l'accessibilité.
Chez Liberogic, nous continuerons à partager ce type de contenus techniques et de retours d'expérience concrets, dans l'objectif de créer des sites et services accessibles à tous. Pour toute question sur l'accessibilité ou pour nous faire part de vos remarques sur nos articles, n'hésitez pas à nous contacter !
Passé du DTP au Web, il maîtrise aussi bien le balisage que le frontend, la direction de projet et l'accessibilité : un véritable « sage de la technique ». Actif chez Liberogic depuis ses débuts, il est aujourd'hui une référence interne incontournable. Ces derniers temps, il explore avec passion l'optimisation par l'IA : « Ne pourrait-on pas davantage s'appuyer sur l'IA pour l'accessibilité ? » Sa technique comme sa réflexion continuent d'évoluer.
Ayumu Futamata
Spécialiste certifié en accessibilité web IAAP (WAS) / Intégrateur balisage / Ingénieur frontend / Directeur web