Référentiel général d'amélioration de l'accessibilité – RGAA Version 4

La direction interministérielle du numérique et du système d’information et de communication de l’État (DINSIC) publie la quatrième version du référentiel général d’amélioration de l’accessibilité (RGAA, anciennement référentiel général d’accessibilité des administrations).

16 septembre 2019 - Mis à jour le 21 octobre 2019

Notes de révision

Ces notes de révision concernent le passage de la version 3 2017 à la version 4 du RGAA.

Documents du référentiel technique impactés par la mise à jour

  • Référentiel technique
  • Glossaire
  • Cas particuliers
  • Notes techniques

Résumé des modifications notables

De nombreux critères et tests ont été modifiés afin que le référentiel technique reste le plus fidèle possible à ce que proposent les critères WCAG 2.1.

Les critères RGAA de niveau triple A (AAA) ont été retirés du référentiel, étant donné que la directive européenne ne tient pas compte elle-même des critères WCAG triple A qu'elle rappelle juste en annexe technique.

Pour information et rappel, voici la liste traduite en français des critères de succès triple A (AAA) des WCAG 2.1 figurant dans cette annexe. Cette traduction a été effectuée pour répondre aux besoins techniques immédiats. En cas de divergence d’interprétation, veuillez vous référer à la traduction officielle de l’AFNOR.

  1. Média temporel. 1.2.6 - Langue des signes (préenregistrée)
  2. Média temporel. 1.2.7 - Audiodescription étendue (préenregistrée)
  3. Média temporel. 1.2.8 - Version de remplacement pour un média temporel (préenregistré)
  4. Média temporel. 1.2.9 - Seulement audio (en direct)
  5. Adaptable. 1.3.6 - Identify purpose (Identification de l’objet)
  6. Distinguable. 1.4.6 - Contraste (amélioré)
  7. Distinguable. 1.4.7 - Arrière-plan sonore de faible volume ou absent
  8. Distinguable. 1.4.8 - Présentation visuelle
  9. Distinguable. 1.4.9 - Texte sous forme d’image (sans exception)
  10. Accessibilité au clavier. 2.1.3 - Clavier (sans exception)
  11. Délai suffisant. 2.2.3 - Pas de délai d’exécution
  12. Délai suffisant. 2.2.4 - Interruptions
  13. Délai suffisant. 2.2.5 - Nouvelle authentification
  14. Délai suffisant. 2.2.6 - Timeouts (Dépassements du temps imparti)
  15. Crises et réactions physiques. 2.3.2 - Trois flashs
  16. Crises et réactions physiques. 2.3.3 - Animation from Interactions (Animation résultant des interactions)
  17. Navigable. 2.4.8 - Localisation
  18. Navigable. 2.4.9 - Fonction du lien (lien uniquement)
  19. Navigable. 2.4.10 - En-têtes de section
  20. Input modalities (Modalités de saisie). 2.5.5 - Target Size (Taille de la cible)
  21. Input modalities (Modalités de saisie). 2.5.6 - Concurrent Input Mechanisms (Mécanismes de saisie concurrents)
  22. Lisible. 3.1.3 - Mots rares
  23. Lisible. 3.1.4 - Abréviations
  24. Lisible. 3.1.5 - Niveau de lecture
  25. Lisible. 3.1.6 - Prononciation
  26. Prévisible. 3.2.5 - Changement à la demande
  27. Assistance à la saisie. 3.3.5 - Aide
  28. Assistance à la saisie. 3.3.6 - Prévention des erreurs (toutes)

Modifications générales sur tout ou partie des documents

  • Suppression des niveaux RGAA.
  • Supression de la référence aux principes WCAG.
  • La mention "ARIA" a été systématiquement remplacée par "WAI-ARIA".
  • La mention "propriété" WAI-ARIA a été remplacée par "attribut".
  • Lorsqu'il est fait mention d'une balise ou d'un élément HTML, l'entité en question est délimitée par des chevrons ouvrant et fermant.
  • Les notes techniques et les cas particuliers sont désormais directement associés au critère dont ils relèvent.

Référentiel technique

Modification du Critère 1.1 [A] Chaque image a-t-elle une alternative textuelle?

WCAG n’exige pas la présence systématique d’un attribut alt mais la présence d’une alternative textuelle lorsque nécessaire quelle que soit la technique utilisée à partir du moment où elle est compatible avec l’accessibilité. Le critère est donc restreint au cas des images porteuses d’informations et la définition de glossaire "alternative textuelle" est modifiée pour préciser les différentes techniques permettant d'associer une alternative textuelle.

Ancien critère 1.1

Critère 1.1 [A] Chaque image a-t-elle une alternative textuelle?

Nouveau critère 1.1

Critère 1.1 Chaque image porteuse d’information a-t-elle une alternative textuelle?

Modification du test 1.1.1

WCAG n’exige pas la présence systématique d’un attribut alt mais la présence d’une alternative textuelle lorsque nécessaire quelle que soit la technique utilisée à partir du moment où elle est compatible avec l’accessibilité. Prise en compte de l’attribut WAI-ARIA role="img".

Ancien test 1.1.1

Test 1.1.1 : Chaque image (balise img) a-t-elle un attribut alt?

Nouveau test 1.1.1

Test 1.1.1 : Chaque image (balise <img> ou balise possédant l’attribut WAI-ARIA role="img") porteuse d’information a-t-elle une alternative textuelle?

Modification du test 1.1.2

WCAG n’exige pas la présence systématique d’un attribut alt mais la présence d’une alternative textuelle lorsque nécessaire quelle que soit la technique utilisée à partir du moment où elle est compatible avec l’accessibilité.

Ancien test 1.1.2

Test 1.1.2 : Chaque zone (balise area) d'une image réactive a-t-elle un attribut alt?

Nouveau test 1.1.2

Test 1.1.2 : Chaque zone d'une image réactive (balise <area>) porteuse d’information a-t-elle une alternative textuelle?

Modification du test 1.1.3

WCAG n’exige pas la présence systématique d’un attribut alt mais la présence d’une alternative textuelle lorsque nécessaire quelle que soit la technique utilisée à partir du moment où elle est compatible avec l’accessibilité.

Ancien test 1.1.3

