RAWeb 1: Critères et tests

Avertissement : Pour chaque critère du référentiel, une méthodologie d’évaluation est proposée. Néanmoins, cette méthodologie n’a pas de valeur normative, c’est-à-dire qu’elle n’est fournie qu’à titre d’aide à la prise en main du référentiel, en donnant un exemple d’une méthode possible d’évaluation mais il peut exister d’autres méthodes d’évaluation. De plus, le contenu de cette méthodologie ainsi que ces étapes ne peuvent pas constituer une base opposable en cas de contestation. Enfin, il est possible que des erreurs ne soient pas détectées sur la seule base de cette méthodologie. Seuls le contenu du critère et les tests associés ont une valeur normative.

Thématique 1 : Images

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

Tests du critère 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 ?
Méthodologie du test 1.1.1
  1. Retrouver dans le document les images structurées au moyen d’un élément <img> ou d’un élément possédant l’attribut WAI-ARIA role="img".
  2. Pour chaque image, déterminer si l’image est porteuse d’information.
  3. Dans le cas où il s’agit d’un élément <img>, vérifier que l’image est pourvue au moins d’une alternative textuelle parmi les suivantes :
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label ;
    • contenu de l’attribut alt ;
    • contenu de l’attribut title.
  4. Dans le cas où il s’agit d’un élément possédant l’attribut WAI-ARIA role="img", vérifier que l’image est pourvue au moins d’une alternative textuelle parmi les suivantes :
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label.
  5. Si au moins une alternative textuelle est trouvée, le test est validé.
Test 1.1.2 Chaque zone d’une image réactive (balise <area>) porteuse d’information a-t-elle une alternative textuelle ?
Méthodologie du test 1.1.2
  1. Retrouver dans le document les éléments <area>.
  2. Pour chaque élément <area>, déterminer si la zone réactive est porteuse d’information.
  3. Vérifier que la zone réactive est pourvue au moins d’une alternative textuelle parmi les suivantes :
    • contenu de l’attribut WAI-ARIA aria-label ;
    • contenu de l’attribut alt ;
  4. Si au moins une alternative textuelle est trouvée, le test est validé.
Test 1.1.3 Chaque bouton de type image (balise <input> avec l’attribut type="image") a-t-il une alternative textuelle ?
Méthodologie du test 1.1.3
  1. Retrouver dans le document les éléments <input> pourvus de l’attribut type="image".
  2. Pour chaque élément <input> pourvu de l’attribut type="image", déterminer si l’image utilisée est porteuse d’information.
  3. Vérifier que l’élément <input> est pourvu au moins d’une alternative textuelle parmi les suivantes :
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label ;
    • contenu de l’attribut alt ;
    • contenu de l’attribut title.
  4. Si au moins une alternative textuelle est trouvée, le test est validé.
Test 1.1.4 Chaque zone cliquable d’une image réactive côté serveur est-elle doublée d’un mécanisme utilisable quel que soit le dispositif de pointage utilisé et permettant d’accéder à la même destination ?
Méthodologie du test 1.1.4
  1. Retrouver dans le document les éléments <img> pourvus de l’attribut ismap.
  2. Pour chaque élément <img> pourvu de l’attribut ismap, vérifier la présence d’un lien ou d’un ensemble de liens (ou bien d’un autre type de composant d’interface qui jouerait un rôle similaire comme une liste de sélection, par exemple) permettant d’accéder aux mêmes ressources que lorsque l’image fait l’objet d’un clic.
  3. Si c’est le cas, le test est validé.
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.
Méthodologie du test 1.1.5
  1. Retrouver dans le document les éléments <svg>.
  2. Pour chaque élément <svg>, déterminer si l’image est porteuse d’information.
  3. S’assurer que l’élément <svg> est pourvu d’un attribut WAI-ARIA role="img".
  4. Si ce n’est pas le cas, le test est invalidé.
  5. Le cas échéant, vérifier que l’élément <svg> est pourvu au moins d’une alternative textuelle parmi les suivantes :
    • contenu de l’élément <title> ;
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label ;
  6. Si au moins une alternative textuelle est trouvée, le test est validé.
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 ?
Méthodologie du test 1.1.6
  1. Retrouver dans le document les balises ouvrantes <object> pourvues de l’attribut type="image/…".
  2. Pour chaque balise ouvrante <object> pourvue de l’attribut type="image/…", déterminer si l’image utilisée est porteuse d’information.
  3. Vérifier que l’élément <object> est pourvu d’un attribut WAI-ARIA role="img".
  4. Vérifier que l’élément <object> est pourvu au moins d’une alternative textuelle parmi les suivantes :
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label ;
    • contenu de l’attribut title.
  5. Si au moins une alternative textuelle est trouvée, le test est validé.
  6. Sinon, vérifier que l’élément <object> est :
    • soit immédiatement suivi d’un lien ou bouton adjacent permettant d’accéder à un contenu alternatif ;
    • soit un mécanisme permet à l’utilisateur de remplacer l’élément <object> par un contenu alternatif.
  7. Si c’est le cas, le test est validé.
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 ?
Méthodologie du test 1.1.7
  1. Pour chaque élément <embed> pourvu de l’attribut type="image/…", déterminer si l’image utilisée est porteuse d’information.
  2. Vérifier que l’élément <embed> est pourvu d’un attribut WAI-ARIA role="img".
  3. Vérifier que l’élément <embed> est pourvu au moins d’une alternative textuelle parmi les suivantes :
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label ;
    • contenu de l’attribut title.
  4. Si au moins une alternative textuelle est trouvée, le test est validé.
  5. Sinon, vérifier que l’élément <embed> est :
    • soit immédiatement suivi d’un lien ou bouton adjacent permettant d’accéder à un contenu alternatif ;
    • soit un mécanisme permet à l’utilisateur de remplacer l’élément <embed> par un contenu alternatif.
  6. Si c’est le cas, le test est validé.
Test 1.1.8 Chaque image bitmap (balise <canvas>) porteuse d’information, vérifie-t-elle une de ces conditions ?
Méthodologie du test 1.1.8
  1. Retrouver dans le document les éléments <canvas>.
  2. Pour chaque élément <canvas>, déterminer si l’image utilisée est porteuse d’information.
  3. Vérifier que l’élément <canvas> est pourvu d’un attribut WAI-ARIA role="img".
  4. Vérifier que la balise ouvrante <canvas> est pourvue au moins d’une alternative textuelle parmi les suivantes :
    • passage de texte associé via l’attribut WAI-ARIA aria-labelledby ;
    • contenu de l’attribut WAI-ARIA aria-label.
  5. Si au moins une alternative textuelle est trouvée, le test est validé.
  6. Si les étapes 3 et 4 ne sont pas satisfaites, vérifier que l’élément <canvas> est :
    • soit pourvu d’un contenu alternatif présent entre les balises <canvas> et </canvas> ;
    • soit immédiatement suivi d’un lien ou bouton adjacent permettant d’accéder à un contenu alternatif ;
    • soit un mécanisme permet à l’utilisateur de remplacer l’élément <canvas> par un contenu alternatif.
  7. Si c’est le cas, le test est validé.

Note : si l’élément <canvas> dispose d’un rôle img, son alternative ne peut être fournie que par les techniques listées à l’étape 4.

Correspondances

Critère 1.2 [A] : Chaque image de décoration est-elle correctement ignorée par les technologies d’assistance ?

Tests du critère 1.2

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".
Méthodologie du test 1.2.1
  1. Retrouver dans le document les images décoratives dépourvues de légende structurées au moyen d’un élément <img>.
  2. Pour chaque image, vérifier que l’image ne possède pas d’attributs aria-labelledby, aria-label ou title et qu’elle possède :
    • soit un attribut alt vide (alt="") ;
    • soit un attribut WAI-ARIA aria-hidden="true" ou role="presentation".
  3. Si c’est le cas pour chaque image, le test est validé.
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".
Méthodologie du test 1.2.2
  1. Retrouver dans le document les images décoratives structurées au moyen d’un élément <area> (sans attribut href).
  2. Pour chaque image, vérifier que l’élément <area> ne possède pas d’attributs aria-labelledby, aria-label ou title et qu’il possède :
    • soit un attribut alt vide (alt="") ;
    • soit un attribut WAI-ARIA aria-hidden="true" ou role="presentation".
  3. Si c’est le cas pour chaque image, le test est validé.
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 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>.
Méthodologie du test 1.2.3
  1. Retrouver dans le document les images décoratives structurées dépourvues de légende au moyen d’un élément <object> (avec un attribut type="image/…").
  2. Pour chaque image, vérifier que la balise ouvrante <object> ne possède pas d’attributs aria-labelledby, aria-label ou title et qu’elle :
    • possède un attribut WAI-ARIA aria-hidden="true" ;
    • et est dépourvue d’alternative textuelle ;
    • et est dépourvue d’un contenu alternatif présent entre les balises <object> et </object>.
  3. Si c’est le cas pour chaque image, le test est validé.
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 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.
Méthodologie du test 1.2.4
  1. Retrouver dans le document les images décoratives dépourvues de légende structurées au moyen d’un élément <svg>.
  2. Pour chaque image, vérifier que l’élément <svg> ne possède pas d’attributs aria-labelledby ou aria-label et qu’il :
    • possède un attribut WAI-ARIA aria-hidden="true" ;
    • et est dépourvu d’alternative textuelle (ainsi que ses éléments enfants) ;
    • et ne contient pas d’éléments <title> et <desc> à moins que vides de contenu ;
    • et est dépourvu d’attribut title (ainsi que ses éléments enfants).
  3. Si c’est le cas pour chaque image, le test est validé.
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 WAI-ARIA aria-hidden="true".
  • La balise <canvas> et ses enfants sont dépourvus d’alternative textuelle.
  • Il n’y a aucun texte faisant office d’alternative textuelle entre <canvas> et </canvas>.
Méthodologie du test 1.2.5
  1. Retrouver dans le document les images décoratives dépourvues de légende structurées au moyen d’un élément <canvas>.
  2. Pour chaque image, vérifier que l’élément <canvas> ne possède pas d’attributs aria-labelledby, aria-label ou title et qu’il :
    • possède un attribut WAI-ARIA aria-hidden="true" ;
    • et est dépourvu d’alternative textuelle ;
    • et est dépourvu d’un contenu alternatif présent entre les balises <canvas> et </canvas>.
  3. Si c’est le cas pour chaque image, le test est validé.
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 WAI-ARIA aria-hidden="true".
  • La balise <embed> et ses enfants sont dépourvus d’alternative textuelle.
Méthodologie du test 1.2.6
  1. Retrouver dans le document les images décoratives dépourvues de légende structurées au moyen d’un élément <embed> (avec un attribut type="image/…").
  2. Pour chaque image, vérifier que l’élément <embed> ne possède pas d’attributs aria-labelledby, aria-label ou title et qu’il :
    • possède un attribut WAI-ARIA aria-hidden="true" ;
    • et est dépourvu d’alternative textuelle ;
  3. Si c’est le cas pour chaque image, le test est validé.
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 à l’élément <svg> associé par le biais de l’élément <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".

Correspondances

Critère 1.3 [A] : Pour chaque image porteuse d’information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ?

Tests du critère 1.3

Test 1.3.1 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.
Méthodologie du test 1.3.1
  1. Retrouver dans le document les images structurées au moyen d’un élément <img> (ou d’un élément possédant l’attribut WAI-ARIA role="img") pourvues d’une alternative textuelle.
  2. Pour chaque image, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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.
Méthodologie du test 1.3.2
  1. Retrouver dans le document les éléments <area> pourvus d’une alternative textuelle.
  2. Pour chaque élément <area>, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.3.3 Pour chaque 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.
Méthodologie du test 1.3.3
  1. Retrouver dans le document les éléments <input> pourvus de l’attribut type="image" et d’une alternative textuelle.
  2. Pour chaque élément <input> pourvu de l’attribut type="image", vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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.
Méthodologie du test 1.3.4
  1. Retrouver dans le document les éléments <object> pourvus de l’attribut type="image/…" et d’une alternative textuelle.
  2. Pour chaque élément <object> pourvu de l’attribut type="image/…", vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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.
Méthodologie du test 1.3.5
  1. Retrouver dans le document les éléments <embed> pourvus de l’attribut type="image/…" et d’une alternative textuelle.
  2. Pour chaque élément <embed> pourvu de l’attribut type="image/…", vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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’élément <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.
Méthodologie du test 1.3.6
  1. Retrouver dans le document les éléments <svg> pourvus d’une alternative textuelle.
  2. Pour chaque élément <svg>, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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.
Méthodologie du test 1.3.7
  1. Retrouver dans le document les éléments <canvas> pourvus d’une alternative textuelle.
  2. Pour chaque élément <canvas>, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.3.8 Pour chaque image bitmap (balise <canvas>) porteuse d’information et ayant un contenu alternatif entre <canvas> et </canvas>, ce contenu alternatif est-il correctement restitué par les technologies d’assistance ?
Méthodologie du test 1.3.8
  1. Retrouver dans le document les éléments <canvas> pourvus d’un contenu alternatif entre les balises <canvas> et </canvas>.
  2. Pour chaque élément <canvas>, vérifier que le contenu alternatif est correctement restitué par les technologies d’assistance.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.3.9 Pour chaque image porteuse d’information et ayant une alternative textuelle, l’alternative textuelle est-elle courte et concise (hors cas particuliers) ?
Méthodologie du test 1.3.9
  1. Retrouver dans le document les images pourvues d’une alternative textuelle.
  2. Pour chaque image, vérifier l’alternative textuelle est courte et concise.
  3. Si c’est le cas pour chaque image, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers lorsque l’image est utilisée comme CAPTCHA ou comme image-test. Dans cette situation, où il n’est pas possible de donner une alternative pertinente sans détruire l’objet du CAPTCHA ou du test, le critère est non applicable.

Note : le cas des CAPTCHA et des images-test est traité de manière spécifique par le critère 1.4.

Correspondances

Critère 1.4 [A] : Pour chaque image utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative permet-elle d’identifier la nature et la fonction de l’image ?

Tests du critère 1.4

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.
Méthodologie du test 1.4.1
  1. Retrouver dans le document les images structurées au moyen d’un élément <img> pourvues d’une alternative textuelle et utilisées comme CAPTCHA ou comme image-test.
  2. Pour chaque image, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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.
Méthodologie du test 1.4.2
  1. Retrouver dans le document les éléments <area> pourvus d’une alternative textuelle et utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque élément <area>, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.4.3 Pour chaque bouton de type image (balise <input> avec l’attribut type="image") utilisé 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.
Méthodologie du test 1.4.3
  1. Retrouver dans le document les éléments <input> pourvus de l’attribut type="image" et d’une alternative textuelle, et utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque élément <input> pourvu de l’attribut type="image", vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
  • 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.
Méthodologie du test 1.4.4
  1. Retrouver dans le document les éléments <object> pourvus de l’attribut type="image/…" et d’une alternative textuelle, et utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque élément <object> pourvu de l’attribut type="image/…", vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
  • 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.
Méthodologie du test 1.4.5
  1. Retrouver dans le document les éléments <embed> pourvus de l’attribut type="image/…" et d’une alternative textuelle, et utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque élément <embed> pourvu de l’attribut type="image/…", vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
  • 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.
Méthodologie du test 1.4.6
  1. Retrouver dans le document les éléments <svg> pourvus d’une alternative textuelle et utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque élément <svg>, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
  • 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.
Méthodologie du test 1.4.7
  1. Retrouver dans le document les éléments <canvas> pourvus d’une alternative textuelle et utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque élément <canvas>, vérifier que l’alternative textuelle est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Correspondances

Critère 1.5 [A] : Pour chaque image utilisée comme CAPTCHA, une solution d’accès alternatif au contenu ou à la fonction du CAPTCHA est-elle présente ?

Tests du critère 1.5

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.
Méthodologie du test 1.5.1
  1. Retrouver dans le document les images (éléments <img>, <area>, <object>, <embed>, <svg>, <canvas> ou possédant un attribut WAI-ARIA role="img") utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque image, vérifier qu’il existe :
    • soit une autre forme de CAPTCHA non graphique, au moins ;
    • soit une autre solution d’accès à la fonctionnalité qui est sécurisée par le CAPTCHA.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.5.2 Chaque bouton associé à une image (balise input avec l’attribut type="image") utilisée comme CAPTCHA vérifie-t-il 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.
Méthodologie du test 1.5.2
  1. Retrouver dans le document les boutons associés à une image (éléments <input> avec l’attribut type="image") utilisés comme CAPTCHA ou comme image-test.
  2. Pour chaque bouton associé à une image, vérifier qu’il existe :
    • soit une autre forme de CAPTCHA non graphique, au moins ;
    • soit une autre solution d’accès à la fonctionnalité qui est sécurisée par le CAPTCHA.
  3. Si c’est le cas pour chaque image, le test est validé.
Correspondances

Critère 1.6 [A] : Chaque image porteuse d’information a-t-elle, si nécessaire, une description détaillée ?

Tests du critère 1.6

Test 1.6.1 Chaque image (balise <img>) porteuse d’information, qui nécessite une description détaillée, vérifie-t-elle une de ces conditions ?
Méthodologie du test 1.6.1
  1. Retrouver dans le document les images structurées au moyen d’un élément <img> (ou d’un élément possédant l’attribut WAI-ARIA role="img") porteuses d’information qui nécessitent une description détaillée.
  2. Pour chaque image, vérifier qu’il existe :
    • Soit une alternative textuelle contenant la référence à une description détaillée adjacente à l’image ;
    • Soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
Méthodologie du test 1.6.2
  1. Retrouver dans le document les éléments <object> pourvus de l’attribut type="image/…", porteurs d’information qui nécessitent une description détaillée.
  2. Pour chaque élément <object> pourvu de l’attribut type="image/…", vérifier qu’il existe :
    • soit une alternative textuelle contenant la référence à une description détaillée adjacente à l’image ;
    • soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée.
  3. Si c’est le cas pour chaque élément <object> pourvu de l’attribut type="image/…", le test est validé.
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 ?
Méthodologie du test 1.6.3
  1. Retrouver dans le document les éléments <embed> pourvus de l’attribut type="image/…", porteurs d’information qui nécessitent une description détaillée.
  2. Pour chaque élément <embed> pourvu de l’attribut type="image/…", vérifier qu’il existe :
    • soit une alternative textuelle contenant la référence à une description détaillée adjacente à l’image ;
    • soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée.
  3. Si c’est le cas pour chaque élément <embed> pourvu de l’attribut type="image/…", le test est validé.
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 ?
Méthodologie du test 1.6.4
  1. Retrouver dans le document les éléments <input> pourvus de l’attribut type="image", porteurs d’information qui nécessitent une description détaillée.
  2. Pour chaque élément <input> pourvu de l’attribut type="image", vérifier qu’il existe :
    • soit une alternative textuelle contenant la référence à une description détaillée adjacente à l’image ;
    • soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée ;
    • soit un attribut WAI-ARIA aria-describedby associant un passage de texte faisant office de description détaillée.
  3. Si c’est le cas pour chaque élément <input> pourvu de l’attribut type="image", le test est validé.
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 ?
Méthodologie du test 1.6.5
  1. Retrouver dans le document les éléments <svg> porteurs d’information qui nécessitent une description détaillée.
  2. Pour chaque élément <svg>, vérifier qu’il existe :
    • soit un attribut WAI-ARIA aria-label contenant l’alternative textuelle et une référence à une description détaillée adjacente ;
    • soit 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 ;
    • soit un attribut WAI-ARIA aria-describedby associant un passage de texte faisant office de description détaillée ;
    • soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée.
  3. Si c’est le cas pour chaque élément <svg>, le test est validé.
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 ?
Méthodologie du test 1.6.6
  1. Retrouver dans le document les éléments <svg> porteurs d’information dont la description détaillée est fournie au moyen d’un attribut aria-label, aria-labelledby ou aria-describedby.
  2. Pour chaque élément <svg>, vérifier que le contenu de la description détaillée est correctement restitué par les technologies d’assistance.
  3. Si c’est le cas pour chaque élément <svg>, le test est validé.
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 ?
Méthodologie du test 1.6.7
  1. Retrouver dans le document les éléments <canvas> porteurs d’information qui nécessitent une description détaillée.
  2. Pour chaque élément <canvas>, vérifier qu’il existe :
    • soit un attribut WAI-ARIA aria-label contenant l’alternative textuelle et une référence à une description détaillée adjacente ;
    • soit 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 ;
    • soit un contenu textuel entre <canvas> et </canvas> faisant référence à une description détaillée adjacente à l’image bitmap ;
    • soit un contenu textuel entre <canvas> et </canvas> faisant office de description détaillée ;
    • soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée.
  3. Si c’est le cas pour chaque élément <canvas>, le test est validé.
Test 1.6.8 Pour chaque image bitmap (balise <canvas>) porteuse d’information, qui implémente une référence à une description détaillée adjacente, cette référence est-elle correctement restituée par les technologies d’assistance ?
Méthodologie du test 1.6.8
  1. Retrouver dans le document les éléments <canvas> porteurs d’information dont la description détaillée est fournie au moyen d’un attribut aria-label, aria-labelledby ou aria-describedby.
  2. Pour chaque élément <canvas>, vérifier que le contenu de la description détaillée est correctement restitué par les technologies d’assistance.
  3. Si c’est le cas pour chaque élément <canvas>, le test est validé.
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 ?
Méthodologie du test 1.6.9
  1. Retrouver dans le document les images (éléments <img>, <input> avec l’attribut type="image", <area>, <object>, <embed>, <svg>, <canvas> ou possédant un attribut WAI-ARIA role="img") porteuses d’information dont la description détaillée utilise un attribut WAI-ARIA aria-describedby.
  2. Pour chaque image, vérifier que le contenu de la description détaillée est correctement restitué par les technologies d’assistance.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
Méthodologie du test 1.6.10
  1. Retrouver dans le document les éléments pourvus d’un attribut WAI-ARIA role="img" porteurs d’information qui nécessitent une description détaillée.
  2. Pour chaque élément role="img", vérifier qu’il existe :
    • soit un attribut WAI-ARIA aria-label contenant l’alternative textuelle et une référence à une description détaillée adjacente ;
    • soit 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 ;
    • soit un attribut WAI-ARIA aria-describedby associant un passage de texte faisant office de description détaillée ;
    • soit un lien ou un bouton adjacent permettant d’accéder à la description détaillée.
  3. Si c’est le cas pour chaque élément role="img", le test est validé.
Notes techniques

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 à la 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 recommandée pour lier une image (<img>, <object>, <embed>, <canvas>) à sa description détaillée, par manque de support des technologies d’assistance. Néanmoins, lorsqu’il est utilisé, l’attribut devra nécessairement faire référence à l’id de la zone contenant la description détaillée.

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).

Correspondances

Critère 1.7 [A] : Pour chaque image porteuse d’information ayant une description détaillée, cette description est-elle pertinente ?

Tests du critère 1.7

Test 1.7.1 Chaque image (balise <img>) porteuse d’information, ayant une description détaillée, vérifie-t-elle ces conditions ?
Méthodologie du test 1.7.1
  1. Retrouver dans le document les images structurées au moyen d’un élément <img> qui possèdent une description détaillée.
  2. Pour chaque image, vérifier que la description détaillée est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
Méthodologie du test 1.7.2
  1. Retrouver dans le document les éléments <input> pourvus de l’attribut type="image" qui possèdent une description détaillée.
  2. Pour chaque élément <input> pourvu de l’attribut type="image", vérifier que la description détaillée est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
Méthodologie du test 1.7.3
  1. Retrouver dans le document les éléments <object> pourvus de l’attribut type="image/…" qui possèdent une description détaillée.
  2. Pour chaque élément <object> pourvu de l’attribut type="image/…", vérifier que la description détaillée est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
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 ?
Méthodologie du test 1.7.4
  1. Retrouver dans le document les éléments <embed> pourvus de l’attribut type="image/…" qui possèdent une description détaillée.
  2. Pour chaque élément <embed> pourvu de l’attribut type="image/…", vérifier que la description détaillée est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.7.5 Chaque image vectorielle (balise <svg>) porteuse d’information, ayant une description détaillée, vérifie-t-elle ces conditions ?
Méthodologie du test 1.7.5
  1. Retrouver dans le document les éléments <svg> qui possèdent une description détaillée.
  2. Pour chaque élément <svg>, vérifier que la description détaillée est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.7.6 Chaque image bitmap (balise <canvas>) porteuse d’information, ayant une description détaillée, vérifie-t-elle ces conditions ?
Méthodologie du test 1.7.6
  1. Retrouver dans le document les éléments <canvas> qui possèdent une description détaillée.
  2. Pour chaque élément <canvas>, vérifier que la description détaillée est pertinente.
  3. Si c’est le cas pour chaque image, le test est validé.
Correspondances

Critère 1.8 [AA] : Chaque image texte 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) ?

Tests du critère 1.8

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) ?
Méthodologie du test 1.8.1
  1. Retrouver dans le document les images texte structurées au moyen d’un élément <img> (ou d’un élément possédant l’attribut WAI-ARIA role="img").
  2. Pour chaque image, vérifier que :
    • soit il existe un mécanisme de remplacement ;
    • soit l’image contient un texte qui fait appel à un effet graphique qui ne peut pas être reproduit en CSS.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.8.2 Chaque bouton « image texte » (balise <input> avec l’attribut type="image") porteur 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) ?
Méthodologie du test 1.8.2
  1. Retrouver dans le document les boutons “images texte” (élément <input> avec l’attribut type="image").
  2. Pour chaque image, vérifier que :
    • soit il existe un mécanisme de remplacement ;
    • soit l’image contient un texte qui fait appel à un effet graphique qui ne peut pas être reproduit en CSS.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.8.3 Chaque image texte objet (balise <object> avec l’attribut type="image/…") 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) ?
Méthodologie du test 1.8.3
  1. Retrouver dans le document les images texte objet (élément <object> avec l’attribut type="image/…").
  2. Pour chaque image, vérifier que :
    • soit il existe un mécanisme de remplacement ;
    • soit l’image contient un texte qui fait appel à un effet graphique qui ne peut pas être reproduit en CSS.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.8.4 Chaque image texte embarquée (balise <embed> avec l’attribut type="image/…") 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) ?
Méthodologie du test 1.8.4
  1. Retrouver dans le document les images texte embarquées (élément <embed> avec l’attribut type="image/…").
  2. Pour chaque image, vérifier que :
    • Soit il existe un mécanisme de remplacement ;
    • Soit l’image contient un texte qui fait appel à un effet graphique qui ne peut pas être reproduit en CSS.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.8.5 Chaque image texte bitmap (balise <canvas>) 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) ?
