De l'accessibilité dans HTML5 ? Je tente le coup

Par
Philippe Le Mesle
Publié le Classé dans HTML5 Lien permanent de l'article Tags : ARIA ~ WAI ~ W3C ~ accessibilité ~ microformats ~ balisage ~ attributs ~ COSE ~ sémantiqueCommentaires (22)

HTML n’a pas été conçu pour créer des applications web. WAI-ARIA est une spécification qui offre la possibilité de définir une description des rôles, des états et des propriétés pour ces petites applications personnalisées qu’on appelle widgets. Avec WAI-ARIA elles deviennent reconnaissables et utilisables par les utilisateurs de technologies d’assistance. L'intégration de WAI-ARIA dans le balisage HTML5 pour une meilleure accessibilité c’est que nous allons découvrir ici. Codes à l’appui.

L'accessibilité des pages Web va grandement s'améliorer avec HTML5.

L'accessibilité du Web — il n'est jamais inutile de le rappeler — c'est garantir l'accès aux services et contenus en ligne par les handicapés et les personnes âgées. C'est une norme définie par la Web Accessibility Initiative (WAI) du W3C. Norme — et c'est énorme — qui n'est pas respectée par les webmestres.

Sauf que...

il y a fort à parier que dans un avenir maintenant proche la structuration et l'intégration de nouvelles données dans les pages Web pour une meilleure accessibilité va permettre un meilleur référencement de ces pages. Du coup, si les référenceurs s'y intéressent, les bénéfices pour le Web ne seront pas minces : en rendant les sites accessibles aux handicapés ils faciliteront l'accès aux contenus pour tous les visiteurs, dont les robots des moteurs de recherche qu'ils chérissent tant.
Mais comment mettre en place un balisage HTML5 pour une meilleure accessibilité ? C'est la question du jour.

• • •
HTML5 et l'accessibilité

Mais, tout d'abord, avant de voir ce balisage HTML5 pour l'accessibilité,

Un rappel de vaccin sur le balisage sémantique et les métadonnées en HTML

Le langage HTML est un langage de description des pages Web simple — l'héritier de son grand-père SGML que j'ai bien connu. Si simple qu'il a fallu que des développeurs extérieurs au W3C prennent des initiatives pour couvrir tous les types de description des données contenues dans les pages Web. Ainsi sont nés :

  • les microformats développés pour élaborer des vocabulaires spécifiques pour des applications déterminées (CV, carnet d’adresses, calendrier, etc.).
  • RDFa qui a été créé pour décrire des données structurées dans une page Web (invisibles pour le lecteur) permettant leurs extractions par des traitements automatisés.

HTML est un langage simple disais-je. Si simple qu'il pourrait même apparaître archaïque au regard des orientations du Web pour plus de fonctionnalités, plus de composants à l'intérieur des pages. Comme HTML n'a pas été conçu à l'origine (1990 — ça fait un bail quand même !) pour créer du contenu dynamique ou des interfaces de contrôle, il a fallu ajouter des applets (Flash, Java, etc.) ou faire exécuter, côté « client », des scripts (généralement en Javascript). L'exemple type étant ces « widgets » qui permettent d'afficher des informations ou déclencher des actions : celui de Flickr pour afficher les photos d'une photothèque en ligne, ou ces boutons « sociaux » (le bouton Delicious, ou celui de Digg) ou, encore, ces boutons de votes.

Tout cela n'a rien à voir avec le sujet de notre article sur l'accessibilité ?
Si si... c'est ce que vous allez voir.

Le problème de l'accessibilité des applications riches

Cette prolifération d'applications pour le Web nécessitant du code Javascript a généré des problèmes d'accessibilité aux personnes souffrant d'un handicap. Ces questions n'avaient pas été abordées dans les précédentes directives pour l'accessibilité aux contenus Web (WCAG 1). Forcément : elles avaient été rédigées pour des sites Web ne nécessitant pas Javascript. Il fallait donc faire quelque chose et ce quelque chose est arrivé : c'est ARIA.

ARIA ? Késaco ?

ARIA est l'acronyme de Accessible Rich Internet Applications. ARIA décrit comment ajouter de la sémantique et des métadonnées aux contenus HTML pour les rendre accessibles. En gros, ARIA permet aux pages Web (ou à des sections dans les pages) de se déclarer comme des applications plutôt que comme de simples documents statiques. Grâce à l'inclusion de « rôles », de « propriétés » ou d'« états » le contenu dynamiquement généré sera accessible.

Pourquoi utiliser ARIA?

