Notes techniques

Les notes techniques ci-dessous donnent des explications pour la prise en charge de certains éléments HTML5 dont le support peut être variable et la manière dont le référentiel propose de les prendre en charge.

Images

Critère 1.2 [A]

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

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

Critère 1.3 [A] : attribut title

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

Critère 1.3 [A] : balise <title> dans les éléments SVG

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

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

Critère 1.6 [A]

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

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

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

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

Critère 1.8 [AA] et 1.9 [AAA]

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

Critère 1.10 [A]

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

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

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

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

Tableaux

Critère 5.1 [A]

La spécification propose plusieurs méthodes pour lier un résumé à un tableau (tableau lié à un passage de texte avec aria-describedby, tableau groupé via figure avec le résumé en texte adjacent, tableau groupé avec figure avec le résumé dans un élément figcaption, résumé dans un élément details dans l'élément caption).

Ces méthodes n'ont pas un support suffisant pour être utilisées actuellement.

Critère 5.7 [A]

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.

Scripts

Critère 7.1 [A]

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

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.

Critère 7.3 [A]

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

Structuration de l'information

Critère 9.1 [A]

ARIA permet de définir des titres via le rôle heading et la propriété 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é.

Bien que la spécification HTML5 autorise l'utilisation exclusive de titres de niveau 1 (h1), le manque de support des technologies d'assistance oblige à utiliser une hiérarchie de titres pertinente.

Critère 9.2 [A]

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

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

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

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

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

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

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

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

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

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

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

Critère 9.3 [A]

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

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

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

Références : The roles model - list

Présentation de l'information

Critère 10.7 [A]

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

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

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

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

Critère 10.13 [A]

WAI-ARIA propose une propriété aria-hidden (true ou false) qui permet d'inhiber la restitution d'un contenu en direction des technologies d'assistance, sans influencer 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é.

Formulaires

Critère 11.11 [AA]

Certains types de formulaire HTML5 proposent des messages d'aide à la saisie automatique, par exemple les types url et email affichent un message du type « veuillez saisir une adresse e-mail valide » dans le cas où l'adresse e-mail saisie ne correspond pas au format attendu. Ces messages sont personnalisables via l'API Constraint Validation qui peut permettre de personnaliser les messages d'erreur et valider le critère. Attention cependant, le support de cette API n'est pas encore stabilisé. Le type pattern qui permet d'effectuer automatiquement des contrôles de format (via des expressions régulières) affiche également un message d'aide, mais ce dernier est personnalisable via l'attribut title, ce dispositif valide le critère.

Référence : WHATWG - 4.10.21.3 The constraint validation API.

Navigation

Critère 12.10 [A]

WAI-ARIA propose des rôles permettant d'indiquer les zones principales (régions) du document. Ces rôles sont très profitables aux utilisateurs de lecteurs d'écran notamment, mais également aux utilisateurs de la navigation au clavier qui peuvent ainsi bénéficier de fonctionnalités de navigation rapide dans la structure du document. Si la plupart des lecteurs d'écran mettent à disposition ces fonctionnalités, les navigateurs n'ont pas encore proposé de fonctionnalité de navigation dédiée pour les utilisateurs qui ne peuvent pas utiliser la souris. La mise en place des liens d'évitement reste donc une exigence.