1178 sujets

Accessibilité du Web

Le point sur les rôles ARIA

Bonjour
Je crois comprendre que ARIA a été conçu pour ajouter de la sémantique aux balises "neutres" telles que <div>, <span> ou <table>, c'est à dire avant HTML5.
Dans la mesure où on utilise des <header>, <nav>, <footer>, <aside> etc., quel est l'intérêt d'utiliser les rôles ARIA dans les pages HTML5 en sus des balises sémantiques? Je suppose qu'il doit exister de "bonnes pratiques" à ce sujet. Pourriez vous m'indiquer un document qui fasse le point sur ce sujet?
Merci de vos conseils.
Merci de ta réponse.

Je ne comprends strictement rien à ces "role":
- quels sont les produits qui en tiennent compte? les navigateurs directement ou les "lecteurs d'écran"?
- qu'en font-ils?
- ne sont ils vraiment pas capables de comprendre que <nav role="navigation"> est une tautologie?
- y a-t-il des roles qui ne seraient pas tautologiques?
- de même que l'on a fait un script qui permet d'afficher du HTML5 sur les vieux navigateurs de Microsoft, n'y a-t-il pas un script équivalent qui joue sur le DOM en ajoutant les roles tautologiques?

Merci d'éclairer ma lanterne.
Bonsoir,

"ne sont-ils vraiment pas capables ..."