Méthodologie du test 1.8.5
  1. Retrouver dans le document les images texte bitmap (élément <canvas>).
  2. Pour chaque image, vérifier que :
    • soit il existe un mécanisme de remplacement ;
    • soit l’image contient un texte qui fait appel à un effet graphique qui ne peut pas être reproduit en CSS.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.8.6 Chaque image texte SVG (balise <svg>) porteuse d’information et dont le texte n’est pas complètement structuré au moyen d’éléments <text>, 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) ?
Méthodologie du test 1.8.6
  1. Retrouver dans le document les images texte vectorielle (élément <svg>) porteuse d’information et dont le texte n’est pas complètement structuré au moyen d’éléments <text>.
  2. Pour chaque image, vérifier que :
    • soit il existe un mécanisme de remplacement ;
    • soit l’image contient un texte qui fait appel à un effet graphique qui ne peut pas être reproduit en CSS.
  3. Si c’est le cas pour chaque image, le test est validé.
Cas particuliers

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.

Notes techniques

Le texte dans les images vectorielles étant du texte réel, il n’est pas concerné par ce critère.

Correspondances

Critère 1.9 [A] : Chaque légende d’image est-elle, si nécessaire, correctement reliée à l’image correspondante ?

Tests du critère 1.9

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), 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>.
Méthodologie du test 1.9.1
  1. Retrouver dans le document les images pourvues d’une légende structurées au moyen d’élément <img>, d’un élément <input> avec l’attribut type="image" ou d’un élément possédant l’attribut WAI-ARIA role="img".
  2. Pour chaque image, vérifier que :
    • l’image et sa légende sont contenues dans une balise <figure> ;
    • la balise <figure> possède une propriété 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>.
  3. Si c’est le cas pour chaque image, le test est validé.
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), vérifie-t-elle, si nécessaire, ces conditions ?
  • L’image objet 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>.
Méthodologie du test 1.9.2
  1. Retrouver dans le document les images objet pourvues d’une légende (élément <object> avec l’attribut type="image/…").
  2. Pour chaque image, vérifier que :
    • l’image et sa légende sont contenues dans une balise <figure> ;
    • la balise <figure> possède une propriété 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>.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.9.3 Chaque image embarquée pourvue d’une légende (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 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>.
Méthodologie du test 1.9.3
  1. Retrouver dans le document les images embarquées pourvues d’une légende (élément <embed> avec l’attribut type="image/…").
  2. Pour chaque image, vérifier que :
    • l’image et sa légende sont contenues dans une balise <figure> ;
    • la balise <figure> possède une propriété 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>.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.9.4 Chaque image vectorielle pourvue d’une légende (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 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>.
Méthodologie du test 1.9.4
  1. Retrouver dans le document les images vectorielles pourvues d’une légende (élément <svg>).
  2. Pour chaque image, vérifier que :
    • l’image et sa légende sont contenues dans une balise <figure> ;
    • la balise <figure> possède une propriété 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>.
  3. Si c’est le cas pour chaque image, le test est validé.
Test 1.9.5 Chaque image bitmap pourvue d’une légende (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 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>.
Méthodologie du test 1.9.5
  1. Retrouver dans le document les images bitmap (élément <canvas>).
  2. Pour chaque image, vérifier que :
    • l’image et sa légende sont contenues dans une balise <figure> ;
    • la balise <figure> possède une propriété 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>.
  3. Si c’est le cas pour chaque image, le test est validé.
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 WAI-ARIA 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.1 et le critère 1.3 relatifs aux images porteuses d’information.

Correspondances

Thématique 2 : Cadres

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

Tests du critère 2.1

Test 2.1.1 Chaque cadre (balise <iframe> ou <frame>) a-t-il un attribut title ?
Méthodologie du test 2.1.1
  1. Retrouver dans le document les cadres (élément <iframe> ou <frame>).
  2. Pour chaque cadre, vérifier qu’il possède un attribut title .
  3. Si c’est le cas pour chaque cadre, le test est validé.
Correspondances

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

Tests du critère 2.2

Test 2.2.1 Pour chaque cadre (balise <iframe> ou <frame>) ayant un attribut title, le contenu de cet attribut est-il pertinent ?
Méthodologie du test 2.2.1
  1. Retrouver dans le document les cadres (élément <iframe> ou <frame>).
  2. Pour chaque cadre pourvu d’un attribut title, vérifier que son contenu est pertinent.
  3. Si c’est le cas pour chaque cadre, le test est validé.
Correspondances

Thématique 3 : Couleurs

Critère 3.1 [A] : Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?

Tests du critère 3.1

Test 3.1.1 Pour chaque mot ou ensemble de mots dont la mise en couleur est porteuse d’information, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 3.1.1
  1. Retrouver dans le document les informations données par la couleur dans un mot ou un ensemble de mots.
  2. Pour chacune de ces informations, vérifier qu’il existe un autre moyen de récupérer cette information (présence d’un attribut title, d’une icône ou d’un effet graphique de forme ou de position, un effet typographique…).
  3. Si c’est le cas pour chaque information, le test est validé.
Test 3.1.2 Pour chaque indication de couleur donnée par un texte, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 3.1.2
  1. Retrouver dans le document les informations données par la couleur dans un texte.
  2. Pour chacune de ces informations, vérifier qu’il existe un autre moyen de récupérer cette information (présence d’un attribut title, d’une icône ou d’un effet graphique de forme ou de position, un effet typographique…).
  3. Si c’est le cas pour chaque information, le test est validé.
Test 3.1.3 Pour chaque image véhiculant une information, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 3.1.3
  1. Retrouver dans le document les informations données par la couleur dans une image.
  2. Pour chacune de ces informations, vérifier qu’il existe un autre moyen de récupérer cette information (présence d’un attribut title, d’une icône ou d’un effet graphique de forme ou de position, un effet typographique…).
  3. Si c’est le cas pour chaque information, le test est validé.
Test 3.1.4 Pour chaque propriété CSS déterminant une couleur et véhiculant une information, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 3.1.4
  1. Retrouver dans le document les informations données par la couleur dans une propriété CSS.
  2. Pour chacune de ces informations, vérifier qu’il existe un autre moyen de récupérer cette information (présence d’un attribut title, d’une icône ou d’un effet graphique de forme ou de position, un effet typographique…).
  3. Si c’est le cas pour chaque information, le test est validé.
Test 3.1.5 Pour chaque média temporel véhiculant une information, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 3.1.5
  1. Retrouver dans le document les informations données par la couleur dans un média temporel.
  2. Pour chacune de ces informations, vérifier qu’il existe un autre moyen de récupérer cette information (présence d’un attribut title, d’une icône ou d’un effet graphique de forme ou de position, un effet typographique…).
  3. Si c’est le cas pour chaque information, le test est validé.
Test 3.1.6 Pour chaque média non temporel véhiculant une information, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 3.1.6
  1. Retrouver dans le document les informations données par la couleur dans un média non temporel.
  2. Pour chacune de ces informations, vérifier qu’il existe un autre moyen de récupérer cette information (présence d’un attribut title, d’une icône ou d’un effet graphique de forme ou de position, un effet typographique…).
  3. Si c’est le cas pour chaque information, le test est validé.
Correspondances

Critère 3.2 [AA] : Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ?

Tests du critère 3.2

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.
Méthodologie du test 3.2.1
  1. Retrouver dans le document les textes et les textes en image sans effet de graisse d’une taille restituée inférieure à 24px qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces textes, vérifier que :
    • soit le rapport de contraste entre le texte et son arrière-plan est de 4.5:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher le texte avec un rapport de contraste de 4.5:1, au moins.
  3. Si c’est le cas pour chaque texte, le test est validé.
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.
Méthodologie du test 3.2.2
  1. Retrouver dans le document les textes et les textes en image en gras d’une taille restituée inférieure à 18,5px qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces textes, vérifier que :
    • soit le rapport de contraste entre le texte et son arrière-plan est de 4.5:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher le texte avec un rapport de contraste de 4.5:1, au moins.
  3. Si c’est le cas pour chaque texte, le test est validé.
Test 3.2.3 Dans chaque page web, le texte et le texte en image sans effet de graisse d’une 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.
Méthodologie du test 3.2.3
  1. Retrouver dans le document les textes et les textes en image sans effet de graisse d’une taille restituée supérieure ou égale à 24px qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces textes, vérifier que :
    • soit le rapport de contraste entre le texte et son arrière-plan est de 3:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher le texte avec un rapport de contraste de 3:1, au moins.
  3. Si c’est le cas pour chaque texte, le test est validé.
Test 3.2.4 Dans chaque page web, le texte et le texte en image en gras d’une 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.
Méthodologie du test 3.2.4
  1. Retrouver dans le document les textes et les textes en image en gras d’une taille restituée supérieure ou égale à 18,5px qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces textes, vérifier que :
    • soit le rapport de contraste entre le texte et son arrière-plan est de 3:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher le texte avec un rapport de contraste de 3:1, au moins.
  3. Si c’est le cas pour chaque texte, le test est validé.
Test 3.2.5 Dans le mécanisme qui permet d’afficher un rapport de contraste conforme, le rapport de contraste entre le texte et la couleur d’arrière-plan est-il suffisamment élevé ?
Méthodologie du test 3.2.5
  1. Retrouver dans le document les mécanismes qui permettent d’afficher un rapport de contraste conforme.
  2. Pour chacun de ces mécanismes, vérifier que le rapport de contraste entre le texte et la couleur d’arrière-plan est suffisamment élevé.
  3. Si c’est le cas pour chaque mécanisme, le test est validé.
Cas particuliers

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

  • Le texte fait partie d’un logo ou d’un nom de marque d’un organisme ou d’une société ;
  • Le texte ou l’image de texte est purement décoratif ;
  • Le texte fait partie d’une image véhiculant une information mais le texte lui-même n’apporte aucune information essentielle ;
  • Le texte ou l’image de texte fait partie d’un élément d’interface sur lequel aucune action n’est possible (par exemple un bouton avec l’attribut disabled).
Correspondances

Critère 3.3 [A] : 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) ?

Tests du critère 3.3

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) ?
Méthodologie du test 3.3.1
  1. Retrouver dans le document les composants d’interface qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces composants, vérifier que :
    • soit le rapport de contraste entre les couleurs du composant dans ses différents états et la couleur d’arrière-plan contiguë est de 3:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher le composant avec un rapport de contraste de 3:1, au moins.
  3. Si c’est le cas pour chaque composant, le test est validé.
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) ?
Méthodologie du test 3.3.2
  1. Retrouver dans le document les éléments graphiques qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces éléments, vérifier que :
    • soit le rapport de contraste entre les couleurs de l’élément graphique nécessaires à sa compréhension et la couleur d’arrière-plan contiguë est de 3:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher l’élément graphique avec un rapport de contraste de 3:1, au moins.
  3. Si c’est le cas pour chaque composant, le test est validé.
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) ?
Méthodologie du test 3.3.3
  1. Retrouver dans le document les éléments graphiques qui pourraient poser des problèmes de contraste.
  2. Pour chacun de ces éléments, vérifier que :
    • soit le rapport de contraste des différentes couleurs contiguës de l’élément graphique entre elles, lorsqu’elles sont nécessaires à sa compréhension, est de 3:1, au moins ;
    • soit un mécanisme permet à l’utilisateur d’afficher l’élément graphique avec un rapport de contraste de 3:1, au moins.
  3. Si c’est le cas pour chaque élément graphique, le test est validé.
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 ?
Méthodologie du test 3.3.4
  1. Retrouver dans le document les mécanismes qui permettent d’afficher un rapport de contraste conforme.
  2. Pour chacun de ces mécanismes, vérifier que le rapport de contraste entre les couleurs du composant ou des éléments graphiques porteurs d’informations qui le composent est suffisamment élevé.
  3. Si c’est le cas pour chaque mécanisme, le test est validé.