Test 1.1.3 : Chaque bouton de type image (balise input avec l'attribut type="image") a-t-il un attribut alt?

Nouveau test 1.1.3

Test 1.1.3 : Chaque bouton de type image (balise <input> avec l'attribut type="image") a-t-il une alternative textuelle?

Ajout du test 1.1.5

Reprise du test 1.3.8 en séparant le test de présence et de pertinence test 1.3.9.

Nouveau test 1.1.5

Test 1.1.5 : Chaque image vectorielle (balise <svg>) porteuse d'information, vérifie-t-elle ces conditions?

  • La balise <svg> possède un attribut WAI-ARIA role="img".
  • La balise <svg> a une alternative textuelle.

Ajout du test 1.1.6

Reprise du test 1.3.4 en séparant le test de présence et de pertinence test 1.3.5.

Nouveau test 1.1.6

Test 1.1.6 : Chaque image objet (balise <object> avec l'attribut type="image/…") porteuse d'information, vérifie-t-elle une de ces conditions?

  • La balise <object> possède une alternative textuelle.
  • L'élément <object> est immédiatement suivi d'un lien ou bouton adjacent permettant d'accéder à un contenu alternatif.
  • Un mécanisme permet à l'utilisateur de remplacer l'élément <object> par un contenu alternatif.

Ajout du test 1.1.7

Reprise du test 1.3.6 en séparant le test de présence et de pertinence test 1.3.7.

Nouveau test 1.1.7

Test 1.1.7 : Chaque image embarquée (balise <embed> avec l'attribut type="image/…") porteuse d'information, vérifie-t-elle une de ces conditions?

  • La balise <embed> possède une alternative textuelle
  • L'élément <embed> est immédiatement suivie d'un lien ou bouton adjacent permettant d'accéder à un contenu alternatif.
  • Un mécanisme permet à l'utilisateur de remplacer l'élément <embed> par un contenu alternatif.

Ajout du test 1.1.8

Reprise du test 1.3.10 en séparant le test de présence et de pertinence test 1.3.11.

Nouveau test 1.1.8

Test 1.1.8 : Chaque image bitmap (balise <canvas>) porteuse d'information, vérifie-t-elle une de ces conditions?

  • La balise <canvas> possède une alternative textuelle
  • Un contenu alternatif est présent entre les balises <canvas> et </canvas>
  • L'élément <canvas> est immédiatement suivi d'un lien ou bouton adjacent permettant d'accéder à un contenu alternatif.
  • Un mécanisme permet à l'utilisateur de remplacer l'élément <canvas> par un contenu alternatif.

Modification du Critère 1.2

WCAG n’exige pas la présence d’une alternative vide mais exige que l’image de décoration soit ignorée par les technologies d’assistance.

Ancien critère 1.2

Critère 1.2 [A] Pour chaque image de décoration ayant une alternative textuelle, cette alternative est-elle vide?

Nouveau critère 1.2

Critère 1.2 Chaque image de décoration est-elle correctement ignorée par les technologies d'assistance?

Modification de la note technique du critère 1.2

Suppression du passage faisant référence à l’attribut WAI-ARIA role=”presentation” suite à intégration de ce rôle dans le critère 1.1 et prise en compte de l’usage des balises <use> dans les <svg>.

Ancienne note technique

Lorsqu'une image est associée à une légende, la note technique WCAG recommande de renseigner systématiquement l'alternative de l'image (cf. critère 1.10). Dans ce cas le critère 1.2 est non applicable.

Un attribut WAI-ARIA role=”presentation” ne peut pas être utilisé pour déclarer une image de décoration conformément aux indications données par la spécification sur les restrictions de l'utilisation des rôles WAI-ARIA.

Nouvelle note technique

Lorsqu'une image est associée à une légende, la note technique WCAG recommande de prévoir systématiquement une alternative textuelle (cf. critère 1.9). Dans ce cas le critère 1.2 est non applicable.

Dans le cas d'une image vectorielle (balise <svg>) de décoration qui serait affichée au travers d'un élément <use href="..."> enfant de l'élément <svg>, le test 1.2.4 s'appliquera également à la balise <svg> associée par le biais de la balise <use>.

Un attribut WAI-ARIA role="presentation" peut être utilisé sur les images de décoration et les zones non cliquables de décoration. Le rôle "none" introduit en ARIA 1.1 et synonyme du rôle "presentation" peut être aussi utilisé. Il reste préférable cependant d'utiliser le rôle "presentation" en attendant un support satisfaisant du rôle "none".

Modification du test 1.2.1

Prise en compte des images de décoration sans alternative textuelle mais possédant un attribut WAI-ARIA aria-hidden="true" ou role="presentation" et modification de la formulation des conditions suite à la prise en compte de l’ensemble des techniques permettant de fournir une alternative textuelle.

Ancien test 1.2.1

Test 1.2.1 : Chaque image (balise img) de décoration, sans légende, et ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt est vide (alt="").
  • L'image de décoration ne possède pas d'attribut title.
  • La balise img est dépourvue de rôle, propriété ou état ARIA visant à labelliser l'image (aria-label, aria-describedby, aria-labelledby par exemple).

Nouveau test 1.2.1

Test 1.2.1 : Chaque image (balise <img>) de décoration, sans légende, vérifie-t-elle une de ces conditions?

  • La balise <img> possède un attribut alt vide (alt="") et est dépourvue de tout autre attribut permettant de fournir une alternative textuelle.
  • La balise <img> possède un attribut WAI-ARIA aria-hidden="true" ou role="presentation".

Modification du test 1.2.2

Prise en compte des zones non cliquables de décoration sans alternative textuelle mais possédant un attribut WAI-ARIA aria-hidden="true" ou role="presentation" et modification de la formulation des conditions suite à la prise en compte de l’ensemble des techniques permettant de fournir une alternative textuelle.

Ancien test 1.2.2

Test 1.2.2 : Chaque zone non cliquable (balise area sans attribut href) de décoration, et ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt est vide (alt="").
  • La zone non cliquable ne possède pas d'attribut title.
  • La balise area est dépourvue de rôle, propriété ou état ARIA visant à labelliser l'image (aria-label, aria-describedby, aria-labelledby par exemple).

Nouveau test 1.2.2

Test 1.2.2 : Chaque zone non cliquable (balise area sans attribut href) de décoration vérifie-t-elle une de ces conditions?

  • La balise <area> possède un attribut alt vide (alt="") et est dépourvue de tout autre attribut permettant de fournir une alternative textuelle.
  • La balise <area> possède un attribut WAI-ARIA aria-hidden="true" ou role="presentation".

Modification du test 1.2.3

Modification de la formulation des conditions suite à la prise en compte de l’ensemble des techniques permettant de fournir une alternative textuelle.

Ancien test 1.2.3

Test 1.2.3 : Chaque image objet (balise object avec l'attribut type="image/…") de décoration, sans légende, vérifie-t-elle ces conditions?

  • La balise object possède un attribut aria-hidden="true".
  • L'alternative textuelle entre <object> et </object> est vide.
  • La balise object ou l'un de ses enfants est dépourvue d'attribut title.
  • La balise object ou l'un de ses enfants est dépourvue de rôle, propriété ou état ARIA visant à labelliser l'image (aria-label, aria-describedby, aria-labelledby par exemple).

Nouveau test 1.2.3

Test 1.2.3 : Chaque image objet (balise <object> avec l'attribut type="image/…") de décoration, sans légende, vérifie-t-elle une de ces conditions?

  • La balise <object> possède un attribut WAI-ARIA aria-hidden="true".
  • La balise <object> est dépourvue d'alternative textuelle.
  • Il n’y a aucun texte faisant office d’alternative textuelle entre <object> et </object>.

Modification du test 1.2.4

Modification de la formulation des conditions suite à la prise en compte de l’ensemble des techniques permettant de fournir une alternative textuelle.

Ancien test 1.2.4

Test 1.2.4 : Chaque image vectorielle (balise svg) de décoration, sans légende, vérifie-t-elle ces conditions?

  • La balise svg possède un attribut aria-hidden="true".
  • Les balises title et desc sont absentes ou vides.
  • La balise svg ou l'un de ses enfants est dépourvue d'attribut title.
  • La balise svg ou l'un de ses enfants est dépourvue de rôle, propriété ou état ARIA visant à labelliser l'image vectorielle (aria-label, aria-describedby, aria-labelledby par exemple).

Nouveau test 1.2.4

Test 1.2.4 : Chaque image vectorielle (balise <svg>) de décoration, sans légende, vérifie-t-elle une de ces conditions?

  • La balise <svg> possède un attribut WAI-ARIA aria-hidden="true".
  • La balise <svg> et ses enfants sont dépourvus d'alternative textuelle.
  • Les balises title et desc sont absentes ou vides.
  • La balise <svg> et ses enfants sont dépourvus d'attribut title.

Modification du test 1.2.5

Modification de la formulation des conditions suite à la prise en compte de l’ensemble des techniques permettant de fournir une alternative textuelle.

Ancien test 1.2.5

Test 1.2.5 : Chaque image bitmap (balise canvas) de décoration, sans légende, vérifie-t-elle ces conditions?

  • La balise canvas possède un attribut aria-hidden="true".
  • Le contenu entre <canvas> et </canvas> est dépourvue de contenus textuels.
  • La balise canvas ou l'un de ses enfants est dépourvue d'attribut title.
  • La balise canvas ou l'un de ses enfants est dépourvue de rôle, propriété ou état ARIA visant à labelliser l'image (aria-label, aria-describedby, aria-labelledby par exemple).

Nouveau test 1.2.5

Test 1.2.5 : Chaque image bitmap (balise <canvas>) de décoration, sans légende, vérifie-t-elle une de ces conditions?

  • La balise <canvas> possède un attribut WAI-ARIA aria-hidden="true".
  • La balise <canvas> et ses enfants sont dépourvus d'alternative textuelle.
  • Les balises title et desc sont absentes ou vides.
  • Il n’y a aucun texte faisant office d’alternative textuelle entre <canvas> et </canvas>.

Modification du test 1.2.6

Modification de la formulation des conditions suite à la prise en compte de l’ensemble des techniques permettant de fournir une alternative textuelle.

Ancien test 1.2.6

Test 1.2.6 : Chaque image embarquée (balise embed avec l'attribut type="image/…") de décoration, sans légende, vérifie-t-elle ces conditions?

  • La balise embed possède un attribut aria-hidden="true".
  • La balise embed ou l'un de ses enfants est dépourvue d'attribut title.
  • La balise embed ou l'un de ses enfants est dépourvue de rôle, propriété ou état ARIA visant à labelliser l'image (aria-label, aria-describedby, aria-labelledby par exemple).

Nouveau test 1.2.6

Test 1.2.6 : Chaque image embarquée (balise <embed> avec l'attribut type="image/…") de décoration, sans légende, vérifie-t-elle une de ces conditions?

  • La balise <embed> possède un attribut WAI-ARIA aria-hidden="true".
  • La balise <embed> et ses enfants sont dépourvus d'alternative textuelle.

Suppression des notes techniques du critère 1.3

Critère 1.3 [A] : attribut title : suite à l'utilisation de l'attribut title dans le calcul du nom accessible d'une alternative textuelle.

Critère 1.3 [A] : balise <title> dans les éléments SVG : suite à la création du test 1.1.5 et au support désormais effectif des balises <title> et <desc> lorsqu’elles sont associées à l’élément <svg> via les attributs WAI-ARIA aria-labelledby et aria-describedby, cette note n’a plus de raison d’être.

Ancienne note technique (attribut title)

La note WCAG interdit l'utilisation de l'attribut title en remplacement de l'attribut alt, néanmoins il est souvent utile d'utiliser l'attribut title pour faire apparaître une infobulle (tooltip) sur les images particulièrement obscures. Si l'attribut title est utilisé de cette manière, le contenu de l'attribut title doit être strictement identique à celui de l'alternative.

Ancienne note technique (balise <title> dans les éléments SVG)

Le manque de support de l'élément <title> par les technologies d'assistance crée une difficulté dans le cas de l'utilisation de l'élément <desc> pour implémenter l'alternative courte de l'image si l'image nécessite une description détaillée. Dans ce cas il est recommandé d'utiliser un texte adjacent ou un lien adjacent pour créer la description détaillée.

Les tests 1.3.9 et 1.3.12 sont utilisés pour vérifier que l'implémentation de l'alternative est compatible avec l'accessibilité (par exemple avec la base de référence considérée).

Modification du test 1.3.1

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à une balise <img>.

Ancien test 1.3.1

Test 1.3.1 : Chaque image (balise img) porteuse d'information, ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu de la propriété aria-label est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu du passage de texte lié via la propriété aria-labelledby est identique au contenu de l'attribut alt.

Nouveau test 1.3.1

Test 1.3.1 : Pour chaque image (balise <img> ou balise possédant l’attribut WAI-ARIA role="img") porteuse d'information, ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Modification du test 1.3.2

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à une zone cliquable.

Ancien test 1.3.2

Test 1.3.2 : Chaque zone (balise area) d'une image réactive porteuse d'information, ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu de la propriété aria-label est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu du passage de texte lié via la propriété aria-labelledby est identique au contenu de l'attribut alt.

Nouveau test 1.3.2

Test 1.3.2 : Pour chaque zone (balise <area>) d'une image réactive porteuse d'information, ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Modification du test 1.3.3

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à un bouton de type image.

Ancien test 1.3.3

Test 1.3.3 : Chaque bouton de type image (balise input avec l'attribut type="image"), ayant un attribut alt, vérifie-t-il ces conditions?

  • Le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu de la propriété aria-label est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu du passage de texte lié via la propriété aria-labelledby est identique au contenu de l'attribut alt.

Nouveau test 1.3.3

Test 1.3.3 : Pour chaque zone bouton de type image (balise <input> avec l'attribut type="image"), ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Suppression du test 1.3.4

Remplacement par le test 1.1.6.

Ancien test 1.3.4

Test 1.3.4 : Chaque image objet (balise object avec l'attribut type="image/...") porteuse d'information vérifie-t-elle une de ces conditions (hors cas particuliers)

  • L'image objet est immédiatement suivie d'un lien adjacent permettant d'afficher une page ou un passage de texte contenant une alternative pertinente.
  • Un mécanisme permet à l'utilisateur de remplacer l'image objet par un texte alternatif pertinent.
  • Un mécanisme permet à l'utilisateur de remplacer l'image objet par une image possédant une alternative pertinente.

Modification du test 1.3.5

Mise en cohérence de la formulation suite à la création du test 1.1.6 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.3.5 est renuméroté en test 1.3.4.

Ancien test 1.3.5

Test 1.3.5 : Chaque image objet (balise object avec l'attribut type="image/...") porteuse d'information, qui utilise une propriété aria-label, aria-labelledby ou un attribut title, vérifie-t-elle ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut aria-label.
  • S'il est présent, le contenu de l'attribut title est identique au passage de texte lié par la propriété aria-labelledby.

Nouveau test 1.3.4

Test 1.3.4 : Pour chaque image objet (balise object avec l'attribut type="image/...") porteuse d'information, ayant une alternative textuelle ou un contenu alternatif, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent le contenu alternatif est pertinent.

Suppression du test 1.3.6

Remplacement par le test 1.1.7.

Ancien test 1.3.6

Test 1.3.6 : Chaque image embarquée (balise embed avec l'attribut type="image/...") porteuse d'information vérifie-t-elle une de ces conditions (hors cas particuliers)

  • L'image embarquée est immédiatement suivie d'un lien adjacent permettant d'afficher une page ou un passage de texte contenant une alternative pertinente.
  • Un mécanisme permet à l'utilisateur de remplacer l'image embarquée par un texte alternatif pertinent.
  • Un mécanisme permet à l'utilisateur de remplacer l'image embarquée par une image possédant une alternative pertinente.

Modification du test 1.3.7

Mise en cohérence de la formulation suite à la création du test 1.1.7 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.3.7 est renuméroté en test 1.3.5.

Ancien test 1.3.7

Test 1.3.7 : Chaque image embarquée (balise embed avec l'attribut type="image/...") porteuse d'information, qui utilise une propriété aria-label, aria-labelledby ou un attribut title, vérifie-t-elle ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut aria-label.
  • S'il est présent, le contenu de l'attribut title est identique au passage de texte lié par la propriété aria-labelledby.

Nouveau test 1.3.5

Test 1.3.5 : Pour chaque image embarquée (balise <embed> avec l'attribut type="image/...") porteuse d'information, ayant une alternative textuelle ou un contenu alternatif, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent le contenu alternatif est pertinent.

Suppression du test 1.3.8

Remplacement par le test 1.1.5.

Ancien test 1.3.8

Test 1.3.8 : Chaque image vectorielle (balise svg) porteuse d'information, en l'absence d'alternative, vérifie-t-elle ces conditions (hors cas particuliers)

  • La balise svg possède un role="img".
  • La balise svg possède une propriété aria-label dont le contenu est pertinent et identique à l'attribut title s'il est présent.
  • La balise svg possède une balise <title> dont le contenu est pertinent et contient un passage de texte identique à la propriété aria-label.

Modification du test 1.3.9

Mise en cohérence de la formulation suite à la création du test 1.1.5 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.3.9 est renuméroté en test 1.3.6.

Ancien test 1.3.9

Test 1.3.9 : Pour chaque image vectorielle (balise svg) porteuse d'information et possédant une alternative, cette alternative est-elle correctement restituée par les technologies d'assistance?

Nouveau test 1.3.6

Test 1.3.6 : Pour chaque image vectorielle (balise <svg>) porteuse d'information, ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Suppression du test 1.3.10

Remplacement par le test 1.1.8.

Ancien test 1.3.10

Test 1.3.10 : Chaque image bitmap (balise canvas) porteuse d'information vérifie-t-elle une de ces conditions (hors cas particuliers)

  • Le contenu de l'alternative (contenu entre <canvas> et </canvas>) est pertinent.
  • L'image bitmap est immédiatement suivie d'un lien adjacent permettant d'afficher une page ou un passage de texte contenant une alternative pertinente.
  • Un mécanisme permet à l'utilisateur de remplacer l'image bitmap par un texte alternatif pertinent.
  • Un mécanisme permet à l'utilisateur de remplacer l'image bitmap par une image possédant une alternative pertinente.

Modification du test 1.3.11

Mise en cohérence de la formulation suite à la création du test 1.1.8 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.3.11 est renuméroté en test 1.3.7.

Ancien test 1.3.11

Test 1.3.11 : Chaque image bitmap (balise canvas) porteuse d'information, qui utilise une propriété aria-label, aria-labelledby ou un attribut title, vérifie-t-elle ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut aria-label.
  • S'il est présent, le contenu de l'attribut title est identique au passage de texte lié par la propriété aria-labelledby.

Nouveau test 1.3.7

Test 1.3.7 : Pour chaque image bitmap (balise canvas) porteuse d'information, ayant une alternative textuelle ou un contenu alternatif, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent le contenu alternatif est pertinent.

Renumérotation des tests 1.3.12 et 1.3.13

Pour tenir compte des suppressions précédentes, les tests 1.3.12 et 1.3.13 sont renumérotés respectivement en tests 1.3.8 et 1.3.9.

Modification du test 1.4.1

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à une balise <img>.

Ancien test 1.4.1

Test 1.4.1 : Chaque image (balise img) utilisée comme CAPTCHA ou comme image-test, ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt permet de comprendre la nature et la fonction de l'image.
  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu de la propriété aria-label est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu du passage de texte lié via la propriété aria-labelledby est identique au contenu de l'attribut alt.

Nouveau test 1.4.1

Test 1.4.1 : Pour chaque image (balise <img>) utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative est-elle pertinente?

  • S'il est présent, le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Modification du test 1.4.2

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à une zone cliquable.

Ancien test 1.4.2

Test 1.4.2 : Chaque zone (balise area) d'une image réactive utilisée comme CAPTCHA ou comme image-test, ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt permet de comprendre la nature et la fonction de l'image.
  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu de la propriété aria-label est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu du passage de texte lié via la propriété aria-labelledby est identique au contenu de l'attribut alt.

Nouveau test 1.4.2

Test 1.4.2 : Pour chaque zone (balise <area>) d'une image réactive utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative est-elle pertinente?

  • S'il est présent, le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Modification du test 1.4.3

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à un bouton de type image

Ancien test 1.4.3

Test 1.4.3 : Chaque bouton associé à une image (balise input avec l'attribut type="image") utilisée comme CAPTCHA ou comme image-test, ayant un attribut alt, vérifie-t-elle ces conditions?

  • Le contenu de l'attribut alt permet de comprendre la nature et la fonction de l'image.
  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu de la propriété aria-label est identique au contenu de l'attribut alt.
  • S'il est présent, le contenu du passage de texte lié via la propriété aria-labelledby est identique au contenu de l'attribut alt.

Nouveau test 1.4.3

Test 1.4.3 : Pour chaque bouton de type image (balise input avec l'attribut type="image") utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative est-elle pertinente?

  • S'il est présent, le contenu de l'attribut alt est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Suppression du test 1.4.4

Remplacement par le test 1.1.6.

Ancien test 1.4.4

Test 1.3.10 : Chaque image objet (balise object avec l'attribut type="image") porteuse d'information vérifie-t-elle une de ces conditions (hors cas particuliers)

  • L'image objet est immédiatement suivie d'un lien adjacent permettant d'afficher une page ou un passage de texte contenant une alternative permettant de comprendre la nature et la fonction de l'image.
  • Un mécanisme permet à l'utilisateur de remplacer l'image objet par un texte alternatif permettant de comprendre la nature et la fonction de l'image.
  • Un mécanisme permet à l'utilisateur de remplacer l'image objet par une image possédant une alternative permettant de comprendre la nature et la fonction de l'image.

Modification du test 1.4.5

Mise en cohérence de la formulation suite à la création du test 1.1.6 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.4.5 est renuméroté en test 1.4.4.

Ancien test 1.4.5

Test 1.4.5 : Chaque image objet (balise object avec l'attribut type="image/...") utilisée comme CAPTCHA ou comme image-test, qui utilise une propriété aria-label, aria-labelledby ou un attribut title, vérifie-t-elle ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut aria-label.
  • S'il est présent, le contenu de l'attribut title est identique au passage de texte lié par la propriété aria-labelledby.

Nouveau test 1.4.4

Test 1.4.4 : Pour chaque image objet (balise object avec l'attribut type="image/...") utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle ou un contenu alternatif, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent le contenu alternatif est pertinent.

Suppression du test 1.4.6

Remplacement par le test 1.1.7.

Ancien test 1.4.6

Test 1.4.6 : Chaque image embarquée (balise embed avec l'attribut type="image/...") utilisée comme CAPTCHA ou comme image-test vérifie-t-elle une de ces conditions?

  • L'image embarquée est immédiatement suivie d'un lien adjacent permettant d'afficher une page ou un passage de texte contenant une alternative permettant de comprendre la nature et la fonction de l'image.
  • Un mécanisme permet à l'utilisateur de remplacer l'image embarquée par un texte alternatif permettant de comprendre la nature et la fonction de l'image.
  • Un mécanisme permet à l'utilisateur de remplacer l'image embarquée par une image possédant une alternative permettant de comprendre la nature et la fonction de l'image.

Modification du test 1.4.7

Mise en cohérence de la formulation suite à la création du test 1.1.7 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.4.7 est renuméroté en test 1.4.5.

Ancien test 1.4.7

Test 1.4.7 : Chaque image embarquée (balise embed avec l'attribut type="image/...") utilisée comme CAPTCHA ou comme image-test, qui utilise une propriété aria-label, aria-labelledby ou un attribut title, vérifie-t-elle ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut aria-label.
  • S'il est présent, le contenu de l'attribut title est identique au passage de texte lié par la propriété aria-labelledby.

Nouveau test 1.4.5

Test 1.4.5 : Pour chaque image embarquée (balise <embed> avec l'attribut type="image/...") utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle ou un contenu alternatif, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent le contenu alternatif est pertinent.

Suppression du test 1.4.8

Remplacement par le test 1.1.5.

Ancien test 1.4.8

Test 1.4.8 : Chaque image vectorielle (balise svg) utilisée comme CAPTCHA ou comme image-test, en l'absence d'alternative, vérifie-t-elle ces conditions (hors cas particuliers)

  • La balise svg possède un role="img".
  • La balise svg possède une propriété aria-label dont le contenu permet de comprendre la nature et la fonction de l'image et identique à l'attribut title s'il est présent.
  • La balise svg possède une balise <title> dont le contenu permet de comprendre la nature et la fonction de l'image et identique à la propriété aria-label.
  • Un lien adjacent permet d'accéder à une alternative dont le contenu permet de comprendre la nature et la fonction de l'image et identique à la propriété aria-label.

Modification du test 1.4.9

Mise en cohérence de la formulation suite à la création du test 1.1.5 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.4.9 est renuméroté en test 1.4.6.

Ancien test 1.4.9

Test 1.4.9 : Pour chaque image vectorielle (balise svg) utilisée comme CAPTCHA ou comme image-test, possédant une alternative, cette alternative est-elle correctement restituée par les technologies d'assistance?

Nouveau test 1.4.6

Test 1.4.6 : Pour chaque image vectorielle (balise <svg>) utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.

Suppression du test 1.4.10

Remplacement par le test 1.1.8.

Ancien test 1.4.10

Test 1.4.10 : Chaque image bitmap (balise canvas) utilisée comme CAPTCHA ou comme image-test vérifie-t-elle une de ces conditions (hors cas particuliers)

  • Le contenu de l'alternative (contenu entre <canvas> et </canvas>) permet de comprendre la nature et la fonction de l'image.
  • L'image bitmap est immédiatement suivie d'un lien adjacent permettant d'afficher une page ou un passage de texte contenant une alternative permettant de comprendre la nature et la fonction de l'image.
  • Un mécanisme permet à l'utilisateur de remplacer l'image bitmap par un texte alternatif permettant de comprendre la nature et la fonction de l'image.
  • Un mécanisme permet à l'utilisateur de remplacer l'image bitmap par une image possédant une alternative permettant de comprendre la nature et la fonction de l'image.

Modification du test 1.4.11

Mise en cohérence de la formulation suite à la création du test 1.1.8 et prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle.

Le test 1.4.11 est renuméroté en test 1.4.7.

Ancien test 1.4.11

Test 1.4.11 : Chaque image bitmap (balise canvas) utilisée comme CAPTCHA ou comme image-test, qui utilise une propriété aria-label, aria-labelledby ou un attribut title, vérifie-t-elle ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est identique au contenu de l'attribut aria-label.
  • S'il est présent, le contenu de l'attribut title est identique au passage de texte lié par la propriété aria-labelledby.

Nouveau test 1.4.7

Test 1.4.7 : Pour chaque image bitmap (balise <canvas>) utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle ou un contenu alternatif, cette alternative est-elle pertinente (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut title est pertinent.
  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte associé via l'attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent le contenu alternatif est pertinent.

Suppression du test 1.4.12

Le support de l'alternative de l'élément <canvas> est désormais assuré par les principaux lecteurs d'écran.

Ancien test 1.4.12

Test 1.4.12 : Pour chaque image bitmap (balise <canvas>) utilisée comme CAPTCHA ou comme image-test, ayant une alternative (contenu entre <canvas> et </canvas>), cette alternative est-elle correctement restituée par les technologies d'assistance?

Modification de la note technique du critère 1.6

Mise à jour suite à l’évolution du test 1.6.6.

Ancienne note technique

Le manque de support de l'élément <title> par les technologies d'assistance crée une difficulté dans le cas de l'utilisation de l'élément <desc> pour implémenter l'alternative courte de l'image si l'image nécessite une description détaillée. Dans ce cas il est recommandé d'utiliser un texte adjacent ou un lien adjacent pour créer la description détaillée.

Si l'élément <desc> est utilisé pour implémenter la description détaillée, il est recommandé d'utiliser un attribut aria-label pour implémenter l'alternative courte de l'image.

L'utilisation de l'attribut aria-describedby n'est pas possible pour lier une image à sa description détaillée par manque de support des technologies d'assistance.

La description détaillée adjacente peut être implémentée via une balise <figcaption>, dans ce cas le critère 1.10 doit être vérifié (utilisation de <figure> et du rôle group, notamment).

Nouvelle note technique

Dans le cas du SVG, le manque de support de l'élément <title> et <desc> par les technologies d'assistance crée une difficulté dans le cas de l'implémentation de l'alternative textuelle de l'image et de sa description détaillée. Dans ce cas, il est recommandé d'utiliser l'attribut WAI-ARIA aria-label pour implémenter à la fois l'alternative textuelle courte et la référence à description détaillée adjacente ou l'attribut WAI-ARIA aria-labelledby pour associer les passages de texte faisant office d'alternative courte et de description détaillée.

L'utilisation de l'attribut WAI-ARIA aria-describedby n'est pas possible pour lier une image à sa description détaillée par manque de support des technologies d'assistance.

La description détaillée adjacente peut être implémentée via une balise <figcaption>, dans ce cas le critère 1.9 doit être vérifié (utilisation de <figure> et des attributs WAI-ARIA role="figure" et aria-label, notamment).

Modification du test 1.5.1

Prise en compte de l’attribut WAI-ARIA role="img".

Ancien test 1.5.1

Test 1.5.1 : Chaque image (balises img, area, object, embed, svg, canvas) utilisée comme CAPTCHA vérifie-t-elle une de ces conditions?

  • Il existe une autre forme de CAPTCHA non graphique, au moins.
  • Il existe une autre solution d'accès à la fonctionnalité sécurisée par le CAPTCHA.

Nouveau test 1.5.1

Test 1.5.1 : Chaque image (balises <img>, <area>, <object>, <embed>, <svg>, <canvas> ou possédant un attribut WAI-ARIA role="img") utilisée comme CAPTCHA vérifie-t-elle une de ces conditions?

  • Il existe une autre forme de CAPTCHA non graphique, au moins.
  • Il existe une autre solution d'accès à la fonctionnalité qui est sécurisée par le CAPTCHA.

Modification du test 1.6.2

Suppression de l’utilisation d’une description détaillée clairement identifiable au profit de la prise en compte des alternatives textuelles à une balise <object> faisant référence à la description détaillée.

Prise en compte de l’usage de bouton adjacent.

Ancien test 1.6.2

Test 1.6.2 : Chaque image objet (balise object avec l'attribut type="image/...") porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions?

  • Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée.
  • Il existe une description détaillée clairement identifiable adjacente à l'image objet.

Nouveau test 1.6.2

Test 1.6.2 : Chaque image objet (balise <object> avec l'attribut type="image/...") porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions?

  • Il existe une alternative textuelle contenant la référence à une description détaillée adjacente à l'image.
  • Il existe un lien ou un bouton adjacent permettant d'accéder à la description détaillée.

Modification du test 1.6.3

Suppression de l’utilisation d’une description détaillée clairement identifiable au profit de la prise en compte des alternatives textuelles à une balise <embed> faisant référence à une description détaillée.

Prise en compte de l’usage de bouton adjacent.

Ancien test 1.6.3

Test 1.6.3 : Chaque image embarquée (balise embed) porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions?

  • Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée.
  • Il existe une description détaillée clairement identifiable adjacente à l'image embarquée.

Nouveau test 1.6.3

Test 1.6.3 : Chaque image embarquée (balise <embed>) porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions?

  • Il existe une alternative textuelle contenant la référence à une description détaillée adjacente à l'image.
  • Il existe un lien ou un bouton adjacent permettant d'accéder à la description détaillée.

Modification du test 1.6.4

Suppression de l’utilisation d’une description détaillée clairement identifiable au profit de la prise en compte des alternatives textuelles à une balise <object> faisant référence à la description détaillée.

Prise en compte de l’usage de bouton adjacent.

Ancien test 1.6.4

Test 1.6.4 : Chaque bouton de type image (balise input avec l'attribut type="image") porteur d'information, qui nécessite une description détaillée, vérifie-t-il une de ces conditions?

  • Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée.
  • Il existe une description détaillée clairement identifiable adjacente à l'image objet.
  • Il existe une propriété aria-describedby référençant un passage de texte faisant office de description détaillée.

Nouveau test 1.6.4

Test 1.6.4 : Chaque bouton de type image (balise <input> avec l'attribut type="image") porteur d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions?

  • Il existe une alternative textuelle contenant la référence à une description détaillée adjacente à l'image.
  • Il existe un lien ou un bouton adjacent permettant d'accéder à la description détaillée.
  • Il existe un attribut WAI-ARIA aria-describedby associant un passage de texte faisant office de description détaillée.

Suppression du test 1.6.5

Suppression de la possibilité d’associer la description détaillée via l’attribut aria-describedby au test 1.6.4

Ancien test 1.6.5

Test 1.6.5 : Chaque bouton de type image (balise input avec l'attribut type="image") porteur d'information, qui implémente une référence à une description détaillée via une propriété aria-describedby, vérifie-t-il ces conditions?

  • Le passage de texte est identifié via un attribut id.
  • La valeur de l'attribut id est unique.
  • La valeur de la propriété ARIA aria-describedby est égale à la valeur de l'attribut id.

Modification du test 1.6.6

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à une balise <svg> dans laquelle il est possible de faire référence à la description détaillée.

Prise en compte de l’usage de bouton adjacent.

Suppression de la possibilité d’avoir recours à la balise <title> et <desc> dont le support est insuffisant pour permettre de fournir ou faire référence à une description détaillée lorsqu’ils sont utilisés sans être associé à la balise <svg> via l’attribut WAI-ARIA aria-labelledby ou aria-describedby.

Le test 1.6.6 est renuméroté en test 1.6.5.

Ancien test 1.6.6

Test 1.6.6 : Chaque image vectorielle (balise svg) porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions?

  • Il existe une propriété aria-label contenant une référence à une description détaillée adjacente à l'image vectorielle.
  • La balise title contient une référence à une description détaillée adjacente à l'image vectorielle.
  • Il existe une balise desc contenant la description détaillée.
  • Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée.

Nouveau test 1.6.5

Test 1.6.5 : Chaque image vectorielle (balise <svg>) porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions ?

  • Il existe un attribut WAI-ARIA aria-label contenant l'alternative textuelle et une référence à une description détaillée adjacente.
  • Il existe un attribut WAI-ARIA aria-labelledby associant un passage de texte faisant office d'alternative textuelle et un autre faisant office de description détaillée.
  • Il existe un attribut WAI-ARIA aria-describedby associant un passage de texte faisant office de description détaillée.
  • Il existe un lien ou un bouton adjacent permettant d'accéder à la description détaillée.

Modification du test 1.6.7

Mise à jour suite à modification du test 1.6.6.

Le test 1.6.7 est renuméroté en test 1.6.6.

Ancien test 1.6.7

Test 1.6.6 : Chaque image vectorielle (balise svg) porteuse d'information, qui implémente une référence à une description détaillée adjacente via une propriété aria-label ou une balise desc, cette référence est-elle correctement restituée par les technologies d'assistance?

Nouveau test 1.6.6

Test 1.6.6 : Pour chaque image vectorielle (balise <svg>) porteuse d'information, ayant une description détaillée, la référence éventuelle à la description détaillée dans l'attribut WAI-ARIA aria-label et la description détaillée associée par l'attribut WAI-ARIA aria-labelledby ou aria-describedby sont-elles correctement restituées par les technologies d'assistance?

Modification du test 1.6.8

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle à une balise <canvas>.

Prise en compte de la mise à disposition d’une description détaillée via un bouton.

Le test 1.6.8 est renuméroté en test 1.6.7.

Ancien test 1.6.8

Test 1.6.8 : Chaque image bitmap (balise canvas) porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions ?

  • Il existe un passage de texte entre <canvas> et </canvas> contenant une référence à une description détaillée adjacente à l'image bitmap.
  • Il existe un contenu textuel entre <canvas> et </canvas> faisant office de description détaillée.
  • Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée.

Nouveau test 1.6.7

Test 1.6.7 : Chaque image bitmap (balise <canvas>) porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions ?

  • Il existe un attribut WAI-ARIA aria-label contenant l'alternative textuelle et une référence à une description détaillée adjacente.
  • Il existe un attribut WAI-ARIA aria-labelledby associant un passage de texte faisant office d'alternative textuelle et un autre faisant office de description détaillée.
  • Il existe un contenu textuel entre <canvas> et </canvas> faisant référence à une description détaillée adjacente à l'image bitmap.
  • Il existe un contenu textuel entre <canvas> et </canvas> faisant office de description détaillée.
  • Il existe un lien ou bouton adjacent permettant d'accéder à la description détaillée.

Renumérotation du test 1.6.9

Pour tenir compte des suppressions précédentes, le test 1.6.9 est renuméroté en test 1.6.8.

Modification du test 1.6.10

Prise en compte de l’attribut WAI-ARIA role="img".

Le test 1.6.10 est renuméroté en test 1.6.9.

Ancien test 1.6.10

Test 1.6.10 : Pour chaque image (balise img, area, object, embed, svg, canvas) porteuse d'information, qui implémente une description détaillée et qui utilise une propriété aria-describedby, la propriété aria-describedby référence-t-elle la description détaillée?

Nouveau test 1.6.9

Test 1.6.9 : Pour chaque image (balise <img>, <input> avec l'attribut type="image", <area>, <object>, <embed>, <svg>, <canvas>, ou possédant un attribut WAI-ARIA role="img") porteuse d'information, qui est accompagnée d'une description détaillée et qui utilise un attribut WAI-ARIA aria-describedby, l'attribut WAI-ARIA aria-describedby associe-t-il la description détaillée?

Création du test 1.6.10

Prise en compte des balises pourvues de l’attribut WAI-ARIA role="img".

Nouveau test 1.6.10

Test 1.6.10 : Chaque balise possédant un attribut WAI-ARIA role="img" porteuse d'information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions ?

  • Il existe un attribut WAI-ARIA aria-label contenant l'alternative textuelle et une référence à une description détaillée adjacente.
  • Il existe un attribut WAI-ARIA aria-labelledby associant un passage de texte faisant office d'alternative textuelle et un autre faisant office de description détaillée.
  • Il existe un lien ou bouton adjacent permettant d'accéder à la description détaillée.

Modification du test 1.7.1

Prise en compte du signalement par le biais de l’ensemble des techniques permettant d’associer une alternative textuelle et par le biais d’un bouton adjacent.

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Ancien test 1.7.1

Test 1.7.1 : Chaque image (balise img) porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée via l'adresse référencée dans l'attribut longdesc est pertinente.
  • La description détaillée dans la page et signalée par l'alternative textuelle est pertinente.
  • La description détaillée via un lien adjacent est pertinente.

Nouveau test 1.7.1

Test 1.7.1 : Chaque image (balise <img>) porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée via l'adresse référencée dans l'attribut longdesc est pertinente.
  • La description détaillée dans la page et signalée dans l'attribut alt est pertinente.
  • La description détaillée via un lien ou bouton adjacent est pertinente.
  • Le passage de texte associé via l'attribut WAI-ARIA aria-describedby est pertinent.

Modification du test 1.7.2

Prise en compte du signalement par le biais de l’ensemble des techniques permettant d’associer une alternative textuelle et par le biais d’un bouton adjacent.

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Ancien test 1.7.2

Test 1.7.2 : Chaque bouton de type image (balise input avec l'attribut type="image") porteur d'information, ayant une description détaillée, vérifie-t-il ces conditions?

  • La description détaillée dans la page et signalée dans l'attribut alt est pertinente.
  • La description détaillée via un lien adjacent est pertinente.
  • Le passage de texte référencé via la propriété aria-describedby est pertinent.

Nouveau test 1.7.2

Test 1.7.2 : Chaque bouton de type image (balise <input> avec l'attribut type="image") porteur d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée dans la page et signalée par l'alternative textuelle est pertinente.
  • La description détaillée via un lien ou bouton adjacent est pertinente.
  • Le passage de texte associé via l'attribut WAI-ARIA aria-describedby est pertinent.

Modification du test 1.7.3

Prise en compte du signalement par le biais de l’ensemble des techniques permettant d’associer une alternative textuelle et par le biais d’un bouton adjacent.

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Ancien test 1.7.3

Test 1.7.3 : Chaque image objet (balise object avec l'attribut type="image/...") porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée adjacente à l'image objet est pertinente.
  • La description détaillée via un lien adjacent est pertinente.

Nouveau test 1.7.3

Test 1.7.3 : Chaque image objet (balise <object> avec l'attribut type="image/...") porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée dans la page et signalée par l'alternative textuelle est pertinente.
  • La description détaillée adjacente à l'image objet est pertinente.
  • La description détaillée via un lien ou bouton adjacent est pertinente.
  • Le passage de texte associé via l'attribut WAI-ARIA aria-describedby est pertinent.

Modification du test 1.7.4

Prise en compte du signalement par le biais de l’ensemble des techniques permettant d’associer une alternative textuelle et par le biais d’un bouton adjacent.

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Ancien test 1.7.4

Test 1.7.4 : Chaque image embarquée (balise embed avec l'attribut type="image/...") porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée adjacente à l'image embarquée est pertinente.
  • La description détaillée via un lien adjacent est pertinente.

Nouveau test 1.7.4

Test 1.7.4 : Chaque image embarquée (balise <embed> avec l'attribut type="image/...") porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée dans la page et signalée par l'alternative textuelle est pertinente.
  • La description détaillée adjacente à l'image embarquée est pertinente.
  • La description détaillée via un lien ou bouton adjacent est pertinente.
  • Le passage de texte associé via l'attribut WAI-ARIA aria-describedby est pertinent.

Modification du test 1.7.5

Prise en compte du signalement par le biais de l’ensemble des alternative textuelles possibles, par le biais de la balise <title>, par le biais d’un bouton adjacent.

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Ancien test 1.7.5

Test 1.7.5 : Chaque image vectorielle (balise svg) porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée adjacente à l'image vectorielle et signalée dans la propriété aria-label ou la balise desc est pertinente.
  • La description détaillée contenue dans la balise desc est pertinente.
  • La description détaillée via un lien adjacent est pertinente.

Nouveau test 1.7.5

Test 1.7.5 : Chaque image embarquée (balise <svg>) porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée dans la page et signalée par l'alternative textuelle est pertinente.
  • La description détaillée dans la page et signalée par le texte contenu dans la balise <desc> ou <title> est pertinente.
  • La description détaillée contenue dans la balise <desc> est pertinente.
  • La description détaillée via un lien ou bouton adjacent est pertinente.
  • Le passage de texte associé via l'attribut WAI-ARIA aria-describedby est pertinent.

Suppression du test 1.7.6

Suppression suite à la mise à jour des tests 1.6.6 et 1.6.7.

Ancien test 1.7.6

Test 1.7.6 : Pour chaque image vectorielle (balise svg) porteuse d'information, ayant une description détaillée implémentée via la balise desc, cette description détaillée est-elle correctement restituée par les technologies d'assistance?

Modification du test 1.7.7

Prise en compte du signalement par le biais de l’alternative textuelle, par le biais d’un contenu alternatif entre <canvas> et </canvas>, par le biais d’un bouton adjacent.

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Le test 1.7.7 est renuméroté en test 1.7.6.

Ancien test 1.7.7

Test 1.7.7 : Chaque image bitmap (balise canvas) porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée adjacente à l'image bitmap est pertinente.
  • La description détaillée contenue entre <canvas> et </canvas> est pertinente.
  • La description détaillée via un lien adjacent est pertinente.

Nouveau test 1.7.6

Test 1.7.6 : Chaque image bitmap (balise <canvas>) porteuse d'information, ayant une description détaillée, vérifie-t-elle ces conditions?

  • La description détaillée dans la page et signalée par l'alternative textuelle est pertinente.
  • La description détaillée dans la page et signalé par le texte contenu entre <canvas> et </canvas> est pertinente.
  • La description détaillée adjacente à l'image bitmap est pertinente.
  • La description détaillée via un lien ou bouton adjacent est pertinente.
  • Le passage de texte associé via l'attribut WAI-ARIA aria-describedby est pertinent.

Suppression du test 1.7.8

Mise à jour suite à l’évolution du support des technologies d’assistance.

Ancien test 1.7.8

Test 1.7.8 : Pour chaque image bitmap (balise canvas) porteuse d'information, ayant une description détaillée entre <canvas> et </canvas>, cette description détaillée est-elle correctement restituée par les technologies d'assistance?

Modification des cas particuliers 1.8

Prise en compte explicite du cas où l’exactitude graphique est “essentielle” tel que prévu par le critère 1.4.5 des WCAG 2.1.

Anciens cas particuliers 1.8

Pour ce critère, il existe une gestion de cas particulier lorsque le texte fait partie d'un logo ou d'un élément associé à l'identité graphique d'un organisme ou d'une société (un slogan, par exemple) ou lorsque le texte en image est utilisé comme CAPTCHA ou comme image-test. Dans ces situations, le critère est non applicable pour ces éléments.

Nouveaux cas particuliers 1.8

Pour ce critère, il existe une gestion de cas particulier lorsque le texte fait partie du logo, d’une dénomination commerciale, d’un CAPTCHA, d’une image-test ou d'une image dont l’exactitude graphique serait considérée comme essentielle à la bonne transmission de l'information véhiculée par l'image. Dans ces situations, le critère est non applicable pour ces éléments.

Modification du test 1.8.1

Mise à jour syntaxique et prise en compte de l’attribut WAI-ARIA role="img".

Vérification de la pertinence de la description détaillée fournie par l’attribut WAI-ARIA aria-describedby puisqu’il est supporté par certaines aides techniques.

Ancien test 1.8.1

Test 1.8.1 : Chaque image texte (balise img) porteuse d'information, en l'absence d'un mécanisme de remplacement, doit si possible être remplacé par du texte stylé. Cette règle est-elle respectée (hors cas particuliers)?

Nouveau test 1.8.1

Test 1.8.1 : Chaque image texte (balise <img> ou possédant un attribut WAI-ARIA role="img") porteuse d'information, en l'absence d'un mécanisme de remplacement, doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ?

Suppression du critère 1.9 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 1.9

Critère 1.9 [AAA] Chaque image texte porteuse d'information, doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée (hors cas particuliers)?

Suppression des cas particuliers 1.9

Suppression du critère 1.9.

Anciens cas particuliers 1.8

Pour ce critère, il existe une gestion de cas particulier lorsque le texte fait partie d'un logo ou d'un élément associé à l'identité graphique d'un organisme ou d'une société (un slogan, par exemple) ou lorsque le texte en image est utilisé comme CAPTCHA ou comme image-test. Dans ces situations, le critère est non applicable pour ces éléments.

Renumérotation du critère 1.10

Pour tenir compte de la suppression du critère 1.9, le critère 1.10 est renuméroté en critère 1.9.

Modification de la note technique du critère 1.10

Mise à jour suite à l’évolution du support des éléments <figure> et <ficaption> par les technologies d’assistance.

Cette note est désormais associée au critère 1.9 compte tenu de la renumérotation du critère 1.10.

Ancienne note technique

L'implémentation d'un role="group" sur l'élément parent figure est destiné à pallier le manque de support actuel des éléments figure par les technologies d'assistance. Bien que recommandée, l'utilisation d'un élément figcaption dans un élément figure est optionnelle. En revanche l'utilisation d'un élément figcaption pour associer une légende à une image impose l'utilisation d'un élément parent figure. La référence à la légende adjacente peut être une expression du type « image 1 » ou équivalent lorsque cette expression est reprise dans la légende.

Bien que recommandé par HTML5, la note WCAG stipule que le title ne peut pas être utilisé pour « labelliser » l'image.

Les attributs aria-labelledby et aria-describedby ne peuvent pas être utilisés actuellement par manque de support par les technologies d'assistance.

Note : les images légendées doivent par ailleurs respecter le critère 1.3 relatif aux images porteuses d'information.

Nouvelle note technique

L'implémentation d'un attribut WAI-ARIA role="group" ou role="figure" sur l'élément parent <figure> est destiné à pallier le manque de support actuel des éléments <figure> par les technologies d'assistance. L'utilisation d'un élément <figcaption> pour associer une légende à une image impose au minimum l'utilisation d'un attribut WAI-ARIA aria-label sur l'élément parent <figure> dont le contenu sera identique au contenu de l'élément <figcaption>. Pour s’assurer d’un support optimal, il peut également être fait une association explicite entre le contenu de l’alternative textuelle de l’image et le contenu de l’élément <figcaption>, par exemple :

<img src="image.png" alt="Photo : soleil couchant" /><figcaption>Photo : crédit xxx</figcaption>

Les attributs aria-labelledby et aria-describedby ne peuvent pas être utilisés actuellement par manque de support par les technologies d'assistance.

Note : les images légendées doivent par ailleurs respecter les critères 1.1 et 1.3 relatifs aux images porteuses d'information.

Modification du test 1.10.1

Mise à jour suite à l’évolution du support des technologies d’assistance.

Le test 1.10.1 est renuméroté en test 1.9.1.

Ancien test 1.10.1

Test 1.10.1 : Chaque image légendée (balise img ou input avec l'attribut type="image" associée à une légende adjacente) vérifie-t-elle, si nécessaire, ces conditions?

  • L'image (balise img) et sa légende sont contenues dans une balise figure.
  • La balise figure possède un attribut role="group".
  • Le contenu de l'attribut alt de l'image contient une référence à la légende adjacente.

Nouveau test 1.9.1

Test 1.9.1 : Chaque image pourvue d'une légende (balise <img>, <input> avec l'attribut type="image" ou possédant un attribut WAI-ARIA role="img" associée à une légende adjacente), ayant une alternative textuelle, vérifie-t-elle, si nécessaire, ces conditions?

  • L'image (balise <img>, <input> avec l'attribut type="image" ou possédant un attribut WAI-ARIA role="img") et sa légende adjacente sont contenues dans une balise <figure>.
  • La balise <figure> possède un attribut WAI-ARIA role="figure" ou role="group".
  • La balise <figure> possède un attribut WAI-ARIA aria-label dont le contenu est identique au contenu de la légende.
  • La légende est contenue dans une balise <figcaption>.

Modification du test 1.10.2

Mise à jour suite à l’évolution du support des technologies d’assistance.

Le test 1.10.2 est renuméroté en test 1.9.2.

Ancien test 1.10.2

Test 1.10.2 : Chaque image objet légendée (balise object avec l'attribut type="image/..." associée à une légende adjacente) vérifie-t-elle, si nécessaire, ces conditions?

  • L'image objet (balise object) et sa légende sont contenues dans une balise figure.
  • La balise figure possède un attribut role="group".

Nouveau test 1.9.2

Test 1.9.2 : Chaque image objet pourvue d'une légende (balise <object> avec l'attribut type="image/..." associée à une légende adjacente), ayant une alternative textuelle, vérifie-t-elle, si nécessaire, ces conditions?

  • L'image objet (balise <object>) et sa légende adjacente sont contenues dans une balise <figure>.
  • La balise <figure> possède un attribut WAI-ARIA role="figure" ou role="group".
  • La balise <figure> possède un attribut WAI-ARIA aria-label dont le contenu est identique au contenu de la légende.
  • La légende est contenue dans une balise <figcaption>.

Modification du test 1.10.3

Mise à jour suite à l’évolution du support des technologies d’assistance.

Le test 1.10.3 est renuméroté en test 1.9.3.

Ancien test 1.10.3

Test 1.10.3 : Chaque image embarquée légendée (balise embed associée à une légende adjacente) vérifie-t-elle, si nécessaire, ces conditions?

  • L'image embarquée (balise embed) et sa légende sont contenues dans une balise figure.
  • La balise figure possède un attribut role="group".
  • L'alternative contient une référence à la légende adjacente.

Nouveau test 1.9.3

Test 1.9.3 : Chaque image embarquée pourvue d'une légende (balise <embed> associée à une légende adjacente), ayant une alternative textuelle, vérifie-t-elle, si nécessaire, ces conditions?

  • L'image embarquée (balise <embed>) et sa légende adjacente sont contenues dans une balise <figure>.
  • La balise <figure> possède un attribut WAI-ARIA role="figure" ou role="group".
  • La balise <figure> possède un attribut WAI-ARIA aria-label dont le contenu est identique au contenu de la légende.
  • La légende est contenue dans une balise <figcaption>.

Modification du test 1.10.4

Mise à jour suite à l’évolution du support des technologies d’assistance.

Le test 1.10.4 est renuméroté en test 1.9.4.

Ancien test 1.10.4

Test 1.10.4 : Chaque image vectorielle légendée (balise svg associée à une légende adjacente) vérifie-t-elle, si nécessaire, ces conditions?

  • L'image vectorielle (balise svg) et sa légende sont contenues dans une balise figure.
  • La balise figure possède un attribut role="group".
  • Le contenu de la propriété aria-label ou de la balise desc de l'image vectorielle contient une référence à la légende adjacente.

Nouveau test 1.9.4

Test 1.9.4 : Chaque image vectorielle pourvue d'une légende (balise <svg> associée à une légende adjacente), ayant une alternative textuelle, vérifie-t-elle, si nécessaire, ces conditions?

  • L'image vectorielle (balise <svg>) et sa légende adjacente sont contenues dans une balise <figure>.
  • La balise <figure> possède un attribut WAI-ARIA role="figure" ou role="group".
  • La balise <figure> possède un attribut WAI-ARIA aria-label dont le contenu est identique au contenu de la légende.
  • La légende est contenue dans une balise <figcaption>.

Modification du test 1.10.5

Mise à jour suite à l’évolution du support des technologies d’assistance.

Le test 1.10.5 est renuméroté en test 1.9.5.

Ancien test 1.10.5

Test 1.10.5 : Chaque image bitmap légendée (balise canvas associée à une légende adjacente) vérifie-t-elle, si nécessaire, ces conditions?

  • L'image bitmap (balise canvas) et sa légende sont contenues dans une balise figure.
  • La balise figure possède un attribut role="group".
  • Le contenu entre <canvas> et </canvas> de l'image bitmap contient une référence à la légende adjacente.

Nouveau test 1.9.5

Test 1.9.5 : Chaque image bitmap pourvue d'une légende (balise <canvas> associée à une légende adjacente), ayant une alternative textuelle, vérifie-t-elle, si nécessaire, ces conditions?

  • L'image bitmap (balise <canvas>) et sa légende adjacente sont contenues dans une balise <figure>.
  • La balise <figure> possède un attribut WAI-ARIA role="figure" ou role="group".
  • La balise <figure> possède un attribut WAI-ARIA aria-label dont le contenu est identique au contenu de la légende.
  • La légende est contenue dans une balise <figcaption>.

Modification du critère 2.1

Mise à jour suite au remplacement de l'entrée de glossaire "cadre en ligne" par "cadre et cadre en ligne" car le RGAA s'applique également aux balises et aux attributs utilisés en HTML4 et en XHTML.

Ancien critère 2.1

Critère 2.1 [A] Chaque cadre en ligne a-t-il un titre de cadre?

Nouveau critère 2.1

Critère 2.1 Chaque cadre a-t-il un titre de cadre ?

Modification du test 2.1.1

Mise à jour suite au remplacement de l'entrée de glossaire "cadre en ligne" par "cadre et cadre en ligne" car le RGAA s'applique également aux balises et aux attributs utilisés en HTML4 et en XHTML.

Ancien test 2.1.1

Test 2.1.1 : Chaque cadre en ligne (balise <iframe>) a-t-il un attribut title?

Nouveau test 2.1.1

Test 2.1.1 : Chaque cadre (balise <iframe> ou <frame>) a-t-il un attribut title ?

Modification du critère 2.2

Mise à jour suite au remplacement de l'entrée de glossaire "cadre en ligne" par "cadre et cadre en ligne" car le RGAA s'applique également aux balises et aux attributs utilisés en HTML4 et en XHTML.

Ancien critère 2.2

Critère 2.2 [A] Pour chaque cadre en ligne ayant un titre de cadre, ce titre de cadre est-il pertinent?

Nouveau critère 2.2

Critère 2.2 Chaque cadre a-t-il un titre de cadre ?

Modification du test 2.2.1

Mise à jour suite au remplacement de l'entrée de glossaire "cadre en ligne" par "cadre et cadre en ligne" car le RGAA s'applique également aux balises et aux attributs utilisés en HTML4 et en XHTML.

Ancien test 2.2.1

Test 2.2.1 : Pour chaque cadre en ligne (balise <iframe>) ayant un attribut title, le contenu de cet attribut est-il pertinent?

Nouveau test 2.2.1

Test 2.2.1 : Pour chaque cadre (balise <iframe> ou <frame>) ayant un attribut title, le contenu de cet attribut est-il pertinent?

Suppression du critère 3.2 et des tests associés

Mise à jour de l’entrée de glossaire Information (donnée par la couleur).

Ancien critère 3.2

Critère 3.2 [A] Dans chaque page web, l'information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle implémentée de façon pertinente?

Renumérotation du critère 3.3

Pour tenir compte de la suppression du critère 3.2, le critère 3.3 est renuméroté en critère 3.2.

Modification du test 3.3.1

Passage à l’usage des pixels pour définir la taille de caractères tel que décrit dans le document Understanding Success Criterion 1.4.3: Contrast (Minimum) des WCAG 2.1.

Renumérotation du test 3.3.1 en test 3.2.1.

Ancien test 3.3.1

Test 3.3.1 : Dans chaque page web, jusqu'à 150% de la taille de police par défaut (ou 1.5em), le texte et le texte en image sans effet de graisse vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 4.5:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 4.5:1, au moins.

Nouveau test 3.2.1

Test 3.2.1 : Dans chaque page web, le texte et le texte en image sans effet de graisse d'une taille restituée inférieure à 24px vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 4.5:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 4.5:1, au moins.

Modification du test 3.3.2

Passage à l’usage des pixels pour définir la taille de caractères tel que décrit dans le document Understanding Success Criterion 1.4.3: Contrast (Minimum) des WCAG 2.1.

Renumérotation du test 3.3.2 en test 3.2.2.

Ancien test 3.3.2

Test 3.3.2 : Dans chaque page web, jusqu'à 120% de la taille de police par défaut (ou 1.2em), le texte et le texte en image en gras vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 4.5:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 4.5:1, au moins.

Nouveau test 3.2.2

Test 3.2.2 : Dans chaque page web, le texte et le texte en image en gras d'une taille restituée inférieure à 18,5px vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 4.5:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 4.5:1, au moins.

Modification des cas particuliers 3.3 - 3.4

Suppression des notes 2 et 3 car rien n’est précisé dans les WCAG concernant les états des liens, et les textes visibles au survol ou à la prise de focus sont explicitement couverts par le critère 1.4.3 d’après le document Understanding Success Criterion 1.4.3: Contrast (Minimum) des WCAG 2.1.

Les cas particuliers ne s'appliquent plus qu'au critère 3.3 compte tenu de la suppression du critère 3.4.

Anciens cas particuliers 3.3 - 3.4

Dans ces situations, les critères sont non applicables pour ces éléments.

  • Le texte fait partie d'un logo ou d'un élément associé à l'identité graphique d'un organisme ou d'une société;
  • Le texte fait partie d'une image de décoration;
  • Le texte inséré dans une image porteuse d'information n'apporte aucune information essentielle;
  • Le texte fait partie d'un élément interactif (par exemple un bouton avec l'attribut disabled) sur lequel aucune action n'est possible et qui n'apporte pas une information essentielle;
  • Le texte est inséré via l'attribut placeholder et n'apporte aucune information essentielle;
  • Le texte est inséré dans une image utilisée comme CAPTCHA ou comme image-test.

Note 1 : Les cas particuliers concernant des textes associés à l'identité graphique d'un organisme ou d'une société devraient être limités à des éléments particuliers comme un slogan par exemple. Dans le cas où c'est l'intégralité d'une charte graphique, particulièrement lorsque la charte graphique est imposée, qui est en cause, comme un choix de couleur de police par exemple, la solution consiste à avoir recours à une version alternative, à fort contraste.

Note 2 : Les changements de couleur consécutifs à la prise de focus ne sont pas concernés par l'application du critère, sauf si le contenu change également lors de la prise de focus.

Note 3 : les indications des états de liens (visités ou actifs) ne sont pas concernées par l'application du critère.

Nouveaux cas particuliers 3.3

Les cas suivants sont non applicables pour ce critère :

  • Composant d'interface inactif (exemple un bouton avec un attribut disabled) sur lequel aucune action n'est possible.
  • Composant d'interface pour lequel l'apparence est gérée par les styles natifs du navigateur sans aucune modification par l'auteur (exemple le style au focus natif dans Chrome ou Firefox).
  • Composant d'interface pour lequel la couleur n'est pas nécessaire pour identifier le composant ou son état (exemple un groupe de liens faisant office de navigation dont la position dans la page, la taille et la couleur du texte permettent de comprendre qu'il s'agit de liens même si la couleur du soulignement des liens avec le fond blanc n'a pas un ratio de 3:1 et que le texte lui a un ratio de 4.5:1).
  • Élément graphique ou parties d'élément graphique non porteur d'information ou ayant une alternative (description longue, informations identiques visibles dans la page).
  • Élément graphique ou parties d'élément graphique faisant partie d'un logo ou du nom de marque d'un organisme ou d'une société.
  • Élément graphique ou parties d'élément graphique dont la présentation est essentielle à l'information véhiculée (exemple drapeaux, logotypes, photos de personnes ou de scènes, captures d'écran, diagrammes médicaux, carte de chaleurs).
  • Élément graphique ou parties d'élément graphique dynamiques dont le contraste au survol / focus est suffisant.

Modification du test 3.3.3

Passage à l’usage des pixels pour définir la taille de caractères tel que décrit dans le document Understanding Success Criterion 1.4.3: Contrast (Minimum) des WCAG 2.1.

Renumérotation du test 3.3.3 en test 3.2.3.

Ancien test 3.3.3

Test 3.3.3 : Dans chaque page web, à partir de 150% de la taille de police par défaut (ou 1.5em), le texte et le texte en image sans effet de graisse vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 3:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 3:1, au moins.

Nouveau test 3.2.3

Test 3.2.3 : Dans chaque page web, le texte et le texte en image sans effet de graisse d’un taille restituée supérieure ou égale à 24px vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 3:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 3:1, au moins.

Modification du test 3.3.4

Passage à l’usage des pixels pour définir la taille de caractères tel que décrit dans le document Understanding Success Criterion 1.4.3: Contrast (Minimum) des WCAG 2.1.

Renumérotation du test 3.3.4 en test 3.2.4.

Ancien test 3.3.4

Test 3.3.4 : Dans chaque page web, à partir de 120% de la taille de police par défaut (ou 1.2em), le texte et le texte en image en gras vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 3:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 3:1, au moins.

Nouveau test 3.2.4

Test 3.2.4 : Dans chaque page web, le texte et le texte en image en gras d'un taille restituée supérieure ou égale à 18,5px vérifient-ils une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste entre le texte et son arrière-plan est de 3:1, au moins.
  • Un mécanisme permet à l'utilisateur d'afficher le texte avec un rapport de contraste de 3:1, au moins.

Suppression du test 3.3.5

Si le mécanisme fait appel à du texte, il est soumis aux autres tests du nouveau critère 3.2.

Si le mécanisme fait appel à un élément graphique uniquement, il est soumis au nouveau critère 3.3.

Ancien test 3.3.5

Test 3.3.5 : Chaque mécanisme qui permet d'afficher le texte avec un rapport de contraste conforme a-t-il un rapport de contraste supérieur ou égal à 4,5:1?

Création du critère 3.3 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 1.4.11 Non-text Contrast (AA).

Nouveau critère 3.3

Critère 3.3 Dans chaque page web, les couleurs utilisées dans les composants d'interface ou les éléments graphiques porteurs d'informations sont-elles suffisamment contrastées (hors cas particuliers)?

Nouveau test 3.3.1

Test 3.3.1 : Dans chaque page web, le rapport de contraste entre les couleurs d'un composant d'interface dans ses différents états et la couleur d'arrière-plan contiguë vérifie-t-il une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste est de 3:1, au moins.
  • Un mécanisme permet un rapport de contraste de 3:1, au moins.

Nouveau test 3.3.2

Test 3.3.2 : Dans chaque page web, le rapport de contraste des différentes couleurs composant un élément graphique, lorsqu'elles sont nécessaires à sa compréhension, et la couleur d'arrière-plan contiguë, vérifie-t-il une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste est de 3:1, au moins.
  • Un mécanisme permet un rapport de contraste de 3:1, au moins.

Nouveau test 3.3.3

Test 3.3.3 : Dans chaque page web, le rapport de contraste des différentes couleurs contiguës entre elles d'un élément graphique, lorsqu'elles sont nécessaires à sa compréhension, vérifie-t-il une de ces conditions (hors cas particuliers)?

  • Le rapport de contraste est de 3:1, au moins.
  • Un mécanisme permet un rapport de contraste de 3:1, au moins.

Nouveau test 3.3.1

Test 3.3.4 : Dans le mécanisme qui permet d'afficher un rapport de contraste conforme, les couleurs du composant ou des éléments graphiques porteurs d’informations qui le composent, sont-elles suffisamment contrastées?

Suppression du critère 4.5 et des tests associés

Contenu exempté par la directive européenne : les contenus audio et/ou vidéo, y compris avec des composants interactifs, diffusés en direct; à noter que lorsque ces contenus sont mis à disposition en ligne ou republiés après leur diffusion en direct, ils sont considérés comme des contenus préenregistrés.

Modification des cas particuliers 4.1 - 4.2 - 4.3 - 4.5 - 4.7 - 4.9 - 4.11 - 4.13

Ajout de deux précisions légales sur les médias concernés en fonction de leur date de publication et de leur propriétaire.

Les cas particuliers ne s'appliquent plus qu'aux critères 4.1, 4.2, 4.3, 4.5 compte tenu de la suppression des critères suivants.

Anciens cas particuliers 4.1 - 4.2 - 4.3 - 4.5 - 4.7 - 4.9 - 4.11 - 4.13

Il existe une gestion de cas particulier lorsque :

  • Le média temporel est utilisé à des fins décoratives (c'est-à-dire qu'il n'apporte aucune information);
  • Le média temporel est lui-même une alternative à un contenu de la page (une vidéo en langue des signes ou la vocalisation d'un texte, par exemple);
  • Le média temporel est utilisé pour accéder à une version agrandie;
  • Le média temporel est utilisé comme un CAPTCHA;
  • Le média temporel fait partie d'un test qui deviendrait inutile si la transcription textuelle, les sous-titres synchronisés ou l'audiodescription étaient communiqués.

Dans ces situations, le critère est non applicable.

Nouveaux cas particuliers 4.1

Il existe une gestion de cas particulier lorsque :

  • Le média temporel est utilisé à des fins décoratives (c'est-à-dire qu'il n'apporte aucune information);
  • Le média temporel est lui-même une alternative à un contenu de la page (une vidéo en langue des signes ou la vocalisation d'un texte, par exemple);
  • Le média temporel est utilisé pour accéder à une version agrandie;
  • Le média temporel est utilisé comme un CAPTCHA;
  • Le média temporel fait partie d'un test qui deviendrait inutile si la transcription textuelle, les sous-titres synchronisés ou l'audiodescription étaient communiqués.
  • Pour les services de l’État, les collectivités territoriales et leurs établissements : si le média temporel a été publié entre le 23 septembre 2019 et le 23 septembre 2020 sur un site internet, intranet ou extranet créé depuis le 23 septembre 2018, il est exempté de l’obligation d’accessibilité ;
  • Pour les personnes de droit privé mentionnées aux 2° à 4° du I de l’article 47 de la loi du 11 février 2005 : si le média temporel a été publié avant le 23 septembre 2020, il est exempté de l’obligation d’accessibilité.

Dans ces situations, le critère est non applicable.

Ce cas particulier s'applique également aux critères 4.2, 4.3, 4.5

Ancien critère 4.5

Critère 4.5 [AA] Chaque média temporel en direct a-t-il, si nécessaire, des sous-titres synchronisés ou une transcription textuelle (hors cas particuliers)?

Suppression du critère 4.6 et des tests associés

Contenu exempté par la directive européenne : les contenus audio et/ou vidéo, y compris avec des composants interactifs, diffusés en direct; à noter que lorsque ces contenus sont mis à disposition en ligne ou republiés après leur diffusion en direct, ils sont considérés comme des contenus préenregistrés.

Ancien critère 4.6

Critère 4.6 [AA] Pour chaque média temporel en direct ayant des sous-titres synchronisés ou une transcription textuelle, ceux-ci sont-ils pertinents?

Suppression des critères 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.19 et des tests respectivement associés

Suppression des critères triple A du RGAA 4.

Suppression des cas particuliers 4.19

Suppression du critère 4.19.

Anciens cas particuliers 4.19

Il existe une gestion de cas particulier lorsque le média temporel est utilisé comme CAPTCHA ou fait partie d'un test qui deviendrait inutile si l'arrière-plan sonore pouvait être désactivé, ou si la ou les pistes de dialogue étaient 20 décibels plus élevées que l'arrière-plan sonore.

Dans ces situations, le critère est non applicable.

Renumérotation des critères 4.7, 4.8, 4.15, 4.16, 4.17, 4.18, 4.20, 4.21, 4.22 et des tests associés

Pour tenir compte de la suppression des critères 4.5, 4.6, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14 et 4.19, les critères 4.7, 4.8, 4.15, 4.16, 4.17, 4.18, 4.20, 4.21, 4.22 sont renumérotés respectivement en critères 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12 et 4.13. Les tests associés sont renumérotés de la même façon.

Modification du test 5.1.1

Mise à jour suite à la prise en compte du rôle table (WAI-ARIA) et à l'élargissement de la manière de proposer un résumé au moyen de l'attribut summary ou de l'attribut WAI-ARIA aria-describedby (voir entrée de glossaire "Résumé").

Ancien test 5.1.1

Test 5.1.1 : Pour chaque tableau de données complexe (balise table) un résumé est-il disponible dans la balise caption?

Nouveau test 5.1.1

Test 5.1.1 : Pour chaque tableau de données complexe un résumé est-il disponible?

Modification du test 5.5.2

Mise à jour suite à la prise en compte du rôle table (WAI-ARIA).

Ancien test 5.5.2

Test 5.2.1 : Pour chaque tableau de donnée complexes (balise table) ayant un résumé, celui-ci est-il pertinent?

Nouveau test 5.5.2

Test 5.1.2 : Pour chaque tableau de donnée complexes ayant un résumé, celui-ci est-il pertinent ?

Modification du critère 5.4

Mise à jour suite à la prise en compte du rôle table (WAI_ARIA) et à la prise en compte de la condition de la technique WCAG H39 qui vérifie la structuration du titre lorsqu’il est présent mais ne rend pas obligatoire la présence d’un titre.

Ancien critère 5.4

Critère 5.4 [A] Chaque tableau de données a-t-il un titre?

Nouveau critère 5.4

Critère 5.4 Pour chaque tableau de données ayant un titre, le titre est-il correctement associé au tableau de données?

Modification du test 5.4.1

Mise à jour suite à la prise en compte du rôle table (WAI-ARIA) et à la prise en compte de la condition de la technique WCAG H39 qui vérifie la structuration du titre lorsqu’il est présent mais ne rend pas obligatoire la présence d’un titre.

Ancien test 5.4.1

Test 5.4.1 : Chaque tableau de données (balise table) a-t-il une balise caption?

Nouveau test 5.4.1

Test 5.4.1 : Pour chaque tableau de données ayant un titre, le titre est-il correctement associé au tableau de données?

Modification du test 5.5.1

Mise à jour suite à la prise en compte du rôle table (WAI-ARIA) et à l'introduction de l'entrée de glossaire "Tableau de données ayant un titre".

Ancien test 5.5.1

Test 5.5.1 : Pour chaque tableau de données (balise table) ayant un titre de tableau dans la balise caption, le titre est-il pertinent?

Nouveau test 5.5.1

Test 5.5.1 Pour chaque tableau de données ayant un titre, ce titre permet-il d'identifier le contenu du tableau de données de manière claire et concise?

Modification du test 5.6.1

Mise à jour suite à la prise en compte des rôles table et columnheader (WAI-ARIA).

Ancien test 5.6.1

Test 5.6.1 : Pour chaque tableau de données (balise table), chaque en-tête de colonnes a-t-il une balise th?

Nouveau test 5.6.1

Test 5.6.1 : Pour chaque tableau de données, chaque en-tête de colonnes s'appliquant à la totalité de la colonne vérifie-t-il une de ces conditions ?

  • L'en-tête de colonnes est structuré au moyen d'une balise <th>.
  • L'en-tête de colonnes est structuré au moyen d'une balise pourvue d'un attribut WAI-ARIA role="columnheader".

Modification du test 5.6.2

Mise à jour suite à la prise en compte des rôles table et rowheader (WAI-ARIA).

Ancien test 5.6.2

Test 5.6.2 : Pour chaque tableau de données (balise table), chaque en-tête de lignes a-t-il une balise th?

Nouveau test 5.6.2

Test 5.6.2 : Pour chaque tableau de données, chaque en-tête de lignes s'appliquant à la totalité de la ligne vérifie-t-il une de ces conditions ?

  • L'en-tête de lignes est structuré au moyen d'une balise <th>.
  • L'en-tête de lignes est structuré au moyen d'une balise pourvue d'un attribut WAI-ARIA role="rowheader".

Création du test 5.6.3

Restriction de l’usage de WAI-ARIA sur les tableaux de données complexes.

Nouveau test 5.6.3

Pour chaque tableau de données, chaque en-tête ne s'appliquant pas à la totalité de la ligne ou de la colonne est-il structuré au moyen d'une balise <th>?

Modification du test 5.7.1

Mise à jour suite à la prise en compte des rôles columnheader et rowheader (WAI-ARIA) et restriction de l’applicabilité du test aux balises <th> uniquement et prise en compte de la note 1 de la technique WCAG H63 autorisant les tableaux de données avec des en-tête <th> sans attribut scope lorsqu’il s’agit de tableaux ayant des en-têtes uniquement sur une seule ligne ou une seule colonne (cas particulier).

Ancien test 5.7.1

Test 5.7.1 : Chaque en-tête (balise th) s'appliquant à la totalité de la ligne ou de la colonne possède-t-il un attribut id unique ou un attribut scope?

Nouveau test 5.7.1

Test 5.7.1 : Pour chaque contenu de balise <th> s'appliquant à la totalité de la ligne ou de la colonne, la balise <th> respecte-t-elle une de ces conditions (hors cas particuliers) ?

  • La balise <th> possède un attribut id unique.
  • La balise <th> possède un attribut scope.
  • La balise <th> possède un attribut WAI-ARIA role="rowheader" ou "columnheader".

Création des cas particuliers 5.7

Ajout des cas particuliers pour le test 5.7.1.

Nouveaux cas particuliers 5.7

Dans le cas de tableaux de données ayant des en-têtes sur une seule ligne ou une seule colonne, les en-têtes peuvent être structurés à l'aide de balise <th> sans attribut scope.

Modification du test 5.7.2

Restriction de l’applicabilité du test aux balises <th> uniquement.

Ancien test 5.7.2

Test 5.7.2 : Chaque en-tête (balise th) s'appliquant à la totalité de la ligne ou de la colonne et possédant un attribut scope vérifie-t-il une de ces conditions?

  • L'en-tête possède un attribut scope avec la valeur "row" pour les en-tête de lignes.
  • L'en-tête possède un attribut scope avec la valeur "col" pour les en-tête de colonnes.

Nouveau test 5.7.2

Test 5.7.2 : Pour chaque contenu de balise <th> s'appliquant à la totalité de la ligne ou de la colonne et possédant un attribut scope, la balise <th> vérifie-t-elle une de ces conditions?

  • La balise <th> possède un attribut scope avec la valeur "row" pour les en-tête de lignes.
  • La balise <th> possède un attribut scope avec la valeur "col" pour les en-tête de colonnes.

Modification du test 5.7.3

Mise à jour suite à la prise en compte des rôles columnheader et rowheader (WAI-ARIA) et restriction de l’applicabilité du test aux balises <th> uniquement.

Ancien test 5.7.3

Test 5.7.3 : Chaque en-tête (balise th) ne s'appliquant pas à la totalité de la ligne ou de la colonne vérifie-t-il ces conditions?

  • L'en-tête ne possède pas d'attribut scope.
  • L'en-tête possède un attribut id unique.

Nouveau test 5.7.3

Test 5.7.3 : Pour chaque contenu de balise <th> ne s'appliquant pas à la totalité de la ligne ou de la colonne, la balise <th> vérifie-t-elle ces conditions?

  • La balise <th> ne possède pas d'attribut scope.
  • La balise <th> ne possède pas d'attribut WAI-ARIA role="rowheader" ou "columnheader".
  • La balise <th> possède un attribut id unique.

Modification du test 5.7.4

Restriction de l'applicabilité du test aux balises <th> uniquement.

Ancien test 5.7.4

Test 5.7.4 : Chaque cellule (balise td ou th) associée à un ou plusieurs en-têtes possédant un attribut id vérifie-t-elle ces conditions?

  • La cellule possède un attribut headers.
  • L'attribut headers possède la liste des valeurs des en-têtes associés à la cellule.

Nouveau test 5.7.4

Test 5.7.4 : Pour chaque contenu de balise <td> ou <th> associée à un ou plusieurs en-têtes possédant un attribut id, la balise vérifie-t-elle ces conditions?

  • La cellule possède un attribut headers.
  • L'attribut headers possède la liste des valeurs d'attribut id des en-têtes associés.

Création du test 5.7.5

Création pour tenir compte des balises pourvues des rôles columnheader et rowheader (WAI-ARIA).

Nouveau test 5.7.5

Test 5.7.5 : Pour chaque balise pourvue d’un attribut WAI-ARIA role="rowheader" ou "columnheader" dont le contenu s'applique à la totalité de la ligne ou de la colonne, la balise vérifie-t-elle une de ces conditions?

  • La balise possède un attribut WAI-ARIA role="rowheader" pour les en-têtes de lignes
  • La balise possède un attribut WAI-ARIA role="columnheader" pour les en-têtes de colonnes.

Modification du critère 6.1

Ajout du lien vers l’entrée de glossaire "Lien".

Ancien critère 6.1

Critère 6.1 [A] Chaque lien est-il explicite (hors cas particuliers)?

Nouveau critère 6.1

Critère 6.1 Chaque lien est-il explicite (hors cas particuliers) ?

Modification des cas particuliers 6.1 et 6.3

Ajout d'une section concernant les exceptions introduites par le critère WCAG 2.5.3 Label in Name.

Les cas particuliers ne s'appliquent plus qu'au critère 6.1 compte tenu de la suppression du critère 6.3.

Anciens cas particuliers 6.1 et 6.3

Il existe une gestion de cas particulier lorsque le lien est ambigu pour tout le monde. Dans cette situation, où il n'est pas possible de rendre le lien explicite dans son contexte, le critère est non applicable.

Nouveaux cas particuliers 6.1

Il existe une gestion de cas particulier pour les tests 6.1.1, 6.1.2, 6.1.3 et 6.1.4 lorsque le lien est ambigu pour tout le monde. Dans cette situation, où il n'est pas possible de rendre le lien explicite dans son contexte, le critère est non applicable.

Il existe une gestion de cas particulier pour le test 6.1.5 lorsque :

  • La ponctuation et les lettres majuscules sont présentes dans le texte de l’intitulé visible : elles peuvent être ignorées dans le nom accessible sans porter à conséquence.
  • Le texte de l’intitulé visible sert de symbole : le texte ne doit pas être interprété littéralement au niveau du nom accessible. Le nom doit exprimer la fonction véhiculée par le symbole (par exemple, "B" au niveau d'un éditeur de texte aura pour nom accessible "Mettre en gras", le signe ">" en fonction du contexte signifiera "Suivant" ou "Lancer la vidéo"). Le cas des symboles mathématiques fait cependant exception (voir la note ci-dessous).

Note : si l'étiquette visible représente une expression mathématique, les symboles mathématiques peuvent être repris littéralement pour servir d'étiquette au nom accessible (ex. : "A>B"). Il est laissé à l'utilisateur le soin d'opérer la correspondance entre l'expression et ce qu'il doit épeler compte tenu de la connaissance qu'il a du fonctionnement de son logiciel de saisie vocale ("A plus grand que B" ou "A supérieur à B").

Modification du test 6.1.1

Précision concernant le contexte du lien qui doit être additionné à l’intitulé du lien.

Ancien test 6.1.1

Test 6.1.1 : Chaque lien texte vérifie-t-il une de ces conditions (hors cas particuliers)?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • Le contexte du lien permet d'en comprendre la fonction et la destination.

Nouveau test 6.1.1

Test 6.1.1 : Chaque lien texte vérifie-t-il une de ces conditions (hors cas particuliers) ?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • L'intitulé de lien additionné au contexte du lien permet d'en comprendre la fonction et la destination.

Modification du test 6.1.2

Précision concernant le contexte du lien qui doit être additionné à l’intitulé du lien.

Ancien test 6.1.2

Test 6.1.2 : Chaque lien image vérifie-t-il une de ces conditions (hors cas particuliers)?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • Le contexte du lien permet d'en comprendre la fonction et la destination.

Nouveau test 6.1.2

Test 6.1.2 : Chaque lien image vérifie-t-il une de ces conditions (hors cas particuliers) ?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • L'intitulé de lien additionné au contexte du lien permet d'en comprendre la fonction et la destination.

Modification du test 6.1.3

Précision concernant le contexte du lien qui doit être additionné à l’intitulé du lien.

Ancien test 6.1.3

Test 6.1.3 : Chaque lien composite vérifie-t-il une de ces conditions (hors cas particuliers)?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • Le contexte du lien permet d'en comprendre la fonction et la destination.

Nouveau test 6.1.3

Test 6.1.3 : Chaque lien composite vérifie-t-il une de ces conditions (hors cas particuliers) ?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • L'intitulé de lien additionné au contexte du lien permet d'en comprendre la fonction et la destination.

Création du test 6.1.4

Prise en compte du lien SVG, voir l’entrée de glossaire "Lien".

Nouveau test 6.1.4

Test 6.1.4 : Chaque lien SVG vérifie-t-il une de ces conditions (hors cas particuliers) ?

  • L'intitulé de lien seul permet d'en comprendre la fonction et la destination.
  • L'intitulé de lien additionné au contexte du lien permet d'en comprendre la fonction et la destination.

Création du test 6.1.5

Prise en compte du critère WCAG 2.1 "Label in name".

Nouveau test 6.1.5

Test 6.1.5 : Pour chaque lien ayant un intitulé visible, le nom accessible du lien contient-il au moins l'intitulé visible (hors cas particuliers)?

Suppression du critère 6.2 et des tests associés

Le critère 6.2 est couvert par la nouvelle définition d’intitulé de lien dont la pertinence est vérifiée par le critère 6.1.

Ancien critère 6.2

Critère 6.2 [A] Pour chaque lien ayant un titre de lien, celui-ci est-il pertinent?

Suppression du critère 6.3 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 6.3

Critère 6.3 [AAA] Chaque intitulé de lien seul est-il explicite hors contexte (hors cas particuliers)?

Suppression du critère 6.4 et des tests associés

Le critère 6.4 est couvert par la nouvelle définition d’intitulé de lien dont la pertinence est vérifiée par le critère 6.1.

Ancien critère 6.4

Critère 6.4 [A] Pour chaque page web, chaque lien identique a-t-il les mêmes fonction et destination?

Modification du critère 6.5

Ajout du lien vers l’entrée de glossaire "Lien".

Pour tenir compte de la suppression des critères 6.2, 6.3 et 6.4, le critère 6.5 est renuméroté en 6.2.

Ancien critère 6.5

Critère 6.5 [A] Dans chaque page web, chaque lien, à l'exception des ancres, a-t-il un intitulé?

Nouveau critère 6.2

Critère 6.2 Dans chaque page web, chaque lien, à l'exception des ancres, a-t-il un intitulé?

Modification du test 6.5.1

Prise en compte de l’entrée de glossaire "Lien".

Renumérotation du test 6.5.1 en test 6.2.1.

Ancien test 6.5.1

Test 6.5.1 : Dans chaque page web, chaque lien (balise a avec un attribut href), à l'exception des ancres, a-t-il un intitulé entre <a> et </a>?

Nouveau test 6.2.1

Test 6.2.1 : Dans chaque page web, chaque lien, à l'exception des ancres, a-t-il un intitulé entre <a> et </a>?

Suppression du test 7.1.2

Élément n’ayant aucun impact sur l’accessibilité. Il s’agit d’un problème d’interopérabilité qui relève du RGI et non du RGAA.

Ancien test 7.1.2

Test 7.1.2 : Chaque fonctionnalité d'insertion de contenu contrôlée par un script utilise-t-elle des propriétés et méthodes conformes à la spécification DOM (Document Object Model)?

Suppression du test 7.1.3

Le respect des motifs de conception relève de la bonne pratique de conception et non de la conformité WCAG. Par ailleurs, la vérification de la présence d’un nom, rôle, valeur, paramétrage et changements d'états sur les composants d’interface ainsi que la bonne restitution est par ailleurs déjà vérifiée via les tests 7.1.1 et 7.1.5.

Ancien test 7.1.3

Test 7.1.3 : Chaque script qui génère, met à jour ou contrôle un composant d'interface qui comporte des rôles des états ou des propriétés correspondant à un motif de conception défini par l'API ARIA vérifie-t-il une de ces conditions?

  • Le composant d'interface est conforme au motif de conception défini par l'API ARIA.
  • Un composant d'interface présent sur la page, permettant d'accéder aux mêmes fonctionnalités, est conforme au motif de conception défini par l'API ARIA.
  • Le composant d'interface adapte un motif de conception défini par l'API ARIA.
  • Une alternative accessible permet d'accéder aux mêmes fonctionnalités.

Création des cas particuliers 7.1

Ajout de cas particuliers concernant les exceptions introduites par le critère WCAG 2.5.3 Label in Name.

Nouveaux cas particuliers 7.1

Il existe une gestion de cas particulier pour le test 7.1.3 lorsque :

  • La ponctuation et les lettres majuscules sont présentes dans le texte de l’intitulé visible : elles peuvent être ignorées dans le nom accessible sans porter à conséquence.
  • Le texte de l’intitulé visible sert de symbole : le texte ne doit pas être interprété littéralement au niveau du nom accessible. Le nom doit exprimer la fonction véhiculée par le symbole (par exemple, "B" au niveau d'un éditeur de texte aura pour nom accessible "Mettre en gras", le signe ">" en fonction du contexte signifiera "Suivant" ou "Lancer la vidéo"). Le cas des symboles mathématiques fait cependant exception (voir la note ci-dessous).

Note : si l'étiquette visible représente une expression mathématique, les symboles mathématiques peuvent être repris littéralement pour servir d'étiquette au nom accessible (ex. : "A>B"). Il est laissé à l'utilisateur le soin d'opérer la correspondance entre l'expression et ce qu'il doit épeler compte tenu de la connaissance qu'il a du fonctionnement de son logiciel de saisie vocale ("A plus grand que B" ou "A supérieur à B").

Suppression du test 7.1.4

Test relevant de la bonne pratique de conception et non de la conformité WCAG. Par ailleurs, la vérification de la présence d’un nom, rôle, valeur, paramétrage, changements d'états sur les composants d’interface, la bonne restitution et l’usage d’un nom et rôle approprié est par ailleurs déjà vérifiée via les test 7.1.1, 7.1.5 et 7.1.7.

Ancien test 7.1.4

Test 7.1.4 : Chaque modification du rôle natif d'un élément HTML respecte-t-elle les règles et préconisations indiquées dans la spécification HTML5 et les notes techniques associées?

Renumérotation du test 7.1.5

Pour tenir compte de la suppression des tests 7.1.2 à 7.1.4, le test 7.1.5 est renuméroté en test 7.1.2.

Suppression du test 7.1.6

Ce test est déjà couvert par le test 7.1.1 et 7.1.5.

Ancien test 7.1.6

Test 7.1.6 : Chaque composant d'interface qui utilise un rôle ARIA application respecte-t-il une de ces conditions?

  • Le composant d'interface est correctement restitué par les technologies d'assistance.
  • Une alternative accessible permet d'accéder aux mêmes fonctionnalités.

Renumérotation du test 7.1.7

Pour tenir compte de la suppression des tests 7.1.2 à 7.1.4 et du test 7.1.6 le test 7.1.7 est renuméroté en test 7.1.3.

Modification du critère 7.3

Prise en compte de l’ensemble des dispositifs de pointage.

Ancien critère 7.3

Critère 7.3 [A] Chaque script est-il contrôlable par le clavier et la souris (hors cas particuliers)?

Nouveau critère 7.3

Critère 7.3 Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage (hors cas particuliers) ?

Modification du test 7.3.1

Prise en compte de l’ensemble des dispositifs de pointage.

Ancien test 7.3.1

Test 7.3.1 : Chaque élément possédant un gestionnaire d'événement contrôlé par un script vérifie-t-il une de ces conditions (hors cas particuliers)?

  • L'élément est accessible par le clavier et la souris.
  • Un élément accessible par le clavier et la souris permettant de réaliser la même action est présent dans la page.

Nouveau test 7.3.1

Test 7.3.1 : Chaque élément possédant un gestionnaire d'événement contrôlé par un script vérifie-t-il une de ces conditions (hors cas particuliers) ?

  • L'élément est accessible par le clavier et tout dispositif de pointage.
  • Un élément accessible par le clavier et tout dispositif de pointage permettant de réaliser la même action est présent dans la page.

Suppression du test 7.3.3

Le respect des motifs de conception relève de la bonne pratique de conception et non de la conformité WCAG. Par ailleurs, la vérification de l’utilisation au clavier reste couverte par les critères 7.1, 12.13 et 12.14.

Ancien test 7.3.3

Test 7.3.3 : Chaque composant d'interface implémenté via un rôle défini par l'API ARIA et correspondant à un motif de conception respecte-t-il une de ces conditions?

  • Les interactions au clavier sont conformes au comportement défini par le motif de conception pour les touches Echap, Barre d'espace, Tabulation et Flèches de direction au moins.
  • Un composant d'interface présent sur la page, permettant de réaliser la même action, possède des interactions au clavier conformes au comportement défini par le motif de conception, pour les touches Échap, Barre d'espace, Tabulation et Flèches de direction au moins.
  • Une alternative permettant d'accéder aux mêmes fonctionnalités est contrôlable par le clavier et la souris.

Suppression des notes techniques du critère 7.3

Suppression du test 7.3.3.

Ancienne note technique

ARIA définit pour un certain nombre de rôles, dédiés au développement de composants d'interface, un ensemble d'interactions au clavier basées sur les touches Échap, Barre d'espace, Tabulation et touches de direction auxquelles peuvent se rajouter d'autres interactions basées sur les touches de pagination, de début ou de fin par exemple. Afin d'accompagner la prise en charge progressive de ces interactions au clavier, le référentiel limite l'exigence aux touches d'interactions principales (Échap, barre d'espace, tabulation, flèches de direction) telles qu'elles sont définies par les motifs de conception.

Suppression du critère 7.5 et du test associé

Suppression des critères triple A du RGAA 4.

Ancien critère 7.5

Critère 7.5 [AAA] Chaque script qui provoque une alerte non sollicitée est-il contrôlable par l'utilisateur (hors cas particuliers)?

Suppression des cas particuliers 7.5

Suppression du critère 7.5.

Anciens cas particuliers 7.5

Il existe une gestion de cas particulier lorsque l'alerte non sollicitée concerne un cas d'urgence, un événement ou une situation soudaine et imprévue qui exige une action immédiate afin de préserver la santé, la sécurité ou la propriété. Dans ces situations, le critère est non applicable.

Création du critère 7.5 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 4.1.3 Status Messages (A).

Nouveau critère 7.5

Critère 7.5 Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d'assistance?

Nouveau test 7.5.1

Test 7.5.1 : Chaque message de statut qui informe de la réussite, du résultat d'une action ou bien de l'état d'une application utilise-t-il l'attribut WAI-ARIA role="status"?

Nouveau test 7.5.2

Test 7.5.2 : Chaque message de statut qui présente une suggestion, ou avertit de l'existence d'une erreur utilise-t-il l'attribut WAI-ARIA role="alert"?

Nouveau test 7.5.3

Test 7.5.3 : Chaque message de statut qui indique la progression d'un processus utilise-t-il l'un des attributs WAI-ARIA role="log", role="progressbar" ou role="status"?

Nouvelle note technique

Les rôles WAI-ARIA log, status et alert ont implicitement une valeur d'attribut WAI-ARIA aria-live et aria-atomic. On pourra donc considérer (conformément à la spécification WAI-ARIA 1.1) que :

  • Un attribut WAI-ARIA aria-live="polite" associé à un message de statut peut valoir pour un rôle WAI-ARIA log.
  • Un attribut WAI-ARIA aria-live="polite" et un attribut aria-atomic="true" associés à un message de statut peuvent valoir pour un rôle WAI-ARIA status.
  • Un attribut aria-live="assertive" et un attribut aria-atomic="true" associés à un message de statut peuvent valoir pour un rôle WAI-ARIA alert.

C'est sous réserve que la nature du message de statut satisfasse bien à la correspondance implicitement établie. Dans le cas d'un message de statut indiquant la progression d'un processus et matérialisé graphiquement par une barre de progression, un rôle WAI-ARIA progressbar explicite est nécessaire.

Modification des cas particuliers 8.2

Mise à jour suite à la suppression du test 8.2.2 et adaptation pour prise en compte des versions antérieures à HTML5.

Anciens cas particuliers 8.2

Il y a une gestion de cas particulier sur la conformité du code HTML.

Pour accompagner la prise en charge progressive de HTML5 par les navigateurs, les APIs d'accessibilité et les technologies d'assistance, certains critères peuvent exiger la présence d'attributs ou de balises déclarés « obsolètes » en HTML5. Dans ce cas le test 8.2.2 est non applicable.

Nouveaux cas particuliers 8.2

Il y a une gestion de cas particulier sur la conformité du code HTML.

Pour accompagner la prise en charge progressive de HTML par les navigateurs, les APIs d'accessibilité et les technologies d'assistance, certains critères peuvent exiger la présence d'attributs ou de balises déclarés « obsolètes » en HTML. Par ailleurs, dans la mesure où des balises ou des attributs déclarés « obsolètes » sont utilisés, ils restent soumis aux autres critères du RGAA (exemple la balise <marquee> serait non conforme par rapport au critère 13.8) et leur support d'accessibilité doit être vérifié au regard de l’environnement de test (ou « base de référence ») retenu.

Modification du test 8.2.1

Mise à jour faite afin de rendre plus explicite les cas de non-conformité liés à l’usage d’attributs id non uniques et de doublage d’attribut des techniques WCAG H93 et H94.

Ancien test 8.2.1

Test 8.2.1 : Pour chaque déclaration de type de document, le code source de la page vérifie-t-il ces conditions (hors cas particuliers)?

  • Les balises respectent les règles d'écriture.
  • L'imbrication des balises est conforme.
  • L'ouverture et la fermeture des balises sont conformes.
  • Les attributs respectent les règles d'écriture.
  • Les valeurs des attributs respectent les règles d'écriture.

Nouveau test 8.2.1

Test 8.2.1 : Pour chaque déclaration de type de document, le code source généré de la page vérifie-t-il ces conditions (hors cas particuliers)?

  • Les balises, attributs et valeurs d’attributs respectent les règles d'écriture,
  • L'imbrication des balises est conforme,
  • L'ouverture et la fermeture des balises sont conformes,
  • Les valeurs d’attribut id sont uniques dans la page,
  • Les attributs ne sont pas doublés sur un même élément.

Suppression du test 8.2.2

En l’absence de techniques ou d’éléments dans les WCAG indiquant l’interdiction d’utiliser des éléments obsolètes, le test est supprimé. L’usage d’éléments ou attributs obsolètes sera encadré par le cas particulier du critère 8.2 demandant de vérifier si ces éléments en question sont toujours compatibles avec l’accessibilité sur la base de référence retenue.

Ancien test 8.2.2

Test 8.2.2 : Pour chaque déclaration de type de document, le code source de la page ne doit pas utiliser d'éléments obsolètes. Cette règle est-elle respectée (hors cas particuliers)?

Modification des cas particuliers 8.7

Réorganisation du texte : note sur le dictionnaire officiel renvoyée en bas de section.

Anciens cas particuliers 8.7

Il y a une gestion de cas particulier sur le changement de langue pour les cas suivants :

  • Nom propre, le critère est non applicable;
  • Nom commun de langue étrangère présent dans le dictionnaire officiel de la langue par défaut de la page web, le critère est non applicable (Note : le dictionnaire officiel est celui recommandé par l'académie en charge de la langue en question). Pour la France, par exemple, le lien vers le dictionnaire officiel se trouve sur le site de l'Académie française à l'adresse suivante : http://www.academie-francaise.fr/le-dictionnaire/la-9e-edition. Pour toute demande auprès du service du dictionnaire de l'Académie française, utiliser le formulaire de contact du service du dictionnaire;
  • Le terme de langue étrangère soumis, via un champ de formulaire et réaffiché dans la page (par exemple comme indication du terme recherché dans le cas d'un moteur de recherche), le critère est non applicable;
  • Passage de texte dont la langue ne peut pas être déterminée : le critère est non applicable;
  • Terme ou passage de texte issus d'une langue morte ou imaginaire pour laquelle il n'existe pas d'interprétation vocale : le critère est non applicable.

Note : pour les noms communs de langue étrangère, absents dans le dictionnaire officiel de la langue par défaut de la page web, et qui sont passés dans le langage commun (exemple : newsletter) : le critère est applicable, uniquement lorsque l'absence d'indication de langue peut provoquer une incompréhension pour la restitution.

Nouveaux cas particuliers 8.7

Il y a une gestion de cas particuliers sur le changement de langue pour les cas suivants :

  • Nom propre, le critère est non applicable;
  • Nom commun de langue étrangère présent dans le dictionnaire officiel de la langue (voir note 1 ci-dessous) par défaut de la page web, le critère est non applicable ;
  • Le terme de langue étrangère soumis, via un champ de formulaire et rappelé dans la page (par exemple comme indication du terme recherché dans le cas d'un moteur de recherche), le critère est non applicable ;
  • Passage de texte dont la langue ne peut pas être déterminée : le critère est non applicable ;
  • Terme ou passage de texte issus d'une langue morte ou imaginaire pour laquelle il n'existe pas d'interprétation vocale : le critère est non applicable.

Note 1 : le dictionnaire officiel est celui recommandé par l'académie en charge de la langue en question. Pour la France, par exemple, le lien vers le dictionnaire officiel se trouve sur le site de l'Académie française à l'adresse suivante : http://www.academie-francaise.fr/le-dictionnaire/la-9e-edition. Pour toute demande auprès du service du dictionnaire de l'Académie française, utiliser le formulaire de contact du service du dictionnaire.

Note 2 : pour les noms communs de langue étrangère, absents dans le dictionnaire officiel de la langue par défaut de la page web, et qui sont passés dans le langage commun (exemple : newsletter) : le critère est applicable, uniquement lorsque l'absence d'indication de langue peut provoquer une incompréhension pour la restitution.

Modification du test 8.7.1

Modification pour mise en cohérence avec la syntaxe du test existant 8.3.1.

Ancien test 8.7.1

Test 8.7.1 : Dans chaque page web, chaque texte écrit dans une langue différente de la langue par défaut vérifie-t-il une de ces conditions (hors cas particuliers)?

  • L'indication de langue est donnée sur l'élément contenant le texte.
  • L'indication de langue est donnée sur un des éléments parents.

Nouveau test 8.7.1

Test 8.7.1 : Dans chaque page web, chaque texte écrit dans une langue différente de la langue par défaut vérifie-t-il une de ces conditions (hors cas particuliers)?

  • L'indication de langue est donnée sur l'élément contenant le texte (attribut lang et/ou xml:lang).
  • L'indication de langue est donnée sur un des éléments parents (attribut lang et/ou xml:lang).

Modification du critère 8.8

Modification pour une mise en cohérence avec la syntaxe du critère existant 8.4 qui vérifie la pertinence du code de langue et non du changement de langue lui-même.

Ancien critère 8.8

Critère 8.8 [AA] Dans chaque page web, chaque changement de langue est-il pertinent?

Nouveau critère 8.8

Critère 8.8 Dans chaque page web, le code de langue de chaque changement de langue est-il valide et pertinent?

Modification du test 8.8.1

Modification pour une mise en cohérence avec la syntaxe du test existant 8.4.1.

Fusion des tests 8.8.1 et 8.8.2.

Ancien test 8.8.1

Test 8.8.1 : Dans chaque page web, chaque changement de langue (attribut lang et/ou xml:lang) est-il valide?

Nouveau test 8.8.1

Test 8.8.1 : Pour chaque page web, le code de langue de chaque changement de langue vérifie-t-il ces conditions?

  • Le code de langue est valide.
  • Le code de langue est pertinent.

Suppression du test 8.8.2

Fusion du test 8.8.2 avec 8.8.1.

Ancien test 8.2.2

Dans chaque page web, chaque changement de langue (attribut lang et/ou xml:lang) est-il pertinent?

Suppression du test 9.1.1

Condition non présente dans les WCAG et non nécessaire si une autre technique que l’utilisation des balises <hx> est mise en place pour satisfaire le contournement des blocs de contenu (critère WCAG 2.4.1 Bypass Block).

Ancien test 9.1.1

Test 9.1.1 : Dans chaque page web, y a-t-il un titre de niveau 1 (balise h1 ou balise possédant un rôle ARIA "heading" associé à une propriété aria-level="1")?

Modification du test 9.1.2

Modification sémantique.

Renumérotation du test 9.1.2 et en test 9.1.1.

Ancien test 9.1.2

Test 9.1.2 : Dans chaque page web, la hiérarchie entre les titres (balise h ou balise possédant un rôle ARIA "heading" associé à une propriété aria-level) est-elle pertinente?

Nouveau test 9.1.1

Test 9.1.1 : Dans chaque page web, la hiérarchie entre les titres (balise <hx> ou balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level) est-elle pertinente?

Suppression du test 9.1.3

Condition non présente dans les WCAG et non nécessaire si une autre technique que l’utilisation des balises <hx> est mise en place pour satisfaire le contournement des blocs de contenu (critère WCAG 2.4.1 Bypass Block).

Ancien test 9.1.3

Test 9.1.3 : Dans chaque page web, chaque titre (balise h ou balise possédant un rôle ARIA "heading" associé à une propriété aria-level) nécessaire à la structure de l'information est-il présent?

Modification du test 9.1.4

Modification sémantique.

Renumérotation du test 9.1.4 et en test 9.1.2.

Ancien test 9.1.4

Test 9.1.4 : Dans chaque page web, chaque titre (balise h ou balise possédant un rôle ARIA "heading" associé à une propriété aria-level) est-elle pertinente?

Nouveau test 9.1.1

Test 9.1.2 : Dans chaque page web, le contenu de chaque titre (balise <hx> ou balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level) est-il pertinent?

Création du test 9.1.3

Prise en compte du critère 1.3.1 des WCAG 2.1 demandant la structuration sémantique des titres présents dans la page.

Nouveau test 9.1.3

Test 9.1.3 : Dans chaque page web, chaque passage de texte constituant un titre est-il structuré à l'aide d'une balise <hx> ou d'une balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level?

Modification du critère 9.2

Ajout d’un cas particulier pour tenir compte des sites utilisant HTML4 ou XHTML.

Ancien critère 9.2

Critère 9.2 [A] Dans chaque page web, la structure du document est-elle cohérente?

Nouveau critère 9.2

Critère 9.2 Dans chaque page web, la structure du document est-elle cohérente (hors cas particuliers) ?

Création des cas particuliers 9.2

Ajout d’un cas particulier pour tenir compte des sites utilisant HTML4 ou XHTML.

Nouveaux cas particuliers 9.2

Lorsque le doctype déclaré dans la page n'est pas le doctype HTML5, ce critère est non applicable.

Modification de la note technique critère 9.2

Suppression du test 9.2.2 suite à l'abandon de l'algorithme de titrage tenant compte des éléments sectionnant en HTML5.

Prise en compte de l’usage multiple de l’élément <main>.

Ancienne note technique

L'arborescence du document (outline) est générée par l'utilisation des balises sectionnantes <nav>, <article>, <section>, <aside> et les sections implicites générées par l'utilisation d'une balise <hx> (lorsque la balise <hx> n'est pas le premier enfant d'une section).

Une balise sectionnante permet de structurer ou de regrouper un contenu, les parties d'un contenu, ou un ensemble de contenus qui peuvent être considérés de manière indépendante du reste du document.

Une zone de navigation dans le site ou dans une rubrique, un sommaire ou la zone de navigation d'une collection de pages (<nav>), un contenu « complémentaire » au contenu principal (<aside>), le contenu principal ou le regroupement de plusieurs contenus comme des articles (<article> ou <section>) un ou des contenus secondaires comme un commentaire, un widget Twitter, un fil RSS (<article> ou <section>) sont autant d'exemples de contenus sectionnés.

Lorsqu'il s'agit de contenus, par opposition à des zones de navigation (<nav>) ou des zones de contenus complémentaires (<aside>), une section devrait posséder si c'est approprié une zone d'en-tête (<header>) et un pied de section (<footer>).

Le premier titre <hx> dans une section donne le « nom » de la section tel qu'il sera reporté dans l'arborescence du document. Les titres suivants (<hx>) créent des sections implicites qui seront présentées comme l'arborescence du contenu de la section.

Une section pouvant être considérée de manière indépendante du reste de la page, l'arborescence générée par les sections implicites (<hx>) est calculée à partir d'un niveau 1 affecté au premier titre de la section.

Lorsqu'elle est utilisée, l'arborescence du document peut donc être différente de l'arborescence du contenu représentée par l'ensemble des titres <hx> de la page, même si les deux structures restent similaires.

Cette arborescence doit donc être représentative de la structure du document et être cohérente avec la structuration du contenu générée par l'utilisation des balises <hx>. La structuration du contenu générée par les balises <hx> pouvant être, théoriquement, déduite de l'arborescence du document, la spécification HTML5 recommande d'utiliser uniquement des titres <h1>. Cet usage est proscrit et le critère 9.1 impose d'utiliser une hiérarchie de titres (<hx>) cohérente.

Si l'arborescence du document (à la condition qu'elle soit cohérente) peut permettre de proposer à l'utilisateur des fonctionnalités d'exploration et de navigation, sur certaines technologies d'assistance, elle influe sur la hiérarchie de titres générée par l'utilisation des balises <hx> en modifiant le niveau des titres restitués.

Pour accompagner la prise en charge progressive de l'arborescence du document et compte tenu du fait que le référentiel exige de disposer, en tout état de cause, d'une structure de contenu (balises <hx>) robuste et cohérente, il est acceptable de considérer le test 9.2.2 comme non applicable lorsqu'il n'est pas possible de s'assurer que l'arborescence du document est parfaitement cohérente.

Dans ce cas, la non-conformité au test devrait être relevée sous la forme d'une simple alerte.

Nouvelle note technique

La balise <main> peut être utilisée plusieurs fois dans le même document HTML. Néanmoins, il ne peut y avoir en permanence qu’une seule balise visible et lisible par les technologies d’assistances, les autres devant disposer d’un attribut hidden ou d’un style permettant de les masquer aux technologies d’assistances. A noter cependant que l’utilisation d’un style seul restera insuffisant pour assurer l’unicité d’une balise <main> visible en cas de désactivation des feuilles de styles.

Modification du test 9.2.1

Ajout d’un cas particulier pour tenir compte des sites utilisant HTML4 ou XHTML.

Prise en compte de la possibilité d'utiliser des éléments <main> multiples dans un document.

Ancien test 9.2.1

Test 9.2.1 : Dans chaque page web, la structure du document vérifie-t-elle ces conditions?

  • La zone d'en-tête de la page est structurée via une balise header.
  • Les zones de navigation principales et secondaires sont structurées via une balise nav.
  • La balise nav est réservée à la structuration des zones de navigation principales et secondaires.
  • La zone de contenu principal est structurée via une balise main.
  • La structure du document utilise une balise main unique.
  • La zone de pied de page est structurée via une balise footer.

Nouveau test 9.2.1

Test 9.2.1 : Dans chaque page web, la structure du document vérifie-t-elle ces conditions (hors cas particuliers)?

  • La zone d'en-tête de la page est structurée via une balise header.
  • Les zones de navigation principales et secondaires sont structurées via une balise nav.
  • La balise nav est réservée à la structuration des zones de navigation principales et secondaires.
  • La zone de contenu principal est structurée via une balise main.
  • La structure du document utilise une balise main visible unique.
  • La zone de pied de page est structurée via une balise footer.

Suppression du test 9.2.2

Suppression du test qui ne vaut pas pour les sites utilisant HTML4 ou XHTML.

Abandon de l'algorithme de titrage tenant compte des éléments sectionnant en HTML5.

Ancien test 9.2.2

Test 9.2.2 : Dans chaque page web, l'arborescence du document est-elle cohérente?

Modification des références du critère 9.3

Suppression de la technique WCAG H97 non pertinente au regard du critère.

Modification de la note technique critère 9.3

Suppression du paragraphe relatif à l'attribut WAI-ARIA role="definition" qui propose un argumentaire inexact. La spécification HTML5 associe par défaut un attribut WAI-ARIA role="list" à la balise <dl> et il serait possible d’utiliser alors les attributs WAI-ARIA role="listitem", "term" et "definition" pour constituer un équivalent WAI-ARIA à la balise <dl>.

Ancienne note technique

Les rôles WAI-ARIA list et listitem peuvent nécessiter l'utilisation des propriétés aria-setsize et aria-posinset dans le cas où l'ensemble de la liste n'est pas disponible via le DOM généré au moment de la consultation.

Bien que possédant un rôle definition, utilisé en combinaison avec la propriété aria-labelledby, WAI-ARIA ne propose pas de rôle équivalent à une liste de définition HTML. Le rôle definition ne peut donc pas être utilisé comme équivalent à une liste de définition HTML dl.

Les rôles tree, tablist, menu, combobox et listbox ne sont pas équivalents à une liste HTML ul ou ol.

Références : The roles model – list

Nouvelle note technique

Les attributs WAI-ARIA role="list" et "listitem" peuvent nécessiter l'utilisation des attributs aria-setsize et aria-posinset dans le cas où l'ensemble de la liste n'est pas disponible via le DOM généré au moment de la consultation.

Les attributs WAI-ARIA role="tree", "tablist", "menu", "combobox" et "listbox" ne sont pas équivalents à une liste HTML <ul> ou <ol>.

Voir : The roles model – list

Modification du test 9.3.1

Modification du test pour signaler qu’il ne vaut que pour des listes qui visuellement ressemblent à des listes (avec marqueurs de liste).

Ancien test 9.3.1

Test 9.3.1 : Dans chaque page web, les informations regroupées sous forme de liste non ordonnée vérifient-elles une de ces conditions?

  • La liste utilise les balises HTML ul et li.
  • La liste utilise les rôles ARIA list et listitem.

Nouveau test 9.3.1

Test 9.3.1 : Dans chaque page web, les informations regroupées visuellement sous forme de liste non ordonnée vérifient-elles une de ces conditions?

  • La liste utilise les balises HTML <ul> et <li>.
  • La liste utilise les attributs WAI-ARIA role="list" et "listitem".

Modification du test 9.3.2

Modification du test pour signaler qu’il ne vaut que pour des listes qui visuellement ressemblent à des listes (avec marqueurs de liste).

Ancien test 9.3.2

Test 9.3.2 : Dans chaque page web, les informations regroupées sous forme de liste ordonnée vérifient-elles une de ces conditions?

  • La liste utilise les balises HTML ol et li.
  • La liste utilise les rôles ARIA list et listitem.

Nouveau test 9.3.2

Test 9.3.2 : Dans chaque page web, les informations regroupées visuellement sous forme de liste ordonnée vérifient-elles une de ces conditions?

  • La liste utilise les balises HTML <ol> et <li>.
  • La liste utilise les attributs WAI-ARIA role="list" et "listitem".

Suppression du critère 9.4 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 9.4

Critère 9.4 [AAA] Dans chaque page web, la première occurrence de chaque abréviation permet-elle d'en connaître la signification?

Suppression du critère 9.5 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 9.5

Critère 9.5 [AAA] Dans chaque page web, la signification de chaque abréviation est-elle pertinente?

Renumérotation du critère 9.6 en critère 9.4

Pour tenir compte de la suppression des critères 9.4 et 9.5, le critère 9.6 est renuméroté en critère 9.4.

Modification des cas particuliers 10.4

Mise à jour suite à la suppression des tests 10.4.1 et 10.4.2 et prise en compte des cas particuliers prévus dans le critère 1.4.4 des WCAG.

Anciens cas particuliers 10.4

Il existe une gestion de cas particuliers pour les polices-icônes. Les polices-icônes permettent de créer des icônes à partir d'un fichier de police. Dans ces cas, il est autorisé d'utiliser des tailles en unités fixes pour la propriété CSS font-size.

Nouveaux cas particuliers 10.4

Dans le cas des textes en image et des sous-titres de vidéo le critère est non applicable.

Suppression du test 10.4.2

Suppression suite à la reformulation du test 10.4.3.

Ancien test 10.4.2

Test 10.4.2 : Dans les feuilles de styles du site web, pour les types de média screen, tv, handheld, projection, les tailles de caractères utilisent-elles uniquement des unités relatives (hors cas particuliers)?

Modification du test 10.4.3

Reformulation du test pour mettre en avant différentes conditions de satisfaction du test.

Renumérotation du test 10.4.3 en test 10.4.2.

Ancien test 10.4.3

Test 10.4.3 : Dans chaque page web, l'augmentation de la taille des caractères jusqu'à 200%, au moins, ne doit pas provoquer de perte d'information. Cette règle est-elle respectée?

Nouveau test 9.3.2

Test 10.4.2 : Dans chaque page web, l'augmentation de la taille des caractères jusqu'à 200%, au moins, ne doit pas provoquer de perte d'information. Cette règle est-t-elle respectée selon une de ces conditions (hors cas particuliers)?

  • Lors de l'utilisation de la fonction d'agrandissement du texte du navigateur.
  • Lors de l'utilisation des fonctions de zoom graphique du navigateur.
  • Lors de l'utilisation d'un composant d'interface propre au site permettant d'agrandir le texte ou de zoomer.

Création du test 10.4.3

Ajout d'un test pour s'assurer de la portée de la technique mise en oeuvre dans la gestion de l'agrandissement à 200%.

Nouveau test 9.3.2

Test 10.4.3 : Dans chaque page web, l'augmentation de la taille des caractères jusqu'à 200%, au moins, doit être possible pour l’ensemble du texte dans la page. Cette règle est-t-elle respectée selon une de ces conditions (hors cas particuliers)?

  • Lors de l'utilisation de la fonction d'agrandissement du texte du navigateur.
  • Lors de l'utilisation des fonctions de zoom graphique du navigateur.
  • Lors de l'utilisation d'un composant d'interface propre au site permettant d'agrandir le texte ou de zoomer.

Modification du test 10.6.1

Prise en compte de l’ensemble des conditions présentes dans la technique G183 des WCAG 2.1 précédemment prise en compte dans le test 10.7.3.

Ancien test 10.6.1

Test 10.6.1 : Dans chaque page web, chaque lien texte signalé uniquement par la couleur, et dont la nature n'est pas évidente, a-t-il un rapport de contraste supérieur ou égal à 3:1 par rapport au texte environnant?

Nouveau test 10.6.1

Test 10.6.1 : Dans chaque page web, chaque lien texte signalé uniquement par la couleur, et dont la nature n'est pas évidente, vérifie-t-il ces conditions?

  • La couleur du lien à un rapport de contraste supérieur ou égal à 3:1 par rapport au texte environnant.
  • Le lien dispose d'une indication visuelle au survol autre qu'un changement de couleur.
  • Le lien dispose d'une indication visuelle au focus autre qu'un changement de couleur.

Suppression de la note technique critère 10.7

Prise en compte de l’ensemble des techniques prévues par WCAG.

Ancienne note technique

WCAG propose plusieurs techniques visant à améliorer la visibilité du focus :

  • C15: Using CSS to change the presentation of a user interface component when it receives focus;
  • G195: Using an author-supplied, highly visible focus indicator;
  • SCR31: Using script to change the background color or border of the element with focus.

Bien que ces techniques apportent un bénéfice important à l'utilisateur elles ne sont pas rendues obligatoires par le RGAA du fait de leur impact très fort sur le design et d'éventuelles interactions avec des dispositifs tiers (plugin ou indication native du navigateurs). En tout état de cause elles devraient être proposées via un mécanisme de personnalisation.

Note importante : même si ces techniques sont utilisées elles ne permettent pas de s'abstenir de garantir que l'indication visuelle du focus (propriété outline) n'est ni dégradée ni supprimée. En effet, l'outline controlé et pris en charge par le navigateur apparaît comme la seule solution suffisamment robuste car elle ne dépend pas de l'auteur.

Modification du test 10.7.1

Prise en compte de l’ensemble des techniques WCAG permettant la mise à disposition d’un style au focus.

Ancien test 10.7.1

Test 10.7.1 : Pour chaque élément recevant le focus, l'indication visuelle du navigateur ne doit pas être supprimée (propriété CSS outline, outline-color, outline-width, outline-style). Cette règle est-elle respectée?

Nouveau test 10.7.1

Test 10.7.1 : Pour chaque élément recevant le focus, la prise de focus vérifie-t-elle une de ces conditions?

  • Le style du focus natif du navigateur n'est pas supprimé ou dégradé.
  • Un style du focus défini par l'auteur est visible.

Suppression du test 10.7.2

Suppression suite à la mise à jour du test 10.7.1 et à l'absence d'élément dans les WCAG permettant de juger du caractère dégradé hors tests des contrastes.

Ancien test 10.7.2

Test 10.7.2 : Pour chaque élément recevant le focus, l'indication visuelle du navigateur ne doit pas être dégradée (propriété CSS outline-color). Cette règle est-elle respectée?

Suppression du test 10.7.3

Suppression suite à la mise à jour du test 10.6.1 qui intègre désormais la présence d’une indication visuelle autre que la couleur au survol et au focus.

Ancien test 10.7.3

Test 10.7.3 : Chaque lien dans un texte signalé par la couleur uniquement vérifie-t-il ces conditions?

  • Une indication visuelle autre que la couleur permet de signaler la prise de focus au clavier.
  • Une indication visuelle autre que la couleur permet de signaler le survol du lien à la souris.

Suppression des critères 10.8 à 10.12 et des tests associés

Suppression des critères triple A du RGAA 4.

Suppression des cas particuliers 10.11

Suppression du critère 10.11.

Anciens cas particuliers 10.11

Il existe une gestion de cas particulier pour les langues chinoises, japonaises et coréennes. Dans ces situations, le nombre de caractères de référence est de 40.

Ancien critère 10.8

Critère 10.8 [AAA] Dans chaque page web, le choix de la couleur de fond et de police du texte est-il contrôlable par l'utilisateur?

Ancien critère 10.9

Critère 10.9 [AAA] Pour chaque page web, le texte ne doit pas être justifié. Cette règle est-elle respectée?

Ancien critère 10.10

Critère 10.10 [AAA] Pour chaque page web, en affichage plein écran et avec une taille de police à 200%, chaque bloc de texte reste-t-il lisible sans l'utilisation de la barre de défilement horizontal?

Ancien critère 10.11

Critère 10.11 [AAA] Pour chaque page web, les blocs de texte ont-ils une largeur inférieure ou égale à 80 caractères (hors cas particuliers)?

Ancien critère 10.12

Critère 10.12 [AAA] Pour chaque page web, l'espace entre les lignes et les paragraphes est-il suffisant?

Modification du critère 10.13

Simplification de l’intitulé pour faciliter sa compréhension.

Renumérotation du critère 10.13 en critère 10.8.

Ancien critère 10.13

Critère 10.13 [A] Pour chaque page web, les textes cachés sont-ils correctement affichés pour être restitués par les technologies d'assistance?

Nouveau critère 10.8

Critère 10.8 Pour chaque page web, les contenus cachés ont-ils vocation à être ignorés par les technologies d'assistance?

Modification du test 10.13.1

Modification suite à la mise à jour de l’intitulé du critère 10.13.

Renumérotation du test 10.13.1 en test 10.8.1.

Ancien test 10.13.1

Test 10.13.1 : Dans chaque page web, chaque texte caché vérifie-t-il une de ces conditions?

  • Le texte n'a pas vocation à être restitué par les technologies d'assistance.
  • Le texte est rendu visible sur action de l'utilisateur sur l'élément lui-même ou un élément précédant le texte caché.
  • Le texte caché fait partie d'un motif de conception défini par l'API ARIA, prenant en charge l'état affiché ou masqué du contenu.

Nouveau test 10.8.1

Test 10.8.1 : Dans chaque page web, chaque contenu caché vérifie-t-il une de ces conditions?

  • Le contenu caché a vocation à être ignoré par les technologies d'assistance.
  • Le contenu caché n’a pas vocation à être ignoré par les technologies d’assistances et est rendu restituable par les technologies d'assistance suite à une action de l'utilisateur réalisable au clavier ou par tout dispositif de pointage sur un élément précédent le contenu caché ou suite à un repositionnement du focus dessus.

Modification des références du critère 10.14

Suppression de la technique WCAG G111 non pertinente au regard du critère, car elle concerne une information donnée uniquement par la couleur.

Renumérotation du critère 10.14 en critère 10.9

Pour tenir compte de la suppression des critères 10.8 à 10.12, le critère 10.14 est renuméroté en critère 10.9.

Modification des références du critère 10.15

Suppression de la technique WCAG G111 non pertinente au regard du critère, car elle concerne une information donnée uniquement par la couleur.

Renumérotation du critère 10.15 en critère 10.10

Pour tenir compte de la suppression des critères 10.8 à 10.12, le critère 10.15 est renuméroté en critère 10.10.

Création du critère 10.11 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 1.4.10 Reflow (AA).

Nouveau critère 10.11

Critère 10.11 Pour chaque page web, les contenus peuvent-ils être présentés sans avoir recours à la fois à un défilement vertical pour une fenêtre ayant une hauteur de 256px ou une largeur de 320px (hors cas particuliers)?

Nouveau test 10.11.1

Test 10.11.1 : Pour chaque page web, lorsque le contenu dont le sens de lecture est horizontal est affiché dans une fenêtre réduite à une largeur de 320px, l'ensemble des informations et des fonctionnalités sont-elles disponibles sans aucun défilement horizontal (hors cas particuliers) ?

Nouveau test 10.11.2

Test 10.11.2 : Pour chaque page web, lorsque le contenu dont le sens de lecture est vertical est affiché dans une fenêtre réduite à une hauteur de 256px, l'ensemble des informations et des fonctionnalités sont-elles disponibles sans aucun défilement vertical (hors cas particuliers) ?

Cas particuliers

Font exception à ce critère les contenus dont l'agencement requiert deux dimensions pour être compris ou utilisés comme :

  • Les images, les graphiques ou les vidéos.
  • Les jeux (jeux de plateforme, par exemple).
  • Les présentations (type diaporama, par exemple).
  • Les tableaux de données (complexes).
  • Les interfaces où il est nécessaire d'avoir un ascenseur horizontal lors de la manipulation de l'interface.

Note : la majorité des navigateurs sur les systèmes d'exploitation mobile (Android, iOS) ne gère pas correctement la redistribution en cas de zoom. Dans ce contexte le critère sera considéré comme non applicable sur ces environnements.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.1.4.10 / 1.4.10 Reflow (AA)

Création du critère 10.12 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 1.4.12 Text Spacing (AA).

Nouveau critère 10.12

Critère 10.12 Dans chaque page web, les propriétés d'espacement du texte peuvent-elles être redéfinies par l'utilisateur sans perte de contenu ou de fonctionnalité (hors cas particuliers)?

Nouveau test 10.12.1

Test 10.12.1 : Dans chaque page web, le texte reste-t-il lisible lorsque l'affichage est modifié selon ces conditions (hors cas particuliers)?

  • L'espacement entre les lignes (line-height) est augmenté jusqu'à 1,5 fois la taille de la police;
  • L'espacement suivant les paragraphes (balise <p>) est augmenté jusqu'à 2 fois la taille de la police;
  • L'espacement des lettres (letter-spacing) est augmenté jusqu'à 0,12 fois la taille de la police;
  • L'espacement des mots (word-spacing) est augmenté jusqu'à 0,16 fois la taille de la police;

Cas particuliers

Font exception à ce critère les contenus pour lesquels l'utilisateur n'a pas de possibilité de personnalisation :

  • Les sous-titres directement intégrés à une vidéo.
  • Les images texte.
  • Le texte au sein d'une balise <canvas>.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.1.4.12 / 1.4.12 Text Spacing (AA)

Technique(s) suffisante(s) et/ou échec(s) WCAG 2.1 : C35, C36, C8, C21.

Création du critère 10.13 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 1.4.13 Content on Hover or Focus (AA).

Nouveau critère 10.13

Critère 10.13 Dans chaque page web, les contenus additionnels apparaissant à la prise de focus ou au survol d'un composant d'interface sont-ils contrôlables par l'utilisateur (hors cas particuliers)?

Nouveau test 10.13.1

Test 10.13.1 : Chaque contenu additionnel devenant visible à la prise de focus ou au survol d'un composant d'interface peut-il être masqué par une action utilisateur sans déplacer le focus ou le pointeur de la souris (hors cas particuliers)?

Nouveau test 10.13.2

Test 10.13.2 : Chaque contenu additionnel qui apparaît au survol d'un composant d'interface peut-il être survolé par le pointeur de la souris sans disparaître (hors cas particuliers)?

Nouveau test 10.13.3

Test 10.13.3 : Chaque contenu additionnel qui apparaît à la prise de focus ou au survol d'un composant d'interface vérifie-t-il une de ces conditions (hors cas particuliers)?

  • Le contenu additionnel reste visible jusqu'à ce que l'utilisateur retire le pointeur souris ou le focus du contenu additionnel et du composant d'interface ayant déclenché son apparition.
  • Le contenu additionnel reste visible jusqu'à ce l'utilisateur déclenche une action masquant ce contenu sans déplacer le focus ou le pointeur souris du composant d'interface ayant déclenché son apparition.
  • Le contenu additionnel reste visible jusqu'à ce qu'il ne soit plus valide.

Cas particuliers

Lorsque le contenu additionnel est contrôlé par l'agent utilisateur (par exemple, attribut title ou validation native de formulaire) ou correspond à une fenêtre modale conforme au motif de conception WAI-ARIA dialog, le critère 10.13 est non applicable.

Lorsque le contenu additionnel ne masque ou ne remplace aucun contenu porteur d'information le test 10.13.1 est non applicable.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.1.4.13 / 1.4.13 Content on Hover or Focus (AA)

Technique(s) suffisante(s) et/ou échec(s) WCAG 2.1 : F95.

Création du critère 10.14 et des tests associés

Prise en compte des contenus additionnels gérés au moyen de styles CSS.

Nouveau critère 10.14

Critère 10.14 Dans chaque page web, les contenus additionnels apparaissant via les styles CSS uniquement peuvent-ils être rendus visibles au clavier et par tout dispositif de pointage?

Nouveau test 10.14.1

Test 10.14.1 : Dans chaque page web, les contenus additionnels apparaissant au survol d'un composant d'interface via les styles CSS respectent-ils si nécessaire une de ces conditions?

  • Les contenus additionnels apparaissent également à l'activation du composant via le clavier et tout dispositif de pointage.
  • Les contenus additionnels apparaissent également à la prise de focus du composant.
  • Les contenus additionnels apparaissent également par le biais de l'activation ou de la prise de focus d'un autre composant.

Nouveau test 10.14.2

Test 10.14.2 : Dans chaque page web, les contenus additionnels apparaissant au focus d'un composant d'interface via les styles CSS respectent-ils si nécessaire une de ces conditions?

  • Les contenus additionnels apparaissent également à l'activation du composant via le clavier et tout dispositif de pointage.
  • Les contenus additionnels apparaissent également au survol du composant.
  • Les contenus additionnels apparaissent également par le biais de l'activation ou du survol d'un autre composant.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.1.1 / 2.1.1 Keyboard (A)

Technique(s) suffisante(s) et/ou échec(s) WCAG 2.1 : G202.

Modification du test 11.1.1

Référence directe à la balise

Modification de l'ordre des conditions pour reprendre l'ordre de calcul du nom accessible tel que prévu dans la spécification accname 1.1.

Nouvelle condition de test pour prendre en compte la technique G167 des WCAG.

Ancien test 11.1.1

Test 11.1.1 :Chaque champ de formulaire vérifie-t-il une de ces conditions?

  • Le champ de formulaire possède un attribut title.
  • Une étiquette (balise <label>) est associée au champ de formulaire.
  • Le champ de formulaire possède une propriété aria-label.
  • Le champ de formulaire possède une propriété aria-labelledby référençant un passage de texte identifié.

Nouveau test 11.1.1

Test 11.1.1 : Chaque champ de formulaire vérifie-t-il une de ces conditions?

  • Le champ de formulaire possède un attribut WAI-ARIA aria-labelledby référençant un passage de texte identifié.
  • Le champ de formulaire possède un attribut WAI ARIA aria-label.
  • Une balise <label> ayant un attribut for est associée au champ de formulaire.
  • Le champ de formulaire possède un attribut title.
  • Un bouton adjacent au champ de formulaire lui fournit une étiquette visible et un attribut WAI-ARIA aria-label, aria-labelledby ou title lui fournit un nom accessible.

Modification du test 11.1.2

Référence directe à la balise

Ajout d'une condition en cas de présence d'un attribut aria-label ou d'un attribut aria-labelledby.

Ancien test 11.1.2

Test 11.1.2 : Chaque champ de formulaire, associé à une étiquette (balise <label>), vérifie-t-il ces conditions?

  • Le champ de formulaire possède un attribut id.
  • La valeur de l'attribut id est unique.
  • La balise <label> possède un attribut for.
  • La valeur de l'attribut for est égale à la valeur de l'attribut id du champ de formulaire associé.

Nouveau test 11.1.2

Test 11.1.2 : Chaque champ de formulaire associé à une balise <label> ayant un attribut for, vérifie-t-il ces conditions?

  • Le champ de formulaire possède un attribut id.
  • La valeur de l'attribut for est égale à la valeur de l'attribut id du champ de formulaire associé.

Suppression du test 11.1.3

Suppression du test suite à la modification de l'entrée de glossaire "Passage de texte" qui précise désormais la présence de l'attribut id, son unicité et l'utilisation de sa valeur dans l'attribut aria-labelledby du champ correspondant.

Ancien test 11.1.3

Test 11.1.3 : Chaque champ de formulaire associé à une étiquette via la propriété ARIA aria-labelledby, vérifie-t-il ces conditions?

  • L'étiquette possède un attribut id.
  • La valeur de l'attribut id est unique.
  • Les valeurs de la propriété ARIA aria-labelledby sont égales à la valeur des attributs id des passages de textes utilisés pour créer l'étiquette.

Modification du test 11.1.4

Modification du test en raison de la prise en compte de l'usage de balise <label> masqué et suppression de l'expression redondante ARIA aria-xxx.

Renumérotation du test 11.1.4 en test 11.1.3.

Ancien test 11.1.4

Test 11.1.4 : Chaque champ de formulaire qui utilise une propriété ARIA aria-label ou aria-labelledby est-il, si nécessaire, accompagné d'un passage de texte visible et accolé au champ permettant de comprendre la nature de la saisie attendue?

Nouveau test 11.1.3

Test 11.1.3 : Chaque champ de formulaire ayant une étiquette dont le contenu n'est pas visible ou à proximité (masqué, aria-label) ou qui n’est pas accolé au champ (aria-labelledby), vérifie-t-il une de ses conditions?

  • Le champ de formulaire possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue.
  • Le champ de formulaire est accompagné d'un passage de texte accolé au champ qui devient visible à la prise de focus permettant de comprendre la nature de la saisie attendue.
  • Le champ de formulaire est accompagné d'un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue.

Suppression du test 11.1.5

Suppression de ce test car aucune technique WCAG correspondante à ce test et ce point est déjà couvert par la pertinence de l'étiquette (critère 11.2) pour les cas où le placeholder serait non pertinent et restituté comme nom accessible.

Ancien test 11.1.5

Test 11.1.5 : Chaque champ de formulaire qui utilise un attribut title comme étiquette, vérifie-t-il une de ces conditions?

  • L'attribut placeholder est absent.
  • L'attribut placeholder est identique à l'attribut title.

Création des cas particuliers 11.2

Ajout de cas particuliers concernant les exceptions introduites par le critère WCAG 2.5.3 Label in Name.

Nouveaux cas particuliers 11.2

Il existe une gestion de cas particulier pour le test 11.2.5 lorsque :

  • La ponctuation et les lettres majuscules sont présentes dans le texte de l’intitulé visible : elles peuvent être ignorées dans le nom accessible sans porter à conséquence.
  • Le texte de l’intitulé visible sert de symbole : le texte ne doit pas être interprété littéralement au niveau du nom accessible. Le nom doit exprimer la fonction véhiculée par le symbole (par exemple, "B" au niveau d'un éditeur de texte aura pour nom accessible "Mettre en gras", le signe ">" en fonction du contexte signifiera "Suivant" ou "Lancer la vidéo"). Le cas des symboles mathématiques fait cependant exception (voir la note ci-dessous).

Note : si l'étiquette visible représente une expression mathématique, les symboles mathématiques peuvent être repris littéralement pour servir d'étiquette au nom accessible (ex. : "A>B"). Il est laissé à l'utilisateur le soin d'opérer la correspondance entre l'expression et ce qu'il doit épeler compte tenu de la connaissance qu'il a du fonctionnement de son logiciel de saisie vocale ("A plus grand que B" ou "A supérieur à B").

Modification du test 11.2.1

Référence directe à la balise <label> car les autres techniques pour associer une étiquette sont traitées par les tests suivants.

Ancien test 11.2.1

Test 11.2.1 : Chaque étiquette (balise <label>) permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée?

Nouveau test 11.2.1

Test 11.2.1 : Chaque balise <label> permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée?

Modification du test 11.2.4

Remplacement de "étiquette" par la nouvelle entrée de glossaire "Passage de texte".

Ancien test 11.2.4

Test 11.2.4 : Chaque étiquette implémentée via la propriété ARIA aria-labelledby permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée?

Nouveau test 11.2.4

Test 11.2.4 : Chaque passage de texte associé via l'attribut WAI-ARIA aria-labelledby permet-il de connaître la fonction exacte du champ de formulaire auquel il est associé?

Création du test 11.2.5

Prise en compte du critère WCAG 2.1 “Label in name”.

Nouveau test 11.2.5

Test 11.2.5 : Chaque champ de formulaire ayant un intitulé visible vérifie-t-il ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label du champ de formulaire contient au moins l'intitulé visible.
  • S'il est présent, le passage de texte lié au champ de formulaire via un attribut WAI-ARIA aria-labelledby contient au moins l'intitulé visible.
  • S'il est présent, le contenu de l'attribut title du champ de formulaire contient au moins l'intitulé visible.
  • S'il est présent le contenu de la balise <label> associé au champ de formulaire contient au moins l'intitulé visible.

Création du test 11.2.6

Prise en compte de la possibilité d'utiliser un bouton adjacent au champ de formulaire comme étiquette visible.

Nouveau test 11.2.6

Test 11.2.6 : Chaque bouton adjacent au champ de formulaire qui fournit une étiquette visible permet-il de connaître la fonction exacte du champ de formulaire auquel il est associé ?

Modification du critère 11.4

Ajout d'un cas particulier pour les tests 11.4.2 et 11.4.3.

Ancien critère 11.4

Critère 11.4 [A] Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés?

Nouveau critère 11.4

Critère 11.4 Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers)?

Création des cas particuliers 11.4

Ajout des cas particuliers pour les tests 11.4.2 et 11.4.3.

Nouveaux cas particuliers 11.4

Les tests 11.4.2 et 11.4.3 seront considérés comme non applicable :

  • Dans le cas où l'étiquette mélange une portion de texte qui se lit de droite à gauche avec une portion de texte qui se lit de gauche à droite.
  • Dans le cas où un formulaire contient des labels de plusieurs langues qui se liraient de droite à gauche et inversement. Par exemple un formulaire de commande en arabe qui propose une liste de cases à cocher de produit en langue française ou mixant des produits en langue arabe et en langue française.
  • Dans le cas où les champs de type radio ou checkbox et les balises ayant un attribut WAI-ARIA role="checkbox", role="radio" ou role="switch" ne sont pas visuellement présentés sous forme de bouton radio ou de case à cocher
  • Dans le cas où les champs seraient utilisés dans un contexte où il pourrait être légitime, du point de vue de l'expérience utilisateur, de placer les étiquettes de manière différente à celle requise dans les tests 11.4.2 et 11.4.3.

Création du test 11.4.2

Test ajouté suite à la prise en compte des contraintes présentes dans la technique G162 des WCAG.

Nouveau test 11.4.2

Test 11.4.2 : Chaque étiquette accolée à un champ (à l'exception des case à cocher, bouton radio ou balise ayant un attribut WAI-ARIA role="checkbox", role="radio" ou role="switch"), vérifie-t-elle ces conditions (hors cas particuliers)?

  • L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de gauche à droite.
  • L'étiquette est visuellement accolée immédiatement au-dessus ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de droite à gauche.

Création du test 11.4.3

Test ajouté suite à la prise en compte des contraintes présentes dans la technique G162 des WCAG.

Nouveau test 11.4.3

Test 11.4.3 : Chaque étiquette accolée à un champ de type checkbox ou radio ou à une balise ayant un attribut WAI-ARIA role="checkbox", role="radio" ou role="switch", vérifie-t-elle ces conditions (hors cas particuliers)?

  • L'étiquette est visuellement accolée immédiatement au-dessus ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de gauche à droite.
  • L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de droite à gauche.

Modification du critère 11.5

Modification de l’intitulé du critère suite à la modification de l'entrée de glossaire "Champs de même nature".

Ancien critère 11.5

Critère 11.5 [A] Dans chaque formulaire, les informations de même nature sont-elles regroupées, si nécessaire?

Nouveau critère 11.5

Critère 11.5 Dans chaque formulaire, les champs de même nature sont-ils regroupés, si nécessaire?

Modification des références du critère 11.5

Ajout de la technique WCAG ARIA17 à propos du rôle de regroupement.

Modification du test 11.5.1

Prise en compte de la modification de l’entrée de glossaire "Bloc d'informations de même nature" et de la technique WCAG ARIA17.

Ancien test 11.5.1

Test 11.5.1 : Dans chaque formulaire, les informations de même nature sont-elles regroupées, si nécessaire?

Nouveau test 11.5.1

Test 11.5.1 : Dans chaque formulaire, les champs de même nature vérifient-ils l’une de ces conditions, si nécessaire?

  • Les champs de même nature sont regroupés dans une balise <fieldset>.
  • Les champs de même nature sont regroupés dans une balise possédant un attribut WAI-ARIA role="group".
  • Les champs de même nature de type radio (<input type="radio"> ou balises possédant un attribut WAI-ARIA role="radio") sont regroupés dans une balise possédant un attribut WAI-ARIA role="radiogroup" ou "group".

Modification des références du critère 11.6

Ajout de la technique WCAG ARIA17 à propos du rôle de regroupement.

Modification du test 11.6.1

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Groupement de champ de formulaire" par "champs de même nature" et à la création de l'entrée "Légende".

Ancien test 11.6.1

Test 11.6.1 : Chaque regroupement de champs de formulaire possède-t-il une légende?

Nouveau test 11.6.1

Test 11.6.1 : Chaque regroupement de champs de même nature possède-t-il une légende ?

Modification du critère 11.7

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Groupement de champ de formulaire" par "Champs de même nature".

Ancien critère 11.7

Critère 11.7 [A] Dans chaque formulaire, chaque légende associée à un groupement de champs de formulaire est-elle pertinente?

Nouveau critère 11.7

Critère 11.7 Dans chaque formulaire, chaque légende associée à un regroupement de champs de même nature est-elle pertinente ?

Modification du test 11.7.1

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Groupement de champ de formulaire" par "Champs de même nature".

Ancien test 11.7.1

Test 11.7.1 : Dans chaque formulaire, chaque légende associée à un groupement de champs de formulaire est-elle pertinente?

Nouveau test 11.7.1

Test 11.7.1 : Chaque légende associée à un regroupement de champs de même nature est-elle pertinente ?

Modification du critère 11.8

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Liste de choix" par "Items de même nature d’une liste de choix".

Ancien critère 11.8

Critère 11.8 [A] Dans chaque formulaire, chaque liste de choix est-elle structurée de manière pertinente?

Nouveau critère 11.8

Critère 11.8 Dans chaque formulaire, les items de même nature d'une liste de choix sont-ils regroupées de manière pertinente?

Création de la note technique critère 11.8

Précision concernant l'impossibilité de créer des groupes d’options au moyen de WAI-ARIA.

Nouvelle note technique

Il est possible d’utiliser une balise ayant un attribut WAI-ARIA role="listbox" en remplacement d’une balise <select>. En revanche, il est impossible de créer des groupes d’options au moyen de WAI-ARIA. De ce fait, une liste nécessitant un regroupement d’options et structurée à l’aide d’une balise ayant un attribut WAI-ARIA role="listbox" sera considérée comme non conforme au critère 11.8.

Modification du test 11.8.1

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Liste de choix" par "Items de même nature d’une liste de choix".

Ancien test 11.8.1

Test 11.8.1 : Dans chaque formulaire, pour chaque liste de choix (balise <select>), les items sont-ils regroupés avec une balise <optgroup>, si nécessaire?

Nouveau test 11.8.1

Test 11.8.1 : Pour chaque balise <select>, les items de même nature d'une liste de choix sont-ils regroupés avec une balise <optgroup>, si nécessaire?

Modification du test 11.8.2

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Liste de choix" par "Items de même nature d’une liste de choix".

Ancien test 11.8.2

Test 11.8.2 : Dans chaque liste de choix (balise <select>), chaque regroupement d'items de liste (balise <optgroup>) possède-t-il un attribut label?

Nouveau test 11.8.2

Test 11.8.2 : Dans chaque balise <select>, chaque balise <optgroup> possède-t-elle un attribut label?

Modification du test 11.8.3

Modification de l’intitulé du critère suite au remplacement de l'entrée de glossaire "Liste de choix" par "Items de même nature d’une liste de choix".

Ancien test 11.8.3

Test 11.8.3 : Pour chaque regroupement d'items de liste (balise <optgroup>) ayant un attribut label, le contenu de l'attribut label est-il pertinent?

Nouveau test 11.8.3

Test 11.8.3 : Pour chaque balise <optgroup> ayant un attribut label, le contenu de l'attribut label est-il pertinent?

Création des cas particuliers 11.9

Ajout de cas particuliers concernant les exceptions introduites par le critère WCAG 2.5.3 Label in Name.

Nouveaux cas particuliers 11.4

Pour le test 11.9.2, voir cas particuliers critère 11.2.

Modification des références du critère 11.9

Ajout du critère WCAG 2.1 "Label in name".

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.5.3 / 2.5.3 Label in Name (A)
  • 9.4.1.2 / 4.1.2 Name, Role, Value (A)

Modification du test 11.9.1

Ajouts d'une condition suite à la modification de l’entrée de glossaire "Bouton (formulaire)".

Modification de l'ordre des conditions pour reprendre l'ordre de calcul du nom accessible.

Ancien test 11.9.1

Test 11.9.1 : Dans chaque formulaire, l'intitulé de chaque bouton vérifie-t-il ces conditions?

  • Le contenu de l'attribut value des boutons de formulaire de type submit, reset ou button est pertinent.
  • Le contenu de la balise <button> est pertinent.
  • Le contenu de l'attribut title est pertinent.
  • Le contenu de la propriété ARIA aria-label est pertinent.
  • Un passage de texte est lié au bouton via un attribut aria-labelledby.

Nouveau test 11.9.1

Test 11.9.1 : L'intitulé de chaque bouton est-il pertinent?

  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label est pertinent.
  • S'il est présent, le passage de texte lié au bouton via un attribut WAI-ARIA aria-labelledby est pertinent.
  • S'il est présent, le contenu de l'attribut value d'une balise <input> de type submit, reset ou button est pertinent.
  • S'il est présent, le contenu de la balise <button> est pertinent.
  • S'il est présent, le contenu de l'attribut alt d'une balise <input> de type image est pertinent.
  • S'il est présent, le contenu de l'attribut title est pertinent.

Suppression du test 11.9.2

Suppression du test suite à la modification de l'entrée de glossaire "Passage de texte" qui précise désormais la présence de l'attribut id, son unicité et l'utilisation de sa valeur dans l'attribut aria-labelledby du champ correspondant.

Ancien test 11.9.2

Test 11.9.2 : Dans chaque formulaire, l'intitulé de chaque bouton implémenté via une propriété ARIA aria-labelledby vérifie-t-il ces conditions?

  • Le passage de texte servant d'intitulé possède un attribut id.
  • La valeur de l'attribut id est unique.
  • Les valeurs de la propriété ARIA aria-labelledby sont égales à la valeur des attributs id des passages de textes utilisés pour créer l'intitulé.
  • Le passage de texte est pertinent.

Création du test 11.9.2

Prise en compte du critère WCAG 2.1 "Label in name".

Nouveau test 11.9.2

Test 11.9.2 : Chaque bouton affichant un intitulé visible vérifie-t-il ces conditions (hors cas particuliers)?

  • S'il est présent, le contenu de l'attribut WAI-ARIA aria-label contient au moins l'intitulé visible.
  • S'il est présent, le passage de texte lié au bouton via un attribut WAI-ARIA aria-labelledby contient au moins l'intitulé visible.
  • S'il est présent, le contenu de l'attribut value d'une balise <input> de type submit, reset ou button contient au moins l'intitulé visible.
  • S'il est présent, le contenu de la balise <button> contient au moins l'intitulé visible.
  • S'il est présent, le contenu de l'attribut alt d'une balise <input> de type image contient au moins l'intitulé visible.
  • S'il est présent, le contenu de l'attribut title contient au moins l'intitulé visible.

Modification du critère 11.10

Prise en compte du cas particulier pour le test 11.10.1.

Ancien critère 11.5

Critère 11.10 [A] Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente?

Nouveau critère 11.5

Critère 11.10 Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers)?

Création des cas particuliers 11.10

Précision de l'application du test 11.10.1.

Nouveaux cas particuliers 11.10

Le test 11.10.1 sera considéré comme non applicable lorsque le formulaire comporte un seul champ de formulaire ou qu'il indique les champs optionnels de manière :

  • Visible ;
  • Dans la balise <label> ou dans la légende associée au champ.

Dans le cas où l'ensemble des champs d'un formulaire sont obligatoires, le test 11.10.1 reste applicable.

Modification du test 11.10.1

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Ancien test 11.10.1

Test 11.10.1 : Pour chaque formulaire, les indications de champs obligatoires vérifient-elles une de ces conditions?

  • L'indication de champ obligatoire est donnée par un passage de texte situé avant le champ de formulaire.
  • L'indication de champ obligatoire est donnée via un attribut required.
  • L'indication de champ obligatoire est donnée via la propriété ARIA aria-required.
  • L'indication de champ obligatoire est donnée dans l'étiquette du champ de formulaire.
  • L'indication de champ obligatoire est donnée par un passage de texte lié par la propriété ARIA aria-describedby.

Nouveau test 11.10.1

Test 11.10.1 : Les indications du caractère obligatoire de la saisie des champs vérifient-elles une de ces conditions (hors cas particuliers)?

  • Une indication de champ obligatoire est visible et permet d'identifier nommément le champ concerné préalablement à la validation du formulaire.
  • Le champ obligatoire dispose de l'attribut aria-required="true" ou required préalablement à la validation du formulaire.

Modification du test 11.10.2

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Ancien test 11.10.2

Test 11.10.2 : Chaque indication de champ obligatoire qui utilise les propriétés ARIA aria-label, aria-required ou l'attribut required doit être accompagnée d'une indication visuelle explicite dans l'étiquette ou dans un passage de texte lié au champ par la propriété ARIA aria-describedby ou aria-labelledby, cette règle est-elle respectée?

Nouveau test 11.10.2

Test 11.10.2 : Les champs obligatoires ayant l'attribut aria-required="true" ou required vérifient-ils une de ces conditions?

  • Une indication de champ obligatoire est visible et située dans l'étiquette associé au champ préalablement à la validation du formulaire.
  • Une indication de champ obligatoire est visible et située dans le passage de texte associé au champ préalablement à la validation du formulaire.

Suppression du test 11.10.3

Suppression du test suite à la modification de l'entrée de glossaire "Passage de texte" qui précise désormais la présence de l'attribut id, son unicité et l'utilisation de sa valeur dans l'attribut aria-labelledby du champ correspondant.

Ancien test 11.10.3

Test 11.10.3 : Chaque indication de champ obligatoire qui utilise un passage de texte lié par la propriété ARIA aria-describedby ou aria-labelledby vérifie-t-elle ces conditions?

  • Le passage de texte est identifié via un attribut id.
  • La valeur de l'attribut id est unique.
  • Les valeurs de la propriété ARIA aria-describedby ou aria-labelledby sont égales à la valeur des attributs id.

Modification du test 11.10.4

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Renumérotation du test 11.10.4 en test 11.10.3.

Ancien test 11.10.4

Test 11.10.4 : Pour chaque formulaire, les erreurs de saisie vérifient-elles une de ces conditions?

  • L'erreur de saisie est indiquée dans l'étiquette du champ de formulaire.
  • L'erreur de saisie est indiquée par un passage de texte avant le champ de formulaire.
  • Le champ de formulaire possède un type qui produit de manière automatique un message d'erreur de saisie.
  • L'erreur de saisie est indiquée par un passage de texte lié par la propriété ARIA aria-describedby.
  • L'erreur de saisie est indiquée via la propriété ARIA aria-invalid.

Nouveau test 11.10.3

Test 11.10.3 : Les messages d'erreur indiquant l'absence de saisie d'un champ obligatoire vérifient-ils une de ces conditions?

  • le message d'erreur indiquant l'absence de saisie d'un champ obligatoire est visible et permet d'identifier nommément le champ concerné.
  • Le champ obligatoire dispose de l'attribut aria-invalid="true".

Modification du test 11.10.5

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Renumérotation du test 11.10.5 en test 11.10.4.

Ancien test 11.10.5

Test 11.10.5 : Chaque indication d'erreur de saisie réalisée grâce à la propriété ARIA aria-label ou aria-invalid doit être accompagnée d'une indication visuelle explicite dans l'étiquette : balise label, texte visible à proximité ou passage de texte lié au champ par la propriété ARIA aria-describedby ou aria-labelledby. Cette règle est-elle respectée?

Nouveau test 11.10.4

Test 11.10.4 : Les champs obligatoires ayant l'attribut aria-invalid="true" vérifient-ils une de ces conditions?

  • Une indication de champ obligatoire est visible et située dans l'étiquette associée au champ.
  • Une indication de champ obligatoire est visible et située dans le passage de texte associé au champ.

Suppression du test 11.10.6

Suppression du test suite à la modification de l'entrée de glossaire "Passage de texte" qui précise désormais la présence de l'attribut id, son unicité et l'utilisation de sa valeur dans l'attribut aria-labelledby du champ correspondant.

Ancien test 11.10.6

Test 11.10.6 : Chaque erreur de saisie qui utilise un passage de texte lié par la propriété ARIA aria-describedby ou aria-labelledby vérifie-t-elle ces conditions?

  • Le passage de texte est identifié via un attribut id.
  • La valeur de l'attribut id est unique.
  • Les valeurs de la propriété ARIA aria-describedby ou aria-labelledby sont égales aux valeurs des attributs id des passages de texte utilisés pour créer l'étiquette.

Modification du test 11.10.7

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Renumérotation du test 11.10.7 en test 11.10.5.

Ancien test 11.10.7

Test 11.10.7 : Pour chaque formulaire, chaque champ obligatoire vérifie-t-il une de ces conditions?

  • Le type de données et/ou de format est indiqué, si nécessaire, dans l'étiquette du champ.
  • Le type de données et/ou de format est indiqué, si nécessaire, par un passage de texte avant le champ de formulaire.
  • Le type de données et/ou de format est indiqué, si nécessaire, par un passage de texte lié par la propriété ARIA aria-describedby.

Nouveau test 11.10.5

Test 11.10.5 : Les instructions et indications du type de données et/ou de format obligatoires vérifient-elles une de ces conditions?

  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et permet d'identifier nommément le champ concerné préalablement à la validation du formulaire.
  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible dans l'étiquette ou le passage de texte associé au champ préalablement à la validation du formulaire.

Création du test 11.10.6

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Nouveau test 11.10.6

Test 11.10.6 : Les messages d'erreurs fournissant une instruction ou une indication du type de données et/ou de format obligatoire des champs vérifient-ils une de ces conditions?

  • Le message d'erreur fournissant une instruction ou une indication du type de données et/ou de format obligatoires est visible et identifie le champ concerné.
  • Le champ dispose de l'attribut aria-invalid="true".

Modification du test 11.10.8

Prise en compte de la mise à disposition d'information sur le caractère obligatoire des champs préalablement à la saisie.

Renumérotation du test 11.10.8 en test 11.10.7.

Ancien test 11.10.8

Test 11.10.8 : Chaque indication du type de données et/ou de format réalisée grâce à la propriété ARIA aria-label doit être accompagnée d'une indication visuelle explicite dans l'étiquette ou dans un passage de texte lié au champ par la propriété ARIA aria-describedby ou aria-labelledby, cette règle est-elle respectée?

Nouveau test 11.10.7

Test 11.10.7 : Les champs ayant l'attribut aria-invalid="true" dont la saisie requiert un type de données et/ou de format obligatoires vérifient-ils une de ces conditions?

  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans la balise <label> associée au champ.
  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans le passage de texte associé au champ.

Suppression du test 11.10.9

Suppression du test suite à la modification de l'entrée de glossaire "Passage de texte" qui précise désormais la présence de l'attribut id, son unicité et l'utilisation de sa valeur dans l'attribut aria-labelledby du champ correspondant.

Ancien test 11.10.9

Test 11.10.9 : Chaque indication de type de données et/ou de format qui utilise un passage de texte lié par la propriété ARIA aria-describedby ou aria-labelledby vérifie-t-elle ces conditions?

  • Le passage de texte est identifié via un attribut id.
  • La valeur de l'attribut id est unique.
  • Les valeurs de la propriété ARIA aria-describedby ou aria-labelledby sont égales aux valeurs des attributs id.

Suppression du test 11.10.10

Suppression en l'absence d'une technique WCAG justifiant la nécessité d'une identité des contenus du placeholder et du title.

Ancien test 11.10.10

Test 11.10.10 : Chaque champ de formulaire qui utilise un attribut title comme aide à la saisie, vérifie-t-il une de ces conditions?

  • L'attribut placeholder est absent.
  • L'attribut placeholder est identique à l'attribut title.

Modification note technique critère 11.11

Suppression de l'avertissement concernant le non support de l'API Contraint Validation qui n'est plus d'actualité et mise à jour de la référence.

Ancienne note technique

Certains types de formulaire HTML5 proposent des messages d'aide à la saisie automatique, par exemple les types url et email affichent un message du type « veuillez saisir une adresse e-mail valide » dans le cas où l'adresse e-mail saisie ne correspond pas au format attendu. Ces messages sont personnalisables via l'API Constraint Validation qui peut permettre de personnaliser les messages d'erreur et valider le critère. Attention cependant, le support de cette API n'est pas encore stabilisé. Le type pattern qui permet d'effectuer automatiquement des contrôles de format (via des expressions régulières) affiche également un message d'aide, mais ce dernier est personnalisable via l'attribut title, ce dispositif valide le critère.

Référence : WHATWG - 4.10.21.3 The constraint validation API.

Nouvelle note technique

Certains types de formulaire HTML5 proposent des messages d'aide à la saisie automatique, par exemple les types url et email affichent un message du type « veuillez saisir une adresse e-mail valide » dans le cas où l'adresse e-mail saisie ne correspond pas au format attendu. Ces messages sont personnalisables via l'API Constraint Validation qui peut permettre de personnaliser les messages d'erreur et valider le critère. Le type pattern qui permet d'effectuer automatiquement des contrôles de format (via des expressions régulières) affiche également un message d'aide, mais ce dernier est personnalisable via l'attribut title, ce dispositif valide le critère.

Référence : HTML 5.2 - 4.10.20.3 The constraint validation API.

Modification du critère 11.12

Prise en compte plus complète des cas d'usage définis par le critère 3.3.4 des WCAG.

Ancien critère 11.5

Critère 11.12 [AA] Pour chaque formulaire, les données à caractère financier, juridique ou personnel peuvent-elles être modifiées, mises à jour ou récupérées par l'utilisateur?

Nouveau critère 11.5

Critère 11.12 Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou à un examen, ou dont la validation a des conséquences financières ou juridiques, la saisie des données vérifie-t-elle une de ces conditions?

Modification du test 11.12.1

Modification du test suite à la mise à jour du critère 11.12 et à la création de l’entrée de glossaire "Modifier ou annuler les données et les actions effectuées".

Remplacement de "personnel" par "les réponses de l’utilisateur à un test ou un examen" conformément à WCAG pour le cas confirmation.

Ancien test 11.12.1

Test 11.12.1 : Pour chaque formulaire, la saisie des données à caractère financier, juridique ou personnelle vérifie-t-elle une de ces conditions?

  • L'utilisateur peut modifier ou annuler les données et les actions effectuées sur ces données après leur saisie.
  • L'utilisateur peut vérifier et corriger les données avant la validation du formulaire.
  • Un mécanisme de confirmation explicite, via un champ de formulaire ou une étape supplémentaire, est présent.

Nouveau test 11.12.1

Test 11.12.1 : Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou un examen, ou dont la validation a des conséquences financières ou juridiques, la saisie des données vérifie-t-elle une de ces conditions?

  • L'utilisateur peut modifier ou annuler les données et les actions effectuées sur ces données après la validation du formulaire.
  • L'utilisateur peut vérifier et corriger les données avant la validation d'un formulaire en plusieurs étapes.
  • Un mécanisme de confirmation explicite, via une case à cocher (balise <input> de type checkbox ou balise ayant un attribut WAI-ARIA role="checkbox") ou une étape supplémentaire, est présent.

Modification du test 11.12.2

Modification du test suite à la mise à jour du critère 11.12 et à la création de l’entrée de glossaire "Modifier ou annuler les données et les actions effectuées".

Prise en compte du cas de la modification de données existantes tel que prévu dans les WCAG.

Ancien test 11.12.2

Test 11.12.2 : Pour chaque formulaire , la suppression des données à caractère financier, juridique ou personnelle vérifie-t-elle une de ces conditions?

  • Un mécanisme permet de récupérer les données supprimées par l'utilisateur.
  • Un mécanisme de confirmation explicite de la suppression, via un champ de formulaire ou une étape supplémentaire, est présent.

Nouveau test 11.12.2

Test 11.12.2 : Chaque formulaire dont la validation modifie ou supprime des données à caractère financier, juridique ou personnel vérifie-t-il une de ces conditions?

  • Un mécanisme permet de récupérer les données supprimées ou modifiées par l'utilisateur.
  • Un mécanisme de demande de confirmation explicite de la suppression ou de la modification, via un champ de formulaire ou une étape supplémentaire, est proposé.

Création du critère 11.13 et du test associé

Prise en compte du nouveau critère WCAG 2.1 : 1.3.5 Identify Input Purpose (AA).

Nouveau critère 11.13

Critère 11.13 La finalité d'un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l'utilisateur ?

Nouveau test 11.13.1

Test 11.13.1 : Chaque champ de formulaire dont l'objet se rapporte à une information concernant l'utilisateur vérifie-t-il ces conditions?

  • Le champ de formulaire possède un attribut autocomplete.
  • L'attribut autocomplete est pourvu d'une valeur présente dans la liste des valeurs possibles pour l'attribut autocomplete associés à un champ de formulaire.
  • La valeur indiquée pour l'attribut autocomplete est pertinente au regard du type d'information attendu.

Nouvelle note technique

La liste des valeurs possibles pour l'attribut autocomplete repose sur la liste des valeurs présentes dans la spécifications WCAG2.1 qui reprend elle-même la liste des valeurs de type « field name » de la spécification HTML5.2. Le critère WCAG demande à ce que l'une de ces valeurs soit présente pour qualifier un champ de saisie concernant l'utilisateur.

Ce que le critère WCAG laisse implicite, ce sont les différentes règles de construction possibles pour obtenir une valeur (simple ou composée) pour l'attribut autocomplete. C'est cependant l'affaire du développeur de fournir à l'attribut autocomplete une valeur ou un ensemble de valeurs valides au regard des exigences de l'algorithme fourni par la spécification HTML5.2. Ainsi, un attribut autocomplete ne peut contenir qu'une seule valeur de type field name, comme "name" ou "street-address". On peut avoir également un ensemble composé de différentes valeurs comme, par exemple, autocomplete="shipping name" ou autocomplete="section-software shipping street-address" : "section-software" renvoie à une valeur de type scope et "shipping" à une valeur de type hint set, mais toujours une seule valeur de type field name.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.1.3.5/ 1.3.5 Identify Input Purpose (AA)

Technique(s) suffisante(s) et/ou échec(s) WCAG 2.1 : H98.

Modification du test 12.2.1

Les tests 12.2.1 et 12.2.2 sont redondants car ils disent la même chose pour deux types d’élément, menu et barres de navigation, dont le premier n’est qu’un cas spécifique du second. Ces deux types d’élément peuvent donc être rassemblés en un seul et même test. D’où la modification du test 12.2.1 et la suppression du test 12.2.2, et la fusion des deux entrées de glossaire "Barre de navigation" et "Menu de navigation".

Ancien test 12.2.1

Test 12.2.1 : Dans chaque ensemble de pages, chaque page ayant un menu de navigation vérifie-t-elle ces conditions (hors cas particuliers)?

  • Le menu de navigation est toujours à la même place dans la présentation.
  • Le menu de navigation se présente toujours dans le même ordre relatif dans le code source.

Nouveau test 12.2.1

Test 12.2.1 : Dans chaque ensemble de pages, chaque page disposant d'un menu ou de barres de navigation vérifie-t-elle ces conditions (hors cas particuliers) ?

  • Le menu ou les barres de navigation sont toujours à la même place dans la présentation.
  • Le menu ou les barres de navigation se présentent toujours dans le même ordre relatif dans le code source.

Suppression du test 12.2.2

Les tests 12.2.1 et 12.2.2 sont redondants car ils disent la même chose pour deux types d’élément, menu et barres de navigation, dont le premier n’est qu’un cas spécifique du second. Ces deux types d’élément peuvent donc être rassemblés en un seul et même test. D’où la modification du test 12.2.1 et la suppression du test 12.2.2, et la fusion des deux entrées de glossaire "Barre de navigation" et "Menu de navigation".

Ancien test 12.2.2

Test 12.2.2 : Chaque barre de navigation répétée dans un ensemble de pages vérifie-t-elle ces conditions (hors cas particuliers)?

  • La barre de navigation est toujours à la même place dans la présentation.
  • La barre de navigation se présente toujours dans le même ordre relatif dans le code source.

Suppression du critère 12.3 et des tests associés

Le critère 12.3 est redondant avec le critère 12.2. En effet, soit la notion de "présentation cohérente" correspond à une caractérisation spécifique au niveau de WCAG, ce qui n’est pas le cas; soit cette notion correspond au principe de barres et menus de navigation toujours à la même place, ce qui est déjà couvert par le critère 12.2.

Ancien critère 12.3

Critère 12.3 [AA] Dans chaque ensemble de pages, le menu et les barres de navigation ont-ils une présentation cohérente (hors cas particuliers)?

Renumérotation des critères 12.4, 12.5, 12.6 et des tests associés

Pour tenir compte de la suppression du critère 12.3 les critères 12.4, 12.5 et 12.6 sont renumérotés respectivement en critères 12.3, 12.4 et 12.5. Les tests associés sont renumérotés de la même façon.

Suppression du critère 12.7 et des tests associés

Le critère 12.7 repose sur la considération d’une entité spécifique "collection de pages" alors que WCAG emploie indifféremment les expressions "ensemble de pages" ou "collection de pages". Une collection de pages n’est rien d’autre qu’un ensemble de pages, sans conditions de vérification supplémentaires.

Ancien critère 12.7

Critère 12.7 [AA] Dans chaque page d'une collection de pages, des liens facilitant la navigation sont-ils présents?

Suppression des critères 12.8, 12.9 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 12.8

Critère 12.8 [AAA] Dans chaque page web, un fil d'Ariane est-il présent (hors cas particuliers)?

Ancien critère 12.9

Critère 12.9 [AAA] Dans chaque page web, le fil d'Ariane est-il pertinent?

Suppression des cas particuliers 12.8

Suppression du critère 12.8.

Anciens cas particuliers 12.8

Il existe une gestion de cas particulier lorsque la page est la page d'accueil ou lorsque le site web est constitué d'une seule page. Dans ce cas, le critère est non applicable.

Modification du critère 12.10

Prise en compte de l’ensemble des techniques WCAG liés au critère 2.4.1.

Renumérotation du test 12.10 en test 12.6.

Ancien critère 12.10

Critère 12.10 [A] Dans chaque page web, les groupes de liens importants (menu, barre de navigation…) et la zone de contenu sont-ils identifiés?

Nouveau critère 12.6

Critère 12.6 Les zones de regroupement de contenus présentes dans plusieurs pages web (zones d'en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche) peuvent-elles être atteintes ou évitées?

Suppression de la note technique critère 12.10

Mise à jour et reprise de son contenu dans la nouvelle entrée de glossaire "Landmarks".

Ancienne note technique

WAI-ARIA propose des rôles permettant d'indiquer les zones principales (régions) du document. Ces rôles sont très profitables aux utilisateurs de lecteurs d'écran notamment, mais également aux utilisateurs de la navigation au clavier qui peuvent ainsi bénéficier de fonctionnalités de navigation rapide dans la structure du document. Si la plupart des lecteurs d'écran mettent à disposition ces fonctionnalités, les navigateurs n'ont pas encore proposé de fonctionnalité de navigation dédiée pour les utilisateurs qui ne peuvent pas utiliser la souris. La mise en place des liens d'évitement reste donc une exigence.

Modification du test 12.10.1

Prise en compte de l’ensemble des techniques WCAG liés au critère 2.4.1.

Renumérotation du test 12.10.1 en test 12.6.1.

Ancien test 12.10.1

Test 12.10.1 : Dans chaque page web, la structure du document vérifie-t-elle ces conditions?

  • La zone d'en-tête de la page possède un rôle ARIA banner.
  • Le menu de navigation principal possède un rôle ARIA navigation.
  • La zone de contenu principal possède un rôle ARIA main.
  • La zone de pied de page possède un rôle ARIA contentinfo.
  • Le moteur de recherche sur le site possède un rôle ARIA search.
  • Les rôles ARIA banner, main, contentinfo et search sont uniques dans la page.
  • Le rôle ARIA navigation est réservé aux zones de navigations principales et secondaires.

Nouveau test 12.10.1

Test 12.6.1 : Dans chaque page web où elles sont présentes, la zone d'en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche respectent-elles au moins une de ces conditions :

  • la zone possède un rôle WAI-ARIA de type landmark</code> correspondant à sa nature.
  • la zone possède un titre de hiérarchie dont le contenu permet de comprendre la nature du contenu de la zone.
  • la zone peut être masquée par le biais d'un bouton précédant directement la zone dans l'ordre du code source.
  • la zone peut être évitée par le biais d'un lien d'évitement précédant directement la zone dans l'ordre du code source.
  • la zone peut être atteinte par le biais d'un lien d'accès rapide visible à la prise de focus lors d’une tabulation.

Modification du critère 12.11

Restriction du critère à la simple présence d’un lien d’accès rapide vers la zone de contenu principal, les techniques G1 et G123 étant considérées comme suffisantes pour satisfaire le critère 2.4.1.

Renumérotation du test 12.11 en test 12.7.

Ancien critère 12.11

Critère 12.11 [A] Dans chaque page web, des liens d'évitement ou d'accès rapide aux groupes de liens importants et à la zone de contenu sont-ils présents (hors cas particuliers)?

Nouveau critère 12.7

Critère 12.7 Dans chaque page web, un lien d'évitement ou d'accès rapide à la zone de contenu principal est-il présent (hors cas particuliers)?

Suppression du test 12.11.1

Suppression du test car la technique G1 est considérée comme suffisante pour satisfaire le critère 2.4.1 et ne porte que sur la possibilité d'accéder au contenu principal et non à l'ensemble des zones.

Ancien test 12.11.1

Test 12.11.1 : Dans chaque page web, un lien permet-il d'éviter chaque groupe de liens importants identifié ou d'y accéder (hors cas particuliers)?

Modification du test 12.11.2

Modification syntaxique liée à l’évolution du critère 12.11.

Renumérotation du test 12.11.2 en test 12.7.1.

Ancien test 12.11.2

Test 12.11.2 : Dans chaque page web, un lien permet-il d'éviter la zone de contenu identifiée ou d'y accéder (hors cas particuliers)?

Nouveau test 12.7.1

Test 12.7.1 : Dans chaque page web, un lien permet-il d'éviter la zone de contenu principal ou d'y accéder (hors cas particuliers)?

Suppression du test 12.11.3

Suppression suite à la mise à jour de l'entrée de glossaire de "Liens d'évitement ou d'accès rapide".

Ancien test 12.11.3

Test 12.11.3 : Dans chaque page web, chaque lien d'évitement ou d'accès rapide est-il fonctionnel (hors cas particuliers)?

Modification du test 12.11.4

Modification syntaxique liée à l’évolution du critère 12.11.

Renumérotation du test 12.11.4 en test 12.7.2.

Ancien test 12.11.4

Test 12.11.4 : Dans chaque ensemble de pages, les liens d'évitement ou d'accès rapide vérifient-ils ces conditions (hors cas particuliers)?

  • Chaque lien est situé à la même place dans la présentation.
  • Chaque lien se présente toujours dans le même ordre relatif dans le code source.
  • Chaque lien est visible à la prise de focus de tabulation au moins.

Nouveau test 12.7.2

Test 12.7.2 : Dans chaque ensemble de pages, le lien d'évitement ou d'accès rapide à la zone de contenu principal vérifient-il ces conditions (hors cas particuliers)?

  • Le lien est situé à la même place dans la présentation.
  • Le lien se présente toujours dans le même ordre relatif dans le code source.
  • Le lien est visible à la prise de focus lors d'une tabulation.

Suppression des critères 12.12 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 12.12

Critère 12.12 [AAA] Dans chaque page web, la page en cours de consultation est-elle indiquée dans le menu de navigation?

Renumérotation des critères 12.13, 12.14 et des tests associés

Pour tenir compte de la suppression des critères précédents, les critères 12.13 et 12.14 sont renumérotés respectivement en critères 12.8 et 12.9. Les tests associés sont renumérotés de la même façon.

Création du critère 12.10 et du test associé

Prise en compte du nouveau critère WCAG 2.1 : 2.1.4 Character Key Shortcuts (A).

Nouveau critère 12.10

Critère 12.10 Dans chaque page web, les raccourcis clavier n'utilisant qu'une seule touche (lettre minuscule ou majuscule, ponctuation, chiffre ou symbole) sont-ils contrôlables par l’utilisateur?

Nouveau test 12.10.1

Test 12.10.1 : Dans chaque page web, chaque raccourci clavier n'utilisant qu'une seule touche (lettres minuscule ou majuscule, ponctuation, chiffre ou symbole) vérifie-t-il l'une de ces conditions?

  • Un mécanisme est disponible pour désactiver le raccourci clavier.
  • Un mécanisme est disponible pour configurer la touche de raccourci clavier au moyen des touches de modification (Ctrl, Alt, Maj, etc).
  • Dans le cas d'un composant d'interface utilisateur, le raccourci clavier qui lui est associé ne peut être activé que si le focus clavier est sur ce composant.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.1.4 / 2.1.4 Character Key Shortcuts (A)

Création du critère 12.11 et du test associé

Prise en compte d'un cas d'usage non couvert : les contenus additionnels interactifs.

Nouveau critère 12.11

Critère 12.11 Dans chaque page web, les contenus additionnels apparaissant au survol, à la prise de focus ou à l'activation d'un composant d'interface sont-ils, si nécessaire, atteignables au clavier?

Nouveau test 12.11.1

Test 12.11.1 : Dans chaque page web, les contenus additionnels apparaissant au survol, à la prise de focus ou à l'activation d'un composant d'interface sont-ils, si nécessaire, atteignables au clavier?

Nouvelle note technique

Ce critère adresse les situations où un contenu additionnel contient des composants d'interface avec lesquels il doit être possible d'interagir au clavier. Par exemple, une infobulle personnalisée qui propose un lien dans son contenu.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.1.1 / 2.1.1 Keyboard (A)

Suppression du critère 13.2 et des tests associés

Les techniques référencées correspondent à un critère WCAG 3.2.5 triple A ou bien sont seulement considérées comme "advisory".

Ancien critère 13.2

Critère 13.2 [A] Dans chaque page web, pour chaque ouverture de nouvelle fenêtre, l'utilisateur est-il averti?

Renumérotation du critère 13.3 et des tests associés

Pour tenir compte de la suppression du critère 13.2, le critère 13.3 est renuméroté en critères 13.2. Les tests associés sont renumérotés de la même façon.

Suppression des critères 13.4, 13.5 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 13.4

Critère 13.4 [AAA] Dans chaque page web, une tâche ne doit pas requérir de limite de temps pour être réalisée, sauf si elle se déroule en temps réel ou si cette limite de temps est essentielle. Cette règle est-elle respectée?

Ancien critère 13.5

Critère 13.5 [AAA] Dans chaque page web, lors d'une interruption de session authentifiée, les données saisies par l'utilisateur sont-elles récupérées après ré-authentification?

Suppression du critère 13.6 et des tests associés

Absence d’élément dans les WCAG permettant de considérer que l’absence d’indication de format, poids ou langue des fichiers en téléchargement est un motif de non conformité.

Ancien critère 13.6

Critère 13.6 [A] Dans chaque page web, pour chaque fichier en téléchargement, des informations relatives à sa consultation sont-elles présentes (hors cas particuliers)?

Suppression des cas particuliers 13.6

Suppression du critère 13.6.

Anciens cas particuliers 13.6

Il existe une gestion de cas particulier lorsque le document est produit de manière dynamique (par exemple une facture). Dans cette situation, l'indication de poids est facultative, les autres indications (type de fichier et langue) restent exigibles.

Renumérotation des critères 13.7, 13.8 et des tests associés

Pour tenir compte de la suppression des critères précédents, les critères 13.7 et 13.8 sont renumérotés respectivement en critères 13.3 et 13.4. Les tests associés sont renumérotés de la même façon.

Création des cas particuliers 13.3

Ajout de deux précisions légales sur les médias concernés en fonction de leur date de publication et de leur propriétaire.

Nouveaux cas particuliers 13.3

Il existe une gestion de cas particuliers :

  • Pour les personnes de droit privé mentionnées aux 2° à 4° du I de l’article 47 de la loi du 11 février 2005 : si les fichiers bureautiques (ex : PDF, documents Microsoft ou libreOffice etc.) ont été publiés avant le 23 septembre 2018 (sauf si ce sont des documents nécessaires pour accomplir une démarche administrative relevant des tâches effectuées par l'organisme concerné), ils sont exemptés de l’obligation d’accessibilité;

Dans cette situation, le critère est non applicable.

Suppression des critères 13.9, 13.10 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 13.9

Critère 13.9 [AAA] Dans chaque page web, les expressions inhabituelles, les expressions idiomatiques ou le jargon sont-ils explicités?

Ancien critère 13.10

Critère 13.10 [AAA] Dans chaque page web, pour chaque expression inhabituelle ou limitée, idiomatique ou de jargon ayant une définition, cette définition est-elle pertinente?

Renumérotation des critères 13.11, 13.12 et des tests associés

Pour tenir compte de la suppression des critères précédents, les critères 13.11 et 13.12 sont renumérotés respectivement en critères 13.5 et 13.6. Les tests associés sont renumérotés de la même façon.

Suppression des critères 13.13, 13.14 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 13.13

Critère 13.13 [AAA] Dans chaque page web, pour chaque mot dont le sens ne peut être compris sans en connaître la prononciation, celle-ci est-elle indiquée?

Ancien critère 13.14

Critère 13.14 [AAA] Dans chaque page web, chaque texte qui nécessite un niveau de lecture plus avancé que le premier cycle de l'enseignement secondaire a-t-il une version alternative?

Renumérotation des critères 13.15 et des tests associés

Pour tenir compte de la suppression des critères précédents, le critère 13.15 est renuméroté en critères 13.7. Les tests associés sont renumérotés de la même façon.

Suppression des critères 13.16 et des tests associés

Suppression des critères triple A du RGAA 4.

Ancien critère 13.16

Critère 13.16 [AAA] Dans chaque page web, les changements brusques de luminosité ou les effets de flash ont-ils une fréquence inférieure ou égale à 3 par seconde?

Renumérotation des critères 13.17 et des tests associés

Pour tenir compte de la suppression des critères précédents, le critère 13.17 est renuméroté en critères 13.8. Les tests associés sont renumérotés de la même façon.

Création du critère 13.9 et du test associé

Prise en compte du nouveau critère WCAG 2.1 : 1.3.4 Orientation (AA).

Nouveau critère 13.9

Critère 13.9 Dans chaque page web, le contenu proposé est-il consultable quelle que soit l'orientation de l'écran (portait ou paysage) (hors cas particuliers)?

Nouveau test 13.9.1

Test 13.9.1 : Dans chaque page web, chaque contenu vérifie-t-il ces conditions (hors cas particuliers)?

  • La consultation est possible quel que soit le mode d'orientation de l'écran.
  • Le contenu proposé reste le même quel que soit le mode d'orientation de l'écran utilisé même si sa présentation et le moyen d'y accéder peut différer.

Nouveaux cas particuliers

Il existe des interfaces pour lesquelles l'orientation du périphérique est essentielle à leur utilisation.

Dans ces situations, le critère est non applicable. Il peut s'agir d'interfaces de jeu, de piano, de dépôt de chèques bancaires, etc.

Si l'interface est le seul moyen d'accéder au service proposé, une alternative devrait être mise en place pour pallier cette carence.

Références documentaires :

  • API JS : https://www.w3.org/TR/screen-orientation/
  • API Viewport : https://www.w3.org/TR/css-device-adapt-1/#orientation-desc

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.1.3.4 / 1.3.4 Orientation (AA)

Création du critère 13.10 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 2.5.1 Pointer Gestures (A).

Nouveau critère 13.10

Critère 13.10 Dans chaque page web, les fonctionnalités utilisables ou disponibles au moyen d'un geste complexe peuvent-elles être également disponibles au moyen d'un geste simple (hors cas particuliers)?

Nouveau test 13.10.1

Test 13.10.1 : Dans chaque page web, chaque fonctionnalité utilisable ou disponible suite à un contact multipoint est-elle également utilisable ou disponible suite à un contact en un point unique de l'écran (hors cas particuliers).

Nouveau test 13.10.2

Test 13.10.2 : Dans chaque page web, chaque fonctionnalité utilisable ou disponible suite à un geste basé sur le suivi d'une trajectoire sur l'écran est-elle également utilisable ou disponible suite à un contact en un point unique de l'écran (hors cas particuliers).

Nouveaux cas particuliers

Il existe une gestion de cas particuliers dans deux types de situation :

  • Le critère ne s'applique qu'à des fonctionnalités mises en place par l'auteur du site. Il ne concerne donc pas les gestes requis par l'agent utilisateur ou le système d'exploitation.
  • Le critère ne s'applique pas aux fonctionnalités dont la réalisation d'un geste complexe est essentielle (exécuter le tracé d'une signature, par exemple).

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.5.1 / 2.5.1 Pointer Gestures (A)

Création du critère 13.11 et du test associé

Prise en compte du nouveau critère WCAG 2.1 : 2.5.2 Pointer Cancellation (A).

Nouveau critère 13.11

Critère 13.11 Dans chaque page web, les actions déclenchées au moyen d'un dispositif de pointage sur un point unique de l'écran peuvent-elles faire l'objet d'une annulation (hors cas particuliers)?

Nouveau test 13.11.1

Test 13.11.1 : Dans chaque page web, les actions déclenchées au moyen d'un dispositif de pointage sur un point unique de l'écran vérifient-elles l'une de ces conditions (hors cas particuliers)?

  • L'action est déclenchée au moment où le dispositif de pointage est relâché ou relevé;
  • L'action est déclenchée au moment où le dispositif de pointage est pressé ou posé puis annulée lorsque le dispositif de pointage est relâché ou relevé;
  • Un mécanisme est disponible pour abandonner (avant achèvement de l'action) ou annuler (après achèvement) l'exécution de l'action;

Nouveaux cas particuliers

Il existe une gestion de cas particulier lorsque la fonctionnalité nécessite que le comportement attendu soit réalisé lors d'un événement descendant, par exemple, un émulateur de clavier dont les touches doivent s'activer à la pression comme sur un clavier physique. Dans ces situations, le critère est non applicable.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.5.2 / 2.5.2 Pointer Cancellation (A)

Création du critère 13.12 et des tests associés

Prise en compte du nouveau critère WCAG 2.1 : 2.5.4 Motion Actuation (A).

Nouveau critère 13.12

Critère 13.10 Dans chaque page web, les fonctionnalités utilisables ou disponibles au moyen d'un geste complexe peuvent-elles être également disponibles au moyen d'un geste simple (hors cas particuliers)?

Nouveau test 13.12.1

Test 13.12.1 : Dans chaque page web, les fonctionnalités disponibles en bougeant l'appareil peuvent-elles être accomplies avec des composants d'interface utilisateur (hors cas particuliers)?

Nouveau test 13.12.2

Test 13.12.2 : Dans chaque page web, les fonctionnalités disponibles en faisant un geste en direction de l'appareil peuvent-elles être accomplies avec des composants d'interface utilisateur (hors cas particuliers)?

Nouveau test 13.12.3

Test 13.12.3 : L'utilisateur a-t-il la possibilité de désactiver la détection du mouvement pour éviter un déclenchement accidentel de la fonctionnalité (hors cas particuliers)?

Nouveaux cas particuliers

Il existe une gestion de cas particulier lorsque :

  • Le mouvement est essentiel à l'accomplissement de la fonctionnalité (ex. podomètre).
  • La détection du mouvement est utilisée pour contrôler une fonctionnalité au travers d'une interface compatible avec l'accessibilité.

Références

EN 301 549 V2.1.2 / WCAG 2.1

  • 9.2.5.4 / 2.5.4 Motion Actuation (A)

Glossaire

Modification “Accessible et activable par le clavier et la souris”

Prise en compte de l’ensemble des dispositifs de pointage, prise en compte du nouveau critère 12.15, référence aux motifs de conception

Ancienne entrée

Accessible et activable par le clavier et la souris

  • Un composant d’interface (lien, bouton, élément cliquable dans Flash…) est accessible au clavier et à la souris lorsque l’utilisateur peut prendre, indifféremment, le focus par le pointeur de la souris ou la touche tabulation.
  • Un composant d’interface (lien, bouton, élément cliquable dans Flash…) est activable au clavier et à la souris lorsque l’utilisateur peut enclencher, indifféremment, l’action prévue par le composant d’interface par le clic de la souris ou la touche entrée du clavier.
  • Attention : pour certains composants d’interface comme les sliders (bouton coulissant ou rotatif…), il n’est pas possible de contrôler le composant par la seule touche d’entrée. Dans cette situation, d’autres touches (comme les touches de direction) peuvent être utilisées.

Dans le référentiel, l’expression « contrôlable par le clavier et la souris » se rapporte également à la présente définition.

Note importante : le recours à certaines technologies peut rendre la gestion du focus trop complexe ou trop instable pour ne reposer que sur la tabulation, les touches de direction et la touche entrée.

Dans ce cas, la mise à disposition de raccourcis clavier peut être la seule solution pour rendre le composant utilisable.

Le critère peut être considéré comme conforme à la condition que les raccourcis clavier utilisés soient correctement documentés et qu’ils soient fonctionnels quelle que soit la position du focus dans l’interface.

Vous pouvez consulter, à ce sujet, la technique SL15: Providing Keyboard Shortcuts that Work Across the Entire Silverlight Application pour l’environnement Silverlight par exemple.

Nouvelle entrée

Accessible et activable par le clavier et tout dispositif de pointage

  • Un composant d’interface (lien, bouton, …) est accessible au clavier et par tout dispositif de pointage lorsque l’utilisateur peut prendre, indifféremment, le focus par un pointeur ou la touche tabulation.

  • Un composant d’interface (lien, bouton, …) est activable au clavier et par tout dispositif de pointage lorsque l’utilisateur peut enclencher, indifféremment, l’action prévue par le composant d’interface par une pression du pointeur ou la touche entrée du clavier.

  • Attention : pour certains composants d’interface comme les sliders (bouton coulissant ou rotatif…), il n’est pas possible de contrôler le composant par la seule touche d’entrée. Dans ces situations, d’autres touches (comme les touches de direction) peuvent être utilisées. En particulier pour les éléments ayant un rôle WAI-ARIA correspondant à un motif de conception il est recommandé de considérer le document WAI-ARIA 1.1 Authoring Practices lors de leur implémentation.

Dans le référentiel, l’expression « contrôlable par le clavier et tout dispositif de pointage » se rapporte également à la présente définition.

Note importante : le recours à certaines technologies peut rendre la gestion du focus trop complexe ou trop instable pour ne reposer que sur la tabulation, les touches de direction et la touche entrée. Dans ce cas, la mise à disposition de raccourcis clavier peut être la seule solution pour rendre le composant utilisable.

Le critère ne peut être considéré comme conforme qu’à la condition que les raccourcis clavier utilisés soient correctement documentés, qu’ils soient fonctionnels et qu’ils respectent le critère 12.10.

Modification Accolés (étiquette et champ accolés)

Raison de la suppression

Prise en compte des contraintes de positionnnement de la technique G162 dans la critère 11.4

Ancienne entrée

Il faut que l’étiquette et son champ soient visuellement proches de manière à ce que la relation entre les deux ne puisse pas prêter à confusion.

Note : WCAG préconise que les étiquettes des champs de saisie de texte ou de valeurs prédéterminées, comme les listes par exemple, soient placées avant le champ, donc à gauche ou en haut des champs concernés. À l’inverse, les étiquettes des champs de type radio ou case à cocher devraient être placées après le champ, donc à droite ou en bas. Cette recommandation n’a pas été jugée raisonnable et n’est donc pas reprise dans le RGAA 3. Un positionnement différent, mais respectant une liaison visuelle sans confusion ne peut pas constituer une non-conformité au sens du RGAA 3.

Nouvelle entrée

Il faut que l’étiquette et son champ soient visuellement proches de manière à ce que la relation entre les deux ne puisse pas prêter à confusion.

Modification “Alternative textuelle”

Prise en compte de l’ensemble des techniques permettant d’associer une alternative textuelle aux différentes formes d’images

Ancienne entrée

Texte associé à une image via une technique appropriée et décrivant l’information véhiculée par l’image (par rapport au contexte du contenu web dans lequel elle se trouve). RGAA considère quatre types d’alternatives liées à la nature de l’image :

  • pour une image porteuse d’information, l’alternative apporte l’information nécessaire à la compréhension du contenu auquel l’image est associée;
  • pour une image de décoration, l’alternative doit être vide (alt=“”);
  • pour une image-lien, l’alternative doit permettre de comprendre la fonction et la destination du lien;
  • pour une image CAPTCHA ou une image-test, l’alternative ne peut pas apporter l’information véhiculée par l’image sans rendre la fonction associée inopérante. Dans ce cas de figure, l’alternative doit se contenter de permettre d’identifier la nature et la fonction de l’image.

Note 1 : pour une image CAPTCHA l’alternative peut être, par exemple : « Code de sécurité anti-spam » ou « code pour vérifier que vous êtes un humain » ou toute autre alternative permettant à l’utilisateur de comprendre la nature et la fonction de l’image.

Note 2 : pour un groupe d’images, par exemple un système de vote constitué de plusieurs images d’étoiles, il est fortement conseillé d’utiliser la première image du groupe pour donner une alternative plus cohérente au groupe d’image. Dans ce cas, les autres images du groupe sont considérées comme des images de décoration. Vous pouvez consulter, à ce sujet, la note suivante : A group of images that form a single larger picture with no links.

Nouvelle entrée

Alternative textuelle (image)

« Nom accessible » restitué par les technologies d’assistance pour les éléments graphiques de type :

  • Image (balise <img> ou balise possédant un attribut WAI-ARIA role=“img”);
  • Zone d’image réactive (balise <area>);
  • Bouton de type image (balise <input> avec l’attribut type=“image”);
  • Image objet (balise <object type="image/…">);
  • Image vectorielle (balise <svg>);
  • Image bitmap (balise <canvas>);
  • Image embarquée (balise <embed>).

Dans le cas d’un élément graphique, le « nom accessible » est obtenu selon l’ordre suivant :

Passage de texte associé via l’attribut WAI-ARIA aria-labelledby pour les balises :

  • <img>;
  • <input type="image">;
  • <svg>;
  • <object type="image/…">;
  • <embed type="image/…">;
  • <canvas>;

balises possédant un attribut WAI-ARIA role=“img”.

Sinon, contenu de l’attribut WAI-ARIA aria-label pour les balises :

  • <img>;
  • <area>;
  • <input type="image">;
  • <svg>;
  • <object type="image/…">;
  • <embed type="image/…">;
  • <canvas>;

balises possédant un attribut WAI-ARIA role=“img”.

Sinon, contenu de l’attribut alt pour les balises :

  • <img>;
  • <area>;
  • <input type="image">.

Sinon, contenu de l’attribut title pour les balises :

  • <img>;
  • <input type="image">;
  • <object type="image/…">;
  • <embed type="image/…">.

Cet ordre doit être utilisé pour déterminer ce qui constitue l’alternative textuelle.

Néanmoins, en cas de support partiel de l’algorithme de calcul du « nom accessible », c’est la valeur réellement restituée par les technologies d’assistance utilisées dans l’environnement de test (ou « base de référence ») qu’il faudra considérer comme alternative textuelle.

Par exemple :

  • En cas de présence conjointe d’un attribut WAI-ARIA aria-label et d’un attribut WAI-ARIA aria-labelledby sur une balise <img>, c’est le passage de texte référencé par l’attribut WAI-ARIA aria-labelledby qui doit être considérée comme alternative textuelle si le contenu du passage de texte est réellement restitué par les technologies d’assistance utilisées dans l’environnement de test.

  • En cas de présence conjointe d’un attribut WAI-ARIA aria-label et d’un attribut alt sur une balise <img>, c’est le contenu de l’attribut WAI-ARIA aria-label qui doit être considéré comme alternative textuelle si le contenu de l’attribut WAI-ARIA aria-label est réellement restitué par les technologies d’assistance utilisées dans l’environnement de test.

Référence : Accessible name and description calculation.

RGAA considère trois types d’alternatives textuelles liées à la nature de l’image :

  • Pour une image porteuse d’information, l’alternative textuelle apporte l’information nécessaire à la compréhension du contenu qu’elle véhicule;

  • Pour une image de décoration, aucune alternative textuelle ne doit être restituée ;

  • Pour une image CAPTCHA ou une image-test, l’alternative textuelle décrit seulement la nature et la fonction de l’image. En effet, l’alternative textuelle ne peut apporter l’information véhiculée par l’image sans rendre la fonction associée inopérante.

Note 1 : pour une image CAPTCHA l’alternative peut être, par exemple : « Code de sécurité anti-spam » ou « code pour vérifier que vous êtes un humain » ou toute autre alternative permettant à l’utilisateur de comprendre la nature et la fonction de l’image.

Note 2 : pour un groupe d’images, par exemple un système de vote constitué de plusieurs images d’étoile, il est fortement conseillé d’utiliser soit la première image du groupe pour donner une alternative cohérente au groupe d’image (voir la technique WCAG2.1 G196), soit une balise conteneur pourvue d’un rôle WAI-ARIA img et d’une alternative textuelle. Dans le premier cas, les autres images du groupe sont considérées comme des images de décoration. Dans le second cas, toutes les images du groupe sont considérées comme des images de décoration.

Note 3 : pour les image-lien, l’alternative doit permettre de comprendre la fonction et la destination du lien ; ce cas est traité dans la thématique liens.

Note 4 : pour les images vectorielles (balise <svg>) l’alternative textuelle pourrait se trouver aussi présente dans une balise <text> que cette balise soit ou non visible, même si ce n’est pas le rôle dévolu à cet élément en SVG.

Note 5 : l’utilisation de l’attribut alt étant la seule technique totalement supportée par les aides techniques il est recommandé de privilégier cette solution lors de la mise en œuvre d’une alternative à une balise <img>, <area> et <input type="image">.

Suppression « Arborescence du document »

Raison de la suppression

Suppression du test 9.2.2.

Ancienne entrée

Arborescence du document

Le test 9.2.2 demande de vérifier que la structure des éléments sectionnant (nav, section, article par exemple) est cohérente, c’est-à-dire représentative de l’architecture du document. Cette structure est complémentaire à la structure des titres h(x) qui en sont un élément.

L’utilisation inapropriée de ces éléments sectionnants peut générer une arborescence de document incohérente, par exemple par l’utilisation abusive d’éléments section ou article.

Note 1 : Pour accompagner la prise en charge progressive de l’arborescence du document et compte tenu du fait que le référentiel exige de disposer, en tout état de cause, d’une structure de contenu (balises h(x)) robuste et cohérente, il est acceptable de considérer le test 9.2.2 comme non applicable lorsqu’il n’est pas possible de s’assurer que l’arborescence du document est parfaitement cohérente. Vous pouvez consulter, à ce sujet la note technique : Note technique au sujet de l’arborescence du document.

Note 2 : vous pouvez consulter, à ce sujet, l’exemple donné par la spécification HTML5 : 4.3.10.2 Sample outlines.

Suppression « Attribut target »

Raison de la suppression

Suppression du critère 13.6 et des tests associés.

Ancienne entrée

Attribut target

L’attribut target ouvre une nouvelle fenêtre ou un nouvel onglet du navigateur selon sa valeur. Les valeurs suivantes de target n’ouvrent pas de nouvelles fenêtres :

  • _self;
  • _top;
  • _parent.

Pour toutes les autres valeurs de target, l’élément sur lequel il est positionné ouvrira une nouvelle fenêtre ou un nouvel onglet. C’est le cas de la valeur _blank par exemple, mais également de toute autre valeur (numérique ou alphabétique) non définie par la spécification. Il est à noter d’ailleurs que ces valeurs ne provoquent pas d’erreur lors de la validation du code source en HTML5.

Modification « Barre de navigation »

Raison de la modification de l’entrée

Fusion des deux entrées de glossaire « Barre de navigation » et « Menu de navigation » dont les contenus se recoupent en partie, la notion de menu de navigation étant englobée dans la notion plus générique de barre de navigation. Cette mise en cohérence permet d’éviter les tests redondants des critères 12.2 et 12.3.

Ancienne entrée

Barre de navigation

Liste de liens permettant une navigation spécifique dans le site, dans une rubrique ou dans une collection de pages. Les principales barres de navigation sont :

  • Le menu de navigation principal;
  • Un fil d’Ariane;
  • Une liste de navigation d’une liste de résultats;
  • Un menu de sous-rubrique.

Nouvelle entrée

Menu et barre de navigation

Liste de liens permettant une navigation spécifique dans le site, dans une rubrique ou dans une collection de pages.

Les principales barres de navigation (critère 12.2) sont :

  • Un menu de navigation;
  • Un fil d’Ariane;
  • Une liste de navigation d’une liste de résultats;
  • Des liens d’évitement.

Il existe différents types de menu de navigation (critère 12.1 et critère 12.2) :

  • Menu de navigation principal;
  • Menu de sous-rubrique;
  • Menu contextuel;
  • Table des matières concernant un ensemble de pages.

Note : Les liens de pied de page renvoyant vers les mentions légales, plan du site et autres informations concernant le site ne sont pas considérés comme un menu de navigation principal.

Suppression « Bloc d’informations de même nature »

Raison de la suppression

L’entrée de glossaire bloc d’information de même nature est divisée en deux entrées distinctes.

Ancienne entrée

Dans un formulaire, ensemble des champs pouvant être regroupés par la nature des informations attendues. Le regroupement vise à identifier les champs devant être traités comme un ensemble.

Quelques exemples :

  • Trois champs successifs pour saisir une date (jour/mois/année).
  • Champs successifs pour un numéro de téléphone.
  • Un bloc destiné à saisir l’identité et l’adresse de l’utilisateur, lorsque le formulaire contient plusieurs blocs de contact.
  • Un ensemble de boutons radio ou de cases à cocher qui se rapportent à une question.

Ces champs doivent être regroupés lorsque les intitulés de label ne sont pas suffisants pour informer l’utilisateur que les champs font partie d’un regroupement. HTML propose un dispositif natif par l’intermédiaire des éléments fieldset et legend.

Il est également possible de créer des regroupements avec le rôle ARIA group et un passage de texte, faisant office de légende, liée par la propriété aria-labelledby ou implémentée par l’intermédiaire d’une propriété aria-label.

Note 1 : Les regroupements de champs peuvent utiliser d’autres méthodes qui associent l’information du regroupement directement dans l’étiquette du champ. Par exemple, par l’intermédiaire d’un attribut title, d’une propriété aria-label ou d’une liaison aria-labelledby faisant office d’étiquette ou encore par la propriété aria-describedby associant un texte complémentaire. Dans ce cas, le regroupement de champs devient inutile puisque les labels sont suffisamment pertinents.

Note 2 : Lorsque le formulaire est constitué d’un seul bloc d’informations de même nature (l’identité et l’adresse de l’utilisateur, par exemple) ou d’un champ unique (un moteur de recherche, par exemple), le regroupement des champs n’est pas obligatoire.

Modification « bouton (formulaire) »

Prise en compte du role WAI-ARIA button, modification pour introduire l’utilisation des attributs aria-labelledby et aria-label comme solution de nommage d’un bouton et ajout d’un note pour couvrir le critère 2.5.3 WCAG 2.1 label in name

Ancienne entrée

Élément d’un formulaire qui permet d’effectuer une action prédéfinie. Par exemple, le bouton de soumission d’un formulaire permet l’envoi au serveur des informations collectées pour leur traitement. L’intitulé d’un bouton doit décrire l’action qui résulte de son activation (par exemple : « Lancer votre recherche », « Envoyer votre message »).

En HTML, il y a trois types de boutons de formulaire :

  • Balise input de type submit, reset ou button;
  • Balise input de type image;
  • Balise button.

L’intitulé du bouton peut être de quatre types :

  • Le contenu de l’attribut value des boutons de type submit, reset ou button;
  • Le contenu de l’attribut alt d’un bouton de type image;
  • Le contenu de l’attribut title lorsqu’il est présent;
  • Le contenu de la balise <button>.

Nouvelle entrée

Bouton (formulaire)

Élément d’un formulaire qui permet d’effectuer une action prédéfinie. Par exemple, le bouton de soumission d’un formulaire permet l’envoi au serveur des informations collectées pour leur traitement. L’intitulé d’un bouton doit décrire l’action qui résulte de son activation (par exemple : « Lancer votre recherche », « Envoyer votre message »).

En HTML, il y a trois types de boutons de formulaire :

  • Balise <input> de type submit, reset ou button;
  • Balise <input> de type image;
  • Balise <button>.

Il est également possible de restituer un bouton à l’aide du rôle WAI-ARIA button.

L’intitulé du bouton peut être de six types :

  • Le contenu du passage de texte associé au bouton via l’attribut WAI-ARIA aria-labelledby lorsqu’il est présent;
  • Le contenu de l’attribut aria-label lorsqu’il est présent;
  • Le contenu de l’attribut alt d’un bouton de type image;
  • Le contenu de l’attribut value des boutons de type submit, reset ou button;
  • Le contenu de la balise <button>;
  • Le contenu de l’attribut title lorsqu’il est présent.

Note importante : lorsque plusieurs de ces techniques sont présentes sur un même bouton, le calcul du « nom accessible », c’est-à-dire ce qui sera restitué, obéit à un ordre strict :

  • aria-labelledby;
  • Sinon aria-label;
  • Sinon alt pour le cas des input image;
  • Sinon value pour le cas des input submit, reset ou button;
  • Sinon contenu de la balise <button>;
  • Sinon title.

Cet ordre doit être utilisé pour l’évaluation de la pertinence du « nom accessible » du bouton. Par exemple, même dans le cas de la présence d’un title et d’un passage de texte référencé par aria-labelledby sur le même bouton, c’est le passage de texte référencé par aria-labelledby qui doit être évalué.

Référence : Accessible name and description calculation.

Par ailleurs, un « nom accessible » sera considéré comme non-pertinent s’il ne reprend pas le texte visible du bouton. Par exemple : <button aria-label="confirmer la saisie">valider la saisie</button> sera considéré comme non conforme au critère 11.2.

Modification « cadre en ligne »

Devient « cadre et cadre en ligne »

Bien que html5 qui ne contienne plus la balise <frame> les concepteurs peuvent encore utiliser une version de HTML supportant cette balise (qui par ailleurs continue de fonctionner meme en html5). Il existe également d’anciennes applications utilisant cette balise pour laquelle l’absence de prise en compte de cette balise dans le RGAA signifierait qu’ils n’ont rien à faire pour les rendre conforme.

Ancienne entrée

Élément HTML (balise iframe) permettant d’afficher un contenu dans la page web dans laquelle il est implémenté.

Nouvelle entrée

Cadre : élément HTML (balise <frame>) permettant d’afficher un contenu dans la page web dans laquelle il est implémenté.

Cadre en ligne : élément HTML (balise <iframe>) permettant d’afficher un contenu dans la page web dans laquelle il est implémenté.

Création « Champs de même nature »

Raison de la création

L’entrée de glossaire bloc d’information de même nature est divisée en deux entrées distinctes dont « champs de même nature »

Nouvelle entrée

Champs de même nature

Dans un formulaire, ensemble des champs pouvant être regroupés par la nature des informations attendues. Le regroupement vise à identifier les champs devant être traités comme un ensemble.

Quelques exemples :

  • Trois champs successifs pour saisir une date (jour/mois/année);
  • Champs successifs pour un numéro de téléphone.
  • Un bloc destiné à saisir l’identité et l’adresse de l’utilisateur, lorsque le formulaire contient plusieurs blocs de contact;
  • Un ensemble de boutons radio ou de cases à cocher qui se rapportent à une question.

Ces champs doivent être regroupés lorsque les intitulés de label ne sont pas suffisants pour informer l’utilisateur que les champs font partie d’un regroupement.

Modification « Champ de saisie de formulaire »

Mise à jour suite à l’évolution de la spécification HTML, prise en compte de champs de formulaires simulés via les rôles WAI-ARIA et renommage pour couvrir les champs d’affichage html5 qui ne sont pas des champs “de saisie”

Ancienne entrée

Objet d’un formulaire permettant à l’utilisateur :

De saisir des données textuelles ou préformatées :

  • input type=“text”;
  • input type=“password”;
  • input type=“search”;
  • input type=“tel”;
  • input type=“email”;
  • input type=“number”;
  • input type=“tel”
  • input type=“url”;
  • textarea;

De sélectionner des valeurs prédéfinies :

  • input type=“checkbox”;
  • input type=“radio”;
  • input type=“date”;
  • input type=“range”;
  • input type=“color”;
  • input type=“time”;
  • select;
  • datalist;
  • optgroup;
  • option;
  • keygen;

De télécharger des fichiers :

  • input type=“file”;

Ou d’afficher des résultats :

  • output;
  • progress;
  • meter.

Les objets de formulaires suivants ne sont pas considérés comme des champs de formulaires :

  • input type=“submit”;
  • input type=“reset”;
  • input type=“hidden”;
  • input type=“image”;
  • input type=“button”;
  • button.

Nouvelle entrée

Champ de saisie de formulaire

Objet d’un formulaire permettant à l’utilisateur :

De saisir des données textuelles ou préformatées :

  • input type=“text”;
  • input type=“password”;
  • input type=“search”;
  • input type=“email”;
  • input type=“number”;
  • input type=“tel”;
  • input type=“url”;
  • textarea.

De sélectionner des valeurs prédéfinies :

  • input type=“checkbox”;
  • input type=“radio”;
  • input type=“date”;
  • input type=“range”;
  • input type=“color”;
  • input type=“time”;
  • input type=“month”;
  • input type=“week”;
  • input type=“datetime-local”;
  • select;
  • datalist;
  • optgroup;
  • option.

De télécharger des fichiers :

  • input type=“file”.

Ou d’afficher des résultats :

  • output;
  • progress;
  • meter.

Les balises possédant un rôle WAI-ARIA permettant de restituer un champ de formulaire sont également couvertes par cette définition :

  • progressbar;
  • slider;
  • spinbutton;
  • textbox;
  • listbox;
  • searchbox;
  • combobox;
  • option;
  • checkbox;
  • radio;
  • switch.

Les objets de formulaires et rôle WAI-ARIA suivants ne sont pas considérés comme des champs de formulaires :

  • input type=“submit”;
  • input type=“reset”;
  • input type=“hidden”;
  • input type=“image”;
  • input type=“button”;
  • button;
  • attribut WAI-ARIA role=“button”.

Suppression « Collection de pages »

Raison de la suppression

Suppression de l’entrée de glossaire suite à la suppression du critère 12.7 qui lui est exclusivement associé.

Ancienne entrée

Collection de pages

Pages reliées les unes aux autres par des liens et ayant un thème ou une nature commune. Par exemple, les pages de résultats d’un moteur de recherche ou les pages d’un catalogue (pour une même recherche) sont des collections de pages.

Modification « Composant d’interface »

Ajout de la référence au document “WAI-ARIA 1.1 Authoring Practices”.

Ancienne entrée

Un composant d’interface est un élément avec lequel l’utilisateur peut interagir, par exemple un bouton, un lien, une zone de saisie. Certains composants peuvent être plus complexes comme un menu, une fenêtre de dialogue, un système d’onglets. Enfin un composant d’interface peut être basé sur des éléments natifs de HTML ou développés de toutes pièces avec JavaScript et l’API ARIA.

Nouvelle entrée

Un composant d’interface est un élément avec lequel l’utilisateur peut interagir, par exemple un bouton, un lien, une zone de saisie. Certains composants peuvent être plus complexes comme un menu, une fenêtre de dialogue, un système d’onglets. Enfin un composant d’interface peut être basé sur des éléments natifs de HTML ou développés de toutes pièces en JavaScript et des attributs WAI-ARIA. En particulier pour les éléments ayant des attributs WAI-ARIA correspondant à un motif de conception il est recommandé de considérer le document WAI-ARIA 1.1 Authoring Practices lors de leur implémentation.

Modification « Contexte du lien »

Reformulation de la note 1.

Ancienne entrée

Le contexte du lien représente les informations supplémentaires (on parle d’informations de contexte) qui peuvent être mises en relation par un programme informatique avec l’intitulé du lien. Les informations de contexte qui permettent de rendre un lien explicite sont les suivantes :

  • Le contenu de la phrase dans laquelle le lien texte est présent;
  • Le contenu du paragraphe (balise p) dans lequel le lien texte est présent;
  • Le contenu de l’item de liste (balise li) ou le contenu d’un item de liste parent (balise li) dans lequel le lien texte est présent;
  • Le contenu du titre (balise h) précédent le lien texte;
  • Le contenu de la ou les cellule(s) d’en-tête de tableau (balise(s) th) associée(s) à la cellule de donnée (balise td) dans laquelle le lien texte est présent;
  • Le contenu de la cellule de donnée (balise td) dans laquelle le lien texte est présent;
  • Le contenu du titre de lien (attribut title);
  • Le contenu de la propriété aria-label;
  • Le contenu du passage de texte lié par la propriété aria-labelledby;

Note 1 : l’un des 9 contextes de lien doit permettre à lui seul d’expliciter le lien.

Note 2 : RGAA 3 considère que des liens particuliers comme des liens de type mailto (qui génère un lien sous la forme d’une adresse email cliquable) sont suffisamment explicites et ne requièrent pas de signaler, via un title, que l’action consiste à envoyer un email. L’attention des auteurs est appelée sur le fait que cette règle générale peut être adaptée au contexte, par exemple si la page contient plusieurs adresses email cliquables affectées de comportements différents (envoyer un email via le client de messagerie pour l’une, accéder à un formulaire pour l’autre) il peut être nécessaire de donner des informations complémentaires sur l’action du lien afin de différencier leurs comportements.

Nouvelle entrée

Le contexte du lien représente les informations supplémentaires (on parle d’informations de contexte) qui peuvent être mises en relation par un programme informatique avec l’intitulé du lien. Les informations de contexte qui permettent de compléter l’intitulé du lien sont les suivantes :

  • Le contenu de la phrase dans laquelle le lien texte est présent;
  • Le contenu du paragraphe (balise <p>) dans lequel le lien texte est présent;
  • Le contenu de l’item de liste (balise <li>) ou le contenu d’un item de liste parent (balise <li>) dans lequel le lien texte est présent;
  • Le contenu du titre (balise <hx>) précédent le lien texte;
  • Le contenu de la ou les cellule(s) d’en-tête de tableau (balise(s) <th>) associée(s) à la cellule de donnée (balise <td>) dans laquelle le lien texte est présent;
  • Le contenu de la cellule de donnée (balise <td>) dans laquelle le lien texte est présent;

Note 1 : l’un des 6 contextes de lien combiné à l’intitulé du lien doit permettre de comprendre la fonction et la destination du lien.

Note 2 : RGAA considère que des liens particuliers comme des liens de type mailto (qui génère un lien sous la forme d’une adresse email cliquable) sont suffisamment explicites et ne requièrent pas de signaler que l’action consiste à envoyer un email. L’attention des auteurs est appelée sur le fait que cette règle générale peut être adaptée au contexte, par exemple si la page contient plusieurs adresses email cliquables affectées de comportements différents (envoyer un email via le client de messagerie pour l’une, accéder à un formulaire pour l’autre) il peut être nécessaire de donner des informations complémentaires sur l’action du lien afin de différencier leurs comportements.

Modification « Contrôle de saisie (formulaire) »

En l’absence de technique WCAG correspondante suppression de la note rendant obligatoire la modification du titre d’une page en cas d’erreur de formulaire.

Ancienne entrée

Contrôle de saisie

Note importante : lorsqu’une page est renvoyée avec des erreurs de saisie le titre de la page doit comporter la mention « erreur sur le formulaire ».

Nouvelle entrée

Contrôle de saisie (formulaire)

Ensemble des processus qui permettent de prévenir l’utilisateur des champs obligatoires, des indications de type ou de format attendus et des erreurs de saisie dans un formulaire. Ces contrôles de saisie peuvent être implémentés par l’auteur des contenus ou s’appuyer sur des attributs (comme required ou pattern), des attributs WAI-ARIA (comme aria-required) ou des types de champ qui produisent de manière automatique des indications de saisie ou d’erreurs (comme les types url, email, date, time par exemple).

Création « couleur d’arrière-plan contiguë et couleur contiguë »

Raison de la création

Précisions visant à faciliter la compréhension du critère.

Nouvelle entrée

Couleur d’arrière-plan contiguë et couleur contiguë

Couleur d’arrière-plan contiguë : couleur d’arrière-plan directement en contact avec le bord extérieur du composant d’interface ou de l’élément graphique.

Exemples :

  • Pour un bouton blanc avec une bordure bleue sur un fond blanc, le fond blanc à l’extérieur de la bordure bleu correspond à la couleur d’arrière-plan contiguë;
  • Pour un bouton rouge sur fond blanc, le fond blanc à l’extérieur du rouge correspond à la couleur d’arrière-plan contiguë;
  • Pour un bouton blanc avec une bordure verte qui devient noire à la prise de focus et au survol, le fond blanc à l’extérieur de la bordure verte de l’état par défaut et de la bordure noire de l’état au survol et au focus correspond à la couleur d’arrière-plan contiguë.

Couleur contiguë : couleur directement en contact avec une autre couleur. Exemple dans un panneau de « sens interdit » le rouge du panneau est la couleur contiguë au trait blanc au centre du panneau.

Note 1: dans le cas de la présence d’un dégradé, c’est la couleur contiguë la moins contrastée du dégradé qui sera à considérer comme la couleur contiguë ou couleur d’arrière-plan contiguë.

Note 2 : dans le cas de la présence de plusieurs couleurs, c’est l’ensemble des couleurs qui seront à considérer comme couleur contiguë ou couleur d’arrière-plan contiguë.

Modification « Description détaillée (image) »

Raison de la modification de l’entrée de glossaire Prise en compte de la définition de glossaire alternative textuelle et lien ou bouton adjacente ainsi que de la possibilité d’avoir recours à l’attribut WAI-ARIA aria-labelledby en cas de nos support de l’attribut WAI-ARIA aria-describedby

Ancienne entrée

Contenu associé à une image en complément de son alternative textuelle afin de décrire en totalité l’information véhiculée par l’image. La description détaillée peut être insérée via :

  • Un attribut longdesc qui contient l’adresse d’une page ou d’un emplacement dans la page contenant la description détaillée;
  • Une référence, dans l’attribut alt, à une description détaillée adjacente à l’image;
  • Un lien adjacent à l’image qui contient l’adresse d’une page ou d’un emplacement dans la page contenant la description détaillée;
  • Un ou plusieurs passages de texte identifiés par un id et liés par une propriété aria-describedby sur le modèle aria-describedby=“ID1 ID2 ID3…”.

Note : Pour assurer une compatibilité maximum avec les agents utilisateurs, notamment Internet Explorer 11, il est recommandé d’implémenter un tabindex=“-1” sur les passages de textes qui ne sont pas des éléments interactifs (bouton, liens, éléments de formulaires, etc.).

Nouvelle entrée

Contenu associé à une image en complément de son alternative textuelle afin de décrire en totalité l’information véhiculée par l’image. La description détaillée peut être associée à l’image via :

  • Un attribut longdesc qui contient l’adresse d’une page ou d’un emplacement dans la page contenant la description détaillée;
  • Une référence à une description détaillée adjacente à l’image dans l’alternative textuelle;
  • Un lien ou un bouton adjacent qui permet d’accéder à la description détaillée dans la page ou dans une autre page;
  • Un ou plusieurs passages de texte identifiés par un id et liés par un attribut WAI-ARIA aria-describedby sur le modèle aria-describedby=“ID1 ID2 ID3…”.

Note 1 : Si le support de l’attribut aria-describedby fait défaut, il est possible d’utiliser un ou plusieurs passages de texte identifiés par un id et liés par un attribut WAI-ARIA aria-labelledby à la suite de l’alternative textuelle.

Note 2 : Pour assurer une compatibilité maximum avec les agents utilisateurs, notamment Internet Explorer 11, il est recommandé d’implémenter un tabindex=“-1” sur les balises qui contiennent un passage de texte et qui ne sont pas des éléments interactifs (bouton, liens, éléments de formulaires, etc.).

Création « élément graphique »

Raison de la création

Précisions visant à faciliter la compréhension du critère.

Nouvelle entrée

Élément faisant appel à une représentation visuelle telle que des images, des pictogrammes ou des graphiques.

Cet élément peut être composé d’une ou plusieurs parties dont la visibilité est nécessaire à sa compréhension (par exemple chaque point sur chaque ligne d’un graphique de statistiques).

Modification « En-tête de lignes ou de colonnes »

Prise en compte de WAI-ARIA pour les tableaux de données simple

Ancienne entrée

Contenu d’une cellule dans un tableau de données (la première cellule d’une colonne ou d’une ligne, généralement) qui sert d’intitulé pour la totalité ou une partie des cellules de la colonne ou de la ligne. Une colonne ou une ligne peut contenir plusieurs en-têtes (en-tête intermédiaire). Les en-têtes doivent utiliser une balise th.

Nouvelle entrée

Contenu d’une cellule dans un tableau de données (la première cellule d’une colonne ou d’une ligne, généralement) qui sert d’intitulé pour la totalité ou une partie des cellules de la colonne ou de la ligne. Une colonne ou une ligne peut contenir plusieurs en-têtes (en-tête intermédiaire). Lorsque les en-têtes s’appliquent à l’ensemble d’une ligne ou d’une colonne ils peuvent être structurés avec une balise <th> ou une balise pourvue d’un attribut WAI-ARIA role=“rowheader” ou “columnheader”. Dans le cas contraire seul une balise <th> peut être utilisée.

Note : seule la balise <th> étant totalement supportée par l’ensemble des technologies d’assistance, il est fortement recommandé de privilégier cette solution lors de la mise en oeuvre afin d’éviter de nombreuses vérifications dans les différentes combinaisons prévues dans l’environnement de test (ou « base de référence »).

Modification « Ensemble de pages »

Suppression de l’exemple “Processus de paiement électronique” suite à la mise à jour du cas particulier du critère 12.1

Ancienne entrée

Pages web liées les unes aux autres par des liens et constituant un ensemble cohérent à l’intérieur d’un site web. Par exemple, les pages d’un processus de paiement électronique, les pages d’une rubrique spécifique, les pages d’un blog, les pages d’administration d’un compte client sont autant d’ensembles de page.

Note : la page d’accueil d’un site web peut constituer, à elle seule, un « ensemble de pages » du fait de son unicité.

Nouvelle entrée

Pages web liées les unes aux autres par des liens et constituant un ensemble cohérent à l’intérieur d’un site web. Par exemple, les pages d’une rubrique spécifique, les pages d’un blog, les pages d’administration d’un compte client sont autant d’ensembles de page.

Note : la page d’accueil d’un site web peut constituer, à elle seule, un « ensemble de pages » du fait de son unicité.

Modification « Étiquette de champ de formulaire »

Précision visant à interdire l’usage de l’attribut aria-label pour indiquer le caractère obligatoire des champs car cela rendrait l’indication non visible pour les utilisateurs mal voyants ou en situation de handicap moteur

Nouvelle entrée

Note : l’attribut aria-label ne peut pas être utilisé pour indiquer le caractère obligatoire d’un champ.

Création « Formulaire »

Raison de la création

Prise en compte de WAI-ARIA

Nouvelle entrée

Balise <form> ou possédant un attribut WAI-ARIA role=“form”.

Création « Gestes simples et gestes complexes »

Raison de la création

Précisions visant à faciliter la compréhension des termes relatifs aux différents types de geste.

Nouvelle entrée

Gestes complexes et gestes simples

Un geste simple implique un contact en un point unique de l’écran. Il peut s’agir d’une pression ou d’un clic simple, d’une double-pression ou d’un double-clic, d’une pression prolongée.

Un geste complexe peut être à la fois un geste impliquant plusieurs points de contact sur l’écran (exemple : un geste avec deux doigts sur l’écran pour zoomer ou dézoomer une carte) et un geste basé sur le suivi d’une trajectoire sur l’écran (exemple  : fonction JavaScript permettant de détection le déplacement d’un doigt vers la gauche ou droite sur une surface tactile pour déclencher le passage à l’item précédent / suivant d’un carrousel).

Modification « Image de décoration »

Exclusion des balises possédant un attribut WAI-ARIA role=“img” du champ d’application lorsqu’elle ne possède aucun attribut WAI-ARIA aria-hidden=“true”.

Ancienne entrée

Image n’ayant aucune fonction et ne véhiculant aucune information particulière par rapport au contenu auquel elle est associée. Exemples :

  • Une image servant à caler la mise en page;
  • Une image de coin arrondie pour habiller un bloc d’information;
  • Une image d’illustration n’apportant aucune information nécessaire à la compréhension du texte auquel elle est associée.

Nouvelle entrée

Image n’ayant aucune fonction et ne véhiculant aucune information particulière par rapport au contenu auquel elle est associée. Exemples :

  • Une image précédant chaque item d’une liste;
  • Une image servant à caler la mise en page;
  • Une image de coin arrondie pour habiller un bloc d’information;
  • Une image d’illustration n’apportant aucune information nécessaire à la compréhension du texte auquel elle est associée.

Note : les balises possédant un attribut WAI-ARIA role=“img” ne peuvent faire office d’image de décoration qu’à la condition qu’elles possèdent un attribut WAI-ARIA aria-hidden=“true”.

Création « indication de champ obligatoire »

Raison de la création

Mise à disposition d’information sur ce qu’est une indication de champ obligatoire

Nouvelle entrée

Indication de format obligatoire

Indication textuelle ou graphique (icône) permettant à l’utilisateur de savoir que la saisie d’un champ est obligatoire préalablement à la saisie.

Note : Dans le cas où cette indication n’est pas réalisée de manière textuelle explicite (icône, *, !,…) l’explication de la signification de cette indication doit être visible et dans l’ordre du code source se situer avant la première utilisation de l’indication.

Création « indication du type de données et/ou de format »

Raison de la création

Mise à disposition d’information sur ce qui constitue une indication du type de données et/ou de format

Nouvelle entrée

Indication du type de données et/ou de format

Indication textuelle permettant à l’utilisateur de savoir quel est le type de donnée et/ou le format de saisie requis par un champ obligatoire, préalablement à son renseignement.

Exemples :

  • Courriel (format : vous@domaine.com);
  • Code postal (format : 00000);
  • Date (format : JJ/MM/AAAA).

Modification « Information (donnée par la couleur) »

Mise à jour des exemples et ajout de précisions indiquant les cas permettant de considérer qu’une information est transmise uniquement par la couleur ou non. Cette mise à jour a donc pour effet de rendre le critère 3.2 inutile

Ancienne entrée

Information transmise visuellement par l’intermédiaire d’une couleur. L’indication que les champs en rouge sont obligatoires dans un formulaire, un changement de couleur de fond pour indiquer la page active dans un menu de navigation, le changement de couleur d’un nom d’article pour indiquer son indisponibilité dans une liste d’article sont autant d’exemples d’indication donnée par la couleur.

L’indication donnée uniquement par la couleur doit être accompagnée d’une autre méthode à destination des utilisateurs qui ne voient pas ou perçoivent mal les couleurs ou leurs associations.

L’autre moyen de récupérer une information par la couleur peut être très divers, lorsqu’il s’agit d’un moyen faisant intervenir du graphisme (utilisation de CSS ou d’élément graphique) l’indication visuelle pourrait devoir être accompagnée d’une indication textuelle. Par exemple, un effet de bordure, de gras, de changement typographique ou autre dispositif similaire sera jugé insuffisant car ces indications ne seront pas accessibles aux personnes aveugles, notamment.

Nouvelle entrée

Information transmise visuellement par l’intermédiaire d’une couleur. L’indication que les champs en rouge sont obligatoires dans un formulaire, l’utilisation d’un fond bleu pour indiquer la page en cours de consultation dans un menu avec le fond vert, le changement de couleur d’un nom d’article pour indiquer son indisponibilité dans une liste d’articles sont autant d’exemples d’indication donnée par la couleur.

Lorsqu’une information donnée par la couleur est accompagnée d’une autre méthode à destination des utilisateurs qui ne voient pas ou perçoivent mal les couleurs ou leurs associations, le critère sera considéré comme non applicable.

Les moyens de transmettre une information autrement que par la couleur peuvent être :

  • Une indication textuelle visible;
  • Un moyen faisant intervenir du graphisme (pictogramme, image de fond, forme, style de bordure différent, etc) et par le biais d’un complément au niveau du code (aria-label, title, texte masqué, aria-current, etc.);
  • Un autre style typographique (gras, italique, taille de texte, autre police, etc) et par le biais d’un complément au niveau du code (aria-label, title, texte masqué, aria-current, etc.).

Modification « intitulé de lien »

Prise en compte des liens en SVG, référence aux entrées de glossaire existantes, prise en compte du critère « label in name » 2.5.3 des WCAG 2.1, prise en compte de l’usage de l’attribut title et des intitulés de liens identiques.

Ancienne entrée

Intitulé de lien

Information textuelle comprise entre <a href="…"> et </a> d’un lien, complété si nécessaire d’informations de contexte.

Les 4 différents types de liens sont :

  • Lien texte : il s’agit du texte compris entre <a href="…"> et </a>, complété si nécessaire d’informations de contexte;
  • Lien image : il s’agit du contenu de l’alternative textuelle de l’image comprise entre <a href="…"> et </a>, complété si nécessaire d’informations de contexte;
  • Lien composite : il s’agit de l’ensemble du texte et du contenu de l’alternative textuelle de la ou des images compris entre <a href="…"> et </a>, complété si nécessaire d’informations de contexte;
  • Lien vectoriel : il s’agit du contenu de l’alternative textuelle de l’image vectorielle (balise svg) comprise entre <a href="…"> et </a> complété si nécessaire d’informations de contexte. L’intitulé de lien pour un lien vectoriel est le contenu de l’alternative textuelle de l’image vectorielle.

Note 1 : voir la définition de lien image pour plus de précisions.

Note 2 : un lien image pour lequel l’attribut alt est absent est considéré comme non applicable pour le critère 6.5.

Nouvelle entrée

Intitulé (ou nom accessible) de lien

« Nom accessible » restitué par les technologies d’assistance.

Dans le cas d’un lien HTML, le « nom accessible » est obtenu selon l’ordre suivant :

  • Passage de texte associé par l’attribut WAI-ARIA aria-labelledby;
  • Sinon, contenu de l’attribut WAI-ARIA aria-label;
  • Sinon, contenu du lien;
  • Sinon, contenu de l’attribut title.

Cet ordre doit être utilisé pour déterminer ce qui constitue l’intitulé du lien. Par exemple :

  • En cas de présence conjointe d’un attribut WAI-ARIA aria-label et d’un attribut WAI-ARIA aria-labelledby, c’est le passage de texte référencé par l’attribut WAI-ARIA aria-labelledby qui doit être considéré comme l’intitulé;

  • En cas de présence conjointe d’un attribut WAI-ARIA aria-label et d’un contenu dans le lien, c’est le contenu de l’attribut WAI-ARIA aria-label qui doit être considéré comme l’intitulé.

Référence : Accessible name and description calculation.

Dans le cas où le « nom accessible » est obtenu à partir du contenu du lien, celui-ci sera variable en fonction des cas suivants :

Lien texte :

En HTML, le « nom accessible » correspond au texte constitué à partir :

  • Du texte contenu dans le lien;
  • Du texte contenu dans les éléments enfants du lien.

Lien image :

En HTML, le « nom accessible » correspond au texte constitué à partir de l’alternative textuelle d’une ou plusieurs images dans le lien du type :

  • Image (balise <img> ou balise ayant l’attribut WAI-ARIA role=“img”);
  • Image objet (balise <object>);
  • Image bitmap (balise <canvas>);
  • Image vectorielle (balise <svg>).

Lien composite :

En HTML, le « nom accessible » correspond au texte constitué à partir de l’ensemble :

  • Du texte contenu dans le lien;
  • Du texte contenu dans les éléments enfant du lien;
  • Du contenu de l’alternative textuelle de la ou des images comprises dans le lien.

Dans le cas d’un lien SVG (version 1.1), le « nom accessible » est obtenu comme suit :

  • Passage de texte associé par l’attribut WAI-ARIA aria-labelledby;
  • Sinon, contenu de l’attribut WAI-ARIA aria-label;
  • Sinon, contenu de l’élément <title> enfant direct du lien;
  • Sinon, contenu de l’attribut x-link:title;
  • Sinon, contenu texte d’un ou plusieurs éléments <text>.

Il faut cependant être vigilant car cet algorithme de calcul n’est pas encore pris en compte et effectif au sein des différents lecteurs d’écran. A ce jour, le support est disponible avec VoiceOver, mais incomplet ou lacunaire avec JAWS et NVDA. Si bien que le plus petit dénominateur commun sur lequel il est possible de se reposer pour fournir un intitulé au lien est l’élément <text>.

Note 1 : un intitulé de lien sera considéré comme non-explicite dans le cas où le « nom accessible » ne reprend pas l’intitulé visible du lien.

Note 2 : en raison de la configuration possible des aides techniques permettant de forcer la restitution du « nom accessible » issu du contenu de l’attribut title au détriment du « nom accessible » issu du contenu du lien. Un intitulé de lien sera considéré comme non-explicite dans le cas où le lien possède un attribut title dont la valeur ne reprendrait pas au moins le « nom accessible » issu du contenu du lien.

Note 3 : dans le cas de la présence de plusieurs liens ayant une destination différente dont le « nom accessible » est identique. L’intitulé de lien seul sera considéré comme non-explicite si le contexte de lien ne permet pas de les différencier.

Note 4 : lorsqu’un lien ne comporte aucun contenu (à l’exception des ancres), il sera non conforme au regard du critère 10.2 et du critère 6.4.

Note 5 : bien que le calcul du nom accessible d’un lien tienne compte de contenus texte générés en CSS via les pseudo-éléments ::before et ::after, cette pratique ne doit pas être utilisée car elle constitue une non conformité au critère 1.3.1 des WCAG 2.1 (cf. F87).

Création « Intitulé visible »

Raison de la création

Ajout des tests permettant de couvrir le nouveau critère WCAG 2.1 “Label in name”.

Nouvelle entrée

Texte affiché faisant office d’intitulé visible à l’écran au sein d’un bouton ou d’un lien.

Texte affiché faisant office d’étiquette pour un champ formulaire.

Ce texte peut être constitué de texte ou d’une image contenant du texte.

Création « Contenu alternatif »

Raison de la création

Prise en compte de la possibilité de fournir une alternative textuelle par le biais d’un contenu alternatif pour les images objet (balise <object> avec l’attribut type=“image/…”, les images embarqués (balise <embed> avec l’attribut type=“image/…”) et les images bitmap (balise <canvas>)).

Nouvelle entrée

Contenu venant se substituer à un autre apportant la même information mais pouvant être présenté de façon différente. Ce contenu peut être de forme textuelle mais également être lui-même structuré à l’aide de balises. Un contenu alternatif devra respecter l’ensemble des critères du RGAA qui lui sont applicables pour être considéré comme une alternative accessible à l’élément qu’il remplace. Exemple : un tableau de données peut être le contenu alternatif d’une image bitmap (balise <canvas>) affichant un graphique statistique.

Création «Contenu caché »

Raison de la création

Le critère 10.13 porte logiquement sur l’ensemble des contenus cachés et non uniquement sur le texte. L’entrée de glossaire est ainsi renommée “Contenu caché”. Suppression du cas width et height avec les valeurs 0 (width:0;height:0) qui est désormais restitué par les technologies d’assistances

Nouvelle entrée

Contenu caché

Les technologies d’assistance (notamment les lecteurs d’écran) ne restituent pas le contenu masqué via les propriétés :

  • display avec la valeur none (display: none);
  • visibility avec la valeur hidden (visibility: hidden);
  • font-size avec la valeur 0 (font-size:0);
  • Attribut HTML5 hidden;
  • Attribut WAI-ARIA aria-hidden=“true”.

Tous les contenus utilisant une ou plusieurs de ces propriétés et attributs sont applicables pour le critère 10.13.

Création « Landmark »

Raison de la création

Modification du critère 12.10.

Nouvelle entrée

Landmarks

WAI-ARIA propose des rôles permettant d’indiquer les zones principales (régions) du document. Ces rôles sont très profitables aux utilisateurs de lecteurs d’écran notamment, mais également aux utilisateurs de la navigation au clavier qui peuvent ainsi bénéficier de fonctionnalités de navigation rapide dans la structure du document.

Les rôles doivent être définis dans le document en fonction de la nature de la zone :

  • La zone d’en-tête doit avoir un attribut WAI-ARIA role=“banner”;
  • Le menu de navigation principal doit avoir un attribut WAI-ARIA role=“navigation”;
  • La zone de contenu principal doit avoir un attribut WAI-ARIA role=“main”;
  • La zone de pied de page doit avoir un attribut WAI-ARIA role=“contentinfo”;
  • La zone de moteur de recherche sur le site doit avoir un attribut WAI-ARIA role=“search”.

Note 1 : Si la plupart des lecteurs d’écran mettent à disposition ces fonctionnalités, les navigateurs n’ont pas encore proposé de fonctionnalité de navigation dédiée pour les utilisateurs qui ne peuvent pas utiliser la souris. La mise en place des liens d’évitement reste donc à privilégier par rapport aux landmarks.

Note 2 : Les rôles WAI-ARIA banner, main et contentinfo doivent être uniques dans la page. Le rôle WAI-ARIA navigation est réservé aux zones de navigations principales et secondaires. Lorsqu’il y a plusieurs rôles WAI-ARIA navigation, il peut être utile de les différencier en précisant un nom à chacune des zones via l’attribut WAI-ARIA aria-label ou aria-labelledby.

Modification « Le nom, le rôle, la valeur, le paramétrage et les changements d’états »

Référence au document WAI-ARIA 1.1 Authoring Practices et remplacement de API ARIA par WAI-ARIA

Ancienne entrée

Un composant doit avoir un rôle et un nom appropriés, ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux APIs d’accessibilité notamment.

Un composant peut s’appuyer sur un élément interactif HTML ou sur un élément non interactif surchargé par l’API ARIA via un rôle ad hoc. Important : les boutons (balises button ou input type=“button”) lorsqu’ils sont contrôlés via JavaScript sont à évaluer avec le critère 7.1.

Le nom peut être l’intitulé du composant comme l’intitulé d’un bouton par exemple.

La valeur est, par exemple, l’élément sélectionné d’une liste déroulante ou la valeur actuelle d’un curseur (slider).

Le rôle correspond au type d’élément défini par la spécification HTML ou l’API WAI-ARIA (comme la balise button ou le rôle ARIA role=“button”).

Le paramétrage correspond aux informations particulières d’un composant, généralement mis à disposition par l’API WAI-ARIA. Par exemple aria-controls est un paramètre qui transmet aux APIs l’information que le composant contrôle tel ou tel contenu (référencé par son identifiant - attribut id).

Les changements d’états sont également mis à disposition par l’API WAI-ARIA. Par exemple aria-expanded est un état permettant de signaler aux APIs que le composant est « ouvert » ou « fermé ». Note : un état peut également être transmis via le nom, lorsque l’intitulé est changé dynamiquement pour correspondre à l’état de la zone contrôlée notamment.

Ces paramètres ne sont pas obligatoires mais peuvent être requis s’ils sont indispensables pour rendre le composant accessible. C’est à l’auditeur de considérer les cas où ces paramètres sont indispensables en fonction du contexte lié à l’utilisation du composant.

L’auditeur doit également vérifier que, lorsqu’il sont présents, ces paramètres sont correctement utilisés.

Note : les rôles, propriétés et états ARIA s’implémentent via des attributs, par exemple role=“banner”, aria-hidden=“true”.

Nouvelle entrée

Un composant doit avoir un rôle et un nom appropriés. Ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux APIs d’accessibilité notamment.

Un composant peut s’appuyer sur un élément interactif HTML ou sur un élément non interactif surchargé par WAI-ARIA via un rôle ad hoc. Important : les boutons (balises <button> ou <input type="button">) lorsqu’ils sont contrôlés via JavaScript sont à évaluer avec le critère 7.1.

Le nom peut être l’intitulé du composant (l’intitulé d’un bouton, par exemple).

La valeur est, par exemple, l’élément sélectionné d’une liste déroulante ou la valeur actuelle d’un curseur (slider).

Le rôle correspond au type d’élément défini par la spécification HTML ou WAI-ARIA (comme la balise <button> ou l’attribut WAI-ARIA role=“button”).

Le paramétrage correspond aux informations particulières d’un composant, généralement mis à disposition par WAI-ARIA. Par exemple aria-controls est un paramètre qui transmet aux APIs l’information que le composant contrôle tel ou tel contenu (référencé par son identifiant - attribut id).

Les changements d’états sont également mis à disposition par WAI-ARIA. Par exemple aria-expanded est un état permettant de signaler aux APIs que le composant est « ouvert » ou « fermé ». À noter qu’un état peut également être transmis via le nom, lorsque l’intitulé est changé dynamiquement pour correspondre à l’état de la zone contrôlée notamment.

Ces paramètres ne sont pas obligatoires mais peuvent être requis s’ils sont indispensables pour rendre le composant accessible. C’est à l’auditeur de considérer les cas où ces paramètres sont indispensables en fonction du contexte lié à l’utilisation du composant.

L’auditeur doit également vérifier que, lorsqu’ils sont présents, ces paramètres sont correctement utilisés.

Pour ce faire (s’il juge cela pertinent compte tenu du contexte d’implémentation des composants et des choix ergonomiques mis en œuvre) il peut s’appuyer sur les recommandations d’utilisation de WAI-ARIA pour les composants ayant des attributs WAI-ARIA correspondant à un motif de conception tel que décrit dans le document WAI-ARIA 1.1 Authoring Practices.

Note : les rôles, propriétés et états WAI-ARIA s’implémentent via des attributs, par exemple role=“banner”, aria-hidden=“true”.

Création « Légende »

Raison de la création

L’entrée de glossaire bloc d’information de même nature est divisée en deux entrées distinctes dont Légende

Nouvelle entrée

Légende

HTML propose un dispositif permettant de titrer les groupes de champs de même nature par l’intermédiaire des éléments <fieldset> et <legend>.

Il est également possible de créer des regroupements avec le rôle WAI-ARIA group et un passage de texte, faisant office de légende, liée par l’attribut WAI-ARIA aria-labelledby ou implémentée par l’intermédiaire d’un attribut WAI-ARIA aria-label.

Note 1 : Les regroupements de champs peuvent utiliser d’autres méthodes qui associent l’information du regroupement directement dans l’étiquette du champ. Par exemple, par l’intermédiaire d’un attribut title, d’un attribut WAI-ARIA aria-label, d’une liaison aria-labelledby faisant office d’étiquette ou encore par l’attribut WAI-ARIA aria-describedby associant un texte complémentaire. Dans ce cas, le regroupement de champs devient inutile puisque les labels sont suffisamment pertinents.

Note 2 : Lorsque le formulaire est constitué d’un seul bloc d’informations de même nature (l’identité et l’adresse de l’utilisateur, par exemple) ou d’un champ unique (un moteur de recherche, par exemple), le regroupement des champs n’est pas obligatoire.

Modification « Lien »

Simplification de l’entrée de glossaire, prise en compte des liens WAI-ARIA et SVG.

Ancienne entrée

Élément HTML (balise a) activable par l’utilisateur (par la souris, le clavier…) et déclenchant une action (affichage d’une page web, téléchargement d’un fichier…) ou un événement généré par un script. Un lien possède au minimum :

  • Une référence de ressource (attribut href);
  • Un intitulé de lien compris entre <a href="…"> et </a>.

Nouvelle entrée

En HTML :

  • Balise <a> possédant un attribut href;

  • Balise possédant un attribut WAI-ARIA role=“link” et dont l’action de navigation est prise en charge par un script.

En SVG :

  • Balise <a> possédant un attribut xlink:href en SVG 1.1.

Modification « Lien adjacent ou bouton adjacent »

Prise en compte de l’utilisation de boutons permettant d’accéder à un contenu alternatif dans la page.

Ancienne entrée

Lien adjacent

Lien présenté de manière adjacente dans la représentation graphique (CSS activé) et dans le code HTML. Dans le code HTML, le lien doit se situer juste avant ou juste après l’objet avec lequel il est adjacent.

Nouvelle entrée

Lien ou bouton adjacent

Lien ou bouton présenté de manière adjacente à un élément dans la page. Le lien ou bouton doit être adjacent visuellement dans la représentation graphique (CSS activé) et dans le code HTML. Dans le code HTML, le lien ou bouton doit se situer juste avant ou juste après l’élément auquel il est adjacent.

Modification « Lien composite »

Reformulation suite à la modification de l’entrée de glossaire Lien.

Ancienne entrée

Lien dont le contenu entre <a href="…"> et </a> est constitué de 2 éléments de type différent, au moins; par exemple, du texte et une ou plusieurs images. L’intitulé de lien pour un lien composite est l’ensemble du texte et du contenu de l’alternative textuelle de la ou des images compris entre <a href="…"> et </a>.

Note importante: il est rappelé que l’utilisation de deux liens adjacents (lien image et lien texte) et identiques constitue une gêne importante pour l’utilisateur. Même si cela ne constitue pas une non-conformité, cet usage devrait être évité. Une manière de traiter ce type de liens est d’inclure l’image dans le lien texte de façon à constituer un lien composite, ce qui évitera la redondance.

Vous pouvez consulter à ce sujet la technique H2 : Combining adjacent image and text links for the same resource.

Nouvelle entrée

En HTML, lien contenant à la fois du texte et un ou plusieurs enfants de type image :

  • Image (balise <img> ou balise ayant l’attribut WAI-ARIA role=“img”);
  • Zone cliquable (balise <area>) possédant un attribut href;
  • Image objet (balise <object>);
  • Image bitmap (balise <canvas>);
  • Image vectorielle (balise <svg>).

Note importante: il est rappelé que l’utilisation de deux liens adjacents (lien image et lien texte) et identiques constitue une gêne importante pour l’utilisateur. Même si cela ne constitue pas une non-conformité, cet usage devrait être évité. Une manière de traiter ce type de liens est d’inclure l’image dans le lien texte de façon à constituer un lien composite, ce qui évitera la redondance.

Vous pouvez consulter à ce sujet la technique H2 : Combining adjacent image and text links for the same resource.

Suppression « liens identiques »

Raison de la suppression

Suppression du critère 6.4 désormais traité via la nouvelle définition d’intitulé du lien dont la pertinence est vérifié dans le critère 6.1.

Ancienne entrée

Liens identiques

Deux liens sont dits identiques quand le lien x (intitulé du lien seul, contenu de l’attribut title ou contexte du lien) est égal au lien y. Cette définition s’applique à tous les types de liens : lien texte, lien image (les liens ont alors la même image) et lien composite.

Attention : des liens avec des intitulés identiques mais des titres de liens différents ou des contextes de liens différents ne sont pas identiques (exemple : <a href="lien_bar.html" title="cliquer ici pour télécharger la barre d'outils">cliquer ici </a> et <a href="lien_doc.html" title="cliquer ici pour télécharger le document">cliquer ici</a>).

Modification « Lien image »

Reformulation suite à la modification de l’entrée de glossaire Lien. Faire directement référence à l’entrée de glossaire « Alternative textuelle » pour éviter une redondance.

Ancienne entrée

Lien dont le contenu entre <a href="…"> et </a> est uniquement constitué d’une image. L’intitulé de lien pour un lien image est le contenu de l’alternative textuelle de l’image.

Un lien image peut être constitué :

  • D’une image (balise img), l’alternative est le contenu de l’attribut alt;
  • D’une zone cliquable (balise area) possédant un attribut href, l’alternative est le contenu de l’attribut alt;
  • D’une image objet (balise object), l’alternative est contenue entre <object> et </object>;
  • D’une image bitmap (balise canvas), l’alternative est contenue entre <canvas> et </canvas>;
  • D’une image vectorielle (balise svg), l’alternative est contenue dans l’attribut aria-label ou la balise <title>.

Note au sujet de embed : Pour les doctype antérieurs à HTML5, l’alternative d’une image embarquée peut être contenue entre <embed> et </embed>. En HTML5, la balise embed a été modifiée. C’est une balise autofermante qui ne peut donc pas embarquer de contenu alternatif. Les propriétés ARIA, comme aria-label qui permettrait d’embarquer une alternative, n’étant pas supportées de manière uniforme, les seules méthodes possibles pour fournir une alternative à ces images embarquées porteuses d’informations sont : un lien adjacent permettant d’afficher une page ou un passage de texte contenant une alternative pertinente, un mécanisme qui permet à l’utilisateur de remplacer l’image par un texte alternatif ou par une image possédant une alternative pertinente.

Nouvelle entrée

En HTML, lien contenant uniquement un ou plusieurs enfants de type image :

  • Image (balise <img> ou balise ayant l’attribut WAI-ARIA role=“img”);
  • Zone cliquable (balise <area>) possédant un attribut href;
  • Image objet (balise <object>);
  • Image bitmap (balise <canvas>);
  • Image vectorielle (balise <svg>).

Modification « Lien texte »

Reformulation suite à la modification de l’entrée de glossaire Lien.

Ancienne entrée

Lien dont le contenu entre <a href="…"> et </a> est uniquement constitué de texte (il s’agit de son intitulé de lien).

Nouvelle entrée

En HTML, lien ne contenant aucun élément enfant de type :

  • Image (balise <img> ou balise ayant l’attribut WAI-ARIA role=“img”);
  • Image objet (balise <object>);
  • Image bitmap (balise <canvas>);
  • Image vectorielle (balise <svg>).

Modification « Liens d’évitement ou d’accès rapide »

Précisions sur la notion suite à la modification des tests.

Ancienne entrée

Liens dont la fonction est de permettre de naviguer à l’intérieur du contenu (lien d’évitement, lien d’accès au formulaire de recherche ou au menu…).

Nouvelle entrée

Liens dont la fonction est de permettre de naviguer à l’intérieur de la page (lien d’évitement, lien d’accès au formulaire de recherche ou au menu…). Ces liens peuvent soit permettre d’accéder à une zone de la page (lien d’accès rapide) ou de sauter une zone dans la page (lien d’évitement).

Note 1 : Un lien d’évitement ou d’accès rapide dont l’activation ne permettrait pas de reprendre la lecture et la navigation clavier à partir de la cible du lien lors de l’utilisation des navigateurs et des aides techniques retenus dans l’environnement de test (ou « base de référence ») de l’audit serait considéré comme non conforme.

Note 2 : les liens d’évitements ou d’accès rapide doivent être situés à la même place dans la présentation et dans le même ordre relatif dans le code source afin de satisfaire au critère 12.2.

Modification « listes »

Ajout d’une note pour signaler le changement d’appellation “liste de définition” par “liste de description” en HTML5 et l’ouverture sémantique qui l’accompagne.

Ancienne entrée

Liste

Suite d’éléments pouvant être regroupés sous la forme d’une liste structurée ordonnée, non ordonnée ou de définition. Par exemple la suite des liens d’un menu de navigation est une liste de liens non ordonnée, les différentes étapes d’une procédure est une liste d’éléments ordonnés, le couple terme/définition d’un glossaire est une liste de définition. En HTML, les listes utilisent les balises suivantes :

  • Liste ordonnée : balises ol et li (chaque élément de la liste est affecté d’un marqueur indexé);
  • Liste non ordonnée : balises ul et li (chaque élément de la liste est affecté d’un marqueur non-indexé;
  • Liste de définition : balises dl, dt (terme à définir) et dd (définition).

Nouvelle entrée

Listes

Suite d’éléments pouvant être regroupés sous la forme d’une liste structurée ordonnée, non ordonnée ou de définition. Par exemple la suite des liens d’un menu de navigation est une liste de liens non ordonnée, les différentes étapes d’une procédure est une liste d’éléments ordonnés, le couple terme/description d’un glossaire est une liste de description. En HTML, les listes utilisent les balises suivantes :

  • Liste ordonnée : balises <ol> et <li> (chaque élément de la liste est affecté d’un marqueur indexé);
  • Liste non ordonnée : balises <ul> et <li> (chaque élément de la liste est affecté d’un marqueur non-indexé;
  • Liste de description : balises <dl>, <dt> (terme à décrire) et <dd> (description).

Note 1 : En HTML5, la balise <dl> ne représente plus seulement une liste de définition, mais de manière générique toute liste de description qui peut comprendre comme groupe de termes-descriptions des noms et des définitions, des questions et réponses, des catégories et des sujets, etc.

Note 2 : Il est également possible de structurer les listes à l’aides des attributs WAI-ARIA role=“list” et role=“listitem” pour les listes ordonnées et non ordonnées.

Note 3 : la notion de « regroupées visuellement sous forme de liste » se caractérise par :

  • La présence d’un marqueur visuel permettant de faire comprendre qu’il s’agit d’une liste non ordonnée par exemple -, •, *, etc.;
  • La présence d’un marqueur visuel permettant de faire comprendre qu’il s’agit d’une liste ordonnée par exemple un chiffre, une lettre grecque, etc.;
  • La présence d’une série d’éléments se suivant visuellement les uns les autres, avec une forme visuelle, une nature et un fonctionnement identique, mais sans avoir directement de marqueur visuel de liste (non ordonnée ou ordonnée), comme par exemple un menu de navigation.

Attention cependant toutes les listes ne nécessitent pas obligatoirement une structure de liste, par exemple une série de termes séparés par une virgule.

Modification « Liste de choix »

Remplacement de l’entrée par « Items de même nature des listes de choix »

Ancienne entrée

Champ de formulaire affichant une série d’items à sélectionner sous forme d’une liste déroulante (balise select avec des balises option).

Nouvelle entrée

Dans une liste déroulante (balise <select>), ensemble d’items (balises <option>) pouvant être regroupés par leur nature. Le regroupement vise à identifier les items devant être traités comme un ensemble. Exemple, une liste de départements où il serait possible de choisir une région.

Création « liste des valeurs possibles pour l’attribut autocomplete »

Raison de la création

Prise en compte du nouveau critère de succès 1.3.5 des WCAG 2.1

Nouvelle entrée

Liste des valeurs possibles pour l’attribut autocomplete

La liste des valeurs disponibles est fournie par la spécification WCAG 2.1 :

  • name - Nom complet;
  • honorific-prefix - Abréviation, civilité ou titre;
  • given-name - Prénom;
  • additional-name - Prénoms additionnels;
  • family-name - Nom de famille;
  • honorific-suffix - Suffixe honorifique;
  • nickname - Surnom, diminutif;
  • organization-title - Fonction, intitulé de poste;
  • username - Nom d’utilisateur;
  • new-password - Nouveau mot de passe (par exemple, lors de la création d’un compte ou d’un changement de mot de passe)
  • current-password - Mot de passe actuel pour le compte identifié par le champ username (par exemple, lors d’une connexion)
  • organization - Nom de l’organisation correspondant à la personne, à l’adresse ou à l’information de contact dans les autres champs associés avec ce champ
  • street-address - Adresse postale (multiligne, nouvelles lignes conservées)
  • address-line1 - Adresse postale (une ligne par champ, ligne 1)
  • address-line2 - Adresse postale (une ligne par champ, ligne 2)
  • address-line3 - Adresse postale (une ligne par champ, ligne 3)
  • address-level4 - Le niveau administratif le plus détaillé, pour les adresses pourvues de quatre niveaux administratifs
  • address-level3 - Le troisième niveau administratif, pour les adresses pourvues d’au moins trois niveaux administratifs
  • address-level2 - Le deuxième niveau administratif, pour les adresses pourvues d’au moins deux niveaux administratifs
  • address-level1 - Le plus large niveau administratif d’une adresse, c’est-à-dire la province dans laquelle se trouve la localité
  • country - Code pays
  • country-name - Nom de pays
  • postal-code - Code postal, code CEDEX (si le CEDEX est présent, ajouter “CEDEX”, et ce qui le suit doit être ajouté dans le champ address-level2)
  • cc-name - Nom complet figurant sur le moyen de paiement
  • cc-given-name - Prénom figurant sur le moyen de paiement
  • cc-additional-name - Prénoms additionnels figurant sur le moyen de paiement cc-family-name - Nom de famille figurant sur le moyen de paiement
  • cc-number - Code identifiant le moyen de paiement (e.g., un numéro de carte bancaire)
  • cc-exp - Date d’expiration du moyen de paiement
  • cc-exp-month - Le mois de la date d’expiration du moyen de paiement
  • cc-exp-year - L’année de la date d’expiration du moyen de paiement
  • cc-csc - Code de sécurité du moyen de paiement (also known as the card security code (CSC), card validation code (CVC), card verification value (CVV), signature panel code (SPC), credit card ID (CCID), etc)
  • cc-type - Type de moyen de paiement (e.g. Visa)
  • transaction-currency - La devise qui a la préférence de l’utilisateur lors d’une transaction
  • transaction-amount - Le montant qui a la préférence de l’utilisateur lors d’une transaction (e.g., en réponse à une enchère ou à un prix soldé)
  • language - Langage préféré
  • bday - Date d’anniversaire
  • bday-day - Le jour de la date d’anniversaire
  • bday-month - Le mois de la date d’anniversaire
  • bday-year - L’année de la date d’anniversaire
  • sex - Identité sexuelle
  • url - Page d’accueil ou une autre page Web correspondant à l’organisation, la personne, l’adresse ou à l’information de contact dans les autres champs associés avec ce champ
  • photo - Photographie, icone ou une autre image correspondant à l’organisation, la personne, l’adresse ou à l’information de contact dans les autres champs associés avec ce champ
  • tel - Numéro de téléphone complet, y compris le code pays
  • tel-country-code - Code pays du numéro de téléphone
  • tel-national - Numéro de téléphone sans la partie code pays, avec un préfixe interne au pays, s’il y a lieu.
  • tel-area-code - Indicatif régional du numéro de téléphone, avec un préfixe interne au pays, s’il y a lieu.
  • tel-local - Numéro de téléphone sans la partie code pays ni l’indicatif régional.
  • tel-local-prefix - La première partie du composant du numéro de téléphone qui suit l’indicatif régional, lorsque ce composant est scindé en deux parties
  • tel-local-suffix - La seconde partie du composant du numéro de téléphone qui suit l’indicatif régional, lorsque ce composant est scindé en deux parties
  • tel-extension - Numéro de téléphone d’un poste interne
  • email - Adresse électronique
  • impp - URL correspondant d’un protocole de messagerie instantanée (par exemple, “aim:goim?screenname=example” ou “xmpp:fred@example.net”)

Suppression « Mécanisme qui permet d’afficher le texte avec un rapport de contraste conforme »

Raison de la suppression

Suppression du test 3.3.5

Ancienne entrée

Mécanisme qui permet d’afficher le texte avec un rapport de contraste conforme

Si le mécanisme est géré par un lien ou un bouton dont l’intitulé visible est constitué par un texte seul (contenu entre les balises <a> et </a>, <button> et </button> ou encore attribut value par exemple), alors le rapport de contraste de l’élément est à tester avec les tests 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.4.1, 3.4.2, 3.4.3 ou 3.4.5, selon le niveau exigé et le cas d’application.

Pour toutes les autres implémentations, les tests 3.3.5 et 3.4.5 s’appliquent (selon, le niveau AA ou AAA, exigé).

Suppression « Menu de navigation »

Raison de la suppression

Fusion des deux entrées de glossaire « Barre de navigation » et « Menu de navigation » dont les contenus se recoupent en partie, la notion de menu de navigation étant englobée dans la notion plus générique de barre de navigation. Cette mise en cohérence permet d’éviter les tests redondants des critères 12.2 et 12.3.

Ancienne entrée

Menu de navigation

Zone contenant des liens qui permettent de naviguer dans les rubriques principales du site. Il s’agit généralement du menu principal et des menus contextuels.

Note : Les liens de pied de page renvoyant vers les mentions légales, plan du site et autres informations concernant le site ne sont pas considérés comme un menu de navigation principal.

Voir la définition technique de zone d’en-tête fournie par l’API ARIA navigation (role).

Création « Message de statut »

Raison de la création de l’entrée

Prise en compte du critère WCAG 4.1.3.

Nouvelle entrée

Message de statut

Un message de statut informe l’utilisateur d’un changement de contenu dans la page sans interrompre son activité principale (il n’y a pas de changement de contexte par exemple un repositionnement du focus sur le message).

Un message de statut peut informer sur :

  • Le succès ou le résultat d’une action;
  • L’état occupé d’une application;
  • L’état de progression d’un processus;
  • L’existence d’erreur.

Création « modifier ou annuler les données et les actions effectuées »

Raison de la création

Ajouter visant à faciliter la compréhension du critère

Nouvelle entrée

Modifier ou annuler les données et les actions effectués

Procédés par lesquels un utilisateur peut modifier les données qu’il a saisies, faire annuler sa saisie ou faire annuler les actions découlant de sa saisie par exemple annuler une commande ou un virement bancaire.

Note : La page contenant un formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou un examen, ou dont la validation a des conséquences financières ou juridiques, doit indiquer explicitement la durée pendant laquelle l’utilisateur peut demander l’annulation de sa saisie. Elle devra également contenir la procédure à effectuer pour annuler cette saisie. Cette procédure n’a pas à être obligatoirement réalisable en ligne même si cela reste recommandé.

Modification «Motif de conception»

Mise à jour suite à la suppression des test 7.1.3 et 7.3.3, mise à jour de la référence à la version du document WAI-ARIA Authoring Practices, reformulation du début de la note 2.

Ancienne entrée

Un motif de conception (Design Pattern) est un modèle défini par l’API WAI-ARIA qui décrit la structure, les rôles et propriétés et le comportement que doit respecter un composant JavaScript (widget).

Les motifs de conception sont décrits dans le document : WAI-ARIA 1.0 Authoring Practices.

Un composant développé avec JavaScript doit respecter le motif de conception correspondant au rôle WAI-ARIA utilisé.

Note 1 : compte tenu du manque de support de certaines propriétés et de certains rôles WAI-ARIA et de la grande variabilité des situations dans lesquelles un composant JavaScript peut être proposé, il est possible d’adapter des motifs de conception à des contextes ou des utilisations particulières. Dans ce cas, le motif de conception adapté doit :

  • Respecter la structure générale, par exemple un ensemble de panneaux (rôle tabpanel) d’un système d’onglets est forcément lié à un ensemble d’onglets (rôle tablist);
  • Utiliser en remplacement d’un rôle ou d’une propriété WAI-ARIA mal supporté, un rôle ou une propriété WAI-ARIA équivalent, offrant un comportement et une restitution similaire.

Note 2 : Cela ne concerne pas le fait d’enrichir un motif de conception de rôles ou propriétés WAI-ARIA supplémentaires dont la compatibilité avec l’accessibilité est contrôlée par le test de restitution sur la base de référence. Par exemple l’ajout de la propriété aria-hidden sur les panneaux (rôle tabpanel) d’un système d’onglets ne définit pas un motif de conception adapté.

Nouvelle entrée

Un motif de conception (Design Pattern) est un modèle défini dans le document : WAI-ARIA 1.1 Authoring Practices. qui décrit la structure, les rôles et propriétés et le comportement clavier que doit respecter un composant JavaScript (widget).

Il est recommandé que les composants développés en JavaScript utilisant des attributs WAI-ARIA correspondant à un motif de conception respectent celui-ci. Attention cependant, les motifs de conception ne sont pas tous adaptés à un usage non applicatif, en particulier pour les sites proposant un affichage en contexte mobile.

Note 1 : compte tenu du manque de support de certaines propriétés et de certains rôles WAI-ARIA et de la grande variabilité des situations dans lesquelles un composant JavaScript peut être proposé, il est possible d’adapter des motifs de conception à des contextes ou des utilisations particulières. Dans ce cas, le motif de conception adapté doit :

  • Respecter la structure générale : par exemple un ensemble de panneaux (rôle WAI-ARIA tabpanel) d’un système d’onglets est forcément lié à un ensemble d’onglets (rôle WAI-ARIA tablist);

  • Utiliser en remplacement d’un rôle ou d’une propriété WAI-ARIA mal supporté, un rôle ou une propriété WAI-ARIA équivalent, offrant un comportement et une restitution similaire.

Note 2 : Le fait d’enrichir un motif de conception de rôles ou propriétés WAI-ARIA supplémentaires dont la compatibilité avec l’accessibilité est contrôlée par le test de restitution sur l’environnement de test (ou « base de référence ») ne constitue pas une adaptation d’un motif de conception. Par exemple l’ajout de l’attribut WAI-ARIA aria-hidden sur les panneaux (rôle WAI-ARIA tabpanel) d’un système d’onglets ne définit pas un motif de conception adapté.

Création « Passage de texte associé au tableau de données »

Raison de la création

Prise en compte des attributs WAI-ARIA dans la thématique tableaux

Nouvelle entrée

Passage de texte associé au tableau de données

Texte dans une balise <caption> ou dans une balise associée au tableau de données via l’attribut WAI-ARIA aria-labelledby.

Modification « Passage de texte lié par aria-labelledby ou aria-describedby »

Intégration dans la définition de la présence d’un id unique et de l’association au champ

Ancienne entrée

Il s’agit d’un ou de plusieurs passages de texte identifiés par des id et liés par aria-labelledby ou aria-describedby sur le modèle suivant : aria-labelledby=“ID1 ID2 ID3…”.

Note : pour assurer une compatibilité maximum avec les agents utilisateurs, notamment Internet Explorer 11, il est recommandé d’implémenter un tabindex=“-1”sur les passages de textes qui ne sont pas des éléments interactifs (bouton, liens, éléments de formulaires, etc.).

Nouvelle entrée

Il s’agit d’un ou de plusieurs passages de texte identifiés par des id dont la valeur est unique dans la page et associés à un élément (champ de formulaire, bouton, etc. ) par les attributs WAI-ARIA aria-labelledby ou aria-describedby sur le modèle suivant : aria-labelledby=“ID1 ID2 ID3…” où la valeur de l’attribut utilisé est égale à la liste des valeurs d’attributs id des passages de texte à associer présents dans la page.

Note 1 : pour assurer une compatibilité maximum avec les agents utilisateurs, notamment Internet Explorer 11, il est recommandé d’implémenter un tabindex=“-1” sur les passages de textes qui ne sont pas des éléments interactifs (bouton, liens, éléments de formulaires, etc.).

Note 2 : la valeur des attributs WAI-ARIA aria-labelledby ou aria-describedby ne doivent pas créer de référence récursive (A référence B qui référence A) ou traversante (A qui référence B qui référence C).

Modification « Prise de focus »

Mise à jour de la note 2 suite à la mise à jour du critère 3.3.

Ancienne entrée

La prise de focus est l’état renvoyé par un élément qui reçoit l’attention suite à une action de l’utilisateur. Il y a trois moyens en HTML de donner le focus à un élément :

  • En activant l’élément par un dispositif de pointage (souris);
  • En activant l’élément par la touche tabulation;
  • En activant l’élément par un raccourci clavier (accesskey).

Certains éléments reçoivent naturellement le focus, par exemple : a, area, button, input, object, select, label, legend, optgroup, option et textarea. Le comportement de l’élément, lors de la prise de focus, dépend de sa nature; un lien, par exemple, devra être activé après la prise de focus (sauf utilisation de script). En revanche, un élément de formulaire, comme textarea, devra autoriser la saisie suite à la prise de focus. Les éléments label et legend ne reçoivent la prise de focus que via le pointeur souris. Pour l’élément label, le comportement attendu est de transférer la prise de focus sur l’élément qui lui est associé.

Note 1 : la spécification WAI-ARIA étend le rôle attribué à l’attribut tabindex en définissant que tout élément html peut acquérir la possibilité de recevoir le focus en lui attribuant la valeur tabindex=“0”. En revanche, aucun comportement n’est attribué via la seule présence de tabindex. De même, la valeur tabindex=“-1” retire l’élément qui en est affecté du plan de tabulation en inhibant sa capacité à signaler la « prise de focus ». L’utilisation de tabindex, conformément à la spécification WAI-ARIA, peut valider certains tests relatifs à la gestion du focus de tabulation, notamment.

Note 2 : l’indication visuelle du focus ne doit pas être dégradée, c’est à dire amoindrie au moyen de valeurs qui en dégrade le style par rapport à son style par défaut.

Nouvelle entrée

La prise de focus est l’état renvoyé par un élément qui reçoit l’attention suite à une action de l’utilisateur. Il y a trois moyens en HTML de donner le focus à un élément :

  • En activant l’élément par un dispositif de pointage (exemple : souris);
  • En atteignant l’élément par la touche tabulation ou majuscule + tabulation;
  • En activant l’élément par un raccourci clavier (accesskey).

Certains éléments reçoivent naturellement le focus, par exemple : <a href>, <area href>, <button>, <input>, <object>, <select>, <label>, <legend>, <optgroup>, <option> et <textarea>. Le comportement de l’élément, lors de la prise de focus, dépend de sa nature ; un lien, par exemple, devra être activé après la prise de focus (sauf utilisation de script). En revanche, un élément de formulaire, comme <textarea>, devra autoriser la saisie suite à la prise de focus. Les éléments et <legend> ne reçoivent la prise de focus que via le pointeur souris. Pour l’élément <label>, le comportement attendu est de transférer la prise de focus sur l’élément qui lui est associé.

Note 1 : la spécification WAI-ARIA étend le rôle attribué à l’attribut tabindex en définissant que tout élément HTML peut acquérir la possibilité de recevoir le focus en lui attribuant la valeur tabindex=“0”. En revanche, aucun comportement n’est attribué via la seule présence de tabindex. De même, la valeur tabindex=“-1” lorsqu’elle est utilisée sur un élément recevant naturellement le focus retire l’élément qui en est affecté du plan de tabulation en inhibant sa capacité à signaler la « prise de focus ». L’utilisation de tabindex, conformément à la spécification WAI-ARIA, peut valider certains tests relatifs à la gestion du focus de tabulation, notamment.

Note 2 : l’indication visuelle du focus du navigateur ne doit pas être pas supprimée ou dégradée sauf si un style du focus défini par l’auteur est visible et suffisamment contrasté au regard du critère 3.3.

Création « Pressé ou posé »

Raison de la création

Précisions visant à faciliter la compréhension technique des termes pressé ou posé

Nouvelle entrée

Pressé ou posé

Correspond aux gestionnaires d’événement JavaScript considérés comme des événements descendants (mousedown, touchstart par exemple).

Création « Raccourci clavier »

Raison de la création

Précision sur la nature d’un raccourci clavier et le cas des “Access keys”.

Nouvelle entrée

Raccourci clavier

Un moyen de déclencher une action associée à un composant de l’interface utilisateur en appuyant sur une ou plusieurs touches.

Note : les “Access keys” (attribut HTML accesskey) sont bien des raccourcis clavier, mais ils ne sont pas concernés par le critère 12.15 dans la mesure où leur activation nécessite déjà l’usage de touches de modification (variables suivant les navigateurs).

Création « Règles d’écriture »

Raison de la création

Précisions visant à faciliter la compréhension des règles techniques concernée

Nouvelle entrée

Règles d’écriture

Le code source doit respecter les règles suivantes en accord avec la déclaration de type de document utilisée dans la page :

  • Pas de balise ouvrante ou fermante sans < ou > (exemple d’erreur : li>`toto);
  • pas de balise fermante avec / manquant (exemple d’erreur : <li>toto<li>);
  • pas de valeur d’attribut avec des “ ou ‘ manquant (exemple d’erreur : alt=“toto);
  • pas de valeurs multiple d’attribut séparées par un espace sans “ ou ‘ (exemple d’erreur : alt=bonjour toto);
  • pas d’espace manquant entre les attributs (exemple : alt=”toto”title=”toto”);
  • pas de balise fermante manquante pour les éléments qui en exigent une (exemple d’erreur : <object> sans </object>).

Création « Relâché ou relevé »

Raison de la création

Précisions visant à faciliter la compréhension technique des termes relâché ou relevé.

Nouvelle entrée

Relâché ou relevé

Correspond aux gestionnaires d’événement JavaScript considérés comme des événements ascendants (mouseup, touchend par exemple).

Modification « Résumé »

Modification de la note pour permettre le test du résumé sur les sites utilisant HTML4 ou XHTML. Prise en charge des tableaux WAI-ARIA

Ancienne entrée

Résumé

Un résumé est un passage de texte associé à un tableau de données complexe. Il permet de donner des informations sur la nature et la structure du tableau afin d’en faciliter l’utilisation par les utilisateurs de technologies d’assistance par exemple.

Note : l’attribut summary est obsolète non conforme en HTML5 et ne doit plus être utilisé.

Parmi les 5 techniques proposées par HTML5, la seule technique utilisable actuellement est celle qui consiste à insérer le résumé directement dans le titre (balise <caption>) en masquant le résumé via CSS si nécessaire.

Consulter la note technique au sujet du résumé de tableau.

Nouvelle entrée

Résumé (de tableau)

Un résumé est un passage de texte associé à un tableau de données complexe. Il permet de donner des informations sur la nature et la structure du tableau afin d’en faciliter l’utilisation par les utilisateurs de technologies d’assistance par exemple.

Note : en HTML5, la seule technique utilisable actuellement est celle qui consiste à insérer le résumé directement dans le titre (balise <caption>) en masquant le résumé via CSS si nécessaire.

Dans les versions précédentes de HTML, le résumé peut être inséré via un attribut summary sur la balise <table>.

Dans le cas d’une balise avec l’attribut WAI-ARIA role=“table”, le résumé doit être fourni au moyen d’un attribut aria-describedby et être correctement restitué par les technologies d’assistance.

Modification « Systèmes de navigation »

Remplacement de « Table de contenu » par « Table des matières ».

Ancienne entrée

Tout procédé permettant une navigation dans le site ou dans une page, les systèmes de navigation retenus sont :

  • Menu de navigation principal;
  • Table de contenu;
  • Plan du site;
  • Moteur de recherche

Nouvelle entrée

Tout procédé permettant une navigation dans le site ou dans une page, les systèmes de navigation retenus sont :

  • Menu de navigation principal;
  • Table des matières;
  • Plan du site;
  • Moteur de recherche.

Modification « Tableau de données »

Prise en charge des tableaux WAI-ARIA

Ancienne entrée

Élément HTML (balise table) permettant de structurer des informations en lignes et en colonnes via des cellules de données (balise td) et des cellules d’en-têtes (balise th).

Nouvelle entrée

Un tableau de données est une structure introduite par une balise <table> ou lorsqu’il est correctement restitué par les technologies d’assistance par une balise pourvue d’un attribut WAI-ARIA role=“table”. Cette balise permet de structurer des informations en lignes et en colonnes via des cellules de données et des cellules d’en-têtes.

Création « Tableau de données ayant un titre »

Raison de la création

Prise en compte des attributs WAI-ARIA dans la thématique tableaux

Nouvelle entrée

Tableau de données ayant un attribut ou contenant une balise dont le contenu fait office de titre.

Tableau de données précédé ou suivi d’un passage de texte associé au tableau faisant office de titre.

Dans la mesure où il est bien correctement restitué et associé par les technologies d’assistance au tableau de données, le titre associé peut être :

  • Dans une balise <caption>;
  • Dans un attribut title;
  • Dans un attribut WAI-ARIA aria-label;
  • Dans une balise associée au tableau de données via un attribut WAI-ARIA aria-labelledby sur le tableau.

Note : seule la balise <caption> étant complètement supportée par l’ensemble des technologies d’assistance, il est fortement recommandé de privilégier cette solution lors de la mise en œuvre afin d’éviter de nombreuses vérifications dans les différentes combinaisons prévues par l’environnement de test (ou « base de référence »).

Modification « Tableau de données complexe »

Prise en charge des tableaux WAI-ARIA

Ancienne entrée

Lorsqu’un tableau de données contient des en-têtes qui ne sont pas répartis uniquement sur la première ligne et/ou la première colonne de la grille ou dont la portée n’est pas valable pour l’ensemble de la colonne ou de la ligne, on parle de tableau de données complexe. Il est alors nécessaire de fournir un « résumé » permettant d’en expliquer sa nature et sa structure afin d’en faciliter la consultation pour des utilisateurs de technologies d’assistance par exemple.

Nouvelle entrée

Un tableau de données est une structure introduite par une balise <table> ou lorsqu’il est correctement restitué par les technologies d’assistance par une balise pourvue d’un attribut WAI-ARIA role=“table”.

Lorsqu’un tableau de données contient des en-têtes qui ne sont pas répartis uniquement sur la première ligne et/ou la première colonne de la grille ou dont la portée n’est pas valable pour l’ensemble de la colonne ou de la ligne, on parle de tableau de données complexe. Il est alors nécessaire de fournir un « résumé » permettant d’en expliquer sa nature et sa structure afin d’en faciliter la consultation pour des utilisateurs de technologies d’assistance par exemple.

Modification « Taille de caractère »

Mise à jour suite à la suppression des tests 10.4.1 et 10.4.2 et à la mise à jour du test 10.4.3

Ancienne entrée

Taille de caractères

Valeur attribuée aux polices de caractères présentes sur une page web. Pour les contenus web, les tailles de caractères doivent être définies avec des unités relatives (%, em, rem, vw, vh, vmin ou vmax) ou des mots clés (xx-small, x-small, small, medium, large, x-large, xx-large, smaller, larger).

Note : l’utilisation du pixel (px) est proscrite.

Nouvelle entrée

Taille des caractères

Valeur attribuée aux polices de caractères présentes sur une page web.

Suppression « Texte caché »

Raison de la suppression

Suppression de l’entrée texte caché pour «Contenu caché»

Ancienne entrée

Les technologies d’assistance (notamment les lecteurs d’écran) ne restituent pas le texte masqué via les propriétés :

  • display avec la valeur none (display:none)
  • visibility avec la valeur hidden (visibility :hidden)
  • width et height avec les valeurs 0 (width:0;height:0)
  • font-size avec la valeur 0 (font-size:0)
  • Attribut HTML5 hidden
  • Propriété aria-hidden=“true”

Tous les contenus texte utilisant une ou plusieurs de ces propriétés sont applicables pour le critère 10.13.

Modification « Titre »

Modification de l’entrée pour :

  • supprimer la mention obligatoire d’un titre h1 dans une page
  • supprimer la note concernant les titres masqués suite à la suppression des tests 9.1.1 et 9.1.3.
  • Prendre en compte WAI-ARIA role heading

Ancienne entrée

Élément HTML (balise h) à 6 niveaux de hiérarchie (de h1 pour le titre le plus important à h6 pour le moins important) permettant de structurer l’information d’un contenu web.

La hiérarchie entre les titres doit être respectée dans une page web et les degrés de titre ne peuvent pas être sautés (un titre h3 ne peut pas venir directement après un titre h1, par exemple). Par contre, la hiérarchie ne doit pas obligatoirement débuter par un h1. Même si cet usage n’est pas encouragé, il est considéré comme conforme de débuter la hiérarchie des titres d’une page par un autre niveau que le niveau 1.

Dans chaque page web, il doit y avoir un titre h1, au moins.

Note : les titres cachés via CSS sont considérés comme présents et valident le critère 9.1.

Nouvelle entrée

Élément HTML (balise h) à 6 niveaux de hiérarchie (de h1 pour le titre le plus important à h6 pour le moins important) ou élément HTML ayant les attributs WAI-ARIA role=“heading” et aria-level permettant de structurer l’information d’un contenu web.

La hiérarchie entre les titres doit être respectée dans une page web et les degrés de titre ne peuvent pas être sautés (un titre h3 ne peut pas venir directement après un titre h1, par exemple). Par contre, la hiérarchie ne doit pas obligatoirement débuter par un h1. Même si cet usage n’est pas encouragé, il est considéré comme conforme de débuter la hiérarchie des titres d’une page par un autre niveau que le niveau 1.

Note : les titres cachés via CSS sont considérés comme présents et valident le critère 9.1.

Modification « titre de cadre »

Remplacement de l’expression redondante ARIA aria-hidden par attribut et précision sur l’applicabilité du test.

Ancienne entrée

Note 2 : Si cela ne gêne pas le fonctionnement de ce type de cadre, il est possible de les rendre indisponibles aux technologies d’assistance en utilisant une propriété ARIA aria-hidden=“true” par exemple.

Nouvelle entrée

Note 2 : Si cela ne gêne pas le fonctionnement de ce type de cadre, il est possible de les rendre indisponibles aux technologies d’assistance en utilisant l’attribut WAI-ARIA aria-hidden=“true”. Dans ce cas le critère 2.2 sera non applicable.

Suppression « Titre de lien »

Raison de la suppression

Suppression du critère 6.2 désormais traité via la nouvelle définition d’intitulé du lien dont la pertinence est vérifié dans le critère 6.1.

Ancienne entrée

Titre de lien

Contenu de l’attribut title d’un lien. Ce contenu ne doit être présent que s’il est nécessaire pour identifier la destination du lien de manière explicite. Un titre de lien doit reprendre l’intitulé de lien en y ajoutant des informations. Un titre de lien sera considéré comme non-pertinent dans les cas suivants :

  • Le titre de lien est vide;
  • Le titre de lien est identique à l’intitulé du lien (Cf. note 1);
  • Le titre de lien ne reprend pas l’intitulé du lien.

Note 1 : Par exception, un titre de lien identique à l’intitulé est accepté dans les seuls cas d’un lien image (lien ne contenant que des images), une icône par exemple, ou d’un lien dont le seul contenu visible est une image (lien composite dont le texte est visuellement caché).

Note 2 : Il est rappelé que l’attribut title peut poser de vrais problèmes de restitution, par exemple au clavier, sur les surfaces tactiles, lorsqu’une technologie d’assistance est paramétrée pour ne pas les restituer et ne devrait être utilisé qu’en dernier recours.

Création « Uniquement à des fins de présentation »

Raison de la création

Complément d’information sur la note 1 et remplacement de <blokquote role="presentation"> par <blockquote role="presentation">

Nouvelle entrée

Uniquement à des fins de présentation

Uniquement à des fins de présentation : utilisation de balises HTML pour une finalité différente de celle prévue dans les spécifications (au regard du type de document déclaré). Exemples : utilisation des balises h à seule fin de créer un effet typographique; utilisation de la balise <blockquote> à seule fin de mettre un paragraphe en retrait, etc.

Note 1 : l’utilisation d’éléments <div> ou <span> ou plusieurs <br> pour créer visuellement un paragraphe est considérée comme non conforme et invalide le critère.

Exemple :

<div>

paragraphes d’un bloc de texte simulés

<br>

<br>

à l’aide de plusieurs balises <br>

</div>

Note 2 : WAI-ARIA propose un rôle presentation permettant de supprimer la sémantique d’un élément, par exemple <h1 role="presentation">Titre</h1>. Dans ce cas, le texte sera correctement restitué mais son rôle de titre ne le sera plus. L’utilisation du rôle presentation peut être requise lorsque l’on utilise un motif de conception WAI-ARIA.

Le rôle WAI-ARIA presentation peut être également utilisé pour supprimer la sémantique d’un élément lorsque ce dernier est utilisé uniquement à des fins de présentation, par exemple <blockquote role="presentation"> aura le même effet qu’une absence d’élément <blockquote>.

Même si cette utilisation est fortement déconseillée (dans le cas de technologie d’assistance qui n’implémenteraient pas WAI-ARIA par exemple) elle peut être considérée comme conforme à WCAG. En revanche l’utilisation d’un rôle WAI-ARIA presentation sur un élément dont la nature (par exemple la sémantique) est essentielle à la compréhension du contenu est une violation des règles WCAG (particulièrement de l’échec F92) et invalide le critère.