Tout ce tapage autour d'ARIA

Carrie Fisher

By Carie Fisher

18 septembre 2018

Webp.net redimensionner l'image 43 1

Introduction

C'est la période la plus merveilleuse de l'année ! Non, je ne parle pas des vacances d'hiver, mais de cette autre période magique de l'année que les parents attendent avec impatience et que les enseignants redoutent : la rentrée scolaire ! Blague à part, j’étais ce petit intello qui adorait vraiment l’école. Je me souviens encore de l’odeur des copeaux de crayon et de la poussière de tableau noir, du bruit que fait un livre neuf quand on l’ouvre et qu’on en plie la reliure, du plaisir de revoir mes vieux amis et d’apprendre de nouvelles matières… Comment ne pas aimer ça ?

Aujourd’hui, la plupart des adultes ont une perception un peu différente de l’apprentissage de nouvelles choses. Entre l’âge scolaire et l’âge adulte, l’art d’apprendre change pour beaucoup d’entre nous. Apprendre n’est plus tant une question de créativité et de plaisir, mais devient quelque chose de plus banal, d’obligatoire, voire d’intimidant. Réfléchissez-y : à quand remonte la dernière fois où vous étiez vraiment enthousiaste à l’idée d’apprendre quelque chose de nouveau ?

Avec cette série destinée aux débutants en matière d'accessibilité, j'espère vous faire redécouvrir un peu de cet enthousiasme pour l'apprentissage tout en vous présentant divers sujets liés à l'univers de l'accessibilité numérique. Mon objectif est de proposer des articles simples, factuels et, surtout, de vous apporter des conseils pratiques que vous pourrez intégrer à votre travail quotidien.

ARIA, premier acte

Scène 1 : La Fondation