Cas particuliers

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

  • Composant d’interface inactif (par 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 (par 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 (par 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 (par 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.
Correspondances

Thématique 4 : Multimédia

Critère 4.1 [A] : Chaque média temporel pré-enregistré a-t-il, si nécessaire, une transcription textuelle ou une audiodescription (hors cas particuliers) ?

Tests du critère 4.1

Test 4.1.1 Chaque média temporel pré-enregistré seulement audio, vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.1.1
  1. Retrouver dans le document les médias temporels (éléments <audio>, <video> ou <object>) seulement audio qui nécessitent une transcription textuelle.
  2. Pour chaque média temporel seulement audio, vérifier la présence d’une transcription textuelle :
    • soit accessible au moyen d’un bouton ou d’un lien adjacent (une URL ou une ancre) ;
    • soit adjacente clairement identifiable.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.1.2 Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.1.2
  1. Retrouver dans le document les médias temporels (éléments <video> ou <object>) seulement vidéo qui nécessitent une transcription textuelle.
  2. Pour chaque média temporel seulement vidéo, vérifier la présence :
    • soit d’une version alternative audio seulement accessible au moyen d’un lien ou bouton adjacent (une URL ou une ancre) ;
    • soit d’une version alternative audio seulement adjacente ;
    • soit d’une transcription textuelle accessible au moyen d’un bouton ou d’un lien adjacent (une URL ou une ancre) ;
    • soit d’une transcription textuelle adjacente clairement identifiable ;
    • soit d’une audiodescription synchronisée ;
    • soit d’une version alternative avec une audiodescription synchronisée accessible au moyen d’un bouton ou d’un lien adjacent (une URL ou une ancre).
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.1.3 Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.1.3
  1. Retrouver dans le document les médias temporels (éléments <video> ou <object>) synchronisés qui nécessitent une transcription textuelle.
  2. Pour chaque média temporel synchronisé, vérifier la présence :
    • soit d’une transcription textuelle accessible au moyen d’un lien ou bouton adjacent (une URL ou une ancre) ;
    • soit d’une transcription textuelle adjacente clairement identifiable ;
    • soit d’une audiodescription synchronisée ;
    • soit d’une version alternative avec une audiodescription synchronisée accessible au moyen d’un bouton ou d’un lien adjacent (une URL ou une ancre) ;
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Cas particuliers

Il existe une gestion de cas particulier lorsque :

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

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

Correspondances

Critère 4.2 [A] : Pour chaque média temporel pré-enregistré ayant une transcription textuelle ou une audiodescription synchronisée, celles-ci sont-elles pertinentes (hors cas particuliers) ?

Tests du critère 4.2

Test 4.2.1 Pour chaque média temporel pré-enregistré seulement audio, ayant une transcription textuelle, celle-ci est-elle pertinente (hors cas particuliers) ?
Méthodologie du test 4.2.1
  1. Retrouver dans le document les médias temporels pré-enregistrés seulement audio qui possèdent une transcription textuelle.
  2. Pour chaque média temporel seulement audio, vérifier que transcription textuelle est pertinente.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.2.2 Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.2.2
  1. Retrouver dans le document les médias temporels pré-enregistrés seulement vidéo qui possèdent une transcription textuelle.
  2. Pour chaque média temporel seulement vidéo, vérifier la pertinence :
    • soit de la transcription textuelle ;
    • soit de l’audiodescription synchronisée ;
    • soit de l’audiodescription synchronisée de la version alternative ;
    • soit de la version alternative audio seulement.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.2.3 Chaque média temporel synchronisé pré-enregistré vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.2.3
  1. Retrouver dans le document les médias temporels pré-enregistrés synchronisés.
  2. Pour chaque média temporel synchronisé, vérifier la pertinence :
    • soit de la transcription textuelle ;
    • soit de l’audiodescription synchronisée ;
    • soit de l’audiodescription synchronisée de la version alternative.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Cas particuliers

Voir cas particuliers critère 4.1.

Correspondances

Critère 4.3 [A] : Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés (hors cas particuliers) ?

Tests du critère 4.3

Test 4.3.1 Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.3.1
  1. Retrouver dans le document les médias temporels pré-enregistrés synchronisés.
  2. Pour chaque média temporel synchronisé, vérifier la présence :
    • soit de sous-titres synchronisés ;
    • soit d’une version alternative possédant des sous-titres synchronisés accessible au moyen d’un lien ou d’un bouton adjacent.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.3.2 Pour chaque média temporel synchronisé pré-enregistré possédant des sous-titres synchronisés diffusés via une balise <track>, la balise <track> possède-t-elle un attribut kind="captions" ?
Méthodologie du test 4.3.2
  1. Retrouver dans le document les médias temporels synchronisés possédant des sous-titres synchronisés au moyen d’un élément <track>.
  2. Pour chaque média temporel synchronisé, vérifier que la balise <track> possède un attribut kind="captions".
  3. Si c’est le cas pour chaque média temporel synchronisé, le test est validé.
Cas particuliers

Voir cas particuliers critère 4.1.

Correspondances

Critère 4.4 [A] : Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ces sous-titres sont-ils pertinents ?

Tests du critère 4.4

Test 4.4.1 Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, une piste de sous-titres au moins respecte-t-elle ces conditions ?
  • Les sous-titres sont dans la langue de la vidéo ;
  • Les sous-titres sont pertinents ;
  • Les sous-titres sont correctement synchronisés.
Méthodologie du test 4.4.1
  1. Retrouver dans le document les médias temporels synchronisés possédant des sous-titres synchronisés.
  2. Pour chaque média temporel synchronisé, vérifier que les sous-titres sont :
    • dans la langue de la vidéo (si le contenu oralisé est en anglais, les sous-titres doivent être en anglais) ;
    • pertinents (toutes les informations sonores importantes sont présentes, les dialogues notamment) ;
    • correctement synchronisés. Si vous n’observez pas de décalage entre le discours oralisé et l’apparition des sous-titres, les sous-titres sont correctement synchronisés. La norme de référence spécifie que les sous-titres doivent apparaître dans les 100 ms suivant l’horodatage du sous-titre.
  3. Si c’est le cas pour chaque média temporel synchronisé, le test est validé.
Correspondances

Critère 4.5 [AA] : Chaque média temporel pré-enregistré a-t-il, si nécessaire, une audiodescription synchronisée (hors cas particuliers) ?

Tests du critère 4.5

Test 4.5.1 Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.5.1
  1. Retrouver dans le document les médias temporels pré-enregistrés seulement vidéo qui nécessitent une audiodescription.
  2. Pour chaque média temporel seulement vidéo, vérifier la présence :
    • soit d’une audiodescription synchronisée ;
    • soit d’une version alternative avec une audiodescription synchronisée accessible au moyen d’un bouton ou d’un lien adjacent (une URL ou une ancre).
  3. Si c’est le cas pour chaque média temporel seulement vidéo, le test est validé.
Test 4.5.2 Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.5.2
  1. Retrouver dans le document les médias temporels pré-enregistrés synchronisés qui nécessitent une audiodescription.
  2. Pour chaque média temporel synchronisé, vérifier la présence :
    • soit d’une audiodescription synchronisée ;
    • Soit d’une version alternative avec une audiodescription synchronisée accessible au moyen d’un bouton ou d’un lien adjacent (une URL ou une ancre).
  3. Si c’est le cas pour chaque média temporel synchronisé, le test est validé.
Cas particuliers

Voir cas particuliers critère 4.1.

Correspondances

Critère 4.6 [AA] : Pour chaque média temporel pré-enregistré ayant une audiodescription synchronisée, celle-ci est-elle pertinente ?

Tests du critère 4.6

Test 4.6.1 Pour chaque média temporel pré-enregistré seulement vidéo ayant une audiodescription synchronisée, celle-ci est-elle pertinente ?
Méthodologie du test 4.6.1
  1. Retrouver dans le document les médias temporels seulement vidéo qui possèdent une audiodescription.
  2. Pour chaque média temporel, vérifier que l’audiodescription synchronisée est pertinente (toutes les informations visuelles qu’il est possible de vocaliser dans les blancs de la bande son principale sont présentes, les textes incrustés notamment).
  3. Si c’est le cas pour chaque média temporel seulement vidéo, le test est validé.
Test 4.6.2 Pour chaque média temporel synchronisé ayant une audiodescription synchronisée, celle-ci est-elle pertinente ?
Méthodologie du test 4.6.2
  1. Retrouver dans le document les médias temporels synchronisés qui possèdent une audiodescription.
  2. Pour chaque média temporel, vérifier que l’audiodescription synchronisée est pertinente (toutes les informations visuelles qu’il est possible de vocaliser dans les blancs de la bande son principale sont présentes, les textes incrustés notamment).
  3. Si c’est le cas pour chaque média temporel synchronisé, le test est validé.
Correspondances

Critère 4.7 [A] : Chaque média temporel est-il clairement identifiable (hors cas particuliers) ?

Tests du critère 4.7

Test 4.7.1 Pour chaque média temporel seulement son, seulement vidéo ou synchronisé, le contenu textuel adjacent permet-il d’identifier clairement le média temporel (hors cas particuliers) ?
Méthodologie du test 4.7.1
  1. Retrouver dans le document les médias temporels pré-enregistrés seulement vidéo, audio ou synchronisés.
  2. Pour chaque média temporel, vérifier qu'un passage de texte (un titre ou un paragraphe, par exemple) qui précède ou suit immédiatement le média temporel permet de l’identifier.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Cas particuliers

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). Dans cette situation, le critère est non applicable.

Correspondances

Critère 4.8 [A] : Chaque média non temporel a-t-il, si nécessaire, une alternative (hors cas particuliers) ?

Tests du critère 4.8

Test 4.8.1 Chaque média non temporel vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.8.1
  1. Retrouver dans le document les médias non temporels.
  2. Pour chaque média non temporel, vérifier qu’un lien ou un bouton adjacent, clairement identifiable :
    • soit contient l’adresse (url) d’une page contenant une alternative ;
    • soit permet d’accéder à une alternative dans la page.
  3. Si c’est le cas pour chaque média non temporel, le test est validé.
Test 4.8.2 Chaque média non temporel associé à une alternative vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 4.8.2
  1. Retrouver dans le document les médias non temporels associés à une alternative.
  2. Pour chaque média non temporel, vérifier que :
    • la page référencée par le lien ou le bouton adjacent est accessible ;
    • l’alternative dans la page, référencée par le lien ou le bouton adjacent, est accessible.
  3. Si c’est le cas pour chaque média non temporel, le test est validé.
Cas particuliers

Il existe une gestion de cas particulier lorsque :

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

Correspondances

Critère 4.9 [A] : Pour chaque média non temporel ayant une alternative, cette alternative est-elle pertinente ?

Tests du critère 4.9

Test 4.9.1 Pour chaque média non temporel ayant une alternative, cette alternative permet-elle d’accéder au même contenu et à des fonctionnalités similaires ?
Méthodologie du test 4.9.1
  1. Retrouver dans le document les médias non temporels associés à une alternative.
  2. Pour chaque média non temporel, vérifier que l’alternative est pertinente (elle permet d’accéder au même contenu et à des fonctionnalités similaires).
  3. Si c’est le cas pour chaque média non temporel, le test est validé.
Correspondances

Critère 4.10 [A] : Chaque son déclenché automatiquement est-il contrôlable par l’utilisateur ?

Tests du critère 4.10

Test 4.10.1 Chaque séquence sonore déclenchée automatiquement via une balise <object>, <video>, <audio>, <embed>, <bgsound> ou un code JavaScript vérifie-t-elle une de ces conditions ?
  • La séquence sonore a une durée inférieure ou égale à 3 secondes.
  • La séquence sonore peut être stoppée sur action de l’utilisateur.
  • Le volume de la séquence sonore peut être contrôlé par l’utilisateur indépendamment du contrôle de volume du système.
Méthodologie du test 4.10.1
  1. Au chargement du document, si un son se déclenche automatiquement, vérifier que :
    • soit la séquence sonore a une durée inférieure ou égale à 3 secondes ;
    • soit un dispositif (un bouton par exemple), sur l’élément ayant déclenché le son (voir note), ou dans la page, permet de le stopper ;
    • soit le volume de la séquence peut être contrôlé par l’utilisateur, indépendamment du contrôle de volume du système.
  2. Si c’est le cas, le test est validé.

Note : les éléments suivants sont susceptibles de déclencher des sons au chargement de la page : éléments <audio>, <video>, <object>, <embed>, <bgsound> ou un code JavaScript (utilisation de la Web Audio API, par exemple).

Note

Ce critère est soumis au principe de non-interférence.

Correspondances

Critère 4.11 [A] : La consultation de chaque média temporel est-elle, si nécessaire, contrôlable par le clavier et tout dispositif de pointage ?

Tests du critère 4.11

Test 4.11.1 Chaque média temporel a-t-il, si nécessaire, les fonctionnalités de contrôle de sa consultation ?
Méthodologie du test 4.11.1
  1. Retrouver dans le document les médias temporels.
  2. Pour chaque média temporel, vérifier la présence des fonctionnalités obligatoires de contrôle de la consultation :
    • au minimum : lecture, pause ou stop ;
    • si le média a du son, il doit avoir une fonctionnalité d’activation / désactivation du son ;
    • si le média a des sous-titres, il doit avoir une fonctionnalité de contrôle de l’apparition/disparition des sous-titres ;
    • si le média a une audiodescription, il doit avoir une fonctionnalité de contrôle de l’apparition/disparition de l’audiodescription.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.11.2 Pour chaque média temporel, chaque fonctionnalité vérifie-t-elle une de ces conditions ?
Méthodologie du test 4.11.2
  1. Retrouver dans le document les médias temporels pourvus de fonctionnalités de contrôle.
  2. Pour chaque média temporel, vérifier que :
    • soit la fonctionnalité est accessible par le clavier et tout dispositif de pointage ;
    • soit une fonctionnalité accessible par le clavier et tout dispositif de pointage permettant de réaliser la même action est présente dans la page.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Test 4.11.3 Pour chaque média temporel, chaque fonctionnalité vérifie-t-elle une de ces conditions ?
Méthodologie du test 4.11.3
  1. Retrouver dans le document les médias temporels pourvus de fonctionnalités de contrôle.
  2. Pour chaque média temporel, vérifier que :
    • soit la fonctionnalité est activable par le clavier et tout dispositif de pointage ;
    • soit une fonctionnalité activable par le clavier et tout dispositif de pointage permettant de réaliser la même action est présente dans la page.
  3. Si c’est le cas pour chaque média temporel, le test est validé.
Correspondances

Critère 4.12 [A] : La consultation de chaque média non temporel est-elle contrôlable par le clavier et tout dispositif de pointage ?

Tests du critère 4.12

Test 4.12.1 Pour chaque média non temporel, chaque fonctionnalité vérifie-t-elle une de ces conditions ?
Méthodologie du test 4.12.1
  1. Retrouver dans le document les médias non temporels pourvus de fonctionnalités de contrôle.
  2. Pour chaque média non temporel, vérifier que :
    • soit la fonctionnalité est accessible par le clavier et tout dispositif de pointage ;
    • soit une fonctionnalité accessible par le clavier et tout dispositif de pointage permettant de réaliser la même action est présente dans la page.
  3. Si c’est le cas pour chaque média non temporel, le test est validé.
Test 4.12.2 Pour chaque média non temporel, chaque fonctionnalité vérifie-t-elle une de ces conditions ?
Méthodologie du test 4.12.2
  1. Retrouver dans le document les médias non temporels pourvus de fonctionnalités de contrôle.
  2. Pour chaque média non temporel, vérifier que :
    • soit la fonctionnalité est activable par le clavier et tout dispositif de pointage ;
    • soit une fonctionnalité activable par le clavier et tout dispositif de pointage permettant de réaliser la même action est présente dans la page.
  3. Si c’est le cas pour chaque média non temporel, le test est validé.
Correspondances

Critère 4.13 [A] : Chaque média temporel et non temporel est-il compatible avec les technologies d’assistance (hors cas particuliers) ?

Tests du critère 4.13

Test 4.13.1 Chaque média temporel et non temporel vérifie-t-il une de ces conditions (hors cas particuliers) ?
  • Le nom, le rôle, la valeur, le paramétrage et les changements d’états des composants d’interfaces sont accessibles aux technologies d’assistance via une API d’accessibilité.
  • Une alternative compatible avec une API d’accessibilité permet d’accéder aux mêmes fonctionnalités.
Méthodologie du test 4.13.1
  1. Retrouver dans le document les médias temporels et non temporels.
  2. Pour chaque média, vérifier que :
    • soit le nom, le rôle, la valeur, le paramétrage et les changements d’états des composants d’interfaces sont accessibles aux technologies d’assistance via une API d’accessibilité (par exemple, les zones mises à jour dynamiquement dans un lecteur vidéo sont correctement restituées) ;
    • soit une alternative compatible avec une API d’accessibilité permet d’accéder aux mêmes fonctionnalités.
  3. Si c’est le cas pour chaque média temporel ou non temporel, le test est validé.
Test 4.13.2 Chaque média temporel et non temporel qui possède une alternative compatible avec les technologies d’assistance, vérifie-t-il une de ces conditions ?
Méthodologie du test 4.13.2
  1. Retrouver dans le document les médias temporels et non temporels qui possèdent une alternative compatible avec les technologies d’assistance.
  2. Pour chaque média, vérifier que :
    • soit l’alternative est adjacente au média temporel ou non temporel ;
    • soit l’alternative est accessible au moyen d’un lien ou d’un bouton adjacent ;
    • soit un mécanisme permet de remplacer le média temporel ou non temporel par son alternative.
  3. Si c’est le cas pour chaque média temporel ou non temporel, le test est validé.
Cas particuliers

Il existe une gestion de cas particulier lorsque le média temporel ou non temporel est utilisé à des fins décoratives (c’est-à-dire qu’il n’apporte aucune information).

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

Correspondances

Critère 4.14 [AA] : Pour chaque média temporel qui dispose d’une piste de sous-titres synchronisés ou d’une audiodescription, les fonctionnalités de contrôle de ces alternatives sont-elles présentées au même niveau que les fonctionnalités principales ?

Tests du critère 4.14

Test 4.14.1 Pour chaque média temporel qui dispose d’une piste de sous-titres synchronisés ou d’une audiodescription, les fonctionnalités de contrôle de ces alternatives respectent-elles ces conditions ?
  • Pour chaque média temporel, la fonctionnalité qui permet d’activer et désactiver les sous-titres est présentée au même niveau que les fonctionnalités principales.
  • Pour chaque média temporel, la fonctionnalité qui permet d’activer et désactiver l’audiodescription est présentée au même niveau que les fonctionnalités principales.
Méthodologie du test 4.14.1
  1. Repérer les médias temporels pré-enregistrés avec une piste de sous-titres synchronisés ou une audiodescription.
  2. Vérifier qu’il est possible d’activer et désactiver les sous-titres ou l’audiodescription sans étape supplémentaire par rapport aux fonctionnalités principales (lecture, pause…).
  3. Si c’est le cas, le test est validé.

Exemple : Si le bouton de lecture peut être activé depuis l’interface par un simple clic souris (sans la nécessité d’activer un premier composant pour afficher un menu déroulant par exemple), la fonction de sous-titres doit être disponible de manière équivalente, avec un simple clic. À l’inverse, si la fonction des sous-titres est disponible depuis un menu déroulant qui doit être activé au préalable (par un clic souris par exemple), elle ne sera pas considérée comme étant au même niveau puisqu’il y aura une étape supplémentaire à réaliser.

Correspondances

Critère 4.15 [AA] : Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel synchronisé pré-enregistré qui possède une piste de sous-titres, à l’issue du processus, les sous-titres sont-ils correctement conservés ?

Tests du critère 4.15

Test 4.15.1 Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel synchronisé pré-enregistré qui possède une piste de sous-titres synchronisés, à l’issue du processus, les sous-titres respectent-ils ces conditions ?
Méthodologie du test 4.15.1
  1. Repérer les fonctionnalités qui permettent de transmettre (envoyer un contenu vers un autre terminal ou envoyer une vidéo par e-mail par exemple), convertir (convertir une vidéo au format .avi dans un format .mpg par exemple) ou enregistrer un média temporel synchronisé pré-enregistré (enregistrer une vidéo depuis une plateforme de diffusion sur son ordinateur personnel par exemple).
  2. Exécuter chacune des fonctionnalités (transmettre, convertir et enregistrer).
  3. Pour chaque fonctionnalité, vérifier si les sous-titres :
    • sont toujours présents ;
    • peuvent être affichés ;
    • sont correctement synchronisés ;
    • conservent leurs caractéristiques essentielles (par exemple, si les sous-titres étaient colorés en fonction du locuteur, les couleurs doivent être reprises).
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 4.16 [AA] : Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel pré-enregistré avec une audiodescription synchronisée, à l’issue du processus, l’audiodescription est-elle correctement conservée ?

Tests du critère 4.16

Test 4.16.1 Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel pré-enregistré avec une audiodescription synchronisée, à l’issue du processus l’audiodescription respecte-t-elle ces conditions ?
  • L’audiodescription est présente.
  • L’audiodescription peut être activée.
  • L’audiodescription est correctement synchronisée.
Méthodologie du test 4.16.1
  1. Repérer les fonctionnalités qui permettent de transmettre, convertir ou enregistrer un média temporel. Par exemple : envoyer un contenu vers un autre terminal ou par mail, convertir une vidéo au format .avi dans un format .mpg, enregistrer une vidéo depuis une plateforme de diffusion sur son ordinateur personnel.
  2. Exécuter chacune des fonctionnalités (transmettre, convertir et enregistrer).
  3. Pour chaque fonctionnalité, vérifier si l’audiodescription :
    • est présente ;
    • peut être activée ;
    • est correctement synchronisée :
      • les sons et paroles de l’audiodescription ne chevauchent pas ceux de la bande-son originale et ne provoquent pas de problèmes de perception et de compréhension ;
      • les informations véhiculées dans l’audiodescription sont données au moment où apparaissent les informations visuelles équivalentes.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 4.17 [AA] : Pour chaque média temporel pré-enregistré, la présentation des sous-titres est-elle contrôlable par l’utilisateur (hors cas particuliers) ?

Tests du critère 4.17

Test 4.17.1 Pour chaque média temporel pré-enregistré, la présentation des sous-titres respecte-t-elle une de ces conditions ?
  • Les paramètres système de présentation des sous-titres définis par l’utilisateur s’appliquent aux sous-titres.
  • Il existe une fonctionnalité dans la page qui permet à l’utilisateur de modifier les paramètres de présentation des sous-titres.
Méthodologie du test 4.17.1
  1. Repérer les médias temporels pré-enregistrés qui possèdent des sous-titres.
  2. Définir un ou plusieurs paramètres de présentation des sous-titres depuis les options de personnalisation mises à disposition par le système d’exploitation, par exemple : la taille des sous-titres, la couleur, le style de bordure des sous-titres, la couleur d’arrière-plan, l’opacité de l’arrière-plan, etc. (Note : la norme ne donne pas la liste précise des paramètres qu’il est obligatoire de pouvoir définir, aussi, la possibilité de modifier une seule caractéristique des sous-titres est suffisante pour rendre le critère conforme).
  3. Vérifier que les paramètres définis sont appliqués aux sous-titres.
  4. Sinon, repérer dans la page la présence d’une fonctionnalité permettant de modifier les paramètres de présentation des sous-titres (dans la page ou directement depuis le lecteur multimédia).
  5. Vérifier que les paramètres définis sont appliqués aux sous-titres.
  6. Si c’est le cas, le test est validé.
Cas particuliers

Le critère est non applicable pour les sous-titres incrustés (open captions).

Correspondances

Critère 4.18 [AA] : Pour chaque média temporel synchronisé pré-enregistré qui possède des sous-titres de traduction synchronisés, ceux-ci peuvent-ils être vocalisés (hors cas particuliers) ?

Tests du critère 4.18

Test 4.18.1 Chaque média temporel synchronisé pré-enregistré qui possède des sous-titres de traduction synchronisés vérifie-t-il l’une de ces conditions (hors cas particuliers) ?
  • Une piste sonore contenant une vocalisation de l’ensemble des sous-titres de traduction peut être activée par l’utilisateur.
  • Une fonctionnalité est disponible qui permet de vocaliser les sous-titres de traduction.
  • Les sous-titres de traduction peuvent être vocalisés par les technologies d’assistance.
  • Il existe une version alternative contenant une vocalisation de l’ensemble des sous-titres de traduction, accessible via un lien ou bouton adjacent.
Méthodologie du test 4.18.1
  1. Repérer les médias temporels synchronisés pré-enregistrés avec des sous-titres de traduction.
  2. Vérifier la présence d’une piste sonore qui serait la version vocalisée des sous-titres de traduction :
    1. activer la piste sonore ;
    2. vérifier que les sous-titres vocalisés correspondent aux sous-titres affichés.
  3. Sinon, vérifier la présence d’une fonctionnalité qui permet de vocaliser des sous-titres :
    1. Text-to-speech. Certains lecteurs multimédia (par exemple AblePlayer ou VideoJS), offrent la possibilité d’ajouter une piste de description sous forme d’un fichier texte (d’une construction similaire à un fichier de sous-titres avec un horodatage) qui peut être synthétisée grâce à l’API Web Speech des navigateurs (on parle alors de text-to-speech, ou TTS). En activant cette fonctionnalité, c’est le navigateur qui va lire la description. Cette fonctionnalité peut être utilisée pour fournir une version vocalisée des sous-titres, et serait donc considérée comme une implémentation conforme si elle est correctement documentée pour l’utilisateur. Pour la tester :
      1. activer la fonctionnalité ;
      2. lancer la lecture du contenu multimédia ;
      3. vérifier que les textes affichés par ce moyen sont vocalisés.
    2. Pistes de description. Certains lecteurs multimédias (par exemple, AblePlayer ou BrightCove) offrent la possibilité d’intégrer des pistes de description sous forme d’un fichier texte (d’une construction similaire à un fichier de sous-titres avec un horodatage) et qui est déclarée dans le code grâce à la balise <track> pourvue de l’attribut kind="descriptions" et dont l’implémentation finale est pourvue des propriétés suffisantes pour permettre leur restitution par les lecteurs d’écran (présence de la propriété aria-live par exemple). Cette fonctionnalité peut être utilisée pour fournir une version des sous-titres qui pourra être vocalisée par les lecteurs d’écran, et serait donc considérée comme une implémentation conforme si elle est correctement documentée pour l’utilisateur. Pour la tester :
      1. activer la fonctionnalité ;
      2. activer le lecteur d’écran ;
      3. vérifier que les textes affichés par ce moyen sont vocalisés.
  4. Sinon :
    1. activer les sous-titres de traduction ;
    2. activer le lecteur d’écran ;
    3. vérifier que les sous-titres vocalisés correspondent aux sous-titres affichés.
  5. Sinon :
    1. rechercher la présence d’un média alternatif dont la bande son contient les sous-titres de traduction vocalisés ;
    2. vérifier que les sous-titres vocalisés correspondent aux sous-titres affichés.
  6. Si c’est le cas, le test est validé.
Cas particuliers

Le critère est non applicable pour les sous-titres sont incrustés dans la vidéo (open captions).

Correspondances

Thématique 5 : Tableaux

Critère 5.1 [A] : Chaque tableau de données complexe a-t-il un résumé ?

Tests du critère 5.1

Test 5.1.1 Pour chaque tableau de données complexe, un résumé est-il disponible ?
Méthodologie du test 5.1.1
  1. Retrouver dans le document les tableaux de données complexes (tableau de données - élément <table> ou élément pourvu d’un attribut WAI-ARIA role="table" - contenant 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).
  2. Pour chaque tableau de données complexe, vérifier qu’un passage de texte permettant de comprendre la nature et la structure du tableau, est présent :
    • soit dans l’élément <caption> ;
    • soit dans l’attribut summary de l’élément <table> (dans les versions de HTML et de XHTML antérieures à HTML 5) ;
    • soit dans un passage de texte lié au tableau avec l’attribut aria-describedby.
  3. Si c’est le cas pour chaque tableau de données complexe, le test est validé.
Notes techniques

La spécification HTML propose plusieurs méthodes pour lier un résumé à un tableau (tableau lié à un passage de texte avec l’attribut aria-describedby, tableau groupé dans un élément figure avec un résumé présent dans un élément figcaption ou un élément p, résumé présent dans un élément details contenu dans l’élément caption). Ces méthodes n’ont pas un support suffisant pour être utilisées actuellement.

Correspondances

Critère 5.2 [A] : Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ?

Tests du critère 5.2

Test 5.2.1 Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ?
Méthodologie du test 5.2.1
  1. Retrouver dans le document les résumés de tableaux de données complexes (tels que déterminés par le test 5.1.1).
  2. Pour chaque résumé, vérifier que son contenu est pertinent.
  3. Si c’est le cas pour chaque résumé de tableaux de données complexes, le test est validé.
Correspondances

Critère 5.3 [A] : Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ?

Tests du critère 5.3

Test 5.3.1 Chaque tableau de mise en forme vérifie-t-il ces conditions ?
  • Le contenu linéarisé reste compréhensible.
  • La balise <table> possède un attribut role="presentation".
Méthodologie du test 5.3.1
  1. Retrouver dans le document les tableaux de mise en forme.
  2. Pour chaque tableau de mise en forme, vérifier que :
    • L’ordre d’accès aux cellules est cohérent avec le contenu.
    • L’élément <table> est pourvu d’un attribut WAI-ARIA role="presentation".
  3. Si c’est le cas pour chaque tableau de mise en forme, le test est validé.
Correspondances

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

Tests du critère 5.4

Test 5.4.1 Pour chaque tableau de données ayant un titre, le titre est-il correctement associé au tableau de données ?
Méthodologie du test 5.4.1
  1. Retrouver dans le document les tableaux de données pourvus d’un titre.
  2. Pour chaque titre, vérifier qu’il est fourni au moyen :
    • soit d’un élément <caption> ;
    • soit d’un attribut title ;
    • soit d’un attribut WAI-ARIA aria-label ;
    • soit d’un attribut WAI-ARIA aria-labelledby référençant un passage de texte.
  3. Si c’est le cas pour chaque titre de tableau de données, le test est validé.
Correspondances

Critère 5.5 [A] : Pour chaque tableau de données ayant un titre, celui-ci est-il pertinent ?

Tests du critère 5.5

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 ?
Méthodologie du test 5.5.1
  1. Retrouver dans le document les tableaux de données pourvus d’un titre.
  2. Pour chaque titre, vérifier qu’il est pertinent.
  3. Si c’est le cas pour chaque titre de tableau de données, le test est validé.
Correspondances

Critère 5.6 [A] : Pour chaque tableau de données, chaque en-tête de colonne et chaque en-tête de ligne sont-ils correctement déclarés ?

Tests du critère 5.6

Test 5.6.1 Pour chaque tableau de données, chaque en-tête de colonne s’appliquant à la totalité de la colonne vérifie-t-il une de ces conditions ?
Méthodologie du test 5.6.1
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête de colonnes s’appliquant à la totalité de la colonne, vérifier que l’en-tête de colonne est structuré au moyen :
    • soit d’un élément <th> ;
    • soit d’un élément pourvu d’un attribut WAI-ARIA role="columnheader".
  3. Si c’est le cas pour chaque en-tête de colonne s’appliquant à la totalité de la colonne, le test est validé.
Test 5.6.2 Pour chaque tableau de données, chaque en-tête de ligne 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".
Méthodologie du test 5.6.2
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête de ligne s’appliquant à la totalité de la ligne, vérifier que l’en-tête de ligne est structuré au moyen :
    • soit d’un élément <th> ;
    • soit d’un élément pourvu d’un attribut WAI-ARIA role="rowheader".
  3. Si c’est le cas pour chaque en-tête de ligne s’appliquant à la totalité de la ligne, le test est validé.
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> ?
Méthodologie du test 5.6.3
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête ne s’appliquant pas à la totalité de la ligne ou de la colonne, vérifier que l’en-tête de ligne est structuré au moyen d’un élément <th>.
  3. Si c’est le cas pour chaque en-tête ne s’appliquant pas à la totalité de la ligne ou de la colonne, le test est validé.
Test 5.6.4 Pour chaque tableau de données, chaque cellule associée à plusieurs en-têtes est-elle structurée au moyen d’une balise <td> ou <th> ?
Méthodologie du test 5.6.4
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque cellule associée à plusieurs en-têtes est-elle structurée au moyen d’une balise <th> ou <td>.
  3. Si c’est le cas pour chaque en-tête ne s’appliquant pas à la totalité de la ligne ou de la colonne, le test est validé.
Correspondances

Critère 5.7 [A] : Pour chaque tableau de données, la technique appropriée permettant d’associer chaque cellule avec ses en-têtes est-elle utilisée (hors cas particuliers) ?

Tests du critère 5.7

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 role="columnheader".
Méthodologie du test 5.7.1
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête (élément <th>) s’appliquant à la totalité de la ligne ou de la colonne, vérifier que l’élément <th> possède :
    • soit un attribut id unique ;
    • soit un attribut scope ;
    • soit un attribut WAI-ARIA role="rowheader" ou "columnheader".
  3. Si c’est le cas pour chaque en-tête s’appliquant à la totalité de la ligne ou de la colonne, le test est validé.
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 ?
Méthodologie du test 5.7.2
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête (élément <th>) s’appliquant à la totalité de la ligne ou de la colonne et pourvu d’un attribut scope, vérifier que l’attribut scope possède :
    • soit une valeur "row" pour les en-têtes de ligne ;
    • soit une valeur "col" pour les en-têtes de colonne.
  3. Si c’est le cas pour chaque en-tête s’appliquant à la totalité de la ligne ou de la colonne et pourvu d’un attribut scope, le test est validé.
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 role="columnheader".
  • La balise <th> possède un attribut id unique.
Méthodologie du test 5.7.3
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête (élément <th>) ne s’appliquant pas à la totalité de la ligne ou de la colonne, vérifier que l’élément <th> :
    • possède un attribut id unique ;
    • ne possède pas d’attribut scope  ;
    • ne possède pas d’attribut WAI-ARIA role="rowheader" ou "columnheader".
  3. Si c’est le cas pour chaque en-tête ne s’appliquant pas à la totalité de la ligne ou de la colonne, le test est validé.
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 balise possède un attribut headers.
  • L’attribut headers possède la liste des valeurs d’attribut id des en-têtes associés.
Méthodologie du test 5.7.4
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque élément <td> ou <th> associé à un ou plusieurs en-têtes possédant un attribut id, vérifier que :
    • l’élément <td> ou <th> possède un attribut headers ;
    • l’attribut headers possède la liste des valeurs d’attribut id des en-têtes associés.
  3. Si c’est le cas pour chaque élément <td> ou <th> associé à un ou plusieurs en-têtes possédant un attribut id, le test est validé.
Test 5.7.5 Pour chaque balise pourvue d’un attribut WAI-ARIA role="rowheader" ou role="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 ?
Méthodologie du test 5.7.5
  1. Retrouver dans le document les tableaux de données.
  2. Pour chaque en-tête s’appliquant à la totalité de la ligne ou de la colonne et pourvu d’un attribut WAI-ARIA role="rowheader" ou "columnheader", vérifier que l’élément possède :
    • soit un attribut WAI-ARIA role="rowheader" pour les en-têtes de ligne ;
    • soit un attribut WAI-ARIA role="columnheader" pour les en-têtes de colonne.
  3. Si c’est le cas pour chaque en-tête s’appliquant à la totalité de la ligne ou de la colonne et pourvu d’un attribut WAI-ARIA role="rowheader" ou "columnheader", le test est validé.
Cas particuliers

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.

Notes techniques

Si l’attribut headers est implémenté sur une cellule déjà reliée à un en-tête (de ligne ou de colonne) avec l’attribut scope (avec la valeur col ou row), c’est l’en-tête ou les en-têtes référencés par l’attribut headers qui seront restitués aux technologies d’assistance. Les en-têtes reliés avec l’attribut scope seront ignorés.

Correspondances

Critère 5.8 [A] : Chaque tableau de mise en forme ne doit pas utiliser d’éléments propres aux tableaux de données. Cette règle est-elle respectée ?

Tests du critère 5.8

Test 5.8.1 Chaque tableau de mise en forme (balise <table>) vérifie-t-il ces conditions ?
  • Le tableau de mise en forme (balise <table>) n’a pas d’attribut summary (sinon vide) et ne contient pas de balises <caption>, <th>, <thead>, <tfoot> ou de balises ayant un attribut WAI-ARIA role="rowheader", role="columnheader".
  • Les cellules du tableau de mise en forme (balises <td>) ne possèdent pas d’attributs scope, headers et axis.
Méthodologie du test 5.8.1
  1. Retrouver dans le document les tableaux de mise en forme.
  2. Pour chaque tableau de mise en forme, vérifier que :
    • L’élément <table> ne possède pas d’attribut summary, d’éléments enfant <caption>, <thead>, <th>, <tfoot> ou d’éléments pourvus d’un attribut WAI-ARIA role="rowheader" ou role="columnheader".
    • Les éléments <td> ne possèdent pas d’attributs scope, headers et axis.
  3. Si c’est le cas pour chaque tableau de mise en forme, le test est validé.
Correspondances

Thématique 6 : Liens

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

Tests du critère 6.1

Test 6.1.1 Chaque lien texte vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 6.1.1
  1. Retrouver dans le document les liens texte.
  2. Pour chaque lien texte, vérifier que ce qui permet d’en comprendre la fonction et la destination est :
    • soit l’intitulé du lien seul ;
    • soit le contexte du lien.
  3. Si c’est le cas pour chaque lien texte, le test est validé.
Test 6.1.2 Chaque lien image vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 6.1.2
  1. Retrouver dans le document les liens image (lien avec pour contenu un élément <img> ou un élément ayant l’attribut WAI-ARIA role="img", un élément <area> possédant un attribut href, un élément <object>, un élément <canvas> ou un élément <svg>).
  2. Pour chaque lien image, vérifier que ce qui permet d’en comprendre la fonction et la destination est :
    • soit l’intitulé du lien seul, fourni par l’alternative textuelle de l’image ;
    • soit le contexte du lien.
  3. Si c’est le cas pour chaque lien image, le test est validé.
Test 6.1.3 Chaque lien composite vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 6.1.3
  1. Retrouver dans le document les liens composites (lien composé à la fois de contenu texte et d’éléments de type image).
  2. Pour chaque lien composite, vérifier que ce qui permet d’en comprendre la fonction et la destination est :
    • soit l’intitulé du lien seul, fourni par la combinaison du contenu texte et de l’alternative textuelle de l’image ;
    • soit le contexte du lien.
  3. Si c’est le cas pour chaque lien composite, le test est validé.
Test 6.1.4 Chaque lien SVG vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 6.1.4
  1. Retrouver dans le document les liens SVG (élément <svg> qui possède un élément <a> pourvu d’un attribut xlink-href (SVG 1.1) ou href (SVG 2)).
  2. Pour chaque lien SVG, vérifier que ce qui permet d’en comprendre la fonction et la destination est :
    • soit l’intitulé du lien seul, fourni par le nom accessible de l’élément <svg> (résolu généralement à partir du contenu d’un élément <text>) ;
    • soit le contexte du lien.
  3. Si c’est le cas pour chaque lien SVG, le test est validé.
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) ?
Méthodologie du test 6.1.5
  1. Retrouver dans le document les liens autres que SVG dont le contenu est fourni à la fois par un intitulé visible et par le contenu soit d’un attribut title ou d’un attribut aria-label ou d’un attribut aria-labelledby.
  2. Pour chaque lien, vérifier que le contenu de l’attribut title ou de l’attribut aria-label ou de l’attribut aria-labelledby contient l’intitulé visible.
  3. Si c’est le cas pour chaque lien, le test est validé pour les liens autres que SVG.
  4. Retrouver dans le document les liens SVG dont le contenu est fourni à la fois par un intitulé visible et par le contenu soit d’un attribut aria-labelledby, ou d’un attribut aria-label ou d’un élément title (enfant direct de l’élément <svg>) ou d’un attribut x-link:title (SVG 1.1) ou d’un ou plusieurs éléments <text>.
  5. Pour chaque lien SVG, vérifier que le contenu de l’attribut aria-labelledby ou de l’attribut aria-label ou de l’élément <title> ou de l’attribut x-link:title ou d’un ou plusieurs éléments <text> contient l’intitulé visible.
  6. Si c’est le cas pour chaque lien SVG, le test est validé pour les liens SVG.
  7. Si le test est validé à la fois pour les liens non SVG et pour les liens SVG, le test est globalement validé.
Cas particuliers

Il existe une gestion de cas particuliers 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 particuliers 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”).

Notes techniques

Lorsque l’intitulé visible est complété par une autre expression dans le nom accessible :

  • WCAG insiste sur le placement de l’intitulé visible au début du nom accessible sans toutefois réserver l’exclusivité de cet emplacement ;
  • WCAG considère comme un cas d’échec une correspondance non exacte de la chaîne de caractères de l’intitulé visible au sein du nom accessible.

Par exemple, si l’on considère l’intitulé visible « Commander maintenant » complété dans le nom accessible par l’expression « produit X », on peut avoir les différents cas suivants :

  • « Commander maintenant produit X » est valide (bonne pratique) ;
  • « Produit X : commander maintenant » est valide ;
  • « Commander produit X maintenant » est non valide.
Correspondances

Critère 6.2 [A] : Dans chaque page web, chaque lien a-t-il un intitulé ?

Tests du critère 6.2

Test 6.2.1 Dans chaque page web, chaque lien a-t-il un intitulé entre <a> et </a> ?
Méthodologie du test 6.2.1
  1. Retrouver dans le document les liens quels qu’ils soient.
  2. Pour chaque lien, vérifier que le contenu de l’élément <a> (ou d’un élément pourvu d’un attribut WAI-ARIA role=link) contient un intitulé (texte ou alternative).
  3. Si c’est le cas pour chaque lien, le test est validé.
Notes techniques

Une ancre n’est pas un lien même si pendant longtemps l’élément <a> a servi de support à cette technique. Elle n’est donc pas concernée par le présent critère.

Correspondances

Thématique 7 : Scripts

Critère 7.1 [A] : Chaque script est-il, si nécessaire, compatible avec les technologies d’assistance ?

Tests du critère 7.1

Test 7.1.1 Chaque script qui génère ou contrôle un composant d’interface vérifie-t-il, si nécessaire, une de ces conditions ?
Méthodologie du test 7.1.1
  1. Retrouver dans le document tous les composants d’interface générés ou contrôlés au moyen de JavaScript.
  2. Vérifier que :
    • Le composant possède un rôle cohérent avec son usage (généralement un bouton ou un lien).
    • Le composant possède un nom explicite.
    • Le nom du composant est cohérent avec l’état de la fonctionnalité ou des contenus contrôlés (par exemple pour une fonctionnalité permettant d’afficher ou de masquer une zone de contenu).
  3. Sinon, vérifier la présence d’un composant d’interface accessible permettant d’accéder aux mêmes fonctionnalités.
  4. Sinon, vérifier la présence d’une alternative accessible permettant d’accéder aux mêmes fonctionnalités.
  5. Si c’est le cas, le test est validé.
Test 7.1.2 Chaque script qui génère ou contrôle un composant d’interface respecte-t-il une de ces conditions ?
Méthodologie du test 7.1.2
  1. Pour chacun des composants d’interface ayant validé le test 7.1.1, vérifier que le composant d’interface est correctement restitué par les technologies d’assistance.
  2. Sinon, vérifier qu’une alternative accessible au composant d’interface permet d’accéder aux mêmes fonctionnalités.
  3. Si c’est le cas, le test est validé.
Test 7.1.3 Chaque script qui génère ou contrôle un composant d’interface vérifie-t-il ces conditions (hors cas particuliers) ?
  • Le composant possède un nom pertinent.
  • Le nom accessible du composant contient au moins l’intitulé visible.
  • Le composant possède un rôle pertinent.
Méthodologie du test 7.1.3
  1. Pour chacun des composants d’interface ayant validé le test 7.1.1, vérifier que le composant d’interface possède :
    • un nom pertinent (intitulé visible) ;
    • un rôle pertinent.
  2. Si le composant d’interface possède un nom accessible, vérifier que ce nom est pertinent et contient au moins l’intitulé visible.
  3. Si c’est le cas, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers 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”).

