WCAG : lignes di­rec­trices du W3C pour l’ac­ces­si­bi­lité sur le Web

Les di­rec­tives pour l’ac­ces­si­bi­lité aux contenus Web résument les critères im­por­tants pour un site Web ac­ces­sible. Les personnes han­di­ca­pées, en par­ti­cu­lier, ont souvent besoin d’une adap­ta­tion des sites Web pour pouvoir en percevoir et saisir les contenus.

Que sont les WCAG ?

Les Web Content Ac­ces­si­bi­lity Gui­de­lines (WCAG) sont des di­rec­tives in­ter­na­tio­nales pour la con­cep­tion de sites Web ac­ces­sibles à tous. Elles décrivent la manière dont les contenus Web doivent être conçus tech­ni­que­ment et con­cep­tuel­le­ment afin d’être ac­ces­sibles aux personnes han­di­ca­pées, in­dé­pen­dam­ment des li­mi­ta­tions telles que les dé­fi­ciences visuelles, auditives ou cog­ni­tives.

Les WCAG sont dé­ve­lop­pées par la Web Ac­ces­si­bi­lity Ini­tia­tive (WAI) du World Wide Web Con­sor­tium (W3C) et cons­ti­tuent la base de nom­breuses pres­crip­tions légales, dont la lé­gis­la­tion française et eu­ro­péenne dans le domaine de l’ac­ces­si­bi­lité numérique.

La version ac­tuel­le­ment en vigueur est la WCAG 2.2, of­fi­ciel­le­ment publiée le 5 octobre 2023. Elle ajoute neuf nouveaux critères de succès à la version pré­cé­dente (WCAG 2.1), en par­ti­cu­lier pour les groupes d’uti­li­sa­teurs souffrant de dé­fi­ciences cog­ni­tives, d’une motricité fine limitée ou d’une dé­fi­cience visuelle.

Objectif et sig­ni­fi­ca­tion des WCAG

Les WCAG dé­fi­nis­sent des exigences tech­niques et de con­cep­tion pour les contenus Web afin de garantir que les offres nu­mé­riques soient ac­ces­sibles au plus grand nombre, in­dé­pen­dam­ment des li­mi­ta­tions ou des tech­no­lo­gies utilisées (lecteur d’écran, afficheur braille, contrôle du clavier, etc.).

Les versions 2.1 (2018) et 2.2 (2023) s’appuient sur le WCAG 2.0 (2008) et l’étendent notamment au niveau des terminaux mobiles, des commandes tactiles et de l’as­sis­tance cognitive. Les trois versions sont com­pa­tibles avec les versions pré­cé­dentes, c’est-à-dire que les sites Web conformes aux WCAG 2.2 répondent également aux critères des versions an­té­rieures.

La prochaine version majeure, les WCAG 3.0, est toujours en cours de dé­ve­lop­pe­ment. Elle ne devrait pas être publiée en tant que norme of­fi­cielle avant 2027 et devrait in­tro­duire un nouveau modèle de con­for­mité ainsi que des méthodes d’éva­lua­tion plus complètes.

Les dif­fé­rences entre WCAG 1.0 et WCAG 2.0

Avec les WCAG, l’objectif du W3C est de fournir aux ex­ploi­tants de sites Web une norme in­ter­na­tio­nale pour l’ac­ces­si­bi­lité dans le domaine de la con­cep­tion Web. Ces règles répondent aux besoins des individus, mais aussi des or­ga­ni­sa­tions ou des ins­ti­tu­tions gou­ver­ne­men­tales.

Par rapport à la norme pré­cé­dente, les WCAG 2.1 se ca­rac­té­ri­sent par une approche in­dé­pen­dante de la tech­no­lo­gie. Les lignes di­rec­trices sont formulées pour répondre aux besoins de la tech­no­lo­gie actuelle ainsi qu’aux dé­ve­lop­pe­ments de tech­niques futures.

Une dif­fé­rence majeure entre WCAG 1.0 et WCAG 2.0 est la structure du catalogue de critères :

