WCAG 1.3.6 : Identifier la finalité

Ce que signifie cette règle

\n

WCAG 1.3.6 — Identifier la finalité est un critère de niveau AAA relevant du Principe 1 (Perceptible) qui étend les exigences existantes en matière de structure et de sémantique à un niveau de granularité plus fin. Plus précisément, il exige que la finalité de chaque composant d’interface utilisateur, icône, région et certains champs de saisie puisse être déterminée de manière programmatique — ce qui signifie que l’information sémantique est exposée de façon à ce que les navigateurs, les extensions de navigateur et les technologies d’assistance puissent la lire et agir en conséquence.

\n

Ce critère s’appuie directement sur 1.3.1 (Information et relations) et 1.3.5 (Identifier la finalité de la saisie). Alors que 1.3.5 se concentre sur les champs de saisie de données personnelles courants (nom, e-mail, téléphone, etc.), 1.3.6 élargit l’exigence à toutes les régions et composants de l’interface utilisateur, y compris les repères de navigation, les icônes, les boutons et les widgets interactifs. L’idée centrale est qu’un agent utilisateur ou un outil de personnalisation doit pouvoir remplacer la présentation par défaut — en substituant des libellés textuels par des symboles, en simplifiant une navigation encombrée ou en mettant en évidence les contrôles les plus pertinents — sur la base de données de finalité lisibles par machine intégrées dans le balisage.

\n

Concrètement, une page satisfait à 1.3.6 lorsqu’elle utilise des éléments de repère HTML5 (tels que <header>, <nav>, <main>, <aside>, <footer> et <section>), applique des rôles de repère ARIA appropriés lorsque les éléments de repère ne sont pas utilisés, expose la finalité des icônes et autres composants d’interface non textuels via des noms ou rôles accessibles et — le cas échéant — utilise des jetons de finalité standardisés tels que ceux définis dans la spécification W3C Personalization Semantics (anciennement connue sous le nom de proposition COGA Semantics), par exemple via le vocabulaire d’attributs aui-.

\n

Une page échoue lorsque ses régions sont implémentées comme des conteneurs génériques <div> ou <span> sans rôle sémantique, lorsque des icônes portent une signification mais n’ont pas de nom accessible ni de sémantique associée, ou lorsque des composants interactifs ne fournissent aucun indice programmatique sur leur fonction au-delà de leur apparence visible. Une exception officielle s’applique : l’exigence ne s’applique qu’au contenu implémenté à l’aide de technologies prenant en charge l’identification de la signification attendue. Si aucune technologie ou spécification de support n’existe pour un type de composant particulier dans une pile technologique donnée, le critère ne peut raisonnablement pas être appliqué à ce composant.

\n\n

Pourquoi c’est important

\n

Les principaux bénéficiaires de WCAG 1.3.6 sont les personnes ayant des troubles cognitifs et d’apprentissage, notamment la dyslexie, les troubles de l’attention, les troubles du spectre autistique, les troubles de la mémoire et les déficiences intellectuelles. Selon l’Organisation mondiale de la Santé, environ 1 personne sur 6 dans le monde — plus d’un milliard de personnes — vit avec une forme de handicap significatif, et les handicaps cognitifs représentent l’un des groupes les plus importants et les plus mal desservis. Beaucoup de ces utilisateurs rencontrent des difficultés avec des structures de navigation complexes, des menus textuels denses et des contrôles uniquement sous forme d’icônes qui ne fournissent aucun ancrage sémantique.

\n

Considérons un scénario concret : une personne atteinte de dyslexie sévère s’appuie sur une extension de navigateur qui remplace les libellés de navigation standard par des ensembles de symboles personnels — des icônes basées sur des images provenant d’un tableau de communication qu’elle utilise au quotidien. Pour que cette substitution fonctionne, l’extension doit pouvoir déterminer qu’un certain <div> est en réalité un repère de navigation, qu’une icône en forme d’étoile représente « ajouter aux favoris » et qu’une flèche circulaire représente « actualiser ». Sans finalité déterminable de manière programmatique, l’extension n’a aucun point d’accroche et la substitution échoue silencieusement, laissant l’utilisateur avec une interface qu’il ne peut pas interpréter.