Notes techniques

Le critère 7.1 implémente la notion de « compatible avec les technologies d’assistance » telle que définie par les WCAG, ainsi que le recours à WAI-ARIA pour rendre un composant ou une fonctionnalité accessible. Le bon usage de WAI-ARIA est vérifié via les tests 7.1.1, 7.1.2, 7.1.3.

Note importante : dans un environnement HTML5, beaucoup de composants peuvent nécessiter JavaScript pour fonctionner ; en conséquence la fourniture d’une alternative à un composant JavaScript qui ne pourrait pas être rendu accessible devra bénéficier d’une méthode spécifique au composant en cause, permettant de le remplacer par une alternative accessible (et de le réactiver). Cela signifie que la désactivation de JavaScript pour l’ensemble de la page ne sera pas acceptée comme une méthode valable, à moins qu’elle ne remette pas en cause l’utilisation des autres composants.

Correspondances

Critère 7.2 [A] : Pour chaque script ayant une alternative, cette alternative est-elle pertinente ?

Tests du critère 7.2

Test 7.2.1 Chaque script débutant par la balise <script> et ayant une alternative vérifie-t-il une de ces conditions ?
  • L’alternative entre <noscript> et </noscript> permet d’accéder à des contenus et des fonctionnalités similaires.
  • La page affichée, lorsque JavaScript est désactivé, permet d’accéder à des contenus et des fonctionnalités similaires.
  • La page alternative permet d’accéder à des contenus et des fonctionnalités similaires.
  • Le langage de script côté serveur permet d’accéder à des contenus et des fonctionnalités similaires.
  • L’alternative présente dans la page permet d’accéder à des contenus et des fonctionnalités similaires.
Méthodologie du test 7.2.1
  1. Retrouver les alternatives aux fonctionnalités JavaScript :
  2. Chercher dans la page, les alternatives à un composant ou une fonctionnalité JavaScript mises à disposition.
  3. Désactiver JavaScript dans le document et retrouver les alternatives proposées.
  4. Pour chacune des alternatives proposées, vérifier qu’elle permet d’accéder aux mêmes contenus et à des fonctionnalités similaires.
  5. Si c’est le cas, le test est validé.
Test 7.2.2 Chaque élément non textuel mis à jour par un script (dans la page, ou dans un cadre) et ayant une alternative vérifie-t-il ces conditions ?
  • L’alternative de l’élément non textuel est mise à jour.
  • L’alternative mise à jour est pertinente.
Méthodologie du test 7.2.2
  1. Retrouver dans le document tous les éléments non textuels mis à jour par une fonctionnalité JavaScript.
  2. Si l’élément non textuel a une alternative, vérifier que :
    • l’alternative est mise à jour lorsque le contenu non textuel est mis à jour ;
    • l’alternative mise à jour est pertinente.
  3. Si c’est le cas, le test est validé.
Correspondances

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

Tests du critère 7.3

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) ?
Méthodologie du test 7.3.1
  1. Retrouver dans le document, tous les éléments sur lesquels est implémenté un gestionnaire d’événements JavaScript (par exemple click, focus, mouseover, blur, keydown, touch…).
  2. Vérifier que l’élément est accessible au moyen du clavier :
    • Il est atteignable avec la touche de tabulation (tab).
    • Si l’élément gère une action simple, il est activable au clavier avec la touche entrée (Entrée).
    • Si l’élément gère une action complexe, il est utilisable avec le clavier (généralement avec les touches de direction).
  3. Sinon, vérifier qu’un élément accessible par le clavier permettant de réaliser la même action est présent dans la page.
  4. Vérifier que l’élément est accessible par tout dispositif de pointage (souris, toucher, stylet…).
  5. Sinon, vérifier qu’un élément accessible au moyen d’un dispositif de pointage et permettant de réaliser la même action est présent dans la page.
  6. Si c’est le cas, le test est validé.
Test 7.3.2 Un script ne doit pas supprimer le focus d’un élément qui le reçoit. Cette règle est-elle respectée (hors cas particuliers) ?
Méthodologie du test 7.3.2
  1. Activer, l’un après l’autre, tous les éléments capables de recevoir le focus.
  2. Vérifier que le focus n’est pas supprimé via une fonctionnalité JavaScript.
  3. Si c’est le cas, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers lorsque la fonctionnalité dépend de l’utilisation d’un gestionnaire d’événement sans équivalent universel ; par exemple, une application de dessin à main levée ne pourra pas être rendue contrôlable au clavier. Dans ces situations, le critère est non applicable.

Correspondances

Critère 7.4 [A] : Pour chaque script qui initie un changement de contexte, l’utilisateur est-il averti ou en a-t-il le contrôle ?

Tests du critère 7.4

Test 7.4.1 Chaque script qui initie un changement de contexte vérifie-t-il une de ces conditions ?
  • L’utilisateur est averti par un texte de l’action du script et du type de changement avant son déclenchement.
  • Le changement de contexte est initié par un bouton (input de type submit, button ou image ou balise <button>) explicite.
  • Le changement de contexte est initié par un lien explicite.
Méthodologie du test 7.4.1
  1. Retrouver dans le document tous les événements JavaScript qui initient un changement de contexte, par exemple :
    • une mise à jour dynamique de champs de formulaire ;
    • l’ouverture d’une nouvelle page à l’activation d’une option d’une liste de sélection (élément <select>) ;
    • la mise à jour, via un procédé AJAX d’une partie essentielle de la page ;
    • le lancement automatique d’un lecteur vidéo suite à la sélection d’une playlist ;
    • la manipulation du focus ayant pour résultat de modifier la position courante de l’utilisateur dans la page.
  2. Vérifier que :
    • l’utilisateur est averti par un message de l’action du script et du type de changement avant son déclenchement ;
    • ou bien le changement de contexte est initié par un bouton (input de type submit, button ou image ou la balise button) explicite ;
    • ou bien le changement de contexte est initié par un lien explicite.
  3. Si c’est le cas, le test est validé.
Correspondances

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

Tests du critère 7.5

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" ?
Méthodologie du test 7.5.1
  1. Retrouver dans le document les messages qui valent pour message de statut.
  2. Pour chacun de ces messages, déterminer la nature de l’information dont est porteur le message :
  3. Si le message informe de la réussite, du résultat d’une action ou bien de l’état d’une application, vérifier que l’élément qui contient le message :
    • soit utilise l’attribut WAI-ARIA role="status" ;
    • soit utilise les attributs WAI-ARIA aria-live="polite" et aria-atomic="true".
  4. Si le message présente une suggestion, ou avertit de l’existence d’une erreur, vérifier que l’élément qui contient le message :
    • soit utilise l’attribut WAI-ARIA role="alert" ;
    • soit utilise les attributs aria-live="assertive" et aria-atomic="true".
  5. Si le message indique la progression d’un processus, vérifier que l’élément qui contient le message :
    • soit utilise l’un des attributs WAI-ARIA role="log", role="progressbar" ou role="status" ;
    • soit utilise l’attribut WAI-ARIA aria-live="polite" si l’intention est de signaler l’équivalent d’un rôle "log" ;
    • soit utilise les attributs WAI-ARIA aria-live="polite" et aria-atomic="true" si l’intention est de signaler l’équivalent d’un rôle "status".
  6. Si c’est le cas, le test est validé.
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" ?
Méthodologie du test 7.5.2

Tests identiques à 7.5.1

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" ?
Méthodologie du test 7.5.3

Tests identiques à 7.5.1

Notes techniques

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 WAI-ARIA aria-atomic="true" associés à un message de statut peuvent valoir pour un rôle WAI-ARIA status ;
  • Un attribut WAI-ARIA aria-live="assertive" et un attribut WAI-ARIA 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.

Correspondances

Thématique 8 : Éléments obligatoires

Critère 8.1 [A] : Chaque page web est-elle définie par un type de document ?

Tests du critère 8.1

Test 8.1.1 Chaque page web est-elle définie par un type de document ?
Note

Les technologies d’assistance ne dépendent plus de l’analyse directe du HTML. L’absence de déclaration d’un type de document ne pose donc plus de problème d’accessibilité pour les personnes en situation de handicap. Le critère doit dorénavant toujours être considéré comme conforme.

Correspondances

Critère 8.2 [A] : Pour chaque page web, le code source généré est-il valide selon le type de document spécifié ?

Tests du critère 8.2

Test 8.2.1 Pour chaque page web, le code source généré est-il valide selon le type de document spécifié ?
Note

Les technologies d’assistance ne dépendent plus de l’analyse directe du HTML. Les problèmes d’accessibilité spécifiquement liés à la validité du code n’existent plus. Les erreurs remontées par le validateur qui ont un impact pour les personnes en situation de handicap sont traitées par d’autres critères. Le critère doit dorénavant toujours être considéré comme conforme.

Correspondances

Critère 8.3 [A] : Dans chaque page web, la langue par défaut est-elle présente ?

Tests du critère 8.3

Test 8.3.1 Pour chaque page web, l’indication de langue par défaut vérifie-t-elle une de ces conditions ?
  • L’indication de la langue de la page (attribut lang et/ou xml:lang) est donnée pour l’élément html.
  • L’indication de la langue de la page (attribut lang et/ou xml:lang) est donnée sur chaque élément de texte ou sur l’un des éléments parents.
Méthodologie du test 8.3.1
  1. Retrouver dans le document l’indication de langue par défaut.
  2. Vérifier la présence d’une indication de langue :
    • soit au moyen de l’attribut lang sur la balise html si le code est du HTML5 ou du HTML4 ;
    • soit au moyen des attributs lang et xml:lang sur la balise html si le code est du XHTML 1.0 ;
    • soit au moyen de l’attribut xml:lang sur la balise html si le code est du XHTML 1.1 ;
    • Sinon, vérifier la présence d’une indication de langue sur chaque élément de texte ou l’un de ses parents.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 8.4 [A] : Pour chaque page web ayant une langue par défaut, le code de langue est-il pertinent ?

Tests du critère 8.4

Test 8.4.1 Pour chaque page web ayant une langue par défaut, le code de langue vérifie-t-il ces conditions ?
  • Le code de langue est valide.
  • Le code de langue est pertinent.
Méthodologie du test 8.4.1
  1. Retrouver dans le document l’indication de langue par défaut.
  2. Vérifier la présence d’un code de langue :
    • valide (conforme à la norme ISO 639-1 ou ISO 639-2 et suivantes) ;
    • pertinent (qui indique la langue principale du document).
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 8.5 [A] : Chaque page web a-t-elle un titre de page ?

Tests du critère 8.5

Test 8.5.1 Chaque page web a-t-elle un titre de page (balise <title>) ?
Méthodologie du test 8.5.1
  1. Retrouver dans le document le titre structuré au moyen d’un élément <title>.
  2. Si c’est le cas, le test est validé.
Correspondances

Critère 8.6 [A] : Pour chaque page web ayant un titre de page, ce titre est-il pertinent ?

Tests du critère 8.6

Test 8.6.1 Pour chaque page web ayant un titre de page (balise <title>), le contenu de cette balise est-il pertinent ?
Méthodologie du test 8.6.1
  1. Retrouver dans le document le titre structuré au moyen d’un élément <title>.
  2. Vérifier si le contenu de l’élément <title> est suffisamment pertinent (il permet de retrouver la page dans l’historique de navigation ou la liste des onglets).
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 8.7 [AA] : Dans chaque page web, chaque changement de langue est-il indiqué dans le code source (hors cas particuliers) ?

Tests du critère 8.7

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)
Méthodologie du test 8.7.1
  1. Retrouver les passages de texte en langue étrangère, à l’exception :
    • des noms propres ;
    • des mots d’origine étrangère, présents dans le dictionnaire de la langue du document ;
    • des mots d’origine étrangère et d’usage courant dont la prononciation ne provoque pas d’incompréhension.
  2. Vérifier que chaque passage de texte retenu possède une indication de langue (attribut lang et/ou xml:lang sur l’élément lui-même ou l’un de ses parents).
  3. Si c’est le cas, le test est validé.
Cas particuliers

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 : les dictionnaires officiels pour les langues fréquemment employées sur les sites publics luxembourgeois sont les suivants :

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.

Correspondances

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

Tests du critère 8.8

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.
Méthodologie du test 8.8.1
  1. Pour chaque passage de texte validé au test 8.7.1, vérifier que :
    • L’indication de langue est valide.
    • L’indication de langue est pertinente.
  2. Si c’est le cas, le test est validé.
Correspondances

Critère 8.9 [A] : Dans chaque page web, les balises ne doivent pas être utilisées uniquement à des fins de présentation. Cette règle est-elle respectée ?

Tests du critère 8.9

Test 8.9.1 Dans chaque page web les balises (à l’exception de <div>, <span> et <table>) ne doivent pas être utilisées uniquement à des fins de présentation. Cette règle est-elle respectée ?
Méthodologie du test 8.9.1
  1. Retrouver dans le document l’ensemble des éléments sémantiques utilisés à des fins de présentation
  2. Pour chacun de ces éléments, vérifier que :
    • L’élément est pourvu d’un attribut role="presentation".
    • L’utilisation de cet élément à des fins de présentation reste justifiée.
  3. Si c’est le cas, le test est validé.

Note : Quelques exemples, non exhaustifs de détournement de balisage : un élément <div> utilisé comme paragraphe, un titre utilisé comme légende, un élément <blockquote> ou des paragraphes vides ou encore des espaces utilisés pour créer des effets de marges. L’utilisation d’un role="presentation" est formellement déconseillée, mais peut toutefois se justifier dans de rares cas. Cela peut être acceptable sur un élément <blockquote> ou un paragraphe vide, mais sera considéré comme non-conforme sur un titre.

Le cas des tableaux : à noter que ce test aborde les tableaux de présentation qui ne devraient finalement pas apparaître au sein de la thématique Tableaux.

Correspondances

Critère 8.10 [A] : Dans chaque page web, les changements du sens de lecture sont-ils signalés ?

Tests du critère 8.10

Test 8.10.1 Dans chaque page web, chaque texte dont le sens de lecture est différent du sens de lecture par défaut est contenu dans une balise possédant un attribut dir ?
Méthodologie du test 8.10.1
  1. Retrouver dans le document les passages de textes qui utilisent une langue qui se lit dans le sens inverse de la langue du document (comme l’arabe ou l’hébreu pour le français par exemple).
  2. Pour chaque passage de texte, vérifier que le passage de texte est contenu dans une balise qui possède un attribut dir.
  3. Si c’est le cas pour chaque passage de texte, le test est validé.
Test 8.10.2 Dans chaque page web, chaque changement du sens de lecture (attribut dir) vérifie-t-il ces conditions ?
  • La valeur de l’attribut dir est conforme (rtl ou ltr)
  • La valeur de l’attribut dir est pertinente.
Méthodologie du test 8.10.2
  1. Pour chaque passage de texte validé au test 8.10.1, vérifier que :
    • L’indication de sens de lecture est conforme (ltr, pour le sens « de gauche à droite » et rtl pour le sens « de droite à gauche »)
    • L’indication de sens de lecture est pertinente.
  2. Si c’est le cas pour chaque passage de texte, le test est validé.
Correspondances

Thématique 9 : Structuration de l’information

Critère 9.1 [A] : Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ?

Tests du critère 9.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 ?
Méthodologie du test 9.1.1
  1. Retrouver dans le document les titres (balise <hx> ou balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level).
  2. Vérifier que la hiérarchie entre les titres est pertinente.
  3. Si c’est le cas, le test est validé.
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 ?
Méthodologie du test 9.1.2
  1. Pour chaque titre identifié au test 9.1.1, vérifier que son contenu est pertinent.
  2. Si c’est le cas pour chaque titre, le test est validé.
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 ?
Méthodologie du test 9.1.3
  1. Pour chaque titre identifié au test 9.1.1, vérifier que :
    • soit il est structuré au moyen d’une balise <hx> (“x” désignant une valeur numérique comprise entre 1 et 6) ;
    • soit il est structuré au moyen d’une balise possédant un attribut WAI-ARIA role="heading" et un attribut WAI-ARIA aria-level=x (“x” désignant une valeur numérique).
  2. Si c’est le cas pour chaque titre, le test est validé.
Notes techniques

WAI-ARIA permet de définir des titres via le rôle heading et l’attribut aria-level (indication du niveau de titre). Bien qu’il soit préférable d’utiliser l’élément de titre natif en HTML <hx>, l’utilisation du rôle WAI-ARIA heading est compatible avec l’accessibilité.

Correspondances

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

Tests du critère 9.2

Test 9.2.1 Dans chaque page web, la structure du document vérifie-t-elle ces conditions (hors cas particuliers) ?
Méthodologie du test 9.2.1
  1. Vérifier que la zone d’en-tête est structurée au moyen d’un élément <header>.
  2. Vérifier que les zones de navigation principales et secondaires sont structurées au moyen d’un élément <nav>.
  3. Vérifier que l’élément <nav> n’est pas utilisé en dehors de la structuration des zones de navigation principales et secondaires.
  4. Vérifier que la zone de contenu principal est structurée au moyen d’un élément <main>.
  5. Si le document possède plusieurs éléments <main>, vérifier qu’un seul de ces éléments est visible (les autres occurrences de l’élément sont pourvues d’un attribut hidden).
  6. Vérifier que la zone de pied de page est structurée au moyen d’un élément <footer>.
  7. Si c’est le cas pour chaque zone de contenu, le test est validé.
Cas particuliers

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

Notes techniques

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. À noter cependant que l’utilisation d’un style seul restera insuffisante pour assurer l’unicité d’une balise <main> visible en cas de désactivation des feuilles de styles.

Correspondances

Critère 9.3 [A] : Dans chaque page web, chaque liste est-elle correctement structurée ?

Tests du critère 9.3

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 role="listitem".
Méthodologie du test 9.3.1
  1. Retrouver dans le document les éléments regroupés visuellement sous la forme d’une liste non ordonnée.
  2. Pour chaque liste, vérifier que la liste est structurée :
    • soit au moyen des éléments <ul> et <li> ;
    • soit au moyen d’éléments pourvus d’attributs WAI-ARIA role="list" et role="listitem".
  3. Si c’est le cas pour chaque liste non ordonnée, le test est validé.
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 role="listitem".
Méthodologie du test 9.3.2
  1. Retrouver dans le document les éléments regroupés visuellement sous la forme d’une liste ordonnée.
  2. Pour chaque liste, vérifier que la liste est structurée :
    • soit au moyen des éléments <ol> et <li> ;
    • soit au moyen d’éléments pourvus d’attributs WAI-ARIA role="list" et role="listitem".
  3. Si c’est le cas pour chaque liste ordonnée, le test est validé.
Test 9.3.3 Dans chaque page web, les informations regroupées sous forme de liste de description utilisent-elles les balises <dl> et <dt>/<dd> ?
Méthodologie du test 9.3.3
  1. Retrouver dans le document les éléments regroupés visuellement sous la forme d’une liste de description.
  2. Pour chaque liste, vérifier que la liste est structurée au moyen des éléments <dl>, <dt> et <dd>.
  3. Si c’est le cas pour chaque liste de description, le test est validé.
Notes techniques

Les attributs WAI-ARIA role="list" et role="listitem" peuvent nécessiter l’utilisation des attributs WAI-ARIA 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", role="tablist", role="menu", role="combobox" et role="listbox" ne sont pas équivalents à une liste HTML <ul> ou <ol>.

Correspondances

Critère 9.4 [A] : Dans chaque page web, chaque citation est-elle correctement indiquée ?

Tests du critère 9.4

Test 9.4.1 Dans chaque page web, chaque citation courte utilise-t-elle une balise <q> ?
Méthodologie du test 9.4.1
  1. Retrouver dans le document les citations courtes (ou en ligne).
  2. Pour chaque citation, vérifier que la citation est structurée au moyen d’un élément <q>.
  3. Si c’est le cas pour chaque citation courte, le test est validé.
Test 9.4.2 Dans chaque page web, chaque bloc de citation utilise-t-il une balise <blockquote> ?
Méthodologie du test 9.4.2
  1. Retrouver dans le document les blocs de citation.
  2. Pour chaque bloc de citation, vérifier que le bloc de citation est structuré au moyen d’un élément <blockquote>.
  3. Si c’est le cas pour chaque bloc de citation, le test est validé.
Correspondances

Thématique 10 : Présentation de l’information

Critère 10.1 [A] : Dans le site web, des feuilles de styles sont-elles utilisées pour contrôler la présentation de l’information ?

Tests du critère 10.1

Test 10.1.1 Dans chaque page web, les balises servant à la présentation de l’information ne doivent pas être présentes dans le code source généré des pages. Cette règle est-elle respectée ?
Méthodologie du test 10.1.1
  1. Vérifier l’absence des éléments de présentation <basefont>, <big>, <blink>, <center>, <font>, <marquee>, <s>, <strike>, <tt>.
  2. Vérifier l’absence de l’élément <u> uniquement si le DOCTYPE du document ne correspond pas à HTML 5.
  3. Si c’est le cas, le test est validé.
Test 10.1.2 Dans chaque page web, les attributs servant à la présentation de l’information ne doivent pas être présents dans le code source généré des pages. Cette règle est-elle respectée ?
Méthodologie du test 10.1.2
  1. Vérifier l’absence des attributs de présentation : align, alink, background, bgcolor, border, cellpadding, cellspacing, char, charoff, clear, color, compact, frameborder, hspace, link, marginheight, marginwidth, text, valign, vlink, vspace, size(exception faite de l’élément <select>), width (exception faite des éléments <img>, <object>, <embed>, <canvas> et <svg>), height (exception faite des éléments <img>, <object>, <embed>, <canvas> et <svg>).
  2. Si c’est le cas, le test est validé.
Test 10.1.3 Dans chaque page web, l’utilisation des espaces vérifie-t-elle ces conditions ?
  • Les espaces ne sont pas utilisées pour séparer les lettres d’un mot.
  • Les espaces ne sont pas utilisées pour simuler des tableaux.
  • Les espaces ne sont pas utilisées pour simuler des colonnes de texte.
Méthodologie du test 10.1.3
  1. Désactiver les styles (CSS) du document.
  2. Vérifier l’absence d’espaces utilisées :
    • Entre les lettres d’un mot.
    • Pour créer des effets de marges ou d’alignement.
    • Pour simuler des tableaux ou des colonnes.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 10.2 [A] : Dans chaque page web, le contenu visible porteur d’information reste-t-il présent lorsque les feuilles de styles sont désactivées ?

Tests du critère 10.2

Test 10.2.1 Dans chaque page web, l’information reste-t-elle présente lorsque les feuilles de styles sont désactivées ?
Méthodologie du test 10.2.1
  1. Désactiver les styles (CSS) du document.
  2. Comparer le document dépourvu de styles avec le document mis en forme.
  3. Vérifier si dans le document dépourvu de styles, les contenus visibles porteurs d’information restent présents.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 10.3 [A] : Dans chaque page web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ?

Tests du critère 10.3

Test 10.3.1 Dans chaque page web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ?
Méthodologie du test 10.3.1
  1. Désactiver les styles (CSS) du document.
  2. Vérifier que l’ordre dans lequel les contenus sont implémentés ne pose pas de problème de compréhension.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 10.4 [AA] : Dans chaque page web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu’à 200 %, au moins (hors cas particuliers) ?

Tests du critère 10.4

Test 10.4.1 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 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.
Méthodologie du test 10.4.1
  1. Vérifier dans le document si les textes restent présents et lisibles lorsque :
    • Le zoom texte du navigateur est réglé à 200 %.
    • Le zoom graphique du navigateur est réglé à 200 %.
    • Les fonctionnalités de zoom personnalisées proposé par le document sont utilisés.
  2. Si c’est le cas, le test est validé.