• Structure des WCAG 1.0 : les Web Content Ac­ces­si­bi­lity Gui­de­lines version 1.0 sont divisées en 14 di­rec­tives, chacune contenant 1 à 10 points de contrôle des priorités 1, 2 et 3. Chaque point de test reçoit un exemple, qui se réfère aux normes Web basiques HTML et XML.
• Structure des WCAG 2.x : les Web Content Ac­ces­si­bi­lity Gui­de­lines version 2.x proposent un système dans lequel les di­rec­tives d’ac­ces­si­bi­lité Web sont su­bor­don­nées aux quatre principes design fon­da­men­taux. Il s’agit de la per­cep­ti­bi­lité, la facilité d’uti­li­sa­tion, l’in­tel­li­gi­bi­lité et la ro­bus­tesse. Pour chaque directive, les ex­ploi­tants du site Web WCAG 2.x four­nis­sent un ensemble de critères de succès vé­ri­fiables pour les niveaux de con­for­mité A, AA, AAA (voir ci-dessous).

Les ex­ploi­tants de sites Web ne trouvent pas d’exemple dans la norme actuelle. Des des­crip­tions dé­tail­lées et des notes ont été trans­fé­rées aux pages d’in­for­ma­tion WCAG 2.0 et liées aux critères de succès res­pec­tifs. Vous trouverez davantage de détails dans les pages d’in­for­ma­tions pour la mise en œuvre technique du WCAG 2.0 (en anglais).

Malgré ces dif­fé­rences dans l’or­ga­ni­sa­tion des obli­ga­tions et des critères de con­cep­tion, WCAG 2.x reste com­pa­tible avec son pré­dé­ces­seur. Un site Web peut donc sa­tis­faire aux exigences des deux normes. La con­ver­sion d’un site Web de WCAG 1.0 en WCAG 2.0 est associée au W3C uni­que­ment avec de petits ajus­te­ments. Pour le reste, les WCAG font toujours référence au catalogue de di­rec­tives de la version actuelle 2.1.

La con­for­mité

Si un site Web remplit les exigences WCAG, on parle de con­for­mité. Il convient de noter qu’un site Web conforme aux WCAG ne doit pas forcément tenir compte de tous les critères de succès de la norme. Au lieu de cela, le W3C distingue un total de trois niveaux de con­for­mité : A, AA et AAA. Ceux-ci four­nis­sent des in­for­ma­tions sur la façon dont un site Web est adapté aux besoins des uti­li­sa­teurs d’Internet avec des res­tric­tions.

La con­for­mité s’applique à une page Web entière (c’est-à-dire un document HTML ac­ces­sible via une URL unique) et ne peut être re­ven­di­quée que pour des pages complètes, non pour des éléments isolés.

• Si des zones in­di­vi­duelles d’une page Web ne répondent pas au degré de con­for­mité souhaité, elles ne sont pas at­tri­buées à l’ensemble de la page Web.
• Si la page Web fait partie d’un chemin de clic sur plusieurs pages Web qui lui per­met­tent d’effectuer une action spé­ci­fique, toutes les pages Web du chemin de clic doivent avoir le niveau de con­for­mité désiré ou supérieur. Si une seule page Web ne répond pas aux exigences, le niveau de con­for­mité est alors affecté à l’ensemble du parcours, y compris les pages non conformes.

La con­for­mité en un exemple

Con­trai­re­ment aux WCAG 1.0, WCAG 2.x offre la pos­si­bi­lité d’im­plé­men­ter des aspects in­di­vi­duels d’un site Web ac­ces­sible à dif­fé­rents niveaux de con­for­mité. Pour l’aspect du contraste de couleur, deux dif­fé­rents critères de con­for­mité ont été définis dans la norme actuelle :

• 1.4.3 contraste (minimum) : la pré­sen­ta­tion visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 4.5:1 (sauf dans les cas suivants : (Niveau AA) […])
• 1.4.6 contraste (augmenté) : la pré­sen­ta­tion visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 7:1 (sauf dans les cas suivants : (Niveau AAA) […])

