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.

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"...

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)

Héhéhé, lire ça sur ce forum, c'est toujours assez comique (*)

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

Ç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

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).