Test 10.4.2 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-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.
Méthodologie du test 10.4.2
  1. Vérifier dans le document si les textes sont effectivement agrandis lorsque :
    • Le zoom texte du navigateur est réglé à 200 %.
    • Le zoom graphique du navigateur est réglé à 200 %.
    • Les fonctionnalités de zoom personnalisées proposé par le document sont utilisés.
  2. Si c’est le cas, le test est validé.
Cas particuliers

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

  • Les sous-titres incrustés dans une vidéo ;
  • Les textes en image ;
  • Le texte au sein d’une balise <canvas>.
Correspondances

Critère 10.5 [AA] : Dans chaque page web, les déclarations CSS de couleurs de fond d’élément et de police sont-elles correctement utilisées ?

Tests du critère 10.5

Test 10.5.1 Dans chaque page web, chaque déclaration CSS de couleurs de police (color), d’un élément susceptible de contenir du texte, est-elle accompagnée d’une déclaration de couleur de fond (background, background-color), au moins, héritée d’un parent ?
Méthodologie du test 10.5.1
  1. Retrouver dans le document les textes mis en couleur, à l’exception des couleurs par défaut (par exemple les liens, etc.).
  2. Déterminer l’élément qui contient le texte et vérifier la présence d’une valeur calculée pour la propriété background-color de l’élément.
  3. Si c’est le cas, le test est validé.
Test 10.5.2 Dans chaque page web, chaque déclaration de couleur de fond (background, background-color), d’un élément susceptible de contenir du texte, est-elle accompagnée d’une déclaration de couleur de police (color) au moins, héritée d’un parent ?
Méthodologie du test 10.5.2
  1. Retrouver dans le document les textes mis en couleur, à l’exception des couleurs par défaut (par exemple les liens, etc.).
  2. Déterminer l’élément qui contient le texte et vérifier la présence d’une valeur calculée pour la propriété color de l’élément.
  3. Si c’est le cas, le test est validé.
Test 10.5.3 Dans chaque page web, chaque utilisation d’une image pour créer une couleur de fond d’un élément susceptible de contenir du texte, via CSS (background, background-image), est-elle accompagnée d’une déclaration de couleur de fond (background, background-color), au moins, héritée d’un parent ?
Méthodologie du test 10.5.3
  1. Retrouver dans le document les textes dont l’arrière-plan est constitué d’une image (propriété background-color).
  2. Déterminer l’élément qui contient le texte et vérifier que si l’image d’arrière-plan est absente, le texte reste lisible.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 10.6 [A] : Dans chaque page web, chaque lien dont la nature n’est pas évidente est-il visible par rapport au texte environnant ?

Tests du critère 10.6

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 a 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.
Méthodologie du test 10.6.1
  1. Retrouver dans le document les éléments de type lien (élément <a> ou élément pourvu d’un attribut WAI-ARIA role="link").
  2. Pour chaque élément de type lien, s’il peut être confondu avec un texte normal lorsqu’il est signalé uniquement par la couleur, vérifier que le contraste entre la couleur de police du lien et la couleur de police du texte environnant est de 3:1, au moins.
  3. Cette vérification doit être faite pour les différents états du lien s’ils sont présentés au moyen d’une couleur différente : l’état non visité, l’état visité, l’état activé, l’état au survol et l’état à la prise de focus.
  4. Si c’est le cas pour chaque élément de type lien, le test est validé.
Correspondances

Critère 10.7 [A] : Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ?

Tests du critère 10.7

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.
Méthodologie du test 10.7.1
  1. Retrouver dans le document les éléments susceptibles de recevoir le focus (les éléments d’interface tels que les liens ou les contrôles de formulaire, ainsi que tout élément pourvu d’un attribut tabindex d’une valeur égale ou supérieure à 1).
  2. Pour chaque élément susceptible de recevoir le focus, vérifier que l’indication visuelle de la prise de focus est présente (en agissant sur le contour ou le fond ou les deux) et est suffisamment contrastée (ratio de contraste égal ou supérieur à 3:1).
  3. Si c’est le cas pour chaque élément susceptible de recevoir le focus, le test est validé.
Correspondances

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

Tests du critère 10.8

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’assistance 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.
Méthodologie du test 10.8.1
  1. Retrouver les contenus cachés (éléments pourvus de l’attribut hidden ou de l’attribut WAI-ARIA aria-hidden, ou bien d’une classe ou d’un ensemble de styles CSS susceptibles de masquer le contenu).
  2. Pour chaque contenu caché, vérifier que :
    • Soit le contenu caché a vocation à être ignoré par les technologies d’assistance (un élément statistique de visites par exemple).
    • Soit le contenu caché n’a pas vocation à être ignoré par les technologies d’assistance, et dans ce cas il est rendu restituable par les technologies d’assistance au moyen :
      • Soit d’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é.
      • Soit d’une fonction de programmation qui repositionne le focus sur le contenu.
  3. Si c’est le cas pour chaque contenu caché, le test est validé.
Notes techniques

WAI-ARIA propose un attribut aria-hidden (true ou false) qui permet d’inhiber la restitution d’un contenu en direction des technologies d’assistance, sans action sur sa visibilité en direction des agents utilisateurs : un contenu avec aria-hidden="true" ne sera donc plus vocalisable, mais restera visible.

Sauf si le contenu contrôlé par aria-hidden n’a pas vocation à être restitué par les technologies d’assistance, la valeur de l’attribut aria-hidden doit être cohérente avec l’état affiché ou masqué du contenu à l’écran.

La spécification HTML5 propose un attribut hidden qui permet de rendre indisponible (quand l’attribut hidden est présent) un contenu dans le DOM généré (de manière similaire au type="hidden" sur un contrôle de formulaire).

Il est possible d’avoir des situations où un contenu contrôlé par hidden ou aria-hidden se trouve momentanément dans un état incohérent avec le statut affiché ou masqué du contenu, par exemple si l’on désire rendre disponible un élément, mais que son affichage à l’écran reste dépendant d’une action ultérieure. Dans ce cas, c’est l’état final du contenu qui doit être considéré.

Correspondances

Critère 10.9 [A] : Dans chaque page web, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?

Tests du critère 10.9

Test 10.9.1 Dans chaque page web, pour chaque texte ou ensemble de textes, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?
Méthodologie du test 10.9.1
  1. Retrouver dans le document les informations d’un texte données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier qu’il existe un autre moyen de récupérer cette information.
  3. Si c’est le cas pour chaque information, le test est validé.
Test 10.9.2 Dans chaque page web, pour chaque image ou ensemble d’images, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?
Méthodologie du test 10.9.2
  1. Retrouver dans le document les informations d’une image données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier qu’il existe un autre moyen de récupérer cette information.
  3. Si c’est le cas pour chaque information, le test est validé.
Test 10.9.3 Dans chaque page web, pour chaque média temporel, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?
Méthodologie du test 10.9.3
  1. Retrouver dans le document les informations d’un média temporel données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier qu’il existe un autre moyen de récupérer cette information.
  3. Si c’est le cas pour chaque information, le test est validé.
Test 10.9.4 Dans chaque page web, pour chaque média non temporel, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?
Méthodologie du test 10.9.4
  1. Retrouver dans le document les informations d’un média non temporel données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier qu’il existe un autre moyen de récupérer cette information.
  3. Si c’est le cas pour chaque information, le test est validé.
Correspondances

Critère 10.10 [A] : Dans chaque page web, l’information ne doit pas être donnée par la forme, taille ou position uniquement. Cette règle est-elle implémentée de façon pertinente ?

Tests du critère 10.10

Test 10.10.1 Dans chaque page web, pour chaque texte ou ensemble de textes, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle implémentée de façon pertinente ?
Méthodologie du test 10.10.1
  1. Retrouver dans le document les informations d’un texte données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier que le moyen alternatif de récupérer cette information est pertinent, c’est-à-dire qu’il permet de transmettre l’information dans tous les contextes de consultation et pour tous les utilisateurs.
  3. Si c’est le cas pour chaque information, le test est validé.
Test 10.10.2 Dans chaque page web, pour chaque image ou ensemble d’images, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle implémentée de façon pertinente ?
Méthodologie du test 10.10.2
  1. Retrouver dans le document les informations d’une image données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier que le moyen alternatif de récupérer cette information est pertinent, c’est-à-dire qu’il permet de transmettre l’information dans tous les contextes de consultation et pour tous les utilisateurs.
  3. Si c’est le cas pour chaque information, le test est validé.
Test 10.10.3 Dans chaque page web, pour chaque média temporel, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle implémentée de façon pertinente ?
Méthodologie du test 10.10.3
  1. Retrouver dans le document les informations d’un média temporel données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier que le moyen alternatif de récupérer cette information est pertinent, c’est-à-dire qu’il permet de transmettre l’information dans tous les contextes de consultation et pour tous les utilisateurs.
  3. Si c’est le cas pour chaque information, le test est validé.
Test 10.10.4 Dans chaque page web, pour chaque média non temporel, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle implémentée de façon pertinente ?
Méthodologie du test 10.10.4
  1. Retrouver dans le document les informations d’un média non temporel données par la forme, la taille ou la position.
  2. Pour chaque information donnée par la forme, la taille ou la position, vérifier que le moyen alternatif de récupérer cette information est pertinent, c’est-à-dire qu’il permet de transmettre l’information dans tous les contextes de consultation et pour tous les utilisateurs.
  3. Si c’est le cas pour chaque information, le test est validé.
Correspondances

Critère 10.11 [AA] : Pour chaque page web, les contenus peuvent-ils être présentés sans perte d’information ou de fonctionnalité et sans avoir recours soit à un défilement vertical pour une fenêtre ayant une hauteur de 256 px, soit à un défilement horizontal pour une fenêtre ayant une largeur de 320 px (hors cas particuliers) ?

Tests du critère 10.11

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 320 px, l’ensemble des informations et des fonctionnalités sont-elles disponibles sans aucun défilement horizontal (hors cas particuliers) ?
Méthodologie du test 10.11.1
  1. Retrouver dans le document si son contenu est conçu pour défiler verticalement (le sens de lecture du texte est horizontal), les informations et fonctionnalités.
  2. Réduire la fenêtre d’affichage à une largeur de 320 px et vérifier que les informations et les fonctionnalités restent disponibles sans aucun défilement horizontal.
  3. Si c’est le cas, le test est validé.
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 256 px, l’ensemble des informations et des fonctionnalités sont-elles disponibles sans aucun défilement vertical (hors cas particuliers) ?
Méthodologie du test 10.11.2
  1. Retrouver dans le document si son contenu est conçu pour défiler horizontalement (le sens de lecture du texte est vertical), les informations et fonctionnalités.
  2. Réduire la fenêtre d’affichage à une hauteur de 256 px et vérifier que les informations et les fonctionnalités restent disponibles sans aucun défilement vertical.
  3. Si c’est le cas, le test est validé.
Cas particuliers

L’objectif de ce critère est de garantir un défilement dans une unique direction pour une lecture facilitée selon le sens de l’écriture.

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 ;
  • 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 sur 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.

Note technique

Lorsqu’il est ici question de pixel, il s’agit du pixel CSS tel que défini par le W3C https://www.w3.org/TR/css3-values/

Correspondances

Critère 10.12 [AA] : 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) ?

Tests du critère 10.12

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.
Méthodologie du test 10.12.1
  1. Modifier les styles du document en donnant :
    • une valeur de 1.5 à la propriété line-height de tous les éléments du document ;
    • une valeur de 2em à la propriété margin-bottom des éléments <p> ;
    • une valeur de 0.12em à la propriété letter-spacing de tous les éléments du document ;
    • une valeur de 0.16em à la propriété word-spacing de tous les éléments du document.
  2. Pour chaque passage de texte, vérifier qu’il reste lisible, à l’exception :
    • des sous-titres directement intégrés à une vidéo ;
    • des images texte ;
    • des textes au sein d’une balise <canvas>.
  3. Si c’est le cas pour chaque passage de texte, le test est validé.

Note : une implémentation de ces règles de modification est disponible dans les ressources du critère de succès WCAG 1.4.12 (https://github.com/alastc/adaptation-scripts/blob/master/scripts/text-adaptation.js).

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>.
Correspondances

Critère 10.13 [AA] : 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) ?

Tests du critère 10.13

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 de l’utilisateur sans déplacer le focus ou le pointeur de la souris (hors cas particuliers) ?
Méthodologie du test 10.13.1
  1. Retrouver dans le document les contenus additionnels devenant visible à la prise de focus ou au survol d’un composant d’interface, à l’exception :
    • Des contenus additionnels contrôlés par l’agent utilisateur (par exemple, les infobulles associées à l’attribut title ou à la validation native d’un formulaire.
    • Des contenus additionnels devenant visibles par une activation de l’utilisateur (par exemple, une fenêtre de dialogue).
  2. Pour chaque contenu additionnel, vérifier que :
    • Soit le contenu additionnel est positionné de façon à ce qu’il ne gêne pas la consultation des autres contenus informatifs sur lesquels il viendrait se superposer (y compris le composant d’interface qui a déclenché son apparition), quelles que soient les conditions de consultation (y compris lors de l’utilisation d’un mécanisme de zoom).
    • Soit un mécanisme (au clavier) permet de faire disparaître le contenu additionnel (par exemple, la touche Echap).
  3. Si c’est le cas pour chaque contenu additionnel, le test est validé.
Test 10.13.2 Chaque contenu additionnel qui apparait au survol d’un composant d’interface peut-il être survolé par le pointeur de la souris sans disparaître (hors cas particuliers) ?
Méthodologie du test 10.13.2
  1. Retrouver dans le document les contenus additionnels devenant visible au survol d’un composant d’interface, à l’exception :
    • des contenus additionnels contrôlés par l’agent utilisateur (par exemple, les infobulles associées à l’attribut title ou à la validation native d’un formulaire) ;
    • des contenus additionnels devenant visibles par une activation de l’utilisateur (par exemple, une fenêtre de dialogue).
  2. Pour chaque contenu additionnel, vérifier qu’il peut être survolé par le pointeur de la souris sans disparaître.
  3. Si c’est le cas pour chaque contenu additionnel, le test est validé.
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 que l’utilisateur déclenche une action masquant ce contenu sans déplacer le focus ou le pointeur de la souris du composant d’interface ayant déclenché son apparition.
  • Le contenu additionnel reste visible jusqu’à ce qu’il ne soit plus valide.
Méthodologie du test 10.13.3
  1. Retrouver dans le document les contenus additionnels devenant visible à la prise de focus ou au survol d’un composant d’interface, à l’exception :
    • des contenus additionnels contrôlés par l’agent utilisateur (par exemple, les infobulles associées à l’attribut title ou à la validation native d’un formulaire) ;
    • des contenus additionnels devenant visibles par une activation de l’utilisateur (par exemple, une fenêtre de dialogue).
  2. Pour chaque contenu additionnel, vérifier qu’il reste visible :
    • jusqu’à ce que l’utilisateur retire le pointeur souris ou le focus du contenu additionnel ou du composant d’interface ayant déclenché son apparition ;
    • jusqu’à ce l’utilisateur déclenche le mécanisme prévu pour faire disparaître le contenu additionnel ;
    • jusqu’à ce que l’information proposée par le contenu additionnel ne soit plus valide (par exemple un contenu additionnel signalant l’état “occupé” du composant d’interface que l’utilisateur souhaite activer ou encore un message d’erreur signalé sous la forme d’un contenu additionnel tant que l’utilisateur n’a pas rectifié sa saisie).
  3. Si c’est le cas pour chaque contenu additionnel, le test est validé.
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.

Correspondances

Critère 10.14 [A] : 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 ?

Tests du critère 10.14

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.
Méthodologie du test 10.14.1
  1. Retrouver dans le document les contenus additionnels devenant visible au survol d’un composant d’interface au moyen d’un mécanisme CSS (pseudo-classe :hover).
  2. Pour chaque contenu additionnel, vérifier que les contenus additionnels apparaissent également :
    • À l’activation du composant au moyen du clavier ou de tout autre dispositif de pointage.
    • À la prise de focus du composant.
    • À l’activation ou à la prise de focus d’un autre composant.
  3. Si c’est le cas pour chaque contenu additionnel, le test est validé.
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.
Méthodologie du test 10.14.2
  1. Retrouver dans le document les contenus additionnels devenant visible à la prise de focus d’un composant d’interface au moyen d’un mécanisme CSS (pseudo-classe :focus).
  2. Pour chaque contenu additionnel, vérifier que les contenus additionnels apparaissent également :
  • À l’activation du composant au moyen du clavier ou de tout autre dispositif de pointage.
  • Au survol du composant.
  • À l’activation ou du survol d’un autre composant.
  1. Si c’est le cas pour chaque contenu additionnel, le test est validé.
Correspondances

Thématique 11 : Formulaires

Critère 11.1 [A] : Chaque champ de formulaire a-t-il une étiquette ?

Tests du critère 11.1

Test 11.1.1 Chaque champ de formulaire vérifie-t-il une de ces conditions ?
Méthodologie du test 11.1.1
  1. Retrouver dans le document les champs de formulaire.
  2. Pour chaque champ de formulaire, vérifier que le champ de formulaire :
    • possède un attribut WAI-ARIA aria-labelledby référençant un passage de texte identifié ;
    • possède un attribut WAI-ARIA aria-label ;
    • est associé à un élément <label> ayant un attribut for ;
    • possède un attribut title ;
    • un bouton adjacent au champ de formulaire lui fournit une étiquette visible et un élément <label> visuellement caché ou un attribut WAI-ARIA aria-label, aria-labelledby ou title lui fournit un nom accessible.
  3. Si c’est le cas pour champ de formulaire, le test est validé.
Test 11.1.2 Chaque champ de formulaire associé à une balise <label> ayant un attribut for, vérifie-t-il ces conditions ?
Méthodologie du test 11.1.2
  1. Retrouver dans le document les champs de formulaire associé à un élément <label>.
  2. Pour chaque champ de formulaire, vérifier que :
    • Le champ de formulaire possède un attribut id.
    • La valeur de l’attribut for de l’élément <label> est égale à la valeur de l’attribut id.
  3. Si c’est le cas pour champ de formulaire, le test est validé.
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.
Méthodologie du test 11.1.3
  1. Retrouver dans le document les champs de formulaire dont l’étiquette n’est pas visible ou à proximité (masquée, utilisation de l’attribut aria-label) ou n’est pas accolée au champ (utilisation de l’attribut aria-labelledby).
  2. Pour chaque champ de formulaire, vérifier que le champ de formulaire :
    • soit possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue ;
    • 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 ;
    • est accompagné d’un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue.
Correspondances

Critère 11.2 [A] : Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ?

Tests du critère 11.2

Test 11.2.1 Chaque balise <label> permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée ?
Méthodologie du test 11.2.1
  1. Retrouver dans le document les champs de formulaire dont l’étiquette est fournie par un élément <label>.
  2. Pour chaque champ de formulaire, vérifier que le contenu de l’élément est pertinent.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Test 11.2.2 Chaque attribut title permet-il de connaître la fonction exacte du champ de formulaire auquel il est associé ?
Méthodologie du test 11.2.2
  1. Retrouver dans le document les champs de formulaire dont l’étiquette est fournie par un attribut title.
  2. Pour chaque champ de formulaire, vérifier que le contenu de l’attribut est pertinent.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Test 11.2.3 Chaque étiquette implémentée via l’attribut WAI-ARIA aria-label permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée ?
Méthodologie du test 11.2.3
  1. Retrouver dans le document les champs de formulaire dont l’étiquette est fournie par un attribut WAI-ARIA aria-label.
  2. Pour chaque champ de formulaire, vérifier que le contenu de l’attribut est pertinent.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
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é ?
Méthodologie du test 11.2.4
  1. Retrouver dans le document les champs de formulaire dont l’étiquette est fournie par un attribut WAI-ARIA aria-labelledby.
  2. Pour chaque champ de formulaire, vérifier que le contenu du passage de texte référencé est pertinent.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Test 11.2.5 Chaque champ de formulaire ayant un intitulé visible vérifie-t-il ces conditions (hors cas particuliers) ?
Méthodologie du test 11.2.5
  1. Retrouver dans le document les champs de formulaire dont l’étiquette est fournie à la fois par un intitulé visible et par le contenu soit d’un élément <label>, soit d’un attribut title ou d’un attribut aria-label ou d’un attribut aria-labelledby.
  2. Pour chaque champ de formulaire, vérifier que le contenu de l’élément <label> ou de l’attribut title ou de l’attribut aria-label ou de l’attribut aria-labelledby contient l’intitulé visible.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
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é ?
Méthodologie du test 11.2.6
  1. Retrouver dans le document les champs de formulaire dont l’étiquette visible est fournie par un bouton adjacent.
  2. Pour chaque champ de formulaire, vérifier que le contenu visible du bouton est pertinent.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers 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”).

Ce cas particulier s’applique également au test 11.9.2.

Correspondances

Critère 11.3 [AA] : Dans chaque formulaire, chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages est-elle cohérente ?

Tests du critère 11.3

Test 11.3.1 Chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page est-elle cohérente ?
Méthodologie du test 11.3.1
  1. Retrouver dans le document les champs de formulaire ayant une même fonction (par exemple plusieurs champs d’adresse).
  2. Pour chaque champ de formulaire, vérifier que les étiquettes sont cohérentes (elles permettent de comprendre qu’il s’agit de saisies de natures identiques).
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Test 11.3.2 Chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée dans un ensemble de pages est-elle cohérente ?
Méthodologie du test 11.3.2
  1. Retrouver dans l’ensemble des pages considérées les champs de formulaire ayant une même fonction (par exemple le champ de saisie d’un moteur de recherche ou le champ de saisie d’inscription à une newsletter).
  2. Pour chaque champ de formulaire, vérifier que les étiquettes sont cohérentes (elles permettent de comprendre qu’il s’agit de saisies de natures identiques).
  3. Si c’est le cas pour chaque champ de formulaire de l’ensemble des pages considérées, le test est validé.
Correspondances

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

Tests du critère 11.4