La dé­cla­ra­tion de con­for­mité op­tion­nelle

En option, les ex­ploi­tants de site Web ont la pos­si­bi­lité d’émettre une dé­cla­ra­tion de con­for­mité pour toutes les pages Web répondant aux critères des WCAG. Cette dé­cla­ra­tion est vo­lon­taire et n’a pas d’incidence directe sur l’ac­ces­si­bi­lité réelle du site. Toutefois, si un ad­mi­nis­tra­teur décide de la mettre en place, le W3C impose l’inclusion des in­for­ma­tions obli­ga­toires :

• La date de pu­bli­ca­tion de la dé­cla­ra­tion de con­for­mité
• La version des WCAG concernée, incluant son titre, son numéro de version et un lien vers le document de référence
• Le niveau de con­for­mité atteint (niveau A, AA ou AAA)
• Une des­crip­tion précise des pages Web couvertes par la dé­cla­ra­tion (par exemple, une liste des URLs con­cer­nées)
• La liste des tech­niques Web es­sen­tielles utilisées, ayant une incidence sur la con­for­mité des pages aux WCAG.

De plus, les ex­ploi­tants de sites Web peuvent fa­cul­ta­ti­ve­ment inclure les in­for­ma­tions suivantes dans leur dé­cla­ra­tion de con­for­mité :

• La liste des critères de per­for­mance remplis allant au-delà du niveau de con­for­mité déclaré
• Les tech­niques Web utilisées sur le site mais sans incidence sur la con­for­mité
• Les agents uti­li­sa­teurs (na­vi­ga­teurs et lecteurs d’écran) avec lesquels le site a été testé
• Une version lisible par machine des tech­niques Web es­sen­tielles utilisées dans les pages conformes aux WCAG
• Une version lisible par machine de la dé­cla­ra­tion de con­for­mité elle-même
• Les mesures sup­plé­men­taires mises en œuvre en faveur de l’ac­ces­si­bi­lité, in­dé­pen­dam­ment des exigences WCAG
• Les autres mesures de con­for­mité ap­pli­quées sur le site mais non couvertes par les WCAG. À cet effet, l’Union eu­ro­péenne propose un modèle de dé­cla­ra­tion de con­for­mité.

Aperçu des lignes di­rec­trices du WCAG 2.1

Les Web Content Ac­ces­si­bi­lity Gui­de­lines sont divisées en treize di­rec­tives, elles-mêmes re­grou­pées selon quatre principes fon­da­men­taux. Les principes des WCAG posent les fon­de­ments d’une uti­li­sa­tion sans barrière du Web et donnent les clés pour créer des contenus ac­ces­sibles à tous, dès lors qu’un certain niveau de con­for­mité est recherché. Vous pouvez retrouver la tra­duc­tion française agréée du texte intégral des WCAG 2.0 sur le site du W3C. Nous proposons ci-dessous un bref résumé des WCAG 2.1, qui englobe également les di­rec­tives ac­tua­li­sées des WCAG 2.2.

La per­cep­ti­bi­lité

Pour une uti­li­sa­tion optimale du Web, les contenus doivent être présentés de manière à pouvoir être perçus par tous. Les lignes di­rec­trices du WCAG pour améliorer la per­cep­ti­bi­lité sont les suivantes :