En incluant des fonctions ARIA sur votre site web vous améliorez l'accessibilité de votre site ou de votre application Web. En intégrant ces rôles, ces états et propriétés ARIA, les développeurs rendent le code sémantiquement plus riche.

Mais, en outre, ce contenu statique étant plus accessible, la richesse des informations qu'il transporte peut considérablement aider ce contenu à bien être indexé par les moteurs de recherche. Ah ah...

Comment utiliser ARIA ?

La solution est simple, il y en a 2 ; la facile et la compliquée (selon vos compétences vous allez trouver la « facile », compliquée ou la « compliquée », facile) :

  1. la compliquée :

    la solution compliquée (pour moi) c'est de passer par Javascript. L'objectif étant d'utiliser les attributs HTML existants et manipuler ses valeurs pour ajouter les attributs pour l'accessibilité.
    Exemple : mon script repère l’élément via son identifiant (unique dans la page, c'est l'ID) et lui ajoute le ou les attributs ARIA.

  2. la simple :

    comme HTML5 intègre ARIA nativement et que d'autre part, les navigateurs modernes prennent ses attributs en compte (oui : même IE8 supporte ARIA), je m'en vais les insérer en dur dans le code. Il n’y aura pas de soucis de validité et comme je suis nul en Javascript je me fais l'économie de contorsions cérébrales pour des résultats sans doute incertains.

L'intégration de WAI-ARIA dans le balisage HTML5 du Débloque-notes

Passons maintenant aux exercices. Prenez votre cahier de brouillons, votre règle, votre crayon, et tirez un trait sur les HTML4, les XHTML machin que vous connaissez : tout ce qui va suivre est en HTML5 à la mode XHTML (les balises sont fermées) et, en plus, avec des microformats dedans.
Z'êtes prêt ? C'est parti :

Voici un exemple de base de mon modèle de site. J'ai souligné le rôle spécifique attribué à chaque élément de structure.

La nature du document et la navigation

J'utilise pour ces sections des rôles Landmarks (« Landmarks » ou points de repères) pour indiquer leurs natures.
Ça commence déjà par le body :
body role="document"
Document oui : ce n'est pas une application Web : je l'indique.


<header role="banner">
<hgroup>
<h1><a href="./" rel="home">Un débloque-notes en html5</span></a></h1>
<h2>À s'en faire péter les bretelles</h2>
</hgroup>
</header>

C'est le header du template mais aussi la balise HTML5 header où j'indique son rôle par l'attribut ARIA banner, avec, regroupés dans hgroup, le titre du blog et sa baseline en h1 et h2.


<nav id="menu" role="navigation">
<a class="nav" href="./" rel="home">Maison</a>
<a class="nav" href="tags/">Tags</a>
<a class="nav" rel="directory" href="html5-sources-ressources/">Ressources</a>
<a class="nav" href="sitemap/">Plan</a>
<a class="nav" href="contact/">Contact</a>
</nav>

Ici c'est la barre de menu que j'appelle avec la balise nav. Cette balise HTML5 sert la structuration de la page en indiquant qu'il s'agit d'une zone où se trouveront des liens vers d'autres pages internes au site.
HTML5 c'est pour le rendu de la page Web. ARIA s'adressant aux lecteurs d'écrans, il faut assigner à cette balise un attribut Landmark, ici navigation (enfin, c'est ce que j'ai compris).
J'y place aussi 2 microformats : l'un (rel="home") pour indiquer que ce lien renvoie vers la page d'accueil. L'autre, rel="directory", pour dire que le lien dirige vers une page constituée d'une liste de sites de références sur HTML5.

Le contenu


<div id="content" role="main" class="hfeed">

