Stéphane Deschamps me pique la plume. Le sujet se prête mieux au format de ce blog qu’au sien.
Un peu d’histoire
L’idée d’ARIA c’est de permettre de décrire des rôles et des états, pour améliorer l’accessibilité des clients riches. Ainsi on peut légalement avec ARIA faire une case à cocher en image, pourvu qu’on la décrive comme une case à cocher (role="checkbox") et qu’on indique son état, cochée (aria-checked). C’est pratique pour faire des graphismes modernes, tout en permettant de ne pas sacrifier l’accessibilité au seul profit de ceux qui ont des yeux et une souris, pour résumer.
Quand ARIA a été introduit, on ne parlait pas encore de HTML 5 au W3C : c’est XHTML qui prévalait. Or en XHTML une notion fondamentale est celle des espaces de nommage, permettant de rattacher au document courant (dont l’espace de nommage HTML est implicite) des extensions. ARIA bénéficiait donc d’une déclaration dans le document pour permettre à chacun de ses attributs d’être déclaré avec le préfixe aria:. Par exemple le rôle d’un élément s’écrivait aria:checkbox. Facile.
Avec l’avènement de HTML 5 et ses choix différents en termes de formalisme, qui privilégient l’écriture de code avec la syntaxe HTML, ARIA a dû faire machine arrière : tout a été renommé sans espace de nommage. Les deux points des propriétés spécifiques à ARIA ont été remplacés par des tirets : aria:checked devient aria-checked. Certains attributs quant à eux, qui ont du sens même hors du contexte d’ARIA, n’ont carrément pas de préfixe. C’est le cas de role, qui était prévu dans la spécification XHTML 2.
Pour l’accessibilité dans le monde réel, c’est presque une bonne chose : à ce jour, la revue d’écran la plus utilisée (Jaws) ne reconnaît pas les attributs préfixés. J’en ai fait la douloureuse expérience lorsque mon site est passé en XHTML : Jaws ne comprenait pas les attributs xml:lang et les ignorait purement et simplement ! (Il a fallu doubler tous ces attributs avec l’attribut HTML classique lang).
Oui mais voilà : et la validation dans tout ça ?
À ce jour, le validateur du W3C s’appuie sur le DOCTYPE que vous déclarez dans votre code pour vérifier que vous respectez bien sa grammaire. Or dans une spécification ancienne (XHTML 1.1 date de 2001), il n’était évidemment pas prévu d’intégrer des attributs dont on ignorait qu’ils existeraient un jour ! Sans compter que la logique même d’extensibilité du XHTML venait de l’idée qu’on intégrerait tout ça avec des espaces de nommage, donc l’extension était prévue, mais avec un formalisme que le brouillon courant de HTML 5 remet en cause. Bref, nous voilà au pied du mur : faut-il faire du code invalide, ou respecter maniaquement la spécification et trouver des contournements « légaux » ?
Une solution : opter pour du code invalide
La solution simple serait d’opter pour du code invalide. Eric Meyer considère qu’on peut prôner les standards en étant fidèle à l’esprit mais pas toujours à la lettre : c’est ce qu’il appelle standards-oriented.
En l’occurrence, imaginons que j’aie écrit une page conforme et que j’y rajoute des attributs ARIA. Elle devient non-valide, mais j’ignore les erreurs en connaissance de cause parce que je suis un développeur Web avisé, et que je sais que ça ne posera pas de souci aux navigateurs tout en améliorant l’accessibilité pour tous.
Utiliser un attribut HTML existant et manipuler ses valeurs avec JavaScript
La deuxième solution est plus sportive : je crée du code valide, et je profite de JavaScript pour ajouter les attributs qui me manquent.
Cas classique : je repère l’élément via son id (identifiant unique dans la page), et j’ajoute le ou les attributs dont j’ai besoin pour faire de l’ARIA.
Oui mais : tous mes éléments ne sont pas forcément nommés, pourtant je risque d’avoir besoin de nombreux endroits auxquels me raccrocher pour ajouter des propriétés ARIA.
Le plus simple sera alors d’utiliser un attribut HTML, d’en extraire le contenu et de générer les attribut ARIA à partir de là.
Quel attribut choisir ?
J’ai déjà vu des gens utiliser l’attribut rel des liens, par exemple pour faire des popins (rel="popin,450,300" indique qu’à ce lien sera ajouté un comportement JavaScript d’affichage de la popin, et les dimensions de ladite popin). Pour ma part j’en suis très gêné, il me semble qu’il s’agit là d’un détournement assez osé de l’attribut. Par ailleurs, ça ne fonctionne que sur des liens ; il faut donc trouver un attribut plus générique.
En revanche, la bonne idée depuis plusieurs années, c’est tout de même qu’on tente de ne pas mettre de comportement dans le code. On s’appuie sur le DOM pour inventorier les éléments auxquels affecter tel ou tel comportement, souvent en passant par l’attribut class. Pour revenir à notre exemple de popins, il y a quelques années on aurait fait la même chose en popup, en s’appuyant sur la classe : class="popup".
Essayons donc de nous appuyer sur la classe : il nous semble moins nocif d’utiliser cet attribut plutôt qu’un autre.
Quelle méthode ?
Maintenant que nous avons choisi la classe, quelle convention d’écriture adopter pour tous ces attributs ?
Première proposition, utiliser une notation héritée de JSON : class="{role:contentinfo;}". Son intérêt c’est qu’elle est facile à interpréter, et qu’elle sera extensible si nous devons ajouter plusieurs attributs : class="{role:checkbox;aria-checked:true;}". Son gros défaut c’est qu’elle a l’apparence d’une verrue dans le code, sans compter que cette notation ressemble suffisamment à la notation classique des paires propriété / valeur de CSS pour au mieux prêter à confusion chez le développeur moins au fait que vous, au pire faire tousser un navigateur dont le parseur de code y reconnaîtrait de la CSS (scénario catastrophe, me direz-vous ; oui mais on a déjà vu pire dans certains navigateurs).
Deuxième proposition : utiliser une notation à base de tirets, class="role-contentinfo", et manipuler la chaîne en l’explosant pour générer l’attribut et sa valeur.
Deux situations à différencier
Attention cependant, ARIA propose une approche deux-en-un :
description d’éléments de structure de la page à travers le rôle (les landmarks) ;
description d’éléments interactifs (typiquement les éléments de formulaire).
Selon moi ces deux cas peuvent impliquer une approche différente : le premier cas doit tant qu’à faire fonctionner même sans JavaScript, le deuxième n’a souvent de sens que si JavaScript fonctionne (puisque le changement dynamique d’état ne peut se faire qu’avec JavaScript).
Conclusion
Je serais enclin à faire du code invalide, en particulier dans le cas des landmarks, mais plus partagé sur les propriétés dynamiques (rôles et états des éléments interactifs).
À votre avis ? Faut-il du code invalide, et si oui, quelle méthode choisiriez-vous ?
19 commentaires ↓
[…] ARIA et validation : comment faire ? http://www.htmlzengarden.com/2009/11/aria-et-validation-comment-faire/ […]
Je vote sans hésiter pour du standards-oriented !
Cette méthode s’assimile à un « tirage vers le haut » contrairement à la 2ème solution qui ressemble trop à un détournement.
De plus, être invalide par rapport aux standards ne signifie pas toujours ne pas être accessible.
Tu noteras que je n’ai pas dit le contraire, j’ai juste dit que comme souvent nous prenons les standards comme un bon premier pas vers l’accessibilité, je pense ici que la nouvelle spec prend en quelque sorte le pas sur la vieille.
Actuellement, invalider le code pour améliorer l’accessibilité, oui
Tout dupliquer en JS c’est désastreux en terme de maintenabilité …
D’autre part, si le W3C pouvait se pencher sur la cohabitation des 2 spécifications ce ne serait pas plus mal, ou alors indiquer aux développeurs comment faire dans le Working Draft en cours de « ARIA Practices » http://www.w3.org/TR/wai-aria-practices/
La validité absolue du code n’est pas et n’a jamais était un gage d’accessibilité. En revanche, le fait que : - les éléments aient des balises complètes de début et de fin, - ils soient imbriqués conformément à leurs spécifications, - ils ne comportent pas d’attributs dupliqués, - et chaque id soit unique, (Critère 4.1.1 des WCAG 2.0), ça oui ça peut avoir un impact sur l’accessibilité.
De plus, faire de l’accessibilité c’est, ménager la chèvre et le choux, doser le pour et le contre, faire des compromis et aussi savoir apprécier, avec justesse, le bénéfice apporté à l’utilisateur par rapport aux risques pour celui-ci au niveau de l’axs (accessibilité).
Donc, sans hésiter et sans répéter les argument de mes camarades ci-dessus, ARIA intégré en dur dans le code HTML (5) est infiniment plus bénéfique au client que la recherche jusqu’au boutiste de la validation du code (via des pirouettes JS).
Standards-oriented, sans hésiter.
En plus, avec l’extension Tiny validator, on peut ignorer certains messages d’erreurs pour ne voir que les balises mal imbriquées (par exemple).
Et bien même si cette fameuse notion de standards-oriented plait à tout le monde (elle me plait aussi), je vais tenter de me faire l’avocat du diable.
À savoir : pour une fois nous avions un levier pour pousser l’accessibilité vers le haut qui ne prenait que deux état (valide ou invalide). Nous nous sommes même battus pour faire entendre aux gens du métier que c’était important.
J’ai peur que si maintenant nous venons y apporter une nuance, le propos soit compris comme : « finalement la validation on s’en fout un peu, c’est un peu aléatoire ».
Alors, bien sûr, les plus avisés sauront faire la part des choses et expliquer pourquoi le code est invalide et pourquoi ce n’est pas grave, mais les autres (moins techniques) ne sauront pas s’il s’agit ou non d’une faute « grave ».
En somme, ils perdent un moyen de contrôle rapide et que nous avons pendant des années annoncé comme efficace (avec le petit laïus « ce n’est qu’un outil » qui va bien).
L’historique exposé par Stéphane me donne vraiment l’impression qu’il s’agit un dommage collatéral.
En attendant une solution intelligente fournie par le W3C, nous sommes obligés de ruser d’une manière ou d’une autre : mais cela restera imparfait.
Si je ne dis pas de bêtises, HTML5 prévoit d’intégrer ARIA. Il n’y aura donc pas de soucis de validité. Du coup, on peut expliquer que le validateur dit « bouh c’est pas valide » parce que le validateur n’est pas à jour. Et pouf.
Ah j’oubliais, http://validator.nu/ sait valider un document HTML5+ARIA, donc hein, c’est quoi cette question qui n’en est pas une ?
Il y a quelques mois, j’ai voulu me mettre à Aria. J’ai chercher un validateur, et j’ai vite compris qu’il n’y avait pas de « validateur à jour » en XHTML+ARIA. (Je me trompe?) Je comprends bien ce débat et je l’attendais… Mais une chose m’étonnes: html5 c’est pas pour demain… il y a toujours M$ qui nous em…. Par contre XHTML est encore d’actualité, non? Alors je suis bien d’accord avec Rik. Si on commencait par avoir une solution et des outils ARIA+XHTML! Genre: avez-vous un « bon » addon FF pour valider vite-fait en local? - j’en suis resté à FF3.0, juste à cause de l’extension HTML Validator 0.8.5.6 qui est imcompatible avec FF3.5 mac et qui me semble le seul outil pour valider efficacement mon code. Je rêve d’un truc identique pour ARIA pour m’y mettre… FF Accessibility Extension ne me semble franchement pas ergonomique, mais je n’ai peut-être rien compris.
Est-ce que le but d’ARIA, c’est bien de rendre accessible un contenu généré dynamiquement par du javascript ?
Si oui, quel intérêt de mettre des « role » sur du HTML statique ?
Pas de Js, pas d’ARIA, du js, de l’ARIA.
J’ai faux ?
Rik,
Je n’y arrive pas avec ce validateur. Tu arrives à obtenir une validation correcte de ce blog par exemple ?
Jacques,
C’est ce que Stéphane indique ici : ARIA permet de rendre accessible des comportement JS avancé mais aussi de mieux structurer le document.
Oups, j’aurais pas dû lire si vite…
C’est Stéphane qui parle trop. 😉
@Rik24 : c’est une question qui est une vraie question et qui fait écho à une discussion que Vincent et moi avons eue : XHTML1.0+ARIA = erreur de validation systématique.
Tiens au passage, tout n’est pas réglé avec HTML5, cf. les problèmes de surcharge d’éléments HTML par des propriétés ARIA mentionnés par Steven Faulkner.
[…] http://www.htmlzengarden.com/2009/11/aria-et-validation-comment-faire/ a few seconds ago from web […]
hu hu… si HTML était une vérité absolue, il y a longtemps qu’on aurait plus ce genre de conversation 😉
La validité du code (X)HTML n’est qu’un indice de la qualité du code réalisé, pas son mètre étalon. En outre, ceux qui parle du problème de validation XHTML+ARIA ne doivent pas être très nombreux à servir XHTML avec un content-type XML (essayez une fois just-for-fun… ça fait mal) qui justifierai l’axiome selon lequel XHTML est implémenté dans les navigateurs
Je suis tout à fait partisan de l’approche standard-oriented. Par contre, dans la mesure ou il n’y a pas d’outil suffisamment intelligent à ce jour pour savoir si cela est bien fait, ça demande une discipline de fer au niveau du codage des pages HTML.
Personnellement, je préfère m’orienter vers des pages bien formées (imbrication correcte des balises et fermeture systématiques des balises ouvertes). Les premier validateur HTML5 dont parle Rik sont de bon outils (encore un peu vert, mais utilisable) et ce n’est vraiment pas difficile de passer à HTML5 en étant IE compatible : faites du XHTML strict et changer votre doctype pour celui de HTML5… hop, problème réglé (si j’ose dire 😉
Sur le même sujet (en angais).
Et poum, tout le monde est d’accord pour être non-valide chez Henny Swan : http://www.iheni.com/aria-and-validation/
Laisser un commentaire