• Al­ter­na­tives tex­tuelles : il existe des équi­va­lents textuels aux contenus non textuels tels que les gros ca­rac­tères, le braille, les symboles ou un langage plus simple. Le critère de succès cor­res­pond au niveau de con­for­mité A. De même, ajouter des attributs Alt aux images peut améliorer le clas­se­ment SEO.
• Contenu mul­ti­mé­dia : des contenus al­ter­na­tifs sont mis à dis­po­si­tion pour les médias temporels (par exemple, des contenus audio et vidéo). Les al­ter­na­tives dis­po­nibles sont, selon le niveau de con­for­mité visé, des textes d’ac­com­pag­ne­ment des­crip­tifs, des au­dio­des­crip­tions (comme la synthèse vocale), des sous-titres, des trans­crip­tions ou la langue des signes. La directive comprend neuf critères de succès des niveaux de con­for­mité A, AA et AAA.
• Adap­ta­bi­lité : les contenus doivent pouvoir être présentés sous dif­fé­rentes formes (par exemple, via une mise en page sim­pli­fiée) sans perte d’in­for­ma­tion. La directive comprend six critères de succès aux niveaux A, AA et AAA.
• Dif­fé­ren­cia­bi­lité : les contenus sont créés de manière à se dis­tin­guer clai­re­ment des autres contenus sur le plan visuel et sonore (couleur, taille des ca­rac­tères, contraste, arrière-plan discret). La directive comprend 13 critères de succès des niveaux de con­for­mité A, AA et AAA.

L’usabilité

Les in­ter­faces uti­li­sa­teur doivent être élaborées de manière simple et logique, afin que les in­ter­nautes puissent trouver fa­ci­le­ment les in­for­ma­tions qu’ils re­cherchent. L’usabilité d’un site Web peut être améliorée en suivant les lignes di­rec­trices suivantes :

• Ac­ces­si­bi­lité via le clavier : pour une bonne ac­ces­si­bi­lité du Web, tous les contenus et les fonc­tion­na­li­tés doivent être dis­po­nibles sur le clavier, qui est défini comme l’interface uti­li­sa­teur prin­ci­pale. La directive comprend quatre critères de succès de niveau de con­for­mité A et AAA.
• Aucune con­trainte de temps : les uti­li­sa­teurs disposent de suf­fi­sam­ment de temps pour lire et utiliser le contenu du site, les personnes han­di­ca­pées ayant souvent besoin de plus de temps pour com­prendre le contenu du site ou pour effectuer des actions de saisie. La directive comprend six critères de succès des niveaux de con­for­mité A et AAA.
• Réduction du risque de crises : tous les contenus Web sont conçus de manière à minimiser tout risque de crise liée à des stimuli visuels. Des seuils sont définis pour les stimuli visuels sus­cep­tibles d’entraîner des attaques. La directive comprend trois critères de succès des niveaux de con­for­mité A et AAA.
• Na­vi­ga­tion : le site Web met à la dis­po­si­tion des uti­li­sa­teurs des res­sources leur per­met­tant de naviguer sans effort. Les di­rec­tives pour une na­vi­ga­tion ac­ces­sible con­cer­nent les méta-titres et les méta-des­crip­tions, les textes relatifs aux liens, les pos­si­bi­li­tés d’accès aux pages Web, les titres et légendes de chaque pa­ra­graphe ainsi qu’à l’uti­li­sa­tion du clavier. La directive sur la na­vi­ga­tion comprend 13 critères de succès des niveaux de con­for­mité A, AA et AAA.
• Ac­ces­si­bi­lité par d’autres dis­po­si­tifs : toutes les fonc­tion­na­li­tés dis­po­nibles sur le clavier doivent aussi pouvoir être com­man­dées de manière al­ter­na­tive, par exemple par des gestes. La directive définit huit critères de succès des niveaux de con­for­mité A, AA et AAA.

La com­pré­hen­sion

Les contenus et les fonc­tion­na­li­tés d’un site Web doivent être com­pré­hen­sibles par tous. Pour cela, les ad­mi­nis­tra­teurs doivent respecter les di­rec­tives suivantes :