Test 11.4.1 Chaque étiquette de champ et son champ associé sont-ils accolés ?
Méthodologie du test 11.4.1
  1. Retrouver dans le document les champs de formulaire.
  2. Pour chaque champ de formulaire, vérifier qu’il est accolé à son étiquette.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Test 11.4.2 Chaque étiquette accolée à un champ (à l’exception des cases à cocher, bouton radio ou balises 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.
Méthodologie du test 11.4.2
  1. Retrouver dans le document les champs de formulaire qui ne sont pas des éléments <input> de type checkbox ou de type radio ou des éléments ayant un attribut WAI-ARIA role="checkbox", role="radio" ou role="switch".
  2. Pour chaque champ de formulaire, vérifier que 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.
    • 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.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
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-dessous 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-dessous ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de droite à gauche.
Méthodologie du test 11.4.3
  1. Retrouver dans le document les champs de formulaire qui sont <input> de type checkbox ou de type radio ou des éléments ayant un attribut WAI-ARIA role="checkbox", role="radio" ou role="switch".
  2. Pour chaque champ de formulaire, vérifier que l’étiquette est visuellement accolée :
    • Immédiatement au-dessous ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de gauche à droite.
    • Immédiatement au-dessous ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de droite à gauche.
  3. Si c’est le cas pour chaque champ de formulaire, le test est validé.
Cas particuliers

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

  • 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 ou 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.
Correspondances

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

Tests du critère 11.5

Test 11.5.1 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 role="group".
Méthodologie du test 11.5.1
  1. Retrouver dans le document les champs de formulaire de même nature (par exemple un groupe de saisie d’informations d’identité, une série de cases à cocher, une saisie de date sur plusieurs champs successifs…).
  2. Pour chaque groupe de champs de formulaire de même nature, vérifier que ces champs de même nature sont regroupés :
    • soit dans un élément <fieldset> ;
    • soit dans un élément possédant un attribut WAI-ARIA role="group" ;
    • soit dans un élément possédant un attribut WAI-ARIA role="radiogroup" ou "group", s’il s’agit d’éléments <input> de type radio ( ou d’éléments possédant un attribut WAI-ARIA role="radio").
  3. Si c’est le cas pour chaque groupe de champs de formulaire de même nature, le test est validé.
Correspondances

Critère 11.6 [A] : Dans chaque formulaire, chaque regroupement de champs de même nature a-t-il une légende ?

Tests du critère 11.6

Test 11.6.1 Chaque regroupement de champs de même nature possède-t-il une légende ?
Méthodologie du test 11.6.1
  1. Retrouver dans le document les groupes de champs de formulaire de même nature.
  2. Pour chaque groupe de champs de formulaire de même nature, vérifier que :
    • Si le regroupement utilise un élément <fieldset>, l’élément <fieldset> possède un élément <legend>.
    • Si l’élément de regroupement utilise un attribut WAI-ARIA role="group" ou "radiogroup", il possède un attribut WAI-ARIA aria-label ou aria-labelledby.
  3. Sinon, pour chacun des champs de même nature, vérifier la présence :
    • soit d’un attribut title permettant de déterminer l’appartenance du champ au groupement de champ ;
    • soit d’un attribut aria-label permettant de déterminer l’appartenance du champ au groupement de champ ;
    • soit d’un attribut aria-labelledby qui référence un passage de texte permettant de déterminer l’appartenance du champ au groupement de champ ;
    • soit d’un attribut aria-describedby qui référence un passage de texte permettant de déterminer l’appartenance du champ au groupement de champ ;
  4. Si c’est le cas pour chaque groupe de champs de formulaire ou pour chacun des champs de même nature, le test est validé.
Correspondances

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

Tests du critère 11.7

Test 11.7.1 Chaque légende associée à un regroupement de champs de même nature est-elle pertinente ?
Méthodologie du test 11.7.1
  1. Retrouver dans le document les groupes de champs de formulaire de même nature.
  2. Pour chaque groupe de champs de formulaire de même nature ou pour chacun des champs de même nature qui dispose d’une légende, vérifier que le texte de cette légende est pertinent.
  3. Si c’est le cas pour chaque groupe de champs de formulaire ou pour chacun des champs de même nature, le test est validé.
Correspondances

Critère 11.8 [A] : Dans chaque formulaire, les items de même nature d’une liste de choix sont-ils regroupés de manière pertinente ?

Tests du critère 11.8

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 ?
Méthodologie du test 11.8.1
  1. Retrouver dans le document les listes de sélection (élément <select>).
  2. Pour chaque liste de sélection proposant des groupes d’items de même nature, vérifier que ces items sont regroupés au moyen d’éléments <optgroup>.
  3. Si c’est le cas pour chaque liste de sélection proposant des groupes d’items de même nature, le test est validé.
Test 11.8.2 Dans chaque balise <select>, chaque balise <optgroup> possède-t-elle un attribut label ?
Méthodologie du test 11.8.2
  1. Retrouver dans le document les listes de sélection (élément <select>) qui possèdent des éléments <optgroup>.
  2. Pour chaque élément <optgroup>, vérifier qu’il possède un attribut label.
  3. Si c’est le cas pour chaque élément <optgroup>, le test est validé.
Test 11.8.3 Pour chaque balise <optgroup> ayant un attribut label, le contenu de l’attribut label est-il pertinent ?
Méthodologie du test 11.8.3
  1. Retrouver dans le document les listes de sélection (élément <select>) qui possèdent des éléments <optgroup> pourvus d’un attribut label.
  2. Pour chaque attribut label, vérifier que son contenu est pertinent.
  3. Si c’est le cas pour chaque attribut label, le test est validé.
Notes techniques

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 via l’utilisation de WAI-ARIA. De ce fait, une liste nécessitant un regroupement d’options 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.

Correspondances

Critère 11.9 [A] : Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent (hors cas particuliers) ?

Tests du critère 11.9

Test 11.9.1 L’intitulé de chaque bouton vérifie-t-il ces conditions (hors cas particuliers) ?
  • 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.
Méthodologie du test 11.9.1
  1. Retrouver dans le document les boutons présents au sein d’un formulaire.
  2. Pour chaque bouton, vérifier que son intitulé visible et son nom accessible sont pertinents.
  3. Si c’est le cas pour chaque bouton, le test est validé.
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.
Méthodologie du test 11.9.2
  1. Retrouver dans le document les boutons présents au sein d’un formulaire.
  2. Pour chaque bouton, vérifier que son nom accessible contient au moins son intitulé visible.
  3. Si c’est le cas pour chaque bouton, le test est validé.
Cas particuliers

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

Correspondances

Critère 11.10 [A] : Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ?

Tests du critère 11.10

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.
Méthodologie du test 11.10.1
  1. Retrouver dans le document les champs de formulaire obligatoires.
  2. Pour chaque champ de formulaire, vérifier que préalablement à la validation du formulaire :
    • soit une indication de champ obligatoire est visible et permet d’identifier nommément le champ concerné ;
    • soit le champ possède un attribut aria-required="true" ou required.
  3. Si c’est le cas pour chaque champ de formulaire obligatoire, le test est validé.
Test 11.10.2 Les champs obligatoires ayant l’attribut aria-required="true" ou required vérifient-ils une de ces conditions ?
Méthodologie du test 11.10.2
  1. Retrouver dans le document les champs de formulaire obligatoires qui possèdent un attribut aria-required="true" ou required.
  2. Pour chaque champ de formulaire, vérifier que préalablement à la validation du formulaire :
    • soit une indication de champ obligatoire est visible et située dans l’étiquette associée au champ ;
    • soit une indication de champ obligatoire est visible et située dans le passage de texte associé au champ.
  3. Si c’est le cas pour chaque champ de formulaire obligatoire qui possèdent un attribut aria-required="true" ou required, le test est validé.
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".
Méthodologie du test 11.10.3
  1. Retrouver dans le document les messages d’erreur indiquant l’absence de saisie d’un champ obligatoire.
  2. Pour chaque message d’erreur, vérifier que :
    • soit le message d’erreur est visible et permet d’identifier nommément le champ concerné ;
    • soit le champ obligatoire associé au message d’erreur possède un attribut aria-invalid="true".
  3. Si c’est le cas pour chaque message d’erreur indiquant l’absence de saisie d’un champ obligatoire, le test est validé.
Test 11.10.4 Les champs obligatoires ayant l’attribut aria-invalid="true" vérifient-ils une de ces conditions ?
  • Le message d’erreur indiquant le caractère invalide de la saisie est visible et situé dans l’étiquette associée au champ.
  • Le message d’erreur indiquant le caractère invalide de la saisie est visible et situé dans le passage de texte associé au champ.
Méthodologie du test 11.10.4
  1. Retrouver dans le document les champs de formulaire obligatoires qui possèdent un attribut aria-invalid="true".
  2. Pour chaque champ de formulaire, vérifier que :
    • soit le message d’erreur indiquant le caractère invalide de la saisie est visible et situé dans l’étiquette associée au champ ;
    • soit le message d’erreur indiquant le caractère invalide de la saisie est visible et situé dans le passage de texte associé au champ.
  3. Si c’est le cas pour chaque champ de formulaire obligatoire qui possède un attribut aria-invalid="true", le test est validé.
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.
Méthodologie du test 11.10.5
  1. Retrouver dans le document les champs de formulaire obligatoires auxquels est associée une instruction ou une indication du type de données et/ou de format obligatoire.
  2. Pour chaque champ de formulaire, vérifier que l’instruction ou l’indication du type de données et/ou de format obligatoire est préalablement à la validation du formulaire :
    • soit visible et permet d’identifier nommément le champ concerné ;
    • soit visible dans l’étiquette ou le passage de texte associé au champ.
  3. Si c’est le cas pour chaque champ de formulaire obligatoire auquel est associée une instruction ou une indication du type de données et/ou de format obligatoire, le test est validé.
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".
Méthodologie du test 11.10.6
  1. Retrouver dans le document les messages d’erreur fournissant une instruction ou une indication du type de données et/ou de format obligatoire d’un champ.
  2. Pour chaque message d’erreur, vérifier que :
    • soit le message d’erreur est visible et permet d’identifier nommément le champ concerné ;
    • soit le champ associé au message d’erreur possède un attribut aria-invalid="true".
  3. Si c’est le cas pour chaque message d’erreur indiquant l’absence de saisie d’un champ obligatoire, le test est validé.
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.
Méthodologie du test 11.10.7
  1. Retrouver dans le document les champs de formulaire qui possèdent un attribut aria-invalid="true".
  2. Pour chaque champ de formulaire, vérifier que :
    • soit une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans l’élément <label> associé au champ ;
    • soit 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.
  3. Si c’est le cas pour chaque champ de formulaire qui possède un attribut aria-invalid="true", le test est validé.
Cas particuliers

Le test 11.10.1 et le test 11.10.2 seront considérés comme non applicables 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, les tests 11.10.1 et 11.10.2 restent applicables.

Notes techniques

Dans un long formulaire dont la majorité des champs sont obligatoires, on pourrait constater que ce sont les quelques champs restés facultatifs qui sont explicitement signalés comme tels. Dans ce cas, il faudrait s’assurer que :

  • Un message précise visuellement en haut de formulaire que « tous les champs sont obligatoires sauf ceux indiqués comme étant facultatifs » ;
  • Une mention « facultatif » est présente visuellement dans le libellé des champs facultatifs ou dans la légende d’un groupe de champs facultatifs ;
  • Un attribut required ou aria-required="true" reste associé à chaque champ qui n’est pas concerné par ce caractère facultatif.
Correspondances

Critère 11.11 [AA] : Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ?

Tests du critère 11.11

Test 11.11.1 Pour chaque erreur de saisie, les types et les formats de données sont-ils suggérés, si nécessaire ?
Méthodologie du test 11.11.1
  1. Retrouver dans le document les messages d’erreur.
  2. Pour chaque message d’erreur, vérifier que les types et les formats de données attendus sont suggérés.
  3. Si c’est le cas pour chaque message d’erreur, le test est validé.
Test 11.11.2 Pour chaque erreur de saisie, des exemples de valeurs attendues sont-ils suggérés, si nécessaire ?
Méthodologie du test 11.11.2
  1. Retrouver dans le document les messages d’erreur.
  2. Pour chaque message d’erreur, vérifier que des exemples de valeurs attendues sont suggérés.
  3. Si c’est le cas pour chaque message d’erreur, le test est validé.
Notes techniques

Certains types de contrôles en HTML5 proposent des messages d’aide à la saisie automatique : par exemple le type email affiche 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, ce qui permet de personnaliser les messages d’erreur et de valider le critère. L’attribut pattern permet d’effectuer automatiquement des contrôles de format (via des expressions régulières) et affiche un message d’aide personnalisable via l’attribut title : ce dispositif valide également le critère.

Correspondances

Critère 11.12 [AA] : 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, les données saisies peuvent-elles être modifiées, mises à jour ou récupérées par l’utilisateur ?

Tests du critère 11.12

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.
Méthodologie du test 11.12.1
  1. Retrouver dans le document les formulaires qui modifient ou suppriment des données, ou qui transmettent des réponses à un test ou un examen, ou dont la validation a des conséquences financières ou juridiques.
  2. Pour chaque formulaire, vérifier que l’utilisateur peut :
    • soit modifier ou annuler les données et les actions effectuées sur ces données après la validation du formulaire ;
    • soit vérifier et corriger les données avant la validation d’un formulaire en plusieurs étapes ;
    • soit disposer d’un mécanisme de confirmation explicite (par exemple, une case à cocher ou une étape supplémentaire).
  3. Si c’est le cas pour chaque formulaire retrouvé, le test est validé.
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é.
Méthodologie du test 11.12.2
  1. Retrouver dans le document les formulaires qui modifient ou suppriment des données à caractère financier, juridique ou personnel.
  2. Pour chaque formulaire, vérifier que l’utilisateur dispose :
    • soit d’un mécanisme qui permet de récupérer les données supprimées ou modifiées ;
    • soit d’un mécanisme de demande de confirmation explicite de la suppression ou de la modification (par exemple, une case à cocher ou une étape supplémentaire).
  3. Si c’est le cas pour chaque formulaire retrouvé, le test est validé.
Correspondances

Critère 11.13 [AA] : 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 ?

Tests du critère 11.13

Test 11.13.1 Chaque champ de formulaire dont l’objet se rapporte à une information concernant l’utilisateur vérifie-t-il ces conditions ?
Méthodologie du test 11.13.1
  1. Retrouver dans le document les champs de formulaire qui se rapportent à une information concernant l’utilisateur (nom, prénom, numéro de téléphone, etc.).
  2. Pour chaque champ de formulaire, vérifier que :
    • 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.
    • La valeur indiquée pour l’attribut autocomplete est pertinente au regard du type d’information attendu.
  3. Si c’est le cas pour chaque champ de formulaire retrouvé, le test est validé.
Notes techniques

La liste des valeurs possibles pour l’attribut autocomplete repose sur la liste des valeurs présentes dans la spécification 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".

Correspondances

Thématique 12 : Navigation

Critère 12.1 [AA] : Chaque ensemble de pages dispose-t-il de deux systèmes de navigation différents, au moins (hors cas particuliers) ?

Tests du critère 12.1

Test 12.1.1 Chaque ensemble de pages vérifie-t-il une de ces conditions (hors cas particuliers) ?
Méthodologie du test 12.1.1
  1. Pour chaque ensemble de pages du site, vérifier la présence :
    • Soit d’un menu de navigation et d’un plan du site.
    • Soit d’un menu de navigation et d’un moteur de recherche.
    • Soit d’un moteur de recherche et d’un plan du site.
  2. Si c’est le cas pour chaque ensemble de pages du site, le test est validé.
Cas particuliers

Il existe une gestion de cas particulier lorsque le site web est constitué d’une seule page ou d’un nombre très limité de pages (cf. note). Dans ce cas-là, le critère est non applicable.

Le critère est également non applicable pour les pages d’un ensemble de pages qui sont le résultat ou une partie d’un processus (un processus de paiement ou de prise de commande, par exemple).

Note : l’appréciation d’un nombre très limité de pages devrait être réservé à un site dont l’ensemble des pages sont atteignables depuis la page d’accueil.

Correspondances

Critère 12.2 [AA] : Dans chaque ensemble de pages, le menu et les barres de navigation sont-ils toujours à la même place (hors cas particuliers) ?

Tests du critère 12.2

Test 12.2.1 Dans chaque ensemble de pages, chaque page disposant d’un menu et les barres de navigation vérifie-t-elle ces conditions (hors cas particuliers) ?
Méthodologie du test 12.2.1
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer visuellement les deux pages et vérifier que le menu ou les barres de navigation sont toujours à la même place dans la présentation.
  3. Comparer le code source (généré côté client) des deux pages et vérifier que le menu ou les barres de navigation se présentent toujours dans le même ordre relatif dans la structure.
  4. Si c’est le cas, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers lorsque :

  • La page est la page d’accueil ;
  • Le site web est constitué d’une seule page ;
  • Le changement fait suite à une modification initiée par l’utilisateur.

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

Correspondances

Critère 12.3 [AA] : La page « plan du site » est-elle pertinente ?

Tests du critère 12.3

Test 12.3.1 La page « plan du site » est-elle représentative de l’architecture générale du site ?
Méthodologie du test 12.3.1
  1. Vérifier que le plan du site est représentatif de l’architecture générale du site (cf. note).
  2. Si c’est le cas, le test est validé.

Note : Un plan du site trop complexe ou trop profond n’est pas recommandé pour aider à la navigation. Il n’est pas obligatoire que toutes les pages soient présentes dans le plan du site si elles peuvent être atteintes, par exemple, à partir de la page d’accueil d’une rubrique ou d’un catalogue.

Test 12.3.2 Les liens du plan du site sont-ils fonctionnels ?
Méthodologie du test 12.3.2
  1. Pour tous les liens du plan du site, vérifier qu’ils sont fonctionnels.
  2. Si c’est le cas, le test est validé.
Test 12.3.3 Les liens du plan du site renvoient-ils bien vers les pages indiquées par l’intitulé ?
Méthodologie du test 12.3.3
  1. Pour tous les liens du plan du site, vérifier qu’ils sont à jour (ni obsolètes ni en erreur) et conduisent à la page indiquée par leur intitulé.
  2. Si c’est le cas, le test est validé.
Correspondances

Critère 12.4 [AA] : Dans chaque ensemble de pages, la page « plan du site » est-elle accessible à partir d’une fonctionnalité identique ?

Tests du critère 12.4

Test 12.4.1 Dans chaque ensemble de pages, la page « plan du site » est-elle accessible à partir d’une fonctionnalité identique ?
Méthodologie du test 12.4.1
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer le code source (généré côté client) des deux pages et vérifier que le moyen d’accès au plan du site est toujours le même (un lien ou un bouton, par exemple).
  3. Si c’est le cas, le test est validé.
Test 12.4.2 Dans chaque ensemble de pages, la fonctionnalité vers la page « plan du site » est-elle située à la même place dans la présentation ?
Méthodologie du test 12.4.2
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer le code source (généré côté client) des deux pages et vérifier que le moyen d’accès au plan du site est toujours à la même place dans la structure (par rapport à l’ordre relatif des éléments de la page, par exemple il est toujours en haut de page).
  3. Si c’est le cas, le test est validé.
Test 12.4.3 Dans chaque ensemble de pages, la fonctionnalité vers la page « plan du site » se présente-t-elle toujours dans le même ordre relatif dans le code source ?
Méthodologie du test 12.4.3
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer visuellement les deux pages et vérifier que le moyen d’accès au plan du site est toujours à la même place dans la présentation.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 12.5 [AA] : Dans chaque ensemble de pages, le moteur de recherche est-il atteignable de manière identique ?

Tests du critère 12.5

Test 12.5.1 Dans chaque ensemble de pages, le moteur de recherche est-il accessible à partir d’une fonctionnalité identique ?
Méthodologie du test 12.5.1
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer le code source (généré côté client) des deux pages et vérifier que le moyen d’accès au moteur de recherche est toujours le même (un champ de formulaire, par exemple).
  3. Si c’est le cas, le test est validé.
Test 12.5.2 Dans chaque ensemble de pages, la fonctionnalité vers le moteur de recherche est-elle située à la même place dans la présentation ?
Méthodologie du test 12.5.2
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer visuellement les deux pages et vérifier que le moyen d’accès au moteur de recherche est toujours à la même place dans la présentation.
  3. Si c’est le cas, le test est validé.
Test 12.5.3 Dans chaque ensemble de pages, la fonctionnalité vers le moteur de recherche se présente-t-elle toujours dans le même ordre relatif dans le code source ?
Méthodologie du test 12.5.3
  1. Choisir une page de l’échantillon appartenant au même ensemble que la page en cours d’audit.
  2. Comparer le code source (généré côté client) des deux pages et vérifier que le moyen d’accès au moteur de recherche est toujours à la même place dans la structure (par rapport à l’ordre relatif des éléments de la page, par exemple il est toujours en haut de page).
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 12.6 [A] : 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 ?

Tests du critère 12.6

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 correspondant à sa nature.
  • La zone possède un titre 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édent 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édent 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 ou, à défaut, visible à la prise de focus.
Méthodologie du test 12.6.1
  1. Retrouver dans le document les zones de regroupement de contenus (zones d’en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche).
  2. Pour chaque zone, vérifier que la zone :
    • soit possède un rôle WAI-ARIA de type landmark correspondant à sa nature ;
    • soit possède un titre de hiérarchie dont le contenu permet de comprendre la nature du contenu de la zone ;
    • soit peut être masquée au moyen d’un bouton précédant directement la zone dans l’ordre du code source ;
    • soit peut être évitée au moyen d’un lien d’évitement précédant directement la zone dans l’ordre du code source ;
    • soit peut être atteinte au moyen d’un lien d’accès rapide soit visible par défaut, soit visible à la prise de focus lors d’une tabulation.
  3. Si c’est le cas pour chaque zone de regroupement de contenus, le test est validé.
Correspondances

Critère 12.7 [A] : 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) ?

Tests du critère 12.7

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) ?
Méthodologie du test 12.7.1
  1. Retrouver dans le document la zone de contenu principal (indiquée par l’élément main visible).
  2. Vérifier que la zone :
    • soit peut être évitée au moyen d’un lien d’évitement précédant directement la zone dans l’ordre du code source ;
    • soit peut être atteinte au moyen d’un lien d’accès rapide visible à la prise de focus lors d’une tabulation.
  3. Si c’est le cas, le test est validé.
Test 12.7.2 Dans chaque ensemble de pages, le lien d’évitement ou d’accès rapide à la zone de contenu principal vérifie-t-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 ou, à défaut, visible à la prise de focus.
  • Le lien est fonctionnel.
Méthodologie du test 12.7.2
  1. Retrouver dans le document la zone de contenu principal (indiquée par l’élément main visible).
  2. Vérifier que le lien d’évitement ou d’accès rapide à la zone est :
    • situé à la même place dans la présentation ;
    • présent toujours dans le même ordre relatif dans le code source (généré côté client) ;
    • visible à la prise de focus lors d’une tabulation ;
    • fonctionnel.
  3. Si c’est le cas, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers lorsque le site web est constitué d’une seule page.

Dans ce cas de figure, l’obligation de la présence d’un lien d’accès rapide est liée au contexte de la page : présence ou absence de navigation ou de contenus additionnels, par exemple. Le critère peut être considéré comme non applicable lorsqu’il est avéré qu’un lien d’accès rapide est inutile.

Correspondances

Critère 12.8 [A] : Dans chaque page web, l’ordre de tabulation est-il cohérent ?

Tests du critère 12.8

Test 12.8.1 Dans chaque page web, l’ordre de tabulation dans le contenu est-il cohérent ?
Méthodologie du test 12.8.1
  1. Parcourir dans le document l’ensemble des contenus au moyen de la touche de tabulation vers l’avant (touche Tab) et vers l’arrière (touches Maj+Tab).
  2. Vérifier que l’ordre de déplacement du focus reste cohérent relativement au contenu considéré (par exemple, l’ordre de tabulation dans une fenêtre modale ne doit considérer que les éléments d’interface présents au sein de cette fenêtre).
  3. Si c’est le cas, le test est validé.

Note : il n’est pas obligatoire que la tabulation suive l’ordre de lecture naturel (de gauche à droite et de haut en bas par exemple) tant que les éléments sont accessibles dans un ordre cohérent.

Test 12.8.2 Pour chaque script qui met à jour ou insère un contenu, l’ordre de tabulation reste-t-il cohérent ?
Méthodologie du test 12.8.2
  1. Retrouver dans le document l’ensemble des contenus insérés au moyen d’un script (affichage d’éléments masqués, mise jour de contenu via AJAX par exemple).
  2. Positionner la tabulation sur l’élément déclencheur et l’activer.
  3. Après l’affichage du contenu mis à jour, vérifier que la tabulation reste cohérente (repositionnement correct du focus).
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 12.9 [A] : Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ?

Tests du critère 12.9

Test 12.9.1 Dans chaque page web, chaque élément recevant le focus vérifie-t-il une de ces conditions ?
  • Il est possible d’atteindre l’élément suivant ou précédent pouvant recevoir le focus avec la touche de tabulation.
  • L’utilisateur est informé d’un mécanisme fonctionnel permettant d’atteindre au clavier l’élément suivant ou précédent pouvant recevoir le focus.
Méthodologie du test 12.9.1
  1. Retrouver dans le document l’ensemble des éléments d’interface susceptibles de recevoir le focus (au moyen de la tabulation ou au moyen d’un script).
  2. Pour chaque élément d’interface, vérifier que l’utilisateur peut atteindre l’élément suivant ou précédent pouvant recevoir le focus :
    • soit au moyen de la touche de tabulation (Tab ou Maj+Tab) ;
    • soit au moyen d’une autre interaction clavier dont l’utilisateur est informé (par exemple, les flèches de direction).
  3. Si c’est le cas pour chaque élément d’interface, le test est validé.

Note : certains éléments d’interface complexes, comme un groupe de boutons radio, une liste de sélection et tous les composants développés avec WAI-ARIA font appel à des navigations optimisées qui utilisent généralement les flèches de direction pour passer d’une partie du composant à l’autre. Par exemple, dans un groupe de boutons radio les options sont navigables avec les flèches de direction. De même dans un système d’onglets l’utilisateur active les onglets avec les flèches de direction. Le test sur le piège au clavier se limite alors à vérifier que le composant est atteint avec la tabulation et qu’il est possible de passer au composant suivant ou revenir au composant précédent.

Note

Ce critère est soumis au principe de non-interférence.

Correspondances

Critère 12.10 [A] : 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 ?

Tests du critère 12.10

Test 12.10.1 Dans chaque page web, chaque raccourci clavier n’utilisant qu’une seule touche (lettre 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.
Méthodologie du test 12.10.1
  1. Retrouver dans le document l’ensemble des raccourcis clavier proposés à l’utilisateur
  2. Pour chaque raccourci clavier, vérifier que :
    • soit un mécanisme est disponible pour désactiver le raccourci clavier ;
    • soit un mécanisme est disponible pour configurer la touche de raccourci clavier au moyen des touches de modification (Ctrl, Alt, Maj, etc.) ;
    • soit, 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.
  3. Si c’est le cas pour chaque raccourci clavier, le test est validé.
Correspondances

Critère 12.11 [AA] : 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 ?

Tests du critère 12.11

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 ?
Méthodologie du test 12.11.1
  1. Retrouver dans le document l’ensemble des contenus additionnels apparaissant au survol, à la prise de focus ou à l’activation d’un composant d’interface
  2. Pour chaque contenu additionnel, s’il contient des composants d’interface avec lesquels l’utilisateur peut interagir au clavier (par exemple, une infobulle personnalisée qui propose un lien dans son contenu), vérifier que ces composants d’interface sont atteignables au clavier
  3. Si c’est le cas pour chaque contenu additionnel, le test est validé.
Notes techniques

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.

Correspondances

Thématique 13 : Consultation

Critère 13.1 [A] : Pour chaque page web, l’utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers) ?

Tests du critère 13.1

Test 13.1.1 Pour chaque page web, chaque procédé de rafraîchissement (balise <object>, balise <embed>, balise <svg>, balise <canvas>, balise <meta>) vérifie-t-il une de ces conditions (hors cas particuliers) ?
  • L’utilisateur peut arrêter ou relancer le rafraîchissement.
  • L’utilisateur peut augmenter la limite de temps entre deux rafraîchissements de dix fois, au moins.
  • L’utilisateur est averti de l’imminence du rafraîchissement et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant le prochain rafraîchissement.
  • La limite de temps entre deux rafraîchissements est de vingt heures, au moins.
Méthodologie du test 13.1.1
  1. Retrouver dans le document les rafraîchissements initiés dans le contenu par un élément <object>, <embed>, <svg>, <canvas> ou par un élément <meta http-equiv="refresh" content="[compteur]"> (dans l’élément <head> de la page).
  2. Pour chaque rafraîchissement, vérifier que :
    • soit la présence d’un mécanisme permet à l’utilisateur de stopper et de relancer le rafraîchissement ;
    • soit la présence d’un mécanisme permet à l’utilisateur d’augmenter la limite de temps entre deux rafraîchissements de dix fois, au moins ;
    • soit la présence d’un mécanisme qui avertit l’utilisateur de l’imminence du rafraîchissement, laisse 20 secondes, au moins, à l’utilisateur, pour augmenter la limite de temps avant le prochain rafraîchissement ;
    • soit la limite de temps entre deux rafraîchissements est de vingt heures, au moins.
  3. Si c’est le cas, le test est validé.
Test 13.1.2 Pour chaque page web, chaque procédé de redirection effectué via une balise <meta> est-il immédiat (hors cas particuliers) ?
Méthodologie du test 13.1.2
  1. Retrouver dans le document une redirection automatique initiée par un élément <meta http-equiv="refresh" content="0;URL='[URL ciblée]'" />.
  2. Vérifier que la redirection est immédiate.
  3. Si c’est le cas, le test est validé.
Test 13.1.3 Pour chaque page web, chaque procédé de redirection effectué via un script vérifie-t-il une de ces conditions (hors cas particuliers) ?
  • L’utilisateur peut arrêter ou relancer la redirection.
  • L’utilisateur peut augmenter la limite de temps avant la redirection de dix fois, au moins.
  • L’utilisateur est averti de l’imminence de la redirection et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant la prochaine redirection.
  • La limite de temps avant la redirection est de vingt heures, au moins.
Méthodologie du test 13.1.3
  1. Retrouver dans le document les redirections automatiques initiées par un script (sous la forme d’un décompte par exemple).
  2. Pour chaque redirection automatique, vérifier que :
    • Soit la présence d’un mécanisme permet à l’utilisateur de stopper et relancer la redirection.
    • Soit la présence d’un mécanisme permet à l’utilisateur d’augmenter la limite de temps avant le rafraîchissement de dix fois, au moins.
    • Soit la présence d’un mécanisme qui avertit l’utilisateur de l’imminence du rafraîchissement, laisse 20 secondes, au moins, à l’utilisateur, pour augmenter la limite de temps avant le prochain rafraîchissement.
    • Soit la limite de temps avant la redirection est de vingt heures, au moins.
  3. Si c’est le cas, le test est validé.
Test 13.1.4 Pour chaque page web, chaque procédé limitant le temps d’une session vérifie-t-il une de ces conditions (hors cas particuliers) ?
  • L’utilisateur peut supprimer la limite de temps.
  • L’utilisateur peut augmenter la limite de temps.
  • La limite de temps avant la fin de la session est de vingt heures au moins.
Méthodologie du test 13.1.4
  1. Retrouver dans le document les procédés limitant le temps d’une session (par exemple, après une authentification).
  2. Pour chaque procédé, vérifier que :
    • soit la présence d’un mécanisme permet à l’utilisateur de supprimer la limite de temps ;
    • soit la présence d’un mécanisme permet à l’utilisateur d’augmenter la limite de temps ;
    • soit la limite de temps est de vingt heures, au moins.
  3. Si c’est le cas, le test est validé.
Cas particuliers

Il existe une gestion de cas particuliers lorsque la limite de temps est essentielle, notamment lorsqu’elle ne pourrait pas être supprimée sans changer fondamentalement le contenu ou les fonctionnalités liées au contenu.

Dans ces situations, le critère est non applicable. Par exemple, le rafraîchissement d’un flux RSS dans une page n’est pas une limite de temps essentielle ; le critère est applicable. En revanche, une redirection automatique qui amène vers la nouvelle version d’une page à partir d’une URL obsolète est essentielle ; le critère est non applicable.

Note

Le test 13.1.1 de ce critère est soumis au principe de non-interférence.

Correspondances

Critère 13.2 [A] : Dans chaque page web, l’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur. Cette règle est-elle respectée ?

Tests du critère 13.2

Test 13.2.1 Dans chaque page web, l’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur. Cette règle est-elle respectée ?
Méthodologie du test 13.2.1
  1. Vérifier qu’à l’ouverture du document, aucune nouvelle fenêtre (pop-up ou pop-under, par exemple) n’est ouverte.
  2. Si c’est le cas, le test est validé.
Correspondances

Critère 13.3 [A] : Dans chaque page web, chaque document bureautique en téléchargement possède-t-il, si nécessaire, une version accessible (hors cas particuliers) ?

Tests du critère 13.3

Test 13.3.1 Dans chaque page web, chaque fonctionnalité de téléchargement d’un document bureautique vérifie-t-elle une de ces conditions ?
  • Le document en téléchargement est compatible avec l’accessibilité ;
  • Il en existe une version alternative en téléchargement compatible avec l’accessibilité ;
  • Il en existe une version alternative au format HTML compatible avec l’accessibilité.
Méthodologie du test 13.3.1
  1. Retrouver dans le document les liens et les contrôles de formulaire (un bouton de formulaire ou un formulaire de téléchargement par exemple) permettant de télécharger un fichier au format bureautique.
  2. Pour chaque fichier au format bureautique, vérifier la présence d’une version alternative présentée comme accessible :
    • Pour les documents au format .pdf, vérifier la conformité au référentiel d’évaluation de l’accessibilité des documents au format PDF (RAPDF).
    • Pour les documents au format .doc ou .docx, analyser le fichier avec l’outil de vérification d’accessibilité de Microsoft Office (à partir de la version 2010) et vérifier l’absence d’erreur d’accessibilité (cf. note).
    • Pour les documents au format .odt, analyser le document avec l’outil de vérification d’accessibilité de LibreOffice (à partir de la version 7.0).
    • Pour les documents au format EPUB/DAISY, analyser le document avec un éditeur EPUB/DAISY.
    • Pour les documents eux-mêmes au format .html, analyser l’accessibilité du document.
  3. Si c’est le cas pour chaque fichier au format bureautique, le test est validé.

Note au sujet Microsoft Office : le logiciel offre un vérificateur d’accessibilité en standard, (accessible via le menu « Fichier > Informations > Vérifier la présence de problèmes > Vérifier l’accessibilité »). Ce vérificateur peut être considérablement amélioré via le plugin Word Accessibility Plug-in (voir dans la section Outils). Ce plugin ne fonctionne que sur Windows. Sur Mac, le contrôle doit se faire manuellement.

Note au sujet LibreOffice : le logiciel offre un vérificateur d’accessibilité en standard, accessible via le menu « Tools > Accessibility Check ».

Note au sujet du format EPUB : l’utilitaire Ace by DAISY App permet d’effectuer le travail de validation d’un fichier EPUB 3 de manière efficace.

Cas particuliers

Il existe une gestion de cas particuliers :

  • Si les fichiers bureautiques (ex : PDF, documents Microsoft ou libreOffice, etc.) ont été publiés avant le 23 septembre 2018 (sauf si ces contenus sont nécessaires pour les besoins de processus administratifs actifs concernant des tâches effectuées par l’organisme du secteur public concerné), ils sont exemptés de l’obligation d’accessibilité, d’après la loi du 28 mai 2019

Dans cette situation, le critère est non applicable.

Dans le cas de documents PDF, s’il n’existe pas de version alternative accessible, ceux-ci doivent être conformes au référentiel d’évaluation de l’accessibilité des documents au format PDF (RAPDF).

Correspondances

Critère 13.4 [A] : Pour chaque document bureautique ayant une version accessible, cette version offre-t-elle la même information ?

Tests du critère 13.4

Test 13.4.1 Chaque document bureautique ayant une version accessible vérifie-t-il une de ces conditions ?
  • La version compatible avec l’accessibilité offre la même information.
  • La version alternative au format HTML est pertinente et offre la même information.
Méthodologie du test 13.4.1
  1. Retrouver dans le document les fichiers en téléchargement au format bureautique accompagné de leur version alternative accessible.
  2. Pour chaque couple de fichiers, ouvrir les deux documents (le document d’origine et le document accessible) et vérifier que les deux documents apportent la même information.
  3. Si c’est le cas pour chaque couple de fichiers, le test est validé.
Cas particuliers

Voir cas particuliers critère 13.3.

Correspondances

Critère 13.5 [A] : Dans chaque page web, chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) a-t-il une alternative ?

Tests du critère 13.5

Test 13.5.1 Dans chaque page web, chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) vérifie-t-il une de ces conditions ?
  • Un attribut title est disponible.
  • Une définition est donnée par le contexte adjacent.
Méthodologie du test 13.5.1
  1. Retrouver dans le document les contenus cryptiques (art ASCII, émoticône, syntaxe cryptique).
  2. Pour chaque contenu cryptique, vérifier que :
    • Soit une définition est disponible au moyen d’un attribut title, sur un lien, un contrôle de formulaire, une abréviation (élément <abbr>) par exemple.
    • Soit une définition est donnée dans le contexte adjacent (immédiatement avant ou après).
  3. Si c’est le cas pour chaque contenu cryptique, le test est validé.
Correspondances

Critère 13.6 [A] : Dans chaque page web, pour chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) ayant une alternative, cette alternative est-elle pertinente ?

Tests du critère 13.6

Test 13.6.1 Dans chaque page web, chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) vérifie-t-il une de ces conditions ?
  • Le contenu de l’attribut title est pertinent.
  • La définition donnée par le contexte adjacent est pertinente.
Méthodologie du test 13.6.1
  1. Retrouver dans le document les contenus cryptiques (art ASCII, émoticône, syntaxe cryptique).
  2. Pour chaque contenu cryptique, vérifier que la définition donnée est pertinente.
  3. Si c’est le cas pour chaque contenu cryptique, le test est validé.
Correspondances

Critère 13.7 [A] : Dans chaque page web, les changements brusques de luminosité ou les effets de flash sont-ils correctement utilisés ?

Tests du critère 13.7

Test 13.7.1 Dans chaque page web, chaque image ou élément multimédia (balise <video>, balise <img>, balise <svg>, balise <canvas>, balise <embed> ou balise <object>) qui provoque un changement brusque de luminosité ou un effet de flash vérifie-t-il une de ces conditions ?
  • La fréquence de l’effet est inférieure à 3 par seconde.
  • La surface totale cumulée des effets est inférieure ou égale à 21824 pixels.
Méthodologie du test 13.7.1
  1. Retrouver dans le document les contenus clignotants ou qui provoquent des effets de flash de type image animée, vidéo (cf. note) ou animation (éléments <img>, <svg>, <canvas>, <embed>, <object> ou <video>).
  2. Pour chaque contenu clignotant ou provoquant des effets de flash, vérifier que :
    • soit la fréquence de l’effet est inférieur à 3 par seconde ;
    • soit la surface cumulée est inférieure à 21824 pixels.
  3. Si c’est le cas pour chaque contenu clignotant ou provoquant des effets de flash, le test est validé.

Note : l’évaluation de ce critère peut être complexe. Lorsque l’effet est géré par un script ou au moyen de CSS, l’analyse du code est suffisante. L’outil PEAT permet d’analyser les vidéos au format .avi, par exemple. Un exemple de vidéo ayant provoqué des crises d’épilepsie peut être consulté ici : London 2012 Olympics Seizure.

Test 13.7.2 Dans chaque page web, chaque script qui provoque un changement brusque de luminosité ou un effet de flash vérifie-t-il une de ces conditions ?
  • La fréquence de l’effet est inférieure à 3 par seconde.
  • La surface totale cumulée des effets est inférieure ou égale à 21824 pixels.
Méthodologie du test 13.7.2
  1. Retrouver dans le document les contenus clignotants ou qui provoquent des effets de flash obtenus au moyen d’un script.
  2. Pour chaque contenu clignotant ou provoquant des effets de flash, vérifier que :
    • soit la fréquence de l’effet est inférieur à 3 par seconde ;
    • soit la surface cumulée est inférieure à 21824 pixels.
  3. Si c’est le cas pour chaque contenu clignotant ou provoquant des effets de flash, le test est validé.
Test 13.7.3 Dans chaque page web, chaque mise en forme CSS qui provoque un changement brusque de luminosité ou un effet de flash vérifie-t-il une de ces conditions ?
  • La fréquence de l’effet est inférieure à 3 par seconde.
  • La surface totale cumulée des effets est inférieure ou égale à 21824 pixels.
Méthodologie du test 13.7.3
  1. Retrouver dans le document les contenus clignotants ou qui provoquent des effets de flash obtenus au moyen d’une animation CSS.
  2. Pour chaque contenu clignotant ou provoquant des effets de flash, vérifier que :
    • soit la fréquence de l’effet est inférieur à 3 par seconde ;
    • soit la surface cumulée est inférieure à 21824 pixels.
  3. Si c’est le cas pour chaque contenu clignotant ou provoquant des effets de flash, le test est validé.
Note

Ce critère est soumis au principe de non-interférence.

Correspondances

Critère 13.8 [A] : Dans chaque page web, chaque contenu en mouvement ou clignotant est-il contrôlable par l’utilisateur ?

Tests du critère 13.8

Test 13.8.1 Dans chaque page web, chaque contenu en mouvement déclenché automatiquement, vérifie-t-il une de ces conditions ?
  • La durée du mouvement est inférieure ou égale à 5 secondes.
  • L’utilisateur peut arrêter et relancer le mouvement.
  • L’utilisateur peut afficher et masquer le contenu en mouvement.
  • L’utilisateur peut afficher la totalité de l’information sans le mouvement.
Méthodologie du test 13.8.1
  1. Retrouver dans le document les contenus en mouvement (obtenus au moyen d’une image, d’un script ou d’un effet CSS) déclenchés automatiquement au chargement de la page ou lors de l’affichage d’un contenu (cf. note).
  2. Pour chaque contenu, vérifier que :
    • soit la durée du mouvement est inférieure à 5 secondes ;
    • soit la présence d’un mécanisme (un bouton, par exemple) permet d’arrêter et de relancer le mouvement ;
    • soit la présence d’un mécanisme (un bouton, par exemple) permet de cacher et d’afficher à nouveau le contenu en mouvement ;
    • soit la présence d’un mécanisme (un bouton, par exemple) permet d’afficher la totalité du contenu sans mouvement.
  3. Si c’est le cas pour chaque contenu en mouvement, le test est validé.
Test 13.8.2 Dans chaque page web, chaque contenu clignotant déclenché automatiquement, vérifie-t-il une de ces conditions ?
  • La durée du clignotement est inférieure ou égale à 5 secondes.
  • L’utilisateur peut arrêter et relancer le clignotement.
  • L’utilisateur peut afficher et masquer le contenu clignotant.
  • L’utilisateur peut afficher la totalité de l’information sans le clignotement.
Méthodologie du test 13.8.2
  1. Retrouver dans le document les contenus clignotants (obtenus au moyen d’une image, d’un script ou d’un effet CSS) déclenchés automatiquement au chargement de la page ou lors de l’affichage d’un contenu (cf. note).
  2. Pour chaque contenu, vérifier que :
    • soit la durée du clignotement est inférieure à 5 secondes ;
    • soit la présence d’un mécanisme (un bouton, par exemple) permet d’arrêter et de relancer le clignotement ;
    • soit la présence d’un mécanisme (un bouton, par exemple) permet de cacher et d’afficher à nouveau le contenu clignotant ;
    • soit la présence d’un mécanisme (un bouton, par exemple) permet d’afficher la totalité du contenu clignotant.
  3. Si c’est le cas pour chaque contenu clignotant, le test est validé.

Note : l’arrêt ou la mise en pause d’un contenu en mouvement ou clignotant au moyen de la prise de focus (par exemple, l’effet est suspendu uniquement pendant la prise de focus) n’est pas considéré comme un procédé conforme. Dans certains cas, le mouvement ne peut pas être arrêté, par exemple dans le cas d’une barre de progression, dans ce cas, le critère est non applicable.

Note

Ce critère est soumis au principe de non-interférence.

Correspondances

Critère 13.9 [AA] : Dans chaque page web, le contenu proposé est-il consultable quelle que soit l’orientation de l’écran (portrait ou paysage) (hors cas particuliers) ?

Tests du critère 13.9

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.
Méthodologie du test 13.9.1
  1. Consulter le document dans un mode d’orientation portrait puis dans un mode d’orientation paysage.
  2. Vérifier que :
    • 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.
  3. Si c’est le cas, le test est validé.
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
Correspondances

Critère 13.10 [A] : 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) ?

Tests du critère 13.10

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).
Méthodologie du test 13.10.1
  1. Retrouver dans le document les fonctionnalités utilisables ou disponibles au moyen d’une interaction au toucher de type contact multipoint.
  2. Pour chaque fonctionnalité, vérifier qu’elle reste disponible au moyen d’une interaction au toucher de type contact en un point unique de l’écran (par exemple, la possibilité de consulter les éléments d’une liste par un mouvement de balayage horizontal droit ou gauche doit aussi être disponible au moyen de boutons “précédent” et “suivant” ou encore un geste de pincer et zoomer qui peut être alternativement réalisé au moyen de boutons “plus” et “moins”).
  3. Si c’est le cas pour chaque fonctionnalité utilisable ou disponible au moyen d’une interaction au toucher de type contact multipoint, le test est validé.
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).
Méthodologie du test 13.10.2
  1. Retrouver dans le document les fonctionnalités utilisables ou disponibles au moyen d’une interaction au toucher qui implique le suivi d’une trajectoire sur l’écran.
  2. Pour chaque fonctionnalité, vérifier qu’elle reste disponible au moyen d’une interaction au toucher de type contact en un point unique de l’écran (par exemple, la possibilité de composer son mot de passe en suivant une trajectoire sur un clavier virtuel doit aussi être disponible au moyen de pressions successives sur les touches du clavier).
  3. Si c’est le cas pour chaque fonctionnalité utilisable ou disponible au moyen d’une interaction au toucher qui implique le suivi d’une trajectoire sur l’écran, le test est validé.
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).
Correspondances

Critère 13.11 [A] : 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) ?

Tests du critère 13.11

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.
Méthodologie du test 13.11.1
  1. Retrouver dans le document les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran.
  2. Pour chaque action, vérifier que :
    • soit l’action est déclenchée au moment où le dispositif de pointage est relâché ou relevé ;
    • soit 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é ;
    • soit il existe un mécanisme pour abandonner (avant achèvement de l’action) ou annuler (après achèvement) l’exécution de l’action. Par exemple, lors d’une interaction de type glisser-déposer, un relâchement du dispositif de pointage doit permettre d’abandonner l’interaction en cours et une fois la zone de dépôt atteinte, l’utilisateur doit rester en mesure d’annuler son opération de dépôt au moyen d’un dialogue de confirmation (choix de confirmer ou d’annuler le dépôt) ou par le fait de pouvoir replacer l’élément déposé à sa position initiale.
  3. Si c’est le cas pour chaque action déclenchée au moyen d’un dispositif de pointage sur un point unique de l’écran, le test est validé.
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.

Notes techniques

Deux exemples de mécanisme mis en place pour annuler ou abandonner une action déclenchée au moyen d’un dispositif de pointage sur un point unique de l’écran :

  • Une fenêtre modale permettant d’annuler l’action après son achèvement ;
  • Pour une fonction de glisser/déposer, le fait d’abandonner l’action si l’utilisateur relâche l’élément en dehors de la zone cible.
Correspondances

Critère 13.12 [A] : Dans chaque page web, les fonctionnalités qui impliquent un mouvement de l’appareil ou vers l’appareil peuvent-elles être satisfaites de manière alternative (hors cas particuliers) ?

Tests du critère 13.12

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) ?
Méthodologie du test 13.12.1
  1. Retrouver dans le document les fonctionnalités disponibles en bougeant l’appareil.
  2. Pour chaque fonctionnalité, vérifier qu’elle peut être accomplie au moyen de composants d’interface utilisateur.
  3. Si c’est le cas pour chaque fonctionnalité disponible en bougeant l’appareil, le test est validé.
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) ?
Méthodologie du test 13.12.2
  1. Retrouver dans le document les fonctionnalités disponibles en faisant un geste en direction de l’appareil.
  2. Pour chaque fonctionnalité, vérifier qu’elle peut être accomplie au moyen de composants d’interface utilisateur.
  3. Si c’est le cas pour chaque fonctionnalité disponible en faisant un geste en direction de l’appareil, le test est validé.
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) ?
Méthodologie du test 13.12.3
  1. Retrouver dans le document les fonctionnalités disponibles en mettant en mouvement l’appareil.
  2. Vérifier si l’utilisateur à la possibilité de désactiver la détection du mouvement.
  3. Si c’est le cas, pour chaque fonctionnalité, vérifier qu’elle ne peut pas être déclenchée.
  4. Si c’est le cas pour chaque fonctionnalité disponible en mettant en mouvement l’appareil, le test est validé.
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é.
Correspondances

Critère 13.13 [AA] : Pour chaque fonctionnalité de conversion d’un document, les informations relatives à l’accessibilité disponibles dans le document source sont-elles conservées dans le document de destination (hors cas particuliers) ?

Tests du critère 13.13

Test 13.13.1 Pour chaque fonctionnalité de conversion d’un document, les informations relatives à l’accessibilité disponibles dans le document source sont-elles conservées dans le document de destination (hors cas particuliers) ?
Méthodologie du test 13.13.1

Sont concernés tous les formats numériques tels que le texte, l’audio et la vidéo.

  1. Repérer dans la page les fonctionnalités de conversion de document (exportation en PDF, en .odt, HTML, etc.).
  2. Repérer dans le contenu original les informations d’accessibilité présentes (alternative d’un élément graphique, niveaux de titres, table des matières, etc.).
  3. Vérifier dans le document résultant de la conversion que les informations d’accessibilité sont toujours présentes (sauf si le format de conversion choisi ne possède pas de support pour les informations d’accessibilité du document source).
  4. Si c’est le cas, le test est validé.
Cas particuliers

Le critère est non applicable lorsque le format de conversion ne dispose pas des éléments nécessaires à l’identification des informations d’accessibilité. Par exemple, si la conversion se fait depuis un format HTML vers un format TXT, alors le critère est non applicable.

Correspondances

Critère 13.14 [A] : Chaque fonctionnalité d’identification ou de contrôle qui repose sur l’utilisation de caractéristiques biologiques de l’utilisateur dispose-t-elle d’une méthode alternative ?

Tests du critère 13.14

Test 13.14.1 Chaque fonctionnalité d’identification ou de contrôle qui repose sur l’utilisation de caractéristiques biologiques de l’utilisateur respecte-t-elle une de ces conditions ?
  • Il existe une alternative qui ne repose pas sur une caractéristique biologique de l’utilisateur.
  • Il existe une alternative qui repose sur une caractéristique biologique de l’utilisateur qui est suffisamment différente de la caractéristique biologique initialement demandée.
Méthodologie du test 13.14.1
  1. Repérer dans la page les fonctionnalités d’identification (authentification) et de contrôle qui utilisent des caractéristiques biologiques (reconnaissance vocale, empreinte digitale, reconnaissance faciale, …).
  2. Vérifier qu’il existe une méthode alternative pour réaliser l’action :
    • Pour une fonctionnalité d’authentification qui utilise une reconnaissance d’empreinte digitale, un bouton est disponible sur la page de connexion pour accéder à la saisie d’un mot de passe.
    • Pour une fonctionnalité d’authentification qui utilise une reconnaissance vocale, le site web propose également une reconnaissance d’empreinte digitale.
  3. Si c’est le cas, le test est validé.

Si la méthode alternative repose également sur une caractéristique biologique, il est indispensable qu’elle n’utilise pas une caractéristique biologique similaire. Par exemple, si la méthode initiale repose sur la voix, la méthode alternative ne doit pas utiliser la voix.

Correspondances

Thématique 14 : Documentation et fonctionnalités d’accessibilité

Critère 14.1 [AA] : La documentation du site web décrit-elle les fonctionnalités d’accessibilité disponibles et les informations relatives à la compatibilité avec l’accessibilité ?

Tests du critère 14.1

Test 14.1.1 La documentation du site web inclut-elle les éléments suivants au moins ?
Méthodologie du test 14.1.1
  1. Repérer la présence d’une documentation.
  2. Repérer la présence de fonctionnalités d’accessibilité.
  3. Vérifier la présence dans la documentation :
    • de la description des fonctionnalités d’accessibilité proposées par le site web ;
    • d’explications sur les modalités d’utilisation de ces fonctionnalités (leur localisation, les méthodes pour les activer) ;
    • de la description des composants complexes pour lesquels il est mis en place une gestion particulière selon les technologies d’assistance ;
    • de la description des éléments non conformes ou non compatibles avec certaines technologies d’assistance, et de la présence d’alternatives le cas échéant.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 14.2 [A] : Pour chaque fonctionnalité d’accessibilité décrite dans la documentation, le mécanisme qui permet de l’activer répond aux besoins d’accessibilité des utilisateurs concernés. Cette règle est-elle respectée (hors cas particuliers) ?

Tests du critère 14.2

Test 14.2.1 Pour chaque fonctionnalité d’accessibilité décrite dans la documentation, le mécanisme qui permet de l’activer répond aux besoins d’accessibilité des utilisateurs concernés. Cette règle est-elle respectée (hors cas particuliers) ?
Méthodologie du test 14.2.1
  1. Repérer les fonctionnalités d’accessibilité décrites dans la documentation. Par exemple :
    • accéder à une version du contenu en langage simplifié ;
    • agrandir la taille du texte.
  2. Vérifier que les utilisateurs concernés par chaque fonctionnalité d’accessibilité sont en mesure d’y accéder. Par exemple :
    • Version alternative en langage simplifié : le mécanisme ou l’ensemble des mécanismes qui permettent d’activer la fonctionnalité doit être compréhensible et identifiable par une personne qui bénéficie du langage simplifié (par exemple, l’emploi du logo « Facile à lire » pour identifier le mécanisme est une solution conforme).
    • Agrandissement de la taille des caractères : si le mécanisme contient du texte, alors le texte doit être affiché par défaut avec une taille de police équivalent à 200% de la taille de police .
  3. Vérifier qu’il est possible d’activer cette fonctionnalité.
  4. Si c’est le cas, le test est validé.
Cas particuliers

Le critère est non applicable pour les fonctionnalités intégrées au système d’exploitation ou au navigateur.

Correspondances

Critère 14.3 [AA] : La documentation du site web est-elle conforme aux règles d’accessibilité numérique ?

Tests du critère 14.3

Test 14.3.1 La documentation mise à disposition au format web (HTML, CSS) est-elle conforme au RAWeb ?
Méthodologie du test 14.3.1
  1. Repérer la présence d’une documentation au format web (HTML, CSS).
  2. Vérifier pour chaque élément de documentation qu’il est conforme au RAWeb.
  3. Si c’est le cas, le test est validé.
Test 14.3.2 La documentation mise à disposition au format PDF est-elle conforme au RAPDF ?
Méthodologie du test 14.3.2
  1. Repérer la présence d’une documentation au format PDF.
  2. Vérifier pour chaque élément de documentation qu’il est conforme au RAPDF.
  3. Si c’est le cas, le test est validé.
Test 14.3.3 La documentation mise à disposition dans un format non web (hors PDF) est-elle conforme aux critères de la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1 ?
Méthodologie du test 14.3.3
  1. Repérer la présence d’une documentation au format non web (hors PDF).
  2. Vérifier pour chaque élément de documentation qu’il est conforme aux critères de la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1.
  3. Si c’est le cas, le test est validé.
Correspondances

Thématique 15 : Outils d’édition

Critère 15.1 [AA] : Chaque outil d’édition permet-il de définir les informations d’accessibilité nécessaires pour créer un contenu conforme aux règles d’accessibilité numérique ?

Tests du critère 15.1

Test 15.1.1 Chaque outil d’édition qui crée du contenu au format web (HTML, CSS) permet-il de définir les informations d’accessibilité nécessaires pour créer un contenu conforme au RAWeb ?
Méthodologie du test 15.1.1
  1. Repérer dans l’outil les fonctionnalités d’édition (par exemple, un éditeur de texte, mais cela peut être une médiathèque ou toute autre interface qui permet de saisir du texte ou définir des propriétés) qui permettent de créer du contenu au format web (HTML, CSS).
  2. Vérifier qu’il est possible de définir les informations d’accessibilité nécessaires pour rendre le contenu conforme au RAWeb. Par exemple :
    • définir l’alternative textuelle d’une image depuis l’éditeur de texte ou une médiathèque ;
    • définir un intitulé de lien ;
    • etc.
  3. Si c’est le cas, le test est validé.
Test 15.1.2 Chaque outil d’édition qui crée du contenu au format PDF permet-il de définir les informations d’accessibilité nécessaires pour créer un contenu conforme au RAPDF ?
Méthodologie du test 15.1.2
  1. Repérer dans l’outil les fonctionnalités d’édition (par exemple, un éditeur de texte, mais cela peut être une médiathèque ou toute autre interface qui permet de saisir du texte ou définir des propriétés) qui permettent de créer du contenu au format PDF.
  2. Vérifier qu’il est possible de définir les informations d’accessibilité nécessaires pour rendre le contenu conforme au RAPDF. Par exemple :
    • définir l’alternative textuelle d’une image depuis l’éditeur de texte ou une médiathèque ;
    • définir un intitulé de lien ;
    • etc.
  3. Si c’est le cas, le test est validé.
Test 15.1.3 Chaque outil d’édition qui crée du contenu au format non web (hors PDF) permet-il de définir les informations d’accessibilité nécessaires pour créer un contenu conforme aux critères de la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1 ?
Méthodologie du test 15.1.3
  1. Repérer dans l’outil les fonctionnalités d’édition (par exemple, un éditeur de texte, mais cela peut être une médiathèque ou toute autre interface qui permet de saisir du texte ou définir des propriétés) qui permettent de créer du contenu au format non web (hors PDF).
  2. Vérifier qu’il est possible de définir les informations d’accessibilité nécessaires pour rendre le contenu conforme aux critères de la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1. Par exemple :
    • définir l’alternative textuelle d’une image depuis l’éditeur de texte ou une médiathèque ;
    • définir un intitulé de lien ;
    • etc.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 15.2 [A] : Chaque outil d’édition met-il à disposition des aides à la création de contenus conformes aux règles d’accessibilité numérique ?

Tests du critère 15.2

Test 15.2.1 Chaque outil d’édition met-il à disposition des aides à la création de contenus conformes aux règles d’accessibilité numérique ?
Méthodologie du test 15.2.1
  1. Repérer dans l’outil la présence d’aides à la création de contenus accessibles. Cela peut être :
    • des tests automatiques ou semi-automatiques disponibles depuis les fonctionnalités d’édition ;
    • d’autres outils automatiques (un chatbot par exemple) ;
    • une documentation qui explique comment définir les propriétés d’accessibilité pour chaque élément de contenu ;
    • des tests manuels disponibles depuis les fonctionnalités d’édition pour guider les auteurs dans la détection d’erreurs.
  2. Vérifier que les aides à la création de contenus accessibles sont pertinentes, c’est-à-dire que les résultats ou les indications qu’elles donnent permettent de créer un contenu accessible.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 15.3 [AA] : Le contenu généré par chaque transformation des contenus est-il conforme aux règles d’accessibilité numérique (hors cas particuliers) ?

Tests du critère 15.3

Test 15.3.1 Le contenu généré par chaque transformation des contenus est-il conforme aux règles d’accessibilité numérique (hors cas particuliers) ?
Méthodologie du test 15.3.1
  1. Depuis les fonctionnalités d’édition (un éditeur de texte, mais cela peut être une médiathèque et toute autre interface qui permet de saisir du texte ou définir des propriétés), saisir les typologies de contenus proposées par l’éditeur (titre, liste, tableau, image, etc.). Utiliser également les différents paramètres permettant de définir des informations d’accessibilité (renseigner l’alternative textuelle d’une image, ajouter une description sur un lien, etc.)
  2. Enregistrer les saisies.
  3. Consulter le contenu généré :
    • dans la fonctionnalité d’édition (par exemple, dans l’éditeur de texte) ;
    • et dans l’interface de publication des contenus (par exemple, la page web de publication).
  4. Pour chaque contenu au format web (HTML, CSS), vérifier :
    • que les informations nécessaires pour qu'il soit conforme au RAWeb (par exemple l’alternative d’une image, les niveaux de titres) sont préservées dans le contenu généré.
    • que l’information, si elle est restructurée, reste compatible avec les technologies d’assistance (par exemple, si l’auteur saisit un tableau HTML et qu’après l’enregistrement, l’outil linéarise le tableau, l’information ainsi restructurée doit être compréhensible pour les utilisateurs de technologies d’assistance comme elle l’aurait été dans sa forme initiale).
  5. Pour chaque contenu au format PDF, vérifier :
    • que les informations nécessaires pour qu'il soit conforme au RAPDF (par exemple l’alternative d’une image, les niveaux de titres) sont préservées dans le contenu généré.
    • que l’information, si elle est restructurée, reste compatible avec les technologies d’assistance (par exemple, si l’auteur saisit un tableau et qu’après l’enregistrement, l’outil linéarise le tableau, l’information ainsi restructurée doit être compréhensible pour les utilisateurs de technologies d’assistance comme elle l’aurait été dans sa forme initiale).
  6. Pour chaque contenu au format non web qui n’est pas du PDF, vérifier :
    • que les informations nécessaires pour qu'il soit conforme à la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1 sont préservées dans le contenu généré.
    • que l’information, si elle est restructurée, reste compatible avec les technologies d’assistance (par exemple, si l’auteur saisit un tableau et qu’après l’enregistrement, l’outil linéarise le tableau, l’information ainsi restructurée doit être compréhensible pour les utilisateurs de technologies d’assistance comme elle l’aurait été dans sa forme initiale).
  7. Si c’est le cas, le test est validé.
Cas particuliers

Le critère est non applicable lorsque le format de destination ne permet pas de conserver les informations d’accessibilité présentes dans le contenu en entrée.

Correspondances

Critère 15.4 [AA] : Pour chaque erreur d’accessibilité relevée par un test d’accessibilité automatique ou semi-automatique, l’outil d’édition fournit-il des suggestions de réparation ?

Tests du critère 15.4

Test 15.4.1 Pour chaque erreur d’accessibilité relevée par un test d’accessibilité automatique ou semi-automatique, l’outil d’édition fournit-il des suggestions de réparation ?
Méthodologie du test 15.4.1
  1. Repérer dans l’outil la présence de fonctionnalités de tests automatiques ou semi-automatiques.
  2. Générer du contenu (web et non-web) avec l’outil d’édition avec des erreurs d’accessibilité.
  3. Activer les fonctionnalités de tests.
  4. Vérifier :
    • que l’outil répare automatiquement l’erreur (test automatique) ;
    • ou que l’outil met à disposition de l’auteur des suggestions de réparations (test semi-automatique).
  5. Dans le cas d’un test semi-automatique, vérifier :
    • que l’outil met à disposition une aide à la décision et des suggestions de réparations ;
    • ou que l’outil met à disposition de l’auteur des explications pour effectuer la réparation.
  6. Si c’est le cas, le test est validé.
Correspondances

Critère 15.5 [A] : Pour chaque ensemble de gabarits, un gabarit au moins permet de répondre aux règles d’accessibilité numérique. Cette règle est-elle respectée ?

Tests du critère 15.5

Test 15.5.1 Pour chaque ensemble de gabarits au format web (HTML, CSS), un gabarit au moins est conforme au RAWeb. Cette règle est-elle respectée ?
Méthodologie du test 15.5.1
  1. Repérer la présence de gabarits au format web (HTML, CSS) mis à disposition par l’outil d’édition.
  2. Vérifier qu’au moins un gabarit permet de respecter l’ensemble des critères du RAWeb.
  3. Si c’est le cas, le test est validé.
Test 15.5.2 Pour chaque ensemble de gabarits au format PDF, un gabarit au moins est conforme au RAPDF. Cette règle est-elle respectée ?
Méthodologie du test 15.5.2
  1. Repérer la présence de gabarits au format PDF mis à disposition par l’outil d’édition.
  2. Vérifier qu’au moins un gabarit permet de respecter l’ensemble des critères du RAPDF.
  3. Si c’est le cas, le test est validé.
Test 15.5.3 Pour chaque ensemble de gabarits au format non-web (hors PDF), un gabarit au moins est conforme aux critères de la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1. Cette règle est-elle respectée ?
Méthodologie du test 15.5.3
  1. Repérer la présence de gabarits au format non-web (hors PDF) mis à disposition par l’outil d’édition.
  2. Vérifier qu’au moins un gabarit permet de respecter l’ensemble des critères de la section 10 Non-web documents de la norme européenne EN 301 549 v3.2.1.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 15.6 [A] : Chaque gabarit qui permet de répondre aux règles d’accessibilité numérique est-il clairement identifiable ?

Tests du critère 15.6

Test 15.6.1 Chaque gabarit qui permet de répondre aux règles d’accessibilité numérique est-il clairement identifiable ?
Méthodologie du test 15.6.1
  1. Repérer la présence de gabarits totalement conformes aux règles d’accessibilité numérique mis à disposition par l’outil d’édition.
  2. Vérifier la présence d’une mention explicite permettant de les identifier. Par exemple, depuis la liste des gabarits, les gabarits conformes possèdent une étiquette « gabarit accessible ».
  3. Si c’est le cas, le test est validé.
Correspondances

Thématique 16 : Services d’assistance

Critère 16.1 [AA] : Chaque service d’assistance fournit-il des informations relatives aux fonctionnalités d’accessibilité et à la compatibilité avec l’accessibilité, décrites dans la documentation du site web ?

Tests du critère 16.1

Test 16.1.1 Chaque service d’assistance fournit-il des informations relatives aux fonctionnalités d’accessibilité et à la compatibilité avec l’accessibilité, décrites dans la documentation du site web ?
Méthodologie du test 16.1.1
  1. Repérer la mise à disposition d’un service d’assistance depuis le site web.
  2. Si c’est le cas, repérer dans le site web la présence d’une documentation.
  3. Repérer la présence dans la documentation :
    • de la description des fonctionnalités d’accessibilité proposées par le site web ;
    • de la description des composants complexes pour lesquels il est mis en place une gestion particulière selon les technologies d’assistance ;
    • d’explications sur les modalités d’utilisation de ces fonctionnalités (leur localisation, les méthodes pour les activer) ;
    • de la description des éléments non conformes ou non compatibles avec certaines technologies d’assistance, et de la présence d’alternatives le cas échéant.
  4. Vérifier que le service d’assistance propose des informations concernant ces fonctionnalités.
  5. Si c’est le cas, le test est validé.
Correspondances

Critère 16.2 [A] : Le service d’assistance répond aux besoins de communication des personnes handicapées directement ou par l’intermédiaire d’un service de relais. Cette règle est-elle respectée ?

Tests du critère 16.2

Test 16.2.1 Le service d’assistance répond aux besoins de communication des personnes handicapées directement ou par l’intermédiaire d’un service de relais. Cette règle est-elle respectée ?
Méthodologie du test 16.2.1
  1. Repérer la présence dans le site web d’un service d’assistance.
  2. Si c’est le cas, vérifier que le service d’assistance peut être utilisé par toutes les personnes en situation de handicap. Il peut être utile de rechercher dans la documentation du site web pour trouver ces informations. Par exemple, si le service d’assistance est disponible depuis un numéro de téléphone, vérifier qu’il existe des moyens alternatifs pour les utilisateurs qui n’accèdent pas ou peu au langage oral (personnes sourdes ou malentendantes) ou qui ne peuvent pas utiliser le langage verbal (personnes aphasiques). Par exemple :
    • une adresse mail ou un formulaire en ligne ;
    • une messagerie instantanée ;
    • la mise à disposition d’une traduction écrite simultanée ou visuelle des informations orales ou sonores, ou la mise à disposition d’un interprète en langue des signes (utilisation d’un service de relais).
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 16.3 [AA] : La documentation fournie par le service d’assistance est-elle conforme aux règles d’accessibilité numérique ?

Tests du critère 16.3

Test 16.3.1 La documentation fournie par le service d’assistance est-elle conforme aux règles d’accessibilité numérique ?
Méthodologie du test 16.3.1
  1. Repérer la présence d’une documentation fournie par service d’assistance.
  2. Vérifier pour chaque élément de documentation :
  3. Si c’est le cas, le test est validé.
Correspondances

Thématique 17 : Communication en temps réel

Critère 17.1 [A] : Pour chaque application web de communication orale bidirectionnelle, l’application est-elle capable d’encoder et de décoder cette communication avec une gamme de fréquences dont la limite supérieure est de 7 000 Hz au moins ?

Tests du critère 17.1

Test 17.1.1 Pour chaque application web de communication orale bidirectionnelle, l’application est-elle capable d’encoder et de décoder cette communication avec une gamme de fréquences dont la limite supérieure est de 7 000 Hz au moins ?
Méthodologie du test 17.1.1
  1. Activer l’application web et lancer un appel entre les deux terminaux.
  2. Vérifier que la qualité de l’activité orale avec l’application web est au moins équivalente à la qualité de l’activité orale lors d’un appel avec un téléphone fixe.
  3. Si le test n’est pas satisfaisant (par exemple, mauvaise compréhension de certains mots énoncés par l’interlocuteur, présence de bruits parasites, etc.), vérifier dans la documentation de l’application :
    1. la présence d’une référence à l’implémentation de la recommandation UIT-T G.722 ;
    2. ou la présence d’une référence à l’utilisation du codec opus de l’API WebRTC ;
    3. ou la présence d’une référence à l’utilisation d’un encodage et décodage dont la fréquence est supérieure ou égale à 7 000 Hz.
  4. Sinon, il est recommandé de demander à l’éditeur de l’application de fournir ces détails techniques, notamment en demandant si l’application web implémente par exemple la recommandation UIT-T G.722 ou utilise le codec opus de l’API WebRTC.
  5. Si c’est le cas, le test est validé.
Correspondances

Critère 17.2 [A] : Chaque application web qui permet une communication orale bidirectionnelle dispose-t-elle d’une fonctionnalité de communication écrite en temps réel ?

Tests du critère 17.2

Test 17.2.1 Chaque application web qui permet une communication orale bidirectionnelle respecte-t-elle une de ces conditions ?
Méthodologie du test 17.2.1
  1. Vérifier que l’application web permet la communication orale bidirectionnelle.
  2. Si c’est le cas, vérifier la présence d’une fonctionnalité de communication écrite en temps réel (il peut être parfois nécessaire d’activer un paramètre dédié dans l’application pour permettre la communication écrite en temps réel).
  3. Sinon, vérifier si l’application web peut se connecter à un terminal intégrant une fonctionnalité de communication écrite en temps réel. Cette évaluation peut être complexe à mener sans la mise à disposition d’un terminal de communication en temps réel ou si le réseau utilisé par le terminal ne supporte pas les protocoles de texte en temps réel. Une première étape peut être de rechercher dans la documentation ou de questionner directement l’éditeur de l’application.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 17.3 [A] : Pour chaque application web qui permet une communication orale bidirectionnelle et écrite en temps réel, les deux modes sont-ils utilisables simultanément ?

Tests du critère 17.3

Test 17.3.1 Pour chaque application web qui permet une communication orale bidirectionnelle et écrite en temps réel, les deux modes sont-ils utilisables simultanément ?
Méthodologie du test 17.3.1
  1. Vérifier que l’application web permet la communication orale bidirectionnelle.
  2. Si c’est le cas, vérifier la présence d’une fonctionnalité de communication écrite en temps réel.
  3. Si c’est le cas, vérifier qu’il est possible d’utiliser les deux modes de communications en même temps, c’est-à-dire qu’il est possible pour un même utilisateur de parler et d’utiliser simultanément le système de communication écrite en temps réel.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 17.4 [A] : Pour chaque fonctionnalité de communication écrite en temps réel, les messages peuvent-ils être identifiés (hors cas particuliers) ?

Tests du critère 17.4

Test 17.4.1 Pour chaque fonctionnalité de communication écrite en temps réel, les messages respectent-ils ces conditions ?
  • Les messages reçus et envoyés sont séparés dans la présentation ;
  • La présentation permet d’identifier la nature du message (reçu ou envoyé) ;
  • La nature du message (reçu ou envoyé) est accessible aux technologies d’assistance.
Méthodologie du test 17.4.1
  1. Activer l’application web et la fonctionnalité de communication écrite en temps réel de l’application sur deux terminaux et les connecter à une même session.
  2. Envoyer un message écrit depuis les deux terminaux pour obtenir des messages avec des statuts différents (envoyé et reçu).
  3. Vérifier :
    • que les messages envoyés et reçus sont visuellement séparés (par exemple, les messages envoyés sont dans une fenêtre et les messages reçus dans une autre, ou il y a un saut de ligne entre chaque message reçu et envoyé s’ils sont présentés dans une même fenêtre) ;
    • qu’il est possible visuellement de distinguer les messages envoyés et les messages reçus. Par exemple, par une mise en forme ou une couleur qui les différencie ou par une annotation textuelle visible (repérer la mention « Envoyé » à proximité d’un message envoyé ou « Reçu » à proximité d’un message reçu) ;
    • que l’information de la nature du message (reçu ou envoyé) est accessible aux technologies d’assistance (une information textuelle est disponible pour apporter cette information).
  4. Si c’est le cas, le test est validé.
Test 17.4.2 Pour chaque fonctionnalité de communication écrite en temps réel utilisée avec une fonctionnalité de communication orale bidirectionnelle qui identifie les intervenants, les messages respectent-ils ces conditions ?
  • La présentation permet d’identifier les auteurs des messages ;
  • L’identification de l’auteur du message est accessible aux technologies d’assistance.
Méthodologie du test 17.4.2
  1. Activer l’application web et la fonctionnalité de communication écrite en temps réel de l’application sur deux terminaux et les connecter à une même session.
  2. Envoyer un message écrit depuis les deux terminaux pour obtenir des messages avec des auteurs différents.
  3. Vérifier que les auteurs des messages écrits sont identifiés (par exemple, la présence d’un nom ou un identifiant précédant le message).
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 17.5 [A] : Pour chaque application web de communication orale bidirectionnelle, un indicateur visuel de l’activité orale est-il présent ?

Tests du critère 17.5

Test 17.5.1 Pour chaque application web de communication orale et écrite en temps réel, un indicateur visuel de l’activité orale est-il présent ?
Méthodologie du test 17.5.1
  1. Vérifier que l’application web permet la communication orale bidirectionnelle et la communication écrite en temps réel.
  2. Si c’est le cas, activer l’application web sur deux terminaux et les connecter à une même session.
  3. Faire parler un utilisateur depuis un des terminaux.
  4. Vérifier sur l’interface l’apparition d’un indicateur visuel permettant d’identifier qu’une personne est en train de parler. Il n’est pas nécessaire pour ce critère d’identifier qui parle, mais simplement d’identifier qu’il y a une personne qui est en train de parler. Par exemple, un halo autour ou une icône à proximité de l’avatar de la personne qui parle.
  5. Si c’est le cas, le test est validé.
Test 17.5.2 Pour chaque application web de communication orale bidirectionnelle qui dispose d’une vidéo en temps réel, un indicateur visuel de l’activité orale est-il présent ?
Méthodologie du test 17.5.2
  1. Vérifier que l’application web la communication orale bidirectionnelle et la diffusion de la vidéo en temps réel.
  2. Si c’est le cas, activer l’application sur deux terminaux et les connecter à une même session.
  3. Faire parler un utilisateur depuis un des terminaux.
  4. Vérifier sur l’interface l’apparition d’un indicateur visuel permettant d’identifier qu’une personne est en train de parler. Il n’est pas nécessaire pour ce critère d’identifier qui parle, mais simplement d’identifier qu’il y a une personne qui est en train de parler. Par exemple, un halo autour ou une icône à proximité de l’avatar de la personne qui parle.
  5. Si c’est le cas, le test est validé.
Correspondances

Critère 17.6 [A] : Chaque application web de communication écrite en temps réel qui peut interagir avec d’autres applications de communication écrite en temps réel respecte-t-elle les règles d’interopérabilité en vigueur ?

Tests du critère 17.6

Test 17.6.1 Chaque application web de communication écrite en temps réel qui peut interagir avec d’autres applications de communication écrite en temps réel respecte-t-elle les règles d’interopérabilité en vigueur ?
Méthodologie du test 17.6.1

Ce critère est très complexe à évaluer et demande une certaine maîtrise de l’ensemble des concepts et normes d’interopérabilité.

Il est recommandé de demander à l’éditeur de l’application de vérifier que l’ensemble des exigences décrites dans le critère 6.2.3 Interoperability de la norme EN 301 549 sont respectées.

Correspondances

Critère 17.7 [AA] : Pour chaque application web de communication écrite en temps réel, le délai de transmission de chaque unité de saisie est de 500ms ou moins. Cette règle est-elle respectée ?

Tests du critère 17.7

Test 17.7.1 Pour chaque application web de communication écrite en temps réel le délai de transmission de chaque unité de saisie est de 500ms ou moins. Cette règle est-elle respectée ?
Méthodologie du test 17.7.1
  1. Vérifier que l’application web permet la communication écrite en temps réel.
  2. Si c’est le cas, activer l’application web et la fonctionnalité de communication écrite sur deux terminaux distincts et les connecter à une même session.
  3. Saisir du texte sur le premier terminal et observer son apparition sur le second terminal. L’apparition sur le second terminal doit être instantanée (inférieure à une demi-seconde). Selon le paramétrage de la fonctionnalité, chaque caractère n’est pas envoyé individuellement. En effet, si la fonctionnalité de communication écrite en temps réel implémente une prédiction de mots, c’est lorsque le mot désiré sera sélectionné qu’il sera envoyé, et non pas lors de la saisie des premiers caractères servant à déclencher l’affichage de suggestion. Un test par observation simple peut être suffisant pour constater l’apparition instantanée sur le terminal qui reçoit le message écrit.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 17.8 [A] : Pour chaque application web de télécommunication, l’identification de l’interlocuteur qui initie un appel est-elle accessible ?

Tests du critère 17.8

Test 17.8.1 Pour chaque application web de télécommunication qui fournit l’identification de l’interlocuteur, l’identification respecte-t-elle ces conditions ?
  • L’identification de l’interlocuteur est présentée sous forme de texte ;
  • L’identification de l’interlocuteur est accessible aux technologies d’assistance.
Méthodologie du test 17.8.1
  1. Activer l’application web depuis un terminal.
  2. Depuis un second terminal, lancer un appel vers le premier terminal.
  3. Lorsque l’appel entrant apparaît, vérifier :
    • que l’identification de l’interlocuteur est disponible visuellement sous la forme d’un texte dont la nature est compréhensible (par exemple, un nom ou un numéro de téléphone) ;
    • que cette identification est compatible avec les technologies d’assistance : par exemple, par l’utilisation d’un message de statut pertinent.
  4. Si c’est le cas, le test est validé.
Correspondances

Critère 17.9 [A] : Pour chaque application web de communication orale bidirectionnelle qui permet d’identifier l’activité d’un interlocuteur oralisant, il est possible d’identifier l’activité d’un interlocuteur signant. Cette règle est-elle respectée ?

Tests du critère 17.9

Test 17.9.1 Pour chaque application web de communication orale bidirectionnelle qui permet d’identifier l’activité d’un interlocuteur oralisant, il est possible d’identifier l’activité d’un interlocuteur signant. Cette règle est-elle respectée ?
Méthodologie du test 17.9.1
  1. Activer l’application web et lancer un appel vidéo entre les deux terminaux.
  2. Initier une activité orale, et vérifier la présence sur le second terminal d’une information permettant d’identifier cette activité (par exemple, la présence d’un halo de couleur autour de la vignette de l’interlocuteur en activité).
  3. Si c’est le cas :
    • repérer la présence d’un mécanisme manuel (par exemple, un bouton) qui permettrait à l’interlocuteur signant d’indiquer qu’il est en train de signer ;
    • sinon, réaliser des gestes devant la caméra (voir note) et vérifier l’affichage automatique d’une information permettant d’identifier cette activité visuelle.
  4. Si c’est le cas, le test est validé.

Note : dans les applications de communication, l’identification d’une activité orale ne repose pas sur l’identification d’un message verbal intelligible (mot ou phrase par exemple) mais uniquement sur l’identification d’un son (un bruit par exemple). Ainsi, une activité visuelle, même si elle ne correspond pas à un élément compréhensible en langue des signes, pourrait être détectée automatiquement par cette application et servirait donc comme mécanisme pour identifier l’activité d’une personne signante. Il est donc possible de tester en réalisant des gestes même s’ils ne correspondent pas à un élément de sens en langue des signes.

Correspondances

Critère 17.10 [A] : Pour chaque application web de communication orale bidirectionnelle qui dispose de fonctionnalités vocales, celles-ci sont-elles utilisables sans la nécessité d’écouter ou parler ?

Tests du critère 17.10

Test 17.10.1 Pour chaque application web de communication orale bidirectionnelle qui dispose de fonctionnalités vocales, celles-ci sont-elles utilisables sans la nécessité d’écouter ou parler ?
Méthodologie du test 17.10.1
  1. Repérer dans l’application web les fonctionnalités disponibles (en dehors de la fonctionnalité de communication orale) qui se basent sur l’écoute d’information ou l’énonciation de commande, par exemple :
    • une messagerie vocale ;
    • un standard téléphonique automatique (par exemple, qui demande d’énoncer un chiffre entre 1 et 4 pour être redirigé vers un service) ;
    • ou tout autre serveur vocal interactif.
  2. Vérifier :
    • que l’information est disponible sans devoir écouter ou parler (par exemple grâce à une transcription textuelle ou un système de chat) ;
    • que les actions peuvent être réalisées sans devoir écouter ou parler ou qu’il existe une alternative à la fonctionnalité qui peut être utilisée sans devoir écouter ou parler.
  3. Si c’est le cas, le test est validé.
Correspondances

Critère 17.11 [AA] : Pour chaque application web de communication orale bidirectionnelle qui dispose d’une vidéo en temps réel, la qualité de la vidéo est-elle suffisante ?

Tests du critère 17.11

Test 17.11.1 Pour chaque application web de communication orale bidirectionnelle qui dispose d’une vidéo en temps réel, les conditions suivantes sont-elles respectées ?
  • La résolution de la vidéo répond à la norme QVGA au moins ;
  • La fréquence des images est de 20 images par seconde au moins ;
  • Le décalage entre la vidéo et les paroles ne doit pas être supérieur à 100 ms.
Méthodologie du test 17.11.1

Pour les conditions concernant la résolution et la fréquence des images, la façon la plus sûre d’évaluer ce critère est de faire une recherche soit dans l’interface soit dans la documentation de l’application pour obtenir ces informations. Il est également recommandé de demander à l’éditeur de l’application de fournir ces détails techniques.

Pour la dernière condition concernant le décalage entre la vidéo et l’audio, le test peut s’établir sur une simple observation :

  1. Activer l’application web sur deux terminaux.
  2. Établir une connexion d’appel vidéo entre les deux terminaux.
  3. Vérifier la synchronisation entre les paroles et la vidéo (synchronisation labiale, mouvement des lèvres).
  4. Si c’est le cas, le test est validé.
Correspondances