En tant que développeur, vous souhaitez créer des expériences numériques plus inclusives et plus accessibles pour vos utilisateurs. C'est formidable ! Il se peut toutefois que vous vous sentiez un peu perdu ou submergé par les attributs des éléments qui peuvent avoir une incidence sur l'ergonomie pour les utilisateurs de technologies d'assistance.
ARIA (ou WAI-ARIA, pour « Web Accessibility Initiative – Accessible Rich Internet Applications ») définit certains attributs « aria-* » dont le nom est très similaire à celui d’attributs HTML. Cela peut prêter à confusion. Des questions telles que « Sont-ils identiques, mais l’un d’entre eux est-il destiné à l’accessibilité ? » ou « Dois-je utiliser l’un ou l’autre, ou les deux ? » reviennent très souvent. Voici quelques exemples :
- Est-ce que le
aria-disabledattribut identique à celui du code HTMLdisabledattribut ? - Est-ce que le
aria-autocompleteattribut identique à celui du code HTMLautocompleteattribut ? - Est-ce que le
aria-hiddenattribut identique à celui du code HTMLhiddenattribut ?
Bien que leurs noms soient similaires, leurs finalités sont différentes et ils ne sont pas interchangeables. Il peut s’avérer délicat de les utiliser correctement. Selon une étude WebAIM de 2023, les pages d’accueil utilisant ARIA présentaient en moyenne 68,6 % d’erreurs détectées en plus que celles qui n’utilisaient pas ARIA. Examinons brièvement les similitudes et les différences entre ces attributs, ainsi que la manière de les mettre en œuvre correctement.
« disabled » et « aria-disabled »
Le code HTML disabled L'attribut « disabled » désactive un contrôle de formulaire (ainsi que tous ses contrôles descendants), ce qui signifie qu'il ne pourra pas être modifié, qu'il ne pourra pas recevoir le focus et qu'il ne sera pas envoyé avec le formulaire. De plus, de nombreux navigateurs modifient automatiquement l'apparence du contrôle, qui apparaît alors grisé et inactif. D'un point de vue sémantique, le contrôle de formulaire est désactivé. Vous pouvez ajouter l'attribut disabled attribut appliqué aux boutons, aux champs de saisie, aux éléments « input », aux groupes d'options, aux options, aux listes déroulantes et aux zones de texte.
Le aria-disabled attribut, lorsqu’il est défini sur «true« , se distingue en ce qu’il indique UNIQUEMENT aux technologies d’assistance que l’élément (et tous ses descendants pouvant recevoir le focus) est désactivé. L’ajout de cet attribut à un élément et sa valeur « true » n’ont aucun effet automatique sur la possibilité de le modifier, de lui attribuer le focus ou de le valider dans un formulaire. La présentation visuelle de l’élément ne change pas non plus automatiquement. Toutes ces caractéristiques et fonctionnalités devront être gérées par un développeur. Cependant, cet attribut peut être largement utilisé, y compris sur des contrôles personnalisés, ce qui en fait un outil puissant.
Ces deux attributs sont utiles et peuvent avoir une incidence sur l'accessibilité d'un contrôle. Lorsque l'on utilise des contrôles de formulaire standard, le code HTML disabled Cet attribut est facile à utiliser et permettra, dans la plupart des cas, de désactiver le contrôle. Cependant, si vous avez besoin de plus de souplesse ou si vous développez un contrôle personnalisé (comme un bouton désactivé personnalisé), le aria-disabled L'attribut est la solution idéale ! Vous ne devriez pas avoir besoin de les utiliser tous les deux sur un même contrôle, mais vous pourriez avoir besoin de les utiliser tous les deux dans une page.
Cela vaut la peine d'approfondir le sujet. Vous trouverez une excellente documentation sur ces deux sujets :
Saisie semi-automatique et aria-autocomplete
Le code HTML autocomplete L'attribut permet à un développeur de préciser le type d'informations que le navigateur peut suggérer pour un champ de saisie, ainsi que le type d'informations attendues. Il existe différentes valeurs définies pour la saisie semi-automatique qui sont valides. Par exemple, autocomplete="given-name" Lorsqu'un utilisateur saisit des données dans ce champ, le navigateur sera informé que celui-ci est destiné à un prénom et pourra proposer des suggestions de prénoms que l'utilisateur a déjà fournis par le passé.
Le aria-autocomplete L'attribut, quant à lui, indique à une technologie d'assistance que l'ajout de texte dans une liste déroulante, un champ de recherche ou un champ de saisie peut déclencher l'affichage de valeurs suggérées pendant que l'utilisateur tape (également appelé « suggestion automatique »). Si la valeur de cet attribut est définie sur «inline«, cela signifie qu’il affichera une seule valeur. Et s’il est défini sur «list«, cela signifie qu’une série de valeurs sera présentée dans un élément distinct. Une troisième option, la valeur «both«, indique qu’il affichera une liste et une valeur estimée. Enfin, aria-autocomplete peut être défini sur none, qui est la valeur par défaut, et indique que le contrôle ne fournira pas de prédictions. Étant donné que cet attribut se contente de signaler à une technologie d'assistance que la fonctionnalité est présente sans pour autant déclencher aucune action, tout comportement ou fonctionnalité devra être entièrement géré par un développeur.
Ces deux attributs sont importants pour l'accessibilité. Le code HTML autocomplete Cet attribut peut avoir un impact considérable sur la rapidité, la précision et la facilité avec lesquelles un utilisateur remplit un formulaire sur une page Web. Il contribue également directement au critère de succès 1.3.5 des WCAG, « Identifier la finalité des champs de saisie » (niveau AA). L'utilisation de aria-autocomplete peut aider les utilisateurs de lecteurs d'écran à comprendre les interactions complexes au sein des contrôles personnalisés, tels qu'une recherche interactive ou une liste déroulante.
Cela peut tout de même prêter à confusion et il y a beaucoup de détails importants à prendre en compte. Consultez la documentation complémentaire :
« hidden » et « aria-hidden »
Le code HTML hidden Cet attribut empêche l'affichage de l'élément. Celui-ci n'apparaîtra pas à l'écran et ne sera pas lu par un lecteur d'écran.
Le aria-hidden Lorsque cet attribut est défini sur « true », il empêche un élément d'être pris en charge par les technologies d'assistance. Il ne modifie pas l'affichage visuel de l'élément. Il est donc possible que celui-ci reste visible, mais qu'il ne soit pas lu par un lecteur d'écran. Cela peut entraîner d'importants problèmes d'accessibilité et doit donc être utilisé avec la plus grande prudence. N'ajoutez jamais aria-hidden="true" sur un élément pouvant recevoir le focus, car cela lui ferait perdre son nom d'accessibilité !
Ces deux attributs constituent des outils puissants qui ont une incidence considérable sur l'accessibilité. Si un élément ne doit être affiché à personne mais doit rester dans le DOM, alors le code HTML hidden L'attribut est l'outil qu'il vous faut. Prenons l'exemple d'un contrôle permettant d'afficher ou de masquer du contenu : vous pouvez utiliser JavaScript pour simplement basculer entre les états hidden définir l'attribut « away » pour rendre le contenu visible, puis le redéfinir pour le masquer à tous les utilisateurs. Si vous disposez d'un contenu purement décoratif susceptible de prêter à confusion ou de distraire un utilisateur de lecteur d'écran, vous pouvez envisager d'utiliser aria-hidden avec beaucoup d'attention pour vous assurer que votre message soit clair. Il n'est pas nécessaire d'utiliser aria-hidden pour compléter l'attribut « hidden » du langage HTML. Le code HTML hidden Cet attribut masque le contenu pour tout le monde !
Pour en savoir plus à ce sujet, consultez la documentation détaillée :
Faisons le point
Bien que certains noms d’attributs « aria-* » ressemblent à des attributs HTML, ils ont des fonctions différentes et ne sont pas équivalents. Savoir quand et comment les utiliser fait toute la différence en matière d’accessibilité de l’expérience que vous développez. En général, les attributs « aria-* » servent à transmettre aux technologies d’assistance des informations importantes concernant les contrôles personnalisés ou les interactions complexes. Les attributs HTML, quant à eux, peuvent avoir un impact direct sur les fonctionnalités. Vous devrez utiliser les deux !
Maintenant que tout est clair, n'hésitez pas à créer des expériences exceptionnelles et accessibles !