• Li­si­bi­lité : l’ac­ces­si­bi­lité optimale des sites Web pré­sup­pose des contenus lisibles et com­pré­hen­sibles. La directive sur la li­si­bi­lité comprend des règles, indiquant la manière dont les éléments lin­guis­tiques doivent être signalés et complétés par des in­for­ma­tions sup­plé­men­taires. Pour la li­si­bi­lité, les WCAG dé­fi­nis­sent au total six critères pour les niveaux de con­for­mité A, AA et AAA.
• Pré­vi­si­bi­lité : le com­por­te­ment des éléments fonc­tion­nels et in­te­rac­tifs des sites Web reste pré­vi­sible afin d’en faciliter la com­pré­hen­sion. Les six critères de succès proposés com­pren­nent les niveaux de con­for­mité A, AA et AAA.
• Aide à la saisie : les sites Web ac­ces­sibles per­met­tent aux visiteurs d’éviter de commettre des erreurs en les cor­ri­geant au­to­ma­ti­que­ment grâce notamment à des aides à la saisie. Les ad­mi­nis­tra­teurs disposent de neuf critères de succès des niveaux de con­for­mité A, AA et AAA.

La ro­bus­tesse

Le principe de ro­bus­tesse fait référence à la com­pa­ti­bi­lité technique des contenus Web. Ceux-ci doivent pouvoir être in­ter­pré­tés de manière fiable par les na­vi­ga­teurs et les tech­no­lo­gies d’as­sis­tance, aujourd’hui comme demain.

• Com­pa­ti­bi­lité : la com­pa­ti­bi­lité avec les tech­niques actuelles et futures est maximisée par l’ap­pli­ca­tion sys­té­ma­tique de standards Web spé­ci­fiques. La condition de base est que l’im­plé­men­ta­tion de contenus au moyen de langages de balisage (par exemple HTML) ne comporte pas d’erreur et soit en­tiè­re­ment conforme à la norme cor­res­pon­dante. La directive relative à la com­pa­ti­bi­lité comprend deux critères de succès des niveaux de con­for­mité A et AA.

Les nou­veau­tés des WCAG 2.2

Avec les WCAG 2.2, un total de 9 nouveaux critères de succès est ajouté à dif­fé­rentes di­rec­tives déjà en vigueur.

• Uti­li­sa­tion du clavier : 3 critères pour l’affichage de contenus lors de la mise au point de com­po­sants
• Uti­li­sa­tion de l’écran tactile et de la souris : un critère à la fois pour les fonctions de dé­fi­le­ment et les champs cli­quables
• As­sis­tance sup­plé­men­taire en cas de capacités cog­ni­tives réduites :
  • les fonctions d’aide se trouvent toujours au même endroit
  • as­sis­tance pour les données déjà saisies
  • mé­ca­nismes al­ter­na­tifs pour la saisie du mot de passe et les tests fonc­tion­nels cognitifs
  • al­ter­na­tives à la sélection d’images ou d’objets pour les tests de fonctions cog­ni­tives

Les WCAG 2.2 cons­ti­tuent une amé­lio­ra­tion de la version pré­cé­dente (WCAG 2.1), qui pré­sen­tait encore certaines lacunes dans sa directive actuelle.

Checklist WCAG

La version pré­li­mi­naire du WCAG 2.0 du 27 avril 2006 contenait en annexe une checklist avec l’ensemble des critères définis par le W3C. Elle a servi à de nombreux ex­ploi­tants de sites Web. Depuis la pu­bli­ca­tion du WCAG 2.0 en décembre 2008, cette checklist est devenue obsolète.

Une liste de ré­fé­rences WCAG 2.0 rapide et per­son­na­li­sable a remplacé cette checklist. Elle permet aux ad­mi­nis­tra­teurs de sites Web d’adapter le catalogue de critères pour une con­cep­tion Web ac­ces­sible selon leurs propres besoins (à savoir leurs exigences tech­niques et le degré de con­for­mité souhaité) au moyen d’une fonction de filtrage, afin de créer des listes de vé­ri­fi­ca­tion per­son­na­li­sées.

Les tests WCAG

Les exigences WCAG sont des critères vé­ri­fiables, selon lesquels les ex­ploi­tants de sites Web peuvent évaluer le degré de con­for­mité des pages Web in­di­vi­duelles selon la norme WAI. Pour les ad­mi­nis­tra­teurs de sites Web qui sou­hai­tent vérifier non seulement les pages Web in­di­vi­duelles, mais aussi l’ac­ces­si­bi­lité de l’ensemble du site Internet, la WAI a jusqu’à présent développé quatre stra­té­gies.