Je pense que si : le W3C via son validator nous indique clairement par le biais de warning (donc pas niveau erreur) que la surcouche n'est pas nécessaire :
https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.alsacreations.fr%2F
(désolé pour l'exemple, la plupart de mes propres sites ont les mêmes ^^)

Mais en effet, une réponse argumentée de QuentinC sera très intéressante pour tout le monde (comme les rappels de vaccination Smiley rolleyes )
Le fait que le validateur considère que ces roles ne sont pas nécessaires confirme mon impression initiale.
Alors posons la question de fond: quand cette surcouche est-elle vraiment nécessaire dans une pages en HTML5? Si elle est nécessaire, c'est que le HTML5 a raté partiellement son objectif, me semble-t-il.

Je suis en train de mettre au goût du jour un site ancien qui comporte des choses à faire frémir,. Tant qu'à faire, ce ne serait sans doute pas un problème d'ajouter des roles mais j'ai besoin d'abord de comprendre quand et pourquoi on a besoin de les ajouter.
PapyJP a écrit :
Je ne comprends strictement rien à ces "role"...

Moi non plus. À ce que j'en avais compris à un instant T : les "lecteurs d'écran" sont hyper en retard techniquement, au point qu'ils aient notamment besoin des rôles aria pour compenser leur faiblesses dans le déchiffrage des tags html5 (la propriété css content pose/posait problème elle aussi, et il y avait d'autres incompatibilités de ce type).

Mais étant donné que je ne les ai jamais vraiment utilisés - faute surtout d'être en mesure de les tester - je ne saurais confirmer mon propos, je laisse donc à d'autres plus compétents le soins de confirmer ou d'infléchir cette hypothèse.
Modifié par Olivier C (16 Aug 2016 - 07:16)
PapyJP a écrit :
Le fait que le validateur considère que ces roles ne sont pas nécessaires confirme mon impression initiale.
Alors posons la question de fond: quand cette surcouche est-elle vraiment nécessaire dans une pages en HTML5? Si elle est nécessaire, c'est que le HTML5 a raté partiellement son objectif, me semble-t-il.
Je suis en train de mettre au goût du jour un site ancien qui comporte des choses à faire frémir,. Tant qu'à faire, ce ne serait sans doute pas un problème d'ajouter des roles mais j'ai besoin d'abord de comprendre quand et pourquoi on a besoin de les ajouter.

Sauf erreur de ma part, il me semble que les attributs Aria existaient avant l'arrivée de HTML5. Les balises dites "sémantiques" ont apporté un degré supplémentaire dans la description du contenu qui, effectivement, peut être perçu comme redondant avec un existant Aria et des lecteurs audio qui auront toujours une certaine inertie avant d'être mis au goût du jour.
Je suppose que le marché correspondant à ces lecteurs est jugé trop étroit pour que des sommes significatives soient mises à disposition pour leur évolution (opinion à confirmer / infirmer, bien entendu).
Sur la contrainte que représente l'ajout d'attributs Aria dans une page HTML, je me suis posé la question dans le cadre de mon générateur en cours de développement.
Si j'en crois les commentaires laissés sur différents forums, l'opinion générale semble conclure que c'est compliqué, pour ne concerner, in fine, qu'une partie relativement minime des visiteurs de sites web.
Je ne dis pas que je souscris à cette approche, plutôt condescendante à mon avis vis à vis des personnes atteintes de handicap, mais c'est un frein qui existe bel et bien dans l'adoption des attributs d'accessibilité.
Dans le même temps, je peux concevoir qu'à moins d'y avoir été obligé par un texte de loi, un client hésite à débourser plus pour ce seul motif. Quand on touche au porte-monnaie, la "morale" est bien souvent sacrifiée sur l'autel du retour sur investissement.
Bref, cette réflexion faite, j'ai pris comme option de laisser le choix, via le générateur, de créer des pages HTML pleinement compatibles Aria ou bien débarrassées de ces attributs. Cela me permet d'approfondir les règles d'accessibilité et fournir, ou tenter de fournir, des ressources les plus optimisées que possible, ou bien alléger le source et concevoir une version du site "standard", c'est à dire en se limitant aux spécifications HTML.
L'avantage d'un générateur, c'est qu'il permet de créer, à partir de documents identiques, deux versions parallèles, chacune dédiée à une population précise.
Étant donné que la législation est amenée à être, a priori, de plus en plus coercitive sur l'accessibilité des sites web, cette approche devrait permettre de "basculer" un site non conforme vers sa version "accessible" en changeant juste une option au niveau du projet global alimentant le générateur.
Il est évident que c'est plus confortable que de devoir tout faire "à la main"...
Modérateur
sepecat a écrit :

Sauf erreur de ma part, il me semble que les attributs Aria existaient avant l'arrivée de HTML5. Les balises dites "sémantiques" ont apporté un degré supplémentaire dans la description du contenu qui, effectivement, peut être perçu comme redondant avec un existant Aria et des lecteurs audio qui auront toujours une certaine inertie avant d'être mis au goût du jour.

C'est ça. écrire <nav role="navigation"> n'est que pour de la rétrocompatibilité. Surtout que dans la norme, les balises ont des rôles implicites: https://www.w3.org/TR/html-aria/#sec-strong-native-semantics. Seulement côté Crosoft, ce n'est supporté que depuis Edge, mais pas sur IE11 sauf erreur.

à noter que dans le cas de page web «basiques», ce support d'ARIA est très limité. ARIA c'est aussi et surtout du support pour les applications riches, avec contenu dynamique est éléments d'interface complexes, qui prend tout son sens dans ce genre de cas par exemple:

<span role="checkbox" aria-checked="true" tabindex="0" id="simulatedcheckbox"></span>
Merci à tous pour vos réponses

Je ne dirais pas que ça éclaircisse beaucoup ma compréhension, ou alors si ce que je comprends est bien ce qu'il faut comprendre, j'en déduis que c'est une technologie obsolète qui a dû avoir son intérêt il y a une dizaine d'années, mais dont je ne comprends pas l'intérêt de nos jours.
Si un produit sait comprendre les rôles, ce doit être une affaire de quelques jours ou à la limite quelques mois de travail pour lui faire comprendre les balises sémantique. Si les auteurs ne le font pas, c'est que ça ne les intéressent pas, car ils trouveraient facilement des étudiants ou des retraités pour le faire gratuitement s'ils le voulaient.

Le site sur lequel je travaille comporte des textes avec des illustrations.
J'ai du mal à comprendre comment des illustrations, qui sont dans des balises <figure> avec une balise <img> et assez souvent un titre dans une balise <figcaption> peuvent être rendues lisibles pour des mal voyants. S'il y a quelque chose à faire dans ce sens, je peux l'envisager, quoiqu'il y ait plusieurs milliers d'images e que tout reprendre serait un énorme travail, je suppose.

Quant au texte, il se lit comme un article de revue. L'article est découpé en sections avec des titres, et quelques "encarts" sous forme de balises <aside>, du genre "à propos, voici des infos sur un certain point de détail", le texte est dans des balises <p>, les citations d'auteurs ou les traductions de textes antiques sont dans des balises <q>..

Je vois mal ce que je pourrais ajouter à ça pour le rendre accessible à des personnes handicapées.Je ne vois ps comment les fameux roles pourraient apporter une amélioration substantielle: pour moi, il faudrait beaucoup plus de choses que ces roles.

Il est possible que je comprenne de travers, mais encore une fois, si je ne comprends pas ce qu'il faut faire et pourquoi il faut le faire, ajouter des roles au petit bonheur la chance ne sert à rien, me semble-t-il.

Je continue à suivre vos réponses avec intérêt, j'ai quelques semaines pour me faire une opinion raisonnée avant de décider ou on de faire quelque chose dans ce domaine.
Modifié par PapyJP (15 Aug 2016 - 23:38)
PapyJP a écrit :
Merci à tous pour vos réponses
Je ne dirais pas que ça éclaircisse beaucoup ma compréhension, ou alors si ce que je comprends est bien ce qu'il faut comprendre, j'en déduis que c'est une technologie obsolète qui a dû avoir son intérêt il y a une dizaine d'années, mais dont je ne comprends pas l'intérêt de nos jours.
Si un produit sait comprendre les rôles, ce doit être une affaire de quelques jours ou à la limite quelques mois de travail pour lui faire comprendre les balises sémantique. Si les auteurs ne le font pas, c'est que ça ne les intéressent pas, car ils trouveraient facilement des étudiants ou des retraités pour le faire gratuitement s'ils le voulaient.

Voici un site (parmi d'autres) qui pourrait apporter un éclairage complémentaire sur cette réflexion intéressante (site en anglais).
Dans la langue de Molière, ce site peut également être un complément utile.
Modérateur
PapyJP a écrit :
Merci à tous pour vos réponses

Je ne dirais pas que ça éclaircisse beaucoup ma compréhension, ou alors si ce que je comprends est bien ce qu'il faut comprendre, j'en déduis que c'est une technologie obsolète qui a dû avoir son intérêt il y a une dizaine d'années, mais dont je ne comprends pas l'intérêt de nos jours.
Si un produit sait comprendre les rôles, ce doit être une affaire de quelques jours ou à la limite quelques mois de travail pour lui faire comprendre les balises sémantique. Si les auteurs ne le font pas, c'est que ça ne les intéressent pas, car ils trouveraient facilement des étudiants ou des retraités pour le faire gratuitement s'ils le voulaient.

ARIA est loin d'être obsolète, c'est une des principales normes en vigueur en matière d'accessibilité. ARIA a été développé pour rendre accessibles des interfaces riches et complexes d'applications web. Dans ces cas, les outils et widgets standards se retrouvent bien souvent trop limités et on recrée des composants à l'aide de tagsoup de divs et de javascript. ARIA est là pour rendre tout cela compatible avec les lecteurs d'écran notamment.

ARIA est un système qui s'implémente à l'aide d'attributs, qui se divisent en rôles, états et propriétés. Pour ce qui nous concerne ici, dans le cas de pages web de type «document» somme toutes basiques, et qui ont recours aux composants HTML standards, nul besoin d'user de beaucoup d'ARIA, on se contente juste de quelques rôles. Ces rôles sont principalement les rôles de la catégorie «Landmark» qui permettent de séparer la page en zones d'intérêt. L'utilisateur d'un lecteur d'écran peut ainsi directement sauter au contenu qui l'intéresse. Ajouter ces rôles pour la compatibilité n'est tout de même pas insurmontable. Ne pas le faire est équivalent à sourire devant une personne en chaise bloqué face à deux marches d'escalier en passant tout droit car vous estimez que l'architecte n'avait qu'à penser à une rampe.

Quant aux lecteurs d'écran, ce n'est pas leur travail de parser le HTML. Ils travaillent avec le DOM tel que fourni par le navigateur. Ils doivent fonctionner et s’accommoder à des centaines d'applications et de documents différents et il est absurde d'attendre d'eux qu'ils recodent un navigateur. Le seul responsable de cette rétrocompatibilité qui traîne se nomme Microsoft (pour changer).
kustolovic a écrit :

Ces rôles sont principalement les rôles de la catégorie «Landmark» qui permettent de séparer la page en zones d'intérêt. L'utilisateur d'un lecteur d'écran peut ainsi directement sauter au contenu qui l'intéresse. Ajouter ces rôles pour la compatibilité n'est tout de même pas insurmontable.

Merci pour cette réponse qui me donne une direction de recherche, je vais étudier l'opportunité des «Landmark».

Je sais que je vais soulever des protestations, mais sur le fond, pour moi, le seul intérêt des standards est de me permettre de savoir ce qui supposé être supporté ou non par les navigateurs.

J'ai personnellement dépensé des centaines d'heures à participer à la définition de standards qui ont été adoptés au niveau international après des dizaines voire des centaines de réunions où on se retrouvait dans la même salle que les Japonais et les Américains, au prix de centaines de milliers de dollars pour chaque réunion. Et pourtant ces standards n'ont jamais été mis en œuvres et remplacés par des "standards de facto" que j'avais -- avec d'autres -- essayé en vain de promouvoir...
Héhéhé, lire ça sur ce forum, c'est toujours assez comique (*) Smiley smile

Ces maudits standards permettent tout de même à de très nombreuses personnes de profiter des contenus disponibles sur internet, alors ne jetons pas le bébé avec l'eau du bain trop rapidement Smiley smile

Ça me permet aussi, dans un autre domaine, d'être relativement serein pour monter les différents éléments de ma nouvelle cuisine. Encore que la aussi, il y a quelques points d'amélioration ^^

(*) cf le texte inscrit juste en dessous du logo du site sur lequel nous nous trouvons
Ce que je veux dire c'est que les standards sont là pour être utilisés, pas pour être révérés comme le livre sacré de certains groupes humains.
Mais je pense que vous m'aviez compris... Smiley smile
Bonsoir,

J'arrive un peu tard, désolé.

Je crois que kustolovic a dit l'essentiel: ARIA se destine principalement aux applications riches.

ARIA est notamment important:
1. Dans les cas où il n'existe pas de réel standard définissant la forme que doivent prendre des composants typiques d'interfaces riches. Par exemple il n'y a pas de <tabpanel><tab>...</tab><tab>...</tab>...</tabpanel> ou de <treeview>. Du coup on est obligé d'utiliser une soupe de div/span
2. Dans les (malheureusement nombreux) cas où on pourrait utiliser des composants standard (notamment les types d'input ajoutés à HTML5), mais où on ne les utilise pas parce qu'on les considère moches ou trop limités, et du coup là aussi on utilise du div/span à gogo

Dans ces deux cas, on utilise du div/span qui ne fait évidemment aucun sens pour un lecteur d'écran. ON utilise donc ARIA pour expliquer au lecteur d'écran ce que représente sémantiquement cette soupe.

Dans un monde idéal, on devrait toujours utiliser les composants standard en priorité, et n'utiliser ARIA que ponctuellement.
Car en réalité, bien peu de composants JQuery et autres qui « simulent » des listes déroulantes, des menus, des sliders, des arbres, des calendriers, etc. le font correctement jusqu'au bout, notamment en ce qui concerne la gestion du clavier. En règle général la gestion du clavier est passablement buggée.
C'est bien dommage qu'on abandonne si souvent les standards juste pour des questions de design. La compatibilité n'est qu'une vraie fausse excuse au jour d'aujourd'hui...

Du côté des pages web plus orientées document, kustolovic a également raison, ARIA n'est pas particulièrement utile sauf dans des cas très spéciaux.
ON peut se contenter des roles de type landmark, et bien souvent ils sont implicites donc on n'a plus besoin d'y penser dès lors qu'on pense correctement sa sémantique. Les <nav role="navigation"> et autres lapalissades sont juste là pour la compabilité, et ce n'est guère plus très important aujourd'hui.

Du côté des pages orientées document, il est intéressant d'aller voir ce que fait l'IDPF avec epub3. En epub3, ils ont ajouté un attribut epub:type qui permet d'ajouter beaucoup d'informations sémantiques plus intéressantes pour les pages orientées document. P.ex. notes de bas de page, renvois, etc. Il y a même des parties spécialisées pour les documents éducatifs définis dans un sous-standard.

Je pense qu'il serait utile que le HTML soit divisé en deux groupes: la partie document qui pourrait être epub3, et une partie application qui pourrait s'inspirer un peu plus de XUL, XAML et faire en sorte que les composants classiques avancés comme les arbrs, les onglets et autres soit définis avec des éléments normés (pour éviter qu'on persiste à utiliser du div/span sans réelle alternative). Par exemple, pourquoi n'a-t-on pas ajouté <treeview>, <tabpanel>, <tab>, <toolbar>, <menubar>, un vrai <menu> et <menuitem> ? Ca rendrait le code beaucoup plus clair en plus d'éviter aux développeurs dans se perdre dans quelque chose aussi compliqué qu'ARIA dans lequel ils se perdent car ils n'ont aucune idée de ce à quoi ça sert réellement.
En laissant bien entendu la possibilité q'une application embarque un document (le texte d'un mail dans une app comme gmail par exemple), et inversément (un contenu interactif dans un livre epub3 par exemple).
Bon, QuentinC a déjà dit beaucoup de choses, ma réponse n'en sera que plus courte Smiley lol

Petite précision : les éléments HTML influent sur ce que l'on appelle l'accessibility tree (une sorte de DOM que le navigateur fait pour les aides techniques). Quand tu mets un h1, ça « expose » sur l'a11y tree un titre de niveau 1 (et l'aide technique saura qu'elle doit annoncer un titre).
C'est pour ça que les experts accessibilité ronchonnent toujours en disant un borborygme du genre « putain, utilisez les balises prévues pour », pas besoin d'ARIA pour ces balises qui ont déjà tout dedans.

Pour les roles dupliqués sur les landmarks, même si le validateur gueule, ça ne coûte pas grand chose, et ça assure de la rétro-compatibilité. De mémoire, j'ai vu des conférences sur le sujet y a 5 ans qui disaient que c'était un vaste foutoir côté compat', heureusement, cela s'est bien amélioré depuis.

Que fait ARIA là-dedans ? ARIA permet de changer ces valeurs exposées (et ça n'intervient que sur l'accessibility tree !). Comme ça a été dit, certains éléments n'existent pas en HTML, il n'existe pas de balise pour les onglets en HTML par exemple. Avec ARIA, tu peux permettre via ces roles de transmettre des valeurs aux aides techniques, qui seront donc capable de dire « ceci est un tabpanel ». Et cela permet aussi d'indiquer des états (ce contrôle est ouvert/fermé/etc.).

Si tu veux des exemples, regarde par exemple une démo d'onglets accessibles, codée par bibi.

Autre chose, ne pensez pas toujours uniquement HTML, mais aussi SVG par exemple, ARIA permet de mettre une couche d'accessibilité sur du SVG embarqué dans vos documents HTML.
Sujet clos
Aller à