Le contenu est ceint par cette div. À cette balise j'ajoute 2 informations : ARIA pour le rôle main et class="hfeed" pour le microformat. Il y en a ainsi pour tout le monde : pour l'accessiblité (c'est ARIA) j'ai mes bretelles, pour le référencement (ce sont les microformats) je porte une ceinture. Mon pantalon de codeur et référenceur devrait tenir bon ainsi. Poursuivons.

Dans le footer qu'on appelle footer en HTML5 (mais où vont-ils chercher tout ça ?!) il y en a de l'ARIA ; il y en a des microformats...


<footer id="fouteur" class="clearfix" role="contentinfo">
<section id="bottom">
<h1><a href="#">Vous voulez un site Web en HTML5 optimisé pour le référencement ?</a></h1>
<div>
<span class="vcard">
<img alt="Philippe Le Mesle" src="illus-images/trombine-sepia.jpg" class="fn n photo"></span>
<p class="sepia-fonce gras ptibig etroit">Ce n'est pas une mauvaise idée.</p>
<p class="gris">Si vous êtes une entreprise qui sait ce qu'elle veut</p>
<p class="gris">vous pouvez m'appeler au <span class="rouge gras">06 03 26 91 65</span></p>
<p class="gris">ou m'écrire par <b>lettre recommandée avec accusé réception accompagnée d'un timbre retour et d'un chèque de 149 € pour obtenir une réponse</b></p>
</div>
</section>
<section id="mentions" class="display">
<p>
<span id="W3C-HTML5">
<a href="http://validator.w3.org/check?uri=referer"><em>Hum... hum...</em> conforme HTML5 ?</a></span>
<span class="meta-sep gris">♦</span>
<span id="W3C-CSS3">
<a href="http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fon-air.hiseo.fr%2Fcss%2Fstyle.css&amp;profile=css3" title="Un jour peut-être">Ahum... ahum... Conforme CSS level 3 ?</a></span>
<span class="meta-sep gris">♦</span>
<span id="WCAG-1.0">
<a href="http://wave.webaim.org/report?url=http://on-air.hiseo.fr/">Accessible ?</a></span>
</p>
<p>Ce bloc-notes est le blog personnel d'un <a rel="me author" href="http://www.hiseo.fr/a-propos/">Concepteur-rédacteur Web</a> ♦ Si vous voulez savoir ce que je fabrique c'est par <a href="http://www.hiseo.fr/redacteur-et-referenceur-web/" rel="me">ICI</a></p>
<p class="legal">Copyright © MMVIII - MMX <a href="http://www.hiseo.fr/" rel="me">Hiseo.fr</a> ♦ All wrongs reserved - Tous travers réservés ♦ <a rel="licence" href="http://www.hiseo.fr/informations-legales/">Informations légales</a>
</p>
</section>
</footer>

Des footer on peut en mettre dans tous les coins en HTML5. Par exemple pour envelopper les métadonnées de l'article sous son titre (quand on est sur la page) :
footer class="entry-meta" role="contentinfo"

Le role="contentinfo" indique évidemment que l'on va trouver des informations sur le contenu.

La zone de recherche aussi, est concernée par ARIA ; je lui indique ainsi : section role="search".

Les formulaires

Enfin... le mien : celui pour les commentaires. Le voici, brut de fonderie :


<form method="post" action="http://on-air.hiseo.fr/" id="post" accept-charset="UTF-8">
<p><label for="name"> Nom :</label><br />
<input type="text" name="name" id="name" placeholder="Votre nom ou pseudo" class="text" value="" required aria-required="true" /></p>
<p><label for="url" class="not-required">Site Web avec <b>http:// devant</b>
<span>(en DoFollow, mais faut pas spammer hein ?</span>) :</label><br />
<input type="text" name="url" id="url" placeholder="Votre site ou blog" class="text" value="on-air.hiseo.fr" /></p>
<p><label class="not-required" for="email">Courriel :<br /><span class="smaller">(ne sera pas publié : c'est pour afficher la trombine de votre avatar du service de <a rel="nofollow" href="http://fr.gravatar.com/">gravatar.com</a>)</span></label><br />
<input type="text" name="email" id="email" placeholder="Votre adresse courriel" class="text" value="" /></p>
<p><label class="inline not-required" for="remember_me">Se souvenir de moi</label><input name="remember_me" id="remember_me" value="yes" checked="checked" type="checkbox"></p>
<p><label for="text"> Votre commentaire :</label><br />
<textarea name="text" rows="10" cols="55" id="text" required aria-required="true">
</textarea></p>
<input type="submit" name="comment" id="comment" class="button" value="Expédier" />
</p>
</form>

Commençons par la fin : le bouton. Ce bouton étant un bouton HTML (pas une image) je ne crois pas qu'il y ait d'indication particulière à donner pour ARIA.
Idem pour la checkbox. Dans la cas d'une image (c'est plutôt rare, non ?) il aurait fallu ajouter role="checkbox" aria-checked="true".

Les champs de saisies obligatoires sont renseignés ici par des required aria-required="true". required c'est HTML5. Ce champ devient obligatoire avec cet attribut. Mais il faut qu'ARIA le sache aussi : c'est donc aria-required="true" qui l'indique.
Ici je n'ai pas ajouté autofocus pour d'évidentes raisons. Cet attribut je le réserve au champ nom du formulaire de contact (au passage ça ne marche pas dans la version actuelle de Firefox, la 3.6.x).
Notez aussi la présence de l'attribut placeholder étroitement associé à label. Il sert à définir un espace réservé pour du texte dans un champ de saisie. Son contenu est affiché dans le champ de saisie tant que le champ est vide et que le zoom (autofocus) n'est pas actif. Dès que vous cliquez dans le champ de saisie, son contenu disparaît. Seuls Chrome et Safari prennent en compte cet attribut à l'heure où je vous parle.

Pour conclure

Si l'on dispose d'un bon script (PHP ou autre) pour émettre un code HTML5 bien formé, l'ajout de les attributs ARIA et des microformats est chose aisée. Si j'y suis arrivé, même un singe pourra le faire. De toutes les façons avec la prise en compte d'ARIA en HTML5 plus personne ne devrait faire l'impasse sur l'accessibilité. Tout du moins, les webmestres qui jaugent uniquement de la qualité de leurs codes en le passant au banc du validateur du W3C.
Si les microformats sont, depuis bientôt une année (et plus), pris en compte par les moteurs de recherche ils vont devenir nécessaires aussi au référencement. Nul doute qu'ARIA dans HTML5 produira un effet sur les machines que sont aussi les robots des moteurs de recherche par l'ajout de ces informations sémantiques.

Alors ? Un bon site = HTML5 + ARIA + MICROFORMATS (meilleure qualité + d'accessibilité + meilleur référencement).

Vous pouvez ranger votre cahier de brouillons et passez au propre.




Commentaires :

JJ||#1
JJ
Très intéressant mais je me suis assez dubitatif sur le bénéfice réel des microformats pour le référencement.
Nico||#2
Nico
Et bien, je le relis avec attention celui-là de billet ! :)

Simple question : tu saurais où je peux trouver une liste complète de tous ces rôles... un peu plus digeste que les superbes documents du W3C ?
Michel||#4
Michel
Selon moi le problème majeur de HTML5/CSS3 est sa compatibilité avec tous les autres navigateurs.
Je suis sur le point de créer un site pour ma TPE et j'aimerais vraiment me mettre au HTML5/CSS3 mais étant donné que 80% de mes clients naviguent sous IE et souvent avec une vieille version, ils verront mon site tout déformé .. :(

Pour le moment, je n'ai vu que un ou deux scripts js comme solution et encore c'est pas glorieux ...
Philippe||#5
Philippe
Hello Michel

ce n'est pas tout à fait juste : IE ne pose pas de véritable problème pourvu qu'on lui apprenne les balises HTML5, tout du moins pour les 3 dernières versions 6, 7 et 8 (je ne pense pas qu'il ait des versions plus anciennes qui traînent).

Mais pas toutes les balises. HTML5 n'est encore qu'à l'état de brouillon. Certaines ne sont pas encore clairement définies (mais leur emploi est assez rare).
Si on veut passer son site en HTML5 il faut utiliser les balises sur lesquelles il n'y aura plus de discussions. Elles sont au nombre de 7 :

- header : pour les en-têtes de page ou de sections

- nav : qui regroupe des liens de navigation

- section : qui remplace div pour le placement visuel (non sémantique) de contenus

- footer : qui désigne des pieds de blocs où on va y placer des informations répétitives (les pieds de page d'un gabarit), ou des métadonnées liées à un article par exemple

- article : qui concerne les blogs ou les magazines pour placer du contenu primaire

- aside : pour placer du contenu secondaire

- time : pour les métadonnées temporelles

Quant aux CSS3 alors là je ne vois pas : rien n'oblige à coder en HTML5 en conjonction avec les CSS3 ; on peut très bien coder en HTML5 avec des feuilles de styles CSS2.1 (ou déjà IE butait). Ou s'en tenir en CSS3 aux « plus petits dénominateurs communs » dans le choix des sélecteurs pour une compatibilité avec l'ensemble des navigateurs.

Passer en HTML5 n'est donc pas un problème pourvu que l'on sache bien employer le code et gérer les particularités d'interprétation des différents browsers.
Nico||#6
Nico
Philippe : merci, je vais jeter un oeil ! :)
Petite correction : - nav : qui regroupement (regroupent ?) des liens de navigation

Michel : en fait, vu qu'il faut utiliser Javascript pour "apprendre" ces nouvelles balises à IE (les créer dans le DOM pour qu'IE puisse les styler), c'est surtout si dans ton audience tu as des IE avec Javascript désactivé que ça pose un gros problème.

Je rejoins Philippe : pour ma part, je compte introduire HTML5 en premier et garder mes CSS qui sont compatibles avec IE 6 et supérieurs, et seulement après, j'envisagerai d'introduire CSS 3 sur mon site à titre expérimental.

(d'ailleurs, vivement que les préfixes des navigateurs aient disparu dans les CSS)
Michel||#8
Michel
Merci pour vos réponses, je ne savais pas que ces 7 balises HTML5 étaient reconnues et bien interpretées par tous les navigateurs. Je vais donc me lancer dans le HTML5 et garder mon CSS 2.1 comme Nicolas.

Comment faites-vous pour tester la compatibilité de votre site sur les principaux navigateurs ? Vous installez les navigateurs à l'ancienne ?
Paul||#9
Paul
Un très grand merci. Comme je m'intéresse à HTML 5, aux CSS 3 et à l'accessibilité pour un projet de site pour une association je cherche des articles et des exemples de code. Dans tout ce que j'ai pu trouver c'est sans aucun doute le meilleur article que j'ai pu lire.
Merci encore.
Laurent||#10
Laurent
Rendre accessible son site HTML5 ? Avec tout ça je sens que je vais avoir du boulot. C'est quand même un peu lourd : on va bientôt avoir plus de code que de contenu.
Tom||#11
Tom
Très très bon article et très très bons commentaires.
Guillaume-Nicolas MEYER||#12
Guillaume-Nicolas MEYER
Merci pour ton contenu. Ca m'a donné envie de commencer la refonte de mon blog avec des petits morceaux de tout ça dedans.
L'idéal serait de proposer un patron de page mêlant HTML5, Microformats et ARIA, histoire d'avoir une vue d'ensemble. Ou bien un bon bouquin qui aborderait tous ces sujets de front.
SEO et linguistique||#13
SEO et linguistique
Linguiste de formation, je m'étais intéressé un temps au "web sémantique". Aujourd';hui nous découvrons que Google s'intéresse de près aux données des sciences du langage et je me tourne à nouveau vers la sémantique. Mais ce que j'apprends en lisant votre article dépasse de loin ce que j'imaginais. Il y a tellement de choses déjà en place, des tags tout prêts à être utilisés. C'est comme de dire aux navigateurs ce qu'il doit faire avec le contenu. Référenceur de profession, j'y vois u nmoyen de faciliter la lecture des sites sur lesquels je travaille et je trouve cela formidable !! Merci pour votre article, qui m'en apprend énormément.
titou||#14
titou

Tres tres bon article sérieusement :D
Carine||#15
Carine
Bonjour,

J'aimerai comprendre comment les navigateurs modernes qui supportent ARIA en font usage. Je comprend parfaitement l'utilité pour les lecteurs d'écran mais pas pour les navigateurs.

Merci pour vos explications !
Philippe||#16
Philippe
ARIA ne concerne pas seulement les lecteurs d’écrans mais les navigateurs aussi. À l’origine HTML n’ayant pas été conçu pour concevoir des applications Web, les développeurs ont ajouté de petites applications en Javascript (les Widgets).

Le problème c’est que le rôle, l’état et les propriétés de ces Widgets et de leurs contenus ne sont pas reconnus par les technologies d’assistance intégrés aux browsers.

ARIA résoud donc ce problème en permettant aux développeurs de décrire less éléments de l’interface, la structure des documents, et de dire quelles seront les zones qui seront modifiées par ces Widgets dans les pages.
mathieu||#17
mathieu
Bonjour,
une question me pose problème avec HTML5. Le fait de devoir utiliser javascript pour l'utiliser sous IE ne pose t-il pas un problème d'accessibilité justement?
Mes connaissances datent un peu en accessibilité web et j'en suis toujours au : "un site doit être naviguable avec javascript désactivé". J'aimerais connaître votre avis sur ce point,
merci.
mathieu.
Insolite-du-Geek||#19
Insolite-du-Geek
J'espère vraiment que le HTML 5 va grandement amélioré l'accessibilité pour les personnes handicapés, plus que ce n'était le cas avant !
Philippe||#20
Philippe
Hum... c’est plus une affaire d’hommes que de code je crois. Si les webmestres codaient en pensant à eux, que ce soit en HTML4 ou en HTML5, le monde du Web leur serait plus ouvert.
Vince||#21
Vince
Merci beaucoup pour cet article, mais un article sur l'accessibilité qui inclue cette propriété pour les voyants:

footer.homeentry-meta, footer.entry-meta {
font-size: 0.6em;
}

me semble assez contradictoire... ca donne du georgia 9.6px, ce qui est totalement illisible, même zoomé à à fond...
Philippe||#22
Philippe
Bah ! j’ai fait pire…

Les commentaires pour ce billet sont fermés