ARIA : rôle application

Description

Le rôle application de structure de document, indique aux technologies d'assistance que cette partie du contenu web contient des éléments qui ne se conforment à aucun autre élément HTML connu ni à aucun widget WAI-ARIA. Toute interprétation spéciale des structures HTML et des widgets doit être suspendue, et le contrôle doit être entièrement remis au navigateur et à l'application web pour gérer l'interaction par la souris, le clavier ou le toucher.

Dans ce mode, l'auteur·ice du site est entièrement responsable de la gestion de toutes les saisies clavier, de la gestion du focus et des autres interactions, et ne peut pas supposer que les technologies d'assistance effectueront un traitement de leur côté.

Si l'application web englobée par le rôle application contient des parties qui doivent être traitées comme du contenu web normal, un rôle document ou article doit être utilisé pour contenir ce contenu.

Contexte

Pour des raisons historiques, notamment sous Windows, les lecteurs d'écran et certaines autres technologies d'assistance (TA) ont traditionnellement récupéré l'intégralité du contenu web depuis le navigateur d'un coup une fois le chargement terminé. Les technologies d'assistance construisent leur propre représentation qui a le plus de sens pour qu'un·e utilisateur·ice malvoyant·e consomme le contenu. Cela est souvent appelé document virtuel, mode navigation, ou des termes similaires. Le document est simplifié en une vue à une seule colonne. Un modèle d'interaction clavier est généré, très similaire à un traitement de texte où les utilisateur·ice·s peuvent lire ligne par ligne, phrase par phrase ou paragraphe par paragraphe. La technologie d'assistance lit toutes les informations sémantiques comme les liens, titres, contrôles de formulaire, tableaux, listes ou images.

En outre, un ensemble de soi-disant touches de navigation rapide a été établi au fil des ans, permettant aux utilisateur·ice·s malvoyant·e·s de parcourir rapidement une page via un type d'élément particulier. Ces éléments incluent généralement les titres, champs de formulaire, listes, tableaux, liens, graphiques ou zones repères.

Pour que tout cela fonctionne, les technologies d'assistance interceptent presque toutes les saisies clavier et les consomment elles-mêmes, ne laissant rien passer au navigateur ou à un autre agent utilisateur. Pour interagir avec une page web, un ensemble standard de widgets est reconnu et, en appuyant sur une touche particulière (souvent la touche Entrée), ce mode est désactivé. Le mode lecteur d'écran, souvent appelé mode formulaire ou mode focus, laisse à nouveau toutes les saisies clavier passer au navigateur. Échap est la méthode la plus courante pour revenir en mode navigation, mais dans une section application spécifique, certains lecteurs d'écran peuvent nécessiter d'autres touches pour quitter ce mode volontairement. Par exemple NUM + avec JAWS.

Le rôle application est conçu pour fournir un moyen aux widgets qui ne font pas partie de l'ensemble standard d'être accessibles pour une interaction directe dans les technologies d'assistance qui utilisent à la fois les modes navigation et focus pour interagir avec le contenu web. La plupart des widgets courants ont des comportements d'interaction clavier attendus. Pour cette raison, une expérience clavier personnalisée créée par un auteur web pourrait créer une expérience confuse.

Rôles, états et propriétés WAI-ARIA associés

document, article

Utilisé pour indiquer les parties de l'application qui doivent être traitées comme du contenu web normal

aria-activedescendant

Utilisé pour gérer le focus à l'intérieur de l'application.

aria-label

Utilisé pour fournir le nom de l'application ou la fonction du widget exposé.

aria-describedby

Utilisé pour référencer l'ID d'un élément qui contient des instructions supplémentaires pour la navigation ou l'utilisation de cet élément.

aria-roledescription

Utilisé pour donner à l'application un texte de rôle plus descriptif que les lecteurs d'écran peuvent énoncer. Celui-ci doit être localisé.

aria-disabled

Indique qu'un élément est visible mais désactivé

aria-errormessage

Référence l'élément qui fournit le message d'erreur pour l'élément sur lequel il est défini

aria-expanded

Si défini sur true, l'élément de regroupement détenu ou contrôlé par cet élément est développé, ou false s'il est réduit.

aria-haspopup

Indique qu'il existe un élément contextuel, tel qu'un menu ou une boîte de dialogue, qui peut être déclenché par l'élément.

Interactions clavier

L'interaction clavier est entièrement sous le contrôle de l'auteur·ice du site et peut correspondre à n'importe quoi associé au widget particulier implémenté. Dans une application de présentation, par exemple, un widget pourrait être créé qui utilise les touches fléchées pour positionner des éléments sur la diapositive, et utilise un retour audio via une région ARIA en direct pour communiquer la position et le statut de chevauchement avec d'autres objets. Le focus est géré via aria-activedescendant.

Les touches Tab, Espace et Entrée, ainsi que Échap, doivent être gérées par l'application. La seule exception est si le focus est défini sur un widget standard à l'intérieur de l'application qui prend en charge la navigation clavier du navigateur, par exemple un élément input.

Fonctionnalités JavaScript requises

keyPress

Utilisé pour gérer les saisies clavier et contrôler le focus

Click, Touch

À gérer en fonction de votre widget

Modification des valeurs d'attributs

aria-activedescendant est utilisé pour gérer le focus dans le conteneur de l'application. À définir en réponse aux événements clavier ou autres événements de l'application qui modifient le focus ou le point d'interaction.

Exemples

Quelques applications web notables qui utilisent ou ont utilisé correctement le rôle application sont :

• Google Docs, Sheets et Slides
• Les éditeurs web WYSIWYG CKEditor et TinyMCE, comme celui utilisé sur le Mozilla Developer Network
• Certaines parties de Gmail

Problèmes d'accessibilité

Une utilisation incorrecte du rôle application peut retirer involontairement l'accès à certaines informations d'une page web, soyez donc très attentif à son usage. Réfléchissez bien à si vous en avez réellement besoin et si vous ne pouvez pas simplement utiliser un ensemble d'autres widgets connus pour accomplir la même tâche.

Si utilisé, le rôle application doit être ajouté au conteneur commun le plus bas possible, et non sur l'élément <body>, par exemple. Assurez-vous également de tester ce que vous avez écrit avec des technologies d'assistance, pour vérifier que cela fonctionne comme prévu.

Spécifications

Ordre de priorité

Appliquer le rôle application fera que cet élément et tous ses descendants seront traités comme du contenu applicatif, et non comme du contenu web. Tout mécanisme de lecture que les technologies d'assistance pourraient avoir pour le contenu web ne s'appliquera pas.

Voir aussi

• Si vous utilisez le rôle WAI-ARIA application, faites-le avec discernement ^(angl.) - billet de blog de Marco Zehe
• Utiliser le rôle ARIA application ^(angl.) - par Léonie Watson