ARIA a été développé pour la première fois en 2008 par le groupe Web Accessibility Initiative (WAI) – une branche du World Wide Web Consortium (W3C), l'organisme faîtier chargé de régir et de réglementer Internet. ARIA est l'acronyme de « Accessible Rich Internet Applications » (applications Internet riches et accessibles) et porte officiellement le nom de WAI-ARIA (mais beaucoup l'appellent par son nom abrégé).

Le groupe WAI définit ARIA comme suit :

« Une méthode permettant de rendre les contenus et les applications Web plus accessibles aux personnes en situation de handicap. Elle est particulièrement utile pour les contenus dynamiques et les commandes d'interface utilisateur avancées développées à l'aide d'Ajax, du HTML, de JavaScript et des technologies associées. »

En termes plus simples, ARIA définit un ensemble d'attributs destinés à corriger les balisages incorrects et à pallier les lacunes du langage HTML afin d'offrir une expérience plus accessible aux utilisateurs de technologies d'assistance (TA). L'intégration correcte d'ARIA dans votre code garantit que les utilisateurs de technologies d'assistance disposeront de toutes les informations nécessaires pour utiliser votre site web ou votre application.

 

Les directives définissent trois caractéristiques principales d'ARIA :

  1. Rôles — définissent ce qu’est un élément ou ce qu’il fait. Les rôles peuvent aider à identifier les repères, la structure du document, ainsi que les widgets. En voici un exemple :

    <div role="button">Here is a snazzy button</div>

     

  2. Propriétés — expriment les caractéristiques ou les relations d’un objet. Voici un exemple utilisant `aria-describedby` est :

    <div role="button" aria-describedby="some-other-element">Here is a snazzy button</div> <div id="some-other-element">This page will self destruct in 10 seconds.</div>

     

  3. États ou valeurs — définissent les conditions actuelles ou les valeurs associées à l'élément. Voici un exemple utilisant `aria-pressed` est :

    <div role="button" aria-describedby="some-other-element" aria-pressed="false">Here is a snazzy button</div> <div id="some-other-element">This page will self destruct in 10 seconds.</div>

Bien sûr, il s’agit là d’une explication simplifiée d’ARIA, et les exemples de code ci-dessus sont assez épurés afin d’illustrer les fonctionnalités d’ARIA (en d’autres termes, vous devriez ajouter du code supplémentaire si vous souhaitiez créer un véritable bouton). À mesure que votre code gagne en complexité, les rôles, propriétés et états ARIA peuvent être superposés jusqu’à ce que l’objectif final d’accessibilité soit atteint. Connaître les règles de base de chaque rôle, propriété et état ARIA peut vous aider à déterminer quels éléments doivent figurer à quel endroit dans votre balisage.

À ce stade, vous craignez peut-être qu’ARIA ne modifie les fonctionnalités de votre page web ainsi que son aspect général : ne vous inquiétez pas ! ARIA ne modifie en réalité en rien les fonctionnalités natives du navigateur. Considérez ARIA comme une couche supplémentaire de compréhension entre le HTML et les technologies d’assistance. De même, ARIA ne modifie pas l’aspect visuel de votre page web, à moins que vous n’ajoutiez à votre feuille de style CSS des règles ciblant spécifiquement ARIA. Cela signifie que personne, à l’exception des technologies d’assistance (et des personnes qui les utilisent), ne remarquera de différence entre une page web ou une application utilisant ARIA et une autre qui n’en utilise pas.

Scène 2 : ARIA contre HTML

In 2014, the W3C officially published the HTML5 recommendation to the world. With it came some big changes, including the addition of elements such as `<main>`, `<header>`, `<footer>`, `<aside>`, `<nav>` and attributes like `hidden` and `required`. With the addition of these new HTML5 elements and attributes coupled with increased browser support, parts of ARIA are now obsolete – or at least less critical than before.

Lorsque le navigateur prend en charge une balise HTML comportant un rôle implicite qui possède un équivalent ARIA, il n'est généralement pas nécessaire d'ajouter également des attributs ARIA à cet élément. Cependant, ARIA comprend encore de nombreux rôles, états et propriétés qui ne sont disponibles dans aucune version du langage HTML ; ceux-ci resteront donc utiles pendant un certain temps.

Pour que ce soit simple pour les débutants, lors des formations « Deque », nous rappelons la première règle d'ARIA définie par le W3C :

« Si vous pouvez utiliser un élément ou un attribut HTML natif intégrant déjà la sémantique et le comportement dont vous avez besoin, plutôt que de détourner un élément de sa fonction d'origine et d'y ajouter un rôle, un état ou une propriété ARIA pour le rendre accessible, alors faites-le. »

So if we look back at the earlier coding example, instead of using ARIA to define the role of our button element, we can use the HTML `<button>` element instead.

Code d'origine (utilisant uniquement ARIA) :

<div role="button">Here is a snazzy button</div>

 

Nouveau code (en HTML uniquement) :

<button>Here is a snazzy button</button>

 

Nouveau code (utilisant HTML + ARIA) :

<button aria-describedby="some-other-element">Here is a snazzy button</button> <div id="some-other-element">This page will self destruct in 10 seconds.</div>

 

Technically, each example conveys the same semantics, but the big difference is the ARIA only version requires us to define the functionality of the button role with additional code, while the HTML versions work right out of the box for browsers that support the `<button>` element.* When we combine the powers of HTML and ARIA as shown in the last example, we provide additional information about the button’s purpose.

*Remarque : étant donné que le <button> Cet élément ayant été introduit dans HTML4, je peux raisonnablement supposer qu’il est entièrement pris en charge par les dernières versions de tous les principaux navigateurs et qu’il fonctionnera correctement avec la plupart des technologies d’assistance. On ne peut toutefois pas en dire autant de tous les éléments et attributs HTML5 les plus récents. Pour vérifier la compatibilité des navigateurs, je consulte souvent des sites web tels que Accessibilité HTML5, Puis-je utiliser, ou la liste du W3C des ARIA dans les attributs HTML avant de décider si je peux utiliser des éléments HTML ou ARIA pour un modèle donné. J'approfondirai ce sujet dans un prochain article de blog consacré à ARIA.

Les experts en accessibilité et les utilisateurs de technologies d'assistance ont tous des opinions divergentes sur la question ARIA vs HTML, et ce débat risque de durer encore très longtemps. Ces discussions sont tout à fait pertinentes dans un monde théorique, où un développeur soucieux de l'accessibilité aurait un contrôle total sur le balisage, la mise en forme et les fonctionnalités d'un site web ou d'une application. Mais la réalité est souvent plus complexe.

For example, there may be times where you cannot change all the `<div role=”button”>`’s on your page to `<button>`’s and that is maybe not ideal, but it is OK. If you do have more control over your website or app code, by all means, add in fully supported HTML elements (and any ARIA helpers you may need) from the beginning. But from a practical sense, I encourage other developers to just do what works for your particular situation and be sure to test your code before releasing it. Even if you only change one small piece of code at a time – every little bit helps!

Scène 3 : ARIA en action

Comme mentionné précédemment dans cet article, il est recommandé d’utiliser des éléments HTML natifs lorsque leur prise en charge par les navigateurs est bonne. Cependant, lorsqu’ils sont correctement codés, les éléments ARIA peuvent et doivent se comporter comme des éléments HTML natifs. Vous disposez donc d’une certaine flexibilité pour rendre votre modèle plus accessible !

I find it more useful to see code examples rather than explain them, so let’s break down a typical pattern you might find on a website or app in more detail. For this article, we will look at radio buttons and groups. All radio groups require a group label of some kind. The classic method is using `<fieldset>` and `<legend>`. The ARIA method of `role=”radiogroup”` and `aria-labelledby` can also be used. Both are technically correct, so depending on your situation you could use either method and that would result in a similar experience for the user.

Method 1: Using HTML `<fieldset>` and `<legend>` elements:

<fieldset class="deque-radio-group">

 <legend class="deque-radio-group-label">What's your favorite flavor of ice cream?</legend>

 <div id="radioGroup">

   <span id="Whatsyourfavoriteflavor_0" class="deque-radio" aria-labelledby="vanilla"></span>

   <span id="vanilla">Vanilla</span>

   <span id="Whatsyourfavoriteflavor_1" class="deque-radio" aria-labelledby="chocolate"></span>

   <span id="chocolate">Chocolate</span>

   <span id="Whatsyourfavoriteflavor_2" class="deque-radio" aria-labelledby="strawberry"></span>

   <span id="strawberry">Strawberry</span>

   <span id="Whatsyourfavoriteflavor_3" class="deque-radio" aria-labelledby="none"></span>

   <span id="none">I prefer cake</span>

 </div>

</fieldset>

 

Option 2: Utilisation d'ARIA `role="radiogroup"` et `aria-labelledby` :

<div class="deque-radio-group" role="radiogroup" aria-labelledby="inspire">

 <div class="deque-radio-group-label" id="inspire">

   Which one of these scientists most inspires you?</div>

 <div id="radioGroup">

   <span id="Whichoneofthesescientistsmostinspiresyou_0" class="deque-radio" aria-labelledby="curie"></span>

   <span id="curie">Marie Curie</span>

   <span id="Whichoneofthesescientistsmostinspiresyou_1" class="deque-radio" aria-labelledby="goodall"></span>

   <span id="goodall">Jane Goodall</span>

   <span id="Whichoneofthesescientistsmostinspiresyou_2" class="deque-radio" aria-labelledby="franklin"></span>

   <span id="franklin">Rosalind Franklin</span>

   <span id="Whichoneofthesescientistsmostinspiresyou_3" class="deque-radio" aria-labelledby="lamarr"></span>

   <span id="lamarr">Hedy Lamarr</span>

 </div>

</div>

 

Capture d'écran de l'option 1

Image d'une question comportant quatre choix de réponse

Capture d'écran de l'option 2

Image du résultat de la méthode 2

Comme vous pouvez le constater sur les captures d'écran, le rendu visuel des modèles de boutons radio HTML et ARIA est identique. D'un point de vue fonctionnel, ils devraient également être pratiquement identiques, mais il existe certaines différences selon les combinaisons de navigateurs et de technologies d'assistance. Il n'existe pas de solution universelle ; il peut donc s'avérer nécessaire d'adapter chaque modèle à vos besoins en matière d'accessibilité. Pour voir un exemple concret du code ci-dessus, consultez https://codepen.io/cariefisher/pen/VGPEBo.

Scène 4 : Les subtilités d'ARIA

Bien sûr, cet article ne serait pas complet sans quelques mises en garde concernant ARIA. Tout d’abord, vous devez faire preuve de prudence lorsque vous ajoutez des balises ARIA à votre code ! C’est un domaine où un peu de connaissances en programmation peut s’avérer néfaste (ou tout simplement agaçant) si elles sont mal utilisées. Un mentor m’a dit un jour : « Un ARIA mal utilisé est pire que pas d’ARIA du tout » – des paroles pleines de sagesse que j’essaie de suivre à chaque ligne de code que j’écris. Parfois, dans le but d’aider, on ajoute trop d’attributs ARIA ou les mauvais attributs ARIA. N’oubliez pas de privilégier la simplicité.

Deuxièmement, bien que les modèles de boutons et de boutons radio/groupes que nous avons passés en revue soient relativement simples, la création de modèles personnalisés accessibles peut très vite devenir très compliquée. Il y a de nombreux aspects à prendre en compte (entre autres) : les interactions au clavier, sur mobile et tactiles, les bonnes pratiques de création ARIA, ou même le choix fondamental entre HTML et ARIA. Essayez d’anticiper les besoins de vos utilisateurs et veillez à tester l’accessibilité de votre code. Si vous pouvez trouver (et rémunérer) des utilisateurs de technologies d’assistance pour vous aider à effectuer ces tests, c’est encore mieux. À tout le moins, assurez-vous qu’il existe un moyen accessible permettant à un utilisateur de signaler un bug s’il rencontre un problème.

Ces mises en garde mises à part, l'accessibilité numérique n'est vraiment pas une question de « tout ou rien » : il s'agit d'un spectre qui laisse place à certaines zones d'ombre, comme celle-ci, où plusieurs solutions de codage peuvent être considérées comme « correctes » selon le contexte. L'important, c'est de continuer à apprendre, à tester et à essayer de rendre notre monde numérique plus ouvert à tous !

ARIA, premier acte : résumé

Nous espérons que cet article vous aura donné un bref aperçu de l'univers riche d'ARIA. Voici quelques points à retenir :

  • ARIA définit un ensemble d'attributs destinés à faciliter la correction des balises incorrectes et à combler les lacunes du langage HTML afin d'offrir une expérience plus accessible aux utilisateurs de technologies d'assistance (TA).
  • Une intégration correcte d'ARIA dans votre code garantit que tous les utilisateurs disposeront des informations dont ils ont besoin pour utiliser votre site web ou votre application.
  • Le modèle ARIA peut être décomposé comme suit :
    • Rôles —définissent ce qu'est un élément ou ce qu'il fait.
    • Propriétés —caractéristiques ou relations propres à un objet.
    • États et valeurs — définissent les conditions actuelles ou les valeurs associées à l'élément.
  • À lui seul, ARIA ne modifie ni les fonctionnalités, ni l'aspect général de votre site web ou de votre application.
  • Il existe plusieurs façons d'écrire du code accessible. Le HTML peut souvent remplacer ou être complété par ARIA, mais vous devez d'abord vérifier la prise en charge par les navigateurs.
  • En cas de doute, utilisez un élément HTML pris en charge par les navigateurs et évitez d'utiliser ARIA. Une implémentation incorrecte d'ARIA peut être pire que l'absence totale d'ARIA !
  • Testez votre code, de préférence avec l'aide d'utilisateurs de technologies d'assistance. À tout le moins, mettez en place un moyen accessible permettant de signaler ces bugs.

Cet article s'adressant aux débutants, j'ai volontairement passé sous silence certains sujets importants. Dans le prochain article consacré à ARIA, j'ai l'intention d'aborder des questions d'un niveau plus intermédiaire, telles que :

  • Comment savoir quel élément ARIA ou HTML choisir ?
  • Où la technologie ARIA est-elle prise en charge ?
  • Comment puis-je tester la conformité à ARIA ?

Si vous souhaitez voir d’autres questions générales sur ARIA, n’hésitez pas à me le faire savoir dans les commentaires ! En attendant, pour approfondir vos connaissances sur ARIA et découvrir d’autres exemples de modèles en situation réelle, vous pouvez vous inscrire à nos cours de l’Deque .

Carrie Fisher

Carrie Fisher

Carie Fisher est formatrice senior en accessibilité et développeuse chez Deque. Elle crée des sites web à titre professionnel depuis 2005 et se passionne pour l'accessibilité et la promotion de la diversité dans le monde de la technologie. Elle a fondé à la fois le guide de style « A11y Style Guide » et la série YouTube « Accessibility Talks » afin de sensibiliser le public à l'accessibilité des sites web.

Recevez les articles de blog directement dans votre boîte mail

Pas de bavardages inutiles, mais des informations concrètes sur l'accessibilité, fournies par des experts qualifiés.

Vous acceptez que Deque , utilise et partage des informations conformément à Dequedéclaration de confidentialité. Vous pouvez modifier votre consentement à tout moment en nous contactant.

En savoir plus sur ce sujet

Le standard ARIA pour les débutants : 1re partie

August 17, 2021 By Gerard Cohen

Les applications Internet riches accessibles (ARIA) constituent un ensemble d'attributs qui définissent les moyens de rendre accessibles les contenus et les applications Web (en particulier celles développées avec JavaScript)…

Lire l'article
La spécification ARIA pour les non-initiés

Présentation de l'attribut « feed role »

Suman Damera 300 x 300
July 23, 2019 By Suman Damera

La plupart des utilisateurs ont sans doute recours quotidiennement à des widgets de défilement infini. Les exemples les plus courants de ce type de widget sont les fils d'actualité des réseaux sociaux. Les stories ou les articles publiés sur…

Lire l'article
Image 1 1