Création d’interfaces utilisateur avec un balisage sémantique

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Expliquer la nécessité du balisage sémantique pour rendre le contenu accessible
• Définir les trois types d’attributs dans ARIA

Introduction

De nombreux facteurs entrent en jeu dans la création d’interfaces utilisateur accessibles. D’une manière générale, plus l’interface est complexe, plus vous devez prendre en compte de facteurs. Par exemple, vous aurez moins d’éléments à prendre en compte en matière d’accessibilité pour un simple article de blog ou d’actualité que pour un article d’actualité avec des commentaires, des fonctionnalités de réseaux sociaux ou d’autres fonctionnalités interactives. Une application Web complexe, comme un générateur de rapport ou de tableau de bord, un éditeur de présentation de page ou même une vue de liste Kanban, a des besoins encore plus importants en matière d’accessibilité.

Plus la page Web ou l’application est complexe, plus vous aurez d’efforts à faire pour vous assurer qu’elle est accessible aux utilisateurs en situation de handicap. Cela dit, vous devez commencer par les concepts de base pour être en mesure de rendre une page Web ou une application accessible. 

Présentation du balisage sémantique

Le balisage sémantique constitue la fondation de l’accessibilité. Le contenu qui apparaît sur une page Web doit être présenté à l’aide d’un balisage représentant le type de contenu. Par exemple, les données d’un tableau doivent être présentées en utilisant un balisage lié à l’élément <table>, les listes doivent être présentées en utilisant un balisage lié à l’élément <ul>, les en-têtes visuels doivent utiliser des balises d’en-tête, etc.

Le balisage sémantique rend le contenu lisible et compréhensible par les machines et les logiciels, en particulier les technologies d’assistance, ce qui est nécessaire pour que le contenu soit accessible. Un utilisateur aveugle peut utiliser un lecteur d’écran pour naviguer dans un générateur de rapports créé avec des éléments <table> HTML corrects. Cependant, si ce même contenu comporte un balisage utilisant des éléments <div>, cet utilisateur ne peut pas naviguer correctement ou comprendre ces éléments, qui peuvent pourtant sembler identiques aux utilisateurs voyants.

La structure HTML des pages Web et des applications adapte leur contenu pour les technologies d’assistance et les utilisateurs qui s’appuient sur des technologies d’assistance. Nous vous recommandons d’utiliser des éléments HTML5 sémantiques dans la mesure du possible et de valider votre balisage à l’aide d’un vérificateur tel que le vérificateur HTML Nu.

Premiers pas avec la spécification ARIA

ARIA, qui signifie Accessible Rich Internet Applications, est une extension de code HTML tenant compte du fait que les pages Web ne sont pas seulement utilisées à des fins de balisage ou d’affichage. ARIA comprend que le Web est une plate-forme destinée à créer des applications complexes et offre des options beaucoup plus avancées pour communiquer avec les utilisateurs en situation de handicap, grâce à des technologies d’assistance.

ARIA fonctionne en appliquant des attributs spéciaux aux nœuds DOM de fichiers HTML. Il existe trois types d’attributs disponibles dans ARIA : les rôles, les états et les propriétés.

Rôles

Les rôles sont un moyen de donner une signification sémantique à des éléments HTML qui n’en ont traditionnellement pas, tels que <div> ou <span>. Par exemple, vous pouvez utiliser les rôles ARIA pour identifier un ensemble d’éléments non sémantiques, comme un bouton ou un lien, ou des composants plus complexes tels que des menus, des zones de liste déroulante, des boîtes de dialogue ou des grilles interactives. 

Les rôles correspondent à une promesse faite aux utilisateurs. Si vous ajoutez un rôle ARIA à un élément, par exemple en intégrant role="button" à un élément <div>, cela signifie que cette balise <div> doit s’identifier comme un bouton. Cet élément <div> apparaît maintenant dans l’arbre d’accessibilité du navigateur sous la forme d’un élément <button>. L’arbre d’accessibilité du navigateur est un instantané des informations présentées au lecteur d’écran. Vous devez donc également fournir à l’élément <div> toutes les fonctionnalités dont un bouton dispose nativement. Cela inclut les états de focus, l’interactivité du clavier, l’interactivité de la souris, etc. Le fait d’appeler un élément <div> un bouton sans le faire fonctionner comme tel revient à rompre la promesse faite à vos utilisateurs.

États

Les états sont des attributs qui décrivent l’état d’un composant ARIA dans l’arbre d’accessibilité d’un navigateur. Un état décrit si un menu déroulant est expanded (développé) ou non, si son type d’entrée est disabled (désactivé) ou readonly (en lecture seule), si une case est checked (cochée), si un élément d’une zone de liste est selected (sélectionné), etc. Lors de la création de composants complexes à l’aide d’ARIA, il est essentiel de correctement mettre à jour ses différents états via une opération de contrôle. Tout cela est nécessaire pour tenir la promesse que vous avez faite aux utilisateurs en utilisant un attribut de rôle. 

Propriétés

Le W3C définit les propriétés ARIA comme des « attributs essentiels à la nature d’un objet donné ou qui représentent une valeur de données associée à l’objet ». Ce sont des attributs qui décrivent la nature d’un objet. Pensez à la différence entre un élément <select> avec l’attribut multiple et un élément <select> sans l’attribut multiple. Le premier est une zone de liste déroulante dans laquelle il est possible de faire plusieurs sélections, tandis que le second correspond à une zone de liste déroulante où un utilisateur doit cliquer sur l’état réduit pour ouvrir la zone et sélectionner un seul élément. Dans ce cas, multiple est une propriété de notre élément <select> natif. 

De la même manière, ARIA dispose de nombreux attributs de propriété qui permettent de décrire des objets, mais ne changent pas forcément de manière régulière pour mettre à jour l’état d’un objet.

Il peut être complexe d’identifier toutes les informations relatives aux attributs ARIA. En général, nous vous recommandons vivement de suivre nos plans de composants dans Salesforce Lightning Design System (SLDS). SLDS contient plus de 900 plans HTML, avec des recommandations sur l’accessibilité détaillées pour le balisage, les attributs et les interactions clavier. Ces plans incluent tous les rôles, propriétés et états ARIA corrects placés aux endroits adéquats. De plus, nos plans comprennent des informations concernant l’accessibilité, indiquant comment associer et gérer correctement les états et les propriétés des composants que vous créez. 

Les éléments ARIA figurant dans les plans de composants SLDS ont été testés avec une technologie d’assistance et sont conformes au guide des pratiques de création ARIA. Ce document est régulièrement mis à jour et constitue la source de référence actuelle pour utiliser ARIA et de nombreux modèles de conception courants. 

Il se peut que vous ne trouviez pas tous les modèles d’interaction dont vous avez besoin dans les plans de composants SLDS. Pour tous les éléments qui ne se trouvent pas dans notre système de conception, reportez-vous au guide des pratiques de création ARIA et à la spécification ARIA elle-même. Ne faites confiance à aucune autre référence sur Internet. Il existe de nombreuses années d’idées, d’explorations et de composants véritablement inadaptés et inaccessibles qui se font passer pour des solutions modernes et accessibles.

Maintenant que vous avez découvert les concepts de base de la création d’interfaces utilisateur accessibles, explorons la navigation accessible. 

Ressources

• Documentation : Guide des pratiques de création ARIA
• Documentation : Accessible Rich Internet Applications (WAI-ARIA) 
• Outil : Vérificateur HTML Nu
• Aide Salesforce : Salesforce Lightning Design System