\n

Les personnes ayant un handicap moteur qui s’appuient sur des outils d’accès par contacteur ou de commande vocale en tirent également un bénéfice important, car les outils sensibles à la finalité peuvent générer des superpositions de raccourcis ou des mappages de commandes vocales uniquement pour les contrôles dont la fonction est lisible par machine. Les personnes aveugles qui interagissent via des lecteurs d’écran bénéficient de régions de repère clairement étiquetées, ce qui leur permet d’accéder directement au contenu <main> ou de passer une navigation répétitive. Les personnes malvoyantes qui utilisent le zoom du navigateur ou des feuilles de style personnalisées profitent de la structure de repères, car elle permet au navigateur de réorganiser le contenu de manière prévisible.

\n

Au-delà de l’accessibilité, la mise en œuvre des sémantiques requises par 1.3.6 offre des bénéfices SEO mesurables. Les robots d’indexation des moteurs de recherche utilisent les repères et le balisage de schéma pour comprendre la structure de la page, indexer les hiérarchies de contenu et générer des résultats enrichis. Une page bien structurée avec des régions de repère significatives a plus de chances d’obtenir des extraits optimisés et des scores de pertinence plus élevés. Il existe également un dividende en matière d’utilisabilité direct : les pages dotées d’une structure sémantique claire sont plus faciles à maintenir, tester et faire évoluer par les équipes de développement, ce qui réduit la dette technique à long terme.

\n\n

Règles axe-core associées

\n

WCAG 1.3.6 nécessite des tests manuels en plus de tout contrôle automatisé. Les outils automatisés peuvent vérifier la présence de balisage sémantique mais ne peuvent pas déterminer si ce balisage transmet de manière précise et complète la finalité de chaque composant comme le ferait un testeur humain. Les règles axe-core suivantes sont étroitement liées et servent de substituts automatisés pour certains aspects de ce critère :

\n

\n
• region — Vérifie que tout le contenu de la page est contenu dans une région de repère. Elle signale le contenu qui se trouve en dehors de tout élément de repère reconnu ou rôle de repère ARIA. Bien que cette règle ne teste pas la précision de l’identification de la finalité, elle garantit que la base structurelle requise par 1.3.6 est présente. Un échec signifie qu’un contenu important est invisible pour la navigation basée sur les repères.
\n
• landmark-one-main — Vérifie que la page contient exactement un élément <main> ou un élément avec role='main'. C’est fondamental pour 1.3.6 car la zone de contenu principal est l’une des régions les plus critiques dont la finalité doit être identifiable. Des repères <main> multiples ou absents rendent impossible pour les outils de personnalisation d’isoler le contenu principal.
\n
• landmark-complementary-is-top-level — Vérifie que les éléments <aside> ou les régions avec role='complementary' ne sont pas imbriqués dans la zone de contenu principal d’une manière qui déforme leur finalité. Un mauvais emboîtement induit les technologies d’assistance en erreur quant à la relation entre les régions.
\n
• aria-allowed-role et aria-valid-attr-value — Signalent les attributions de rôles ARIA invalides ou inappropriées. Étant donné que 1.3.6 dépend de sémantiques de rôle exactes, l’utilisation d’un rôle incorrect (par exemple, role='navigation' sur un groupe de boutons) compromet activement l’identification de la finalité et ces règles mettront en évidence de telles incohérences.
\n
• button-name et link-name — Vérifient que les contrôles interactifs ont des noms accessibles. Les boutons et liens uniquement sous forme d’icônes sans noms accessibles constituent un mode d’échec majeur pour 1.3.6, puisqu’aucune finalité ne peut être déterminée pour un contrôle sans nom. Ces règles signalent l’absence de aria-label, aria-labelledby ou de texte visible.
\n

\n

Des tests manuels sont nécessaires car les outils automatisés ne peuvent pas évaluer si les jetons de finalité choisis ou les rôles sémantiques représentent fidèlement la fonction réelle du composant dans le contexte de l’application. Un bouton peut avoir un nom accessible et un rôle ARIA valide mais tout de même ne pas satisfaire 1.3.6 si le nom est trompeur ou si le rôle ne reflète pas ce que le contrôle fait réellement.

\n\n

Comment tester

\n

\n
1. Exécuter une analyse automatisée avec axe DevTools ou Lighthouse. Ouvrez la page dans Chrome, activez l’extension axe DevTools et lancez une analyse de page complète. Filtrez les résultats selon les règles listées ci-dessus : region, landmark-one-main, button-name et link-name. Notez toutes les violations et leurs niveaux d’impact. Dans Lighthouse, exécutez un audit Accessibilité et examinez les sections relatives aux repères et à ARIA. Documentez tous les échecs comme base de référence, en gardant à l’esprit qu’ils ne représentent qu’un sous-ensemble de la conformité à 1.3.6.
\n
2. Inspecter manuellement la structure des repères à l’aide des outils de développement du navigateur. Ouvrez DevTools, accédez au panneau Accessibility Tree (Chrome) ou à l’Accessibility Inspector (Firefox) et vérifiez que la page expose une hiérarchie de repères cohérente : un <header> au niveau supérieur, un <main>, au moins un <nav> (avec une étiquette distinctive si plusieurs sont présents) et un <footer>. Confirmez qu’aucune région de contenu significative n’est enveloppée uniquement dans un <div> ou un <span> générique.
\n
3. Tester avec NVDA et Firefox. Lancez NVDA, ouvrez la page dans Firefox et appuyez sur D pour parcourir les repères. Vérifiez que chaque repère est annoncé avec un rôle significatif et, lorsque plusieurs repères du même type existent, une étiquette unique. Accédez à chaque bouton uniquement sous forme d’icône à l’aide de la touche Tab et confirmez que NVDA annonce un nom accessible descriptif — pas une chaîne vide, un nom de fichier ou une étiquette générique comme « bouton ».
\n
4. Tester avec VoiceOver et Safari (macOS/iOS). Activez VoiceOver (Cmd+F5 sur macOS). Utilisez le Rotor (Vo+U) pour ouvrir la liste des repères et vérifiez que toutes les régions attendues apparaissent. Parcourez les contrôles interactifs avec la touche Tab et écoutez des descriptions significatives. Sur iOS, utilisez un balayage à trois doigts pour naviguer par titres et repères et confirmez que la finalité de chaque région est annoncée correctement.
\n
5. Tester avec JAWS et Chrome. Ouvrez la page dans Chrome avec JAWS en cours d’exécution. Appuyez sur R pour naviguer entre les régions et confirmez que le rôle et l’étiquette de chaque région sont exacts. Utilisez le curseur virtuel JAWS pour parcourir les boutons d’icônes et vérifier que leur finalité est transmise. Utilisez la liste des liens JAWS (Insert+F7) pour vérifier la pertinence de tous les noms de liens.
\n
6. Tester les sémantiques de personnalisation (si implémentées). Si votre page utilise le vocabulaire W3C Personalization Semantics (par exemple, des attributs data-purpose ou aui-), utilisez l’outil de test Personalization Semantics ou une extension de navigateur compatible pour vérifier que les jetons de finalité sont correctement appliqués et lisibles par machine par les agents utilisateurs qui prennent en charge la spécification.
\n
7. Réaliser un audit de finalité composant par composant. Pour chaque composant interactif et chaque icône de la page, demandez-vous : peut-on déterminer la finalité de ce composant sans contexte visuel ? Si, après avoir supprimé tous les CSS et images, la finalité du composant reste claire à partir du DOM et des attributs ARIA seuls, il est conforme. Si la finalité n’est transmise que visuellement, il échoue.
\n

\n\n

Comment corriger

\n\n

Régions div génériques sans repères — Incorrect

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Régions div génériques sans repères — Correct

\n

<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Bouton uniquement avec icône sans nom accessible — Incorrect

\n

<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Bouton uniquement avec icône sans nom accessible — Correct

\n

<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Plusieurs repères de navigation sans étiquettes distinctives — Incorrect

\n

<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)