Easy Checks

Avec Easy Checks, la WAI pose les fon­de­ments d’une con­cep­tion Web sans obstacle. La liste est destinée à permettre aux ex­ploi­tants de sites Web d’avoir un aperçu rapide de l’état de leur projet en ligne. Les critères suivants sont passés à la loupe avec Easy Checks :

• Méta-titres
• Textes al­ter­na­tifs
• Titres
• Niveau de contraste
• Évo­lu­ti­vité des textes
• Ac­ces­si­bi­lité via le clavier
• Contenu mobile, clig­no­tant ou à démarrage au­to­ma­tique
• Al­ter­na­tives mul­ti­mé­dia
• Structure des pages Web

Ce n’est pas l’outil le plus pertinent en termes d’ac­ces­si­bi­lité. Pour une éva­lua­tion de con­for­mité plus complète, d’autres tests WCAG sont né­ces­saires, comme avec WCAG-EM par exemple.

WCAG-EM

Les Easy Checks sont utilisés pour donner aux ad­mi­nis­tra­teurs une première im­pres­sion de l’ac­ces­si­bi­lité générale de leur site Web. Pour les ex­ploi­tants qui sou­hai­tent dé­ter­mi­ner de manière fiable et vé­ri­fiable la con­for­mité de leur projet aux WCAG, la WAI a développé une approche des meil­leures pratiques de sites Web, la Website Ac­ces­si­bi­lity Con­for­mance Eva­lua­tion Me­tho­do­logy (WCAG-EM). L’éva­lua­tion de con­for­mité aux WCAG-EM comprend cinq étapes :

1. Dé­ter­mi­ner le périmètre de l’éva­lua­tion
2. Analyser le site Internet
3. Sé­lec­tion­ner des pages Web re­pré­sen­ta­tives
4. Vérifier les pages Web sé­lec­tion­nées
5. Évaluer la con­for­mité avec le WCAG-EM-Report-Tool.

Aucune pu­bli­ca­tion du cer­ti­fi­cat de con­for­mité n’est requise. Les résultats de l’éva­lua­tion cons­ti­tuent la base d’une dé­cla­ra­tion de con­for­mité op­tion­nelle (voir ci-dessus).

Les éva­lua­tions uti­li­sa­teurs

Les ex­ploi­tants qui veulent évaluer l’ac­ces­si­bi­lité de leur site Internet peuvent se con­cen­trer sur des pro­cé­dures de test nor­ma­li­sées telles que WCAG-EM. La WAI, cependant, conseille de combiner l’éva­lua­tion de la con­for­mité, si possible, avec une éva­lua­tion par l’uti­li­sa­teur. De cette façon, des problèmes d’uti­li­sa­bi­lité n’ayant pas été en­re­gis­trés dans le catalogue des critères WCAG 2.1 peuvent également être iden­ti­fiés.

Un tel test d’ac­ces­si­bi­lité est gé­né­ra­le­ment basé sur des personnes ayant des res­tric­tions ainsi que sur des uti­li­sa­teurs Internet plus âgés. Il est possible d’utiliser des méthodes d’essai in­for­melles sous la forme d’enquêtes ainsi que des tests d’uti­li­sa­bi­lité for­ma­li­sés, qui sont basés sur l’éva­lua­tion sta­tis­tique de certaines tâches qui con­cer­nent le site Web concerné.

Des in­for­ma­tions sur la manière dont les ad­mi­nis­tra­teurs peuvent impliquer les visiteurs de leur site dans de telles pro­cé­dures d’éva­lua­tion de l’ac­ces­si­bi­lité sont dis­po­nibles sur les pages d’in­for­ma­tions de la WAI.

Les outils d’éva­lua­tion

Il existe de nombreux outils per­met­tant d’évaluer l’ac­ces­si­bi­lité des sites Web. La WAI encourage le dé­ve­lop­pe­ment de pro­grammes et de services adaptés à cet objectif. Le site du W3C ne re­com­mande aucun outil en par­ti­cu­lier, mais la WAI met à dis­po­si­tion liste complète des outils d’éva­lua­tion dis­po­nibles, avec des filtres per­met­tant d’affiner la recherche en fonction des besoins spé­ci­fiques et des normes visées.

La prise en compte de ces mesures en France

En France, une cir­cu­laire du Premier ministre de 1999 affirmait : « Les res­pon­sables des sites [publics] veil­le­ront tout par­ti­cu­liè­re­ment à favoriser l’ac­ces­si­bi­lité de l’in­for­ma­tion à tous les in­ter­nautes, notamment les personnes han­di­ca­pées, non voyantes, mal­voyantes ou ma­len­ten­dantes. ». C’est à partir de 2004 que les pouvoirs publics ont lancé une campagne de sen­si­bi­li­sa­tion à des­ti­na­tion des acteurs de l’Internet. L’Agence pour le dé­ve­lop­pe­ment de l’ad­mi­nis­tra­tion élec­tro­nique (ADAE) a alors adapté un « Ré­fé­ren­tiel ac­ces­si­bi­lité des services Internet de l’ad­mi­nis­tra­tion ». Ce rapport n’avait toutefois aucun caractère obli­ga­toire à l’époque.

Ce n’est qu’en février 2005 que la loi pour l’égalité des droits et des chances, la par­ti­ci­pa­tion et la ci­toyen­neté des personnes han­di­ca­pées a instauré l’obli­ga­tion de rendre le Web public ac­ces­sible à tous.

Depuis le décret n° 2019-768 du 24 juillet 2019, le Ré­fé­ren­tiel général d’amé­lio­ra­tion de l’ac­ces­si­bi­lité (RGAA) est devenu obli­ga­toire pour les services publics en ligne. La loi pour une Ré­pu­blique numérique, pro­mul­guée en 2016, a renforcé ces obli­ga­tions en imposant aux or­ga­nismes investis d’une mission de service public de publier une dé­cla­ra­tion d’ac­ces­si­bi­lité et un schéma plu­rian­nuel.

Avec la trans­po­si­tion en droit français de la directive eu­ro­péenne (UE) 2019/882, les obli­ga­tions en matière d’ac­ces­si­bi­lité numérique s’ap­pli­quent désormais également aux en­tre­prises privées dont le chiffre d’affaires dépasse 2 millions d’euros ou comptant plus de 10 salariés. Con­for­mé­ment à cette directive, les produits et services nu­mé­riques concernés devront être rendus ac­ces­sibles au plus tard le 28 juin 2025.

Pour les ges­tion­naires de sites Web, la section critères et tests du RGAA détaille les exigences tech­niques à respecter pour se conformer à la version actuelle du ré­fé­ren­tiel (RGAA 4.1.2).

Pers­pec­tives : WCAG 3.0

Les WCAG 2.1, ou plus pré­ci­sé­ment leur version com­plé­men­taire WCAG 2.2, re­pré­sen­tent les normes actuelles re­com­man­dées par le W3C. Cependant, la WAI travaille déjà sur une nouvelle version des Web Content Ac­ces­si­bi­lity Gui­de­lines : la version WCAG 3.0 prévoit d’inclure de nouvelles di­rec­tives.

Une attention par­ti­cu­lière sera consacrée à de nouveaux tests et à de nouveaux mé­ca­nismes d’éva­lua­tion. Con­trai­re­ment à ses pré­dé­ces­seurs, WCAG 3.0 n’est pas com­pa­tible avec les versions pré­cé­dentes, car il s’agit davantage d’un nouvel ensemble de di­rec­tives. Le modèle de con­for­mité va également être repensé. Si vous êtes intéressé, vous pouvez consulter l’actuelle ébauche de projet des WCAG 3.0 pour plus de pré­ci­sions.