Pour beaucoup de gens, la conformité XHTML et l’accessibilité d’un site Web sont 2 notions équivalentes. Pourtant, il n’en est rien. On peut avoir un site valide et totalement inaccessible, et inversement un site non valide peut être accessible.
Les validateurs : la syntaxe
Les validateurs XHTML s’occupe de vérifier que le code source est syntaxiquement correct. Or, actuellement tous les navigateurs sont très permissifs vis à vis du code source fournit. D’ailleurs, c’est le même interpréteur qui est utilisé pour rendre une page suivant du HTML 4.01 Transitionnal, du XHTML 1.0 Strict, du XHTML 1.1 ou du HTML 5. Les navigateurs ne font aucune différence dans le rendu des pages. Certaines balises (ou attributs) sont donc parfaitement valides dans une variante interdite dans une autre, le navigateurs l’interprétera. L’exemple le plus classique est la propriété « target=_blank », elle est parfaitement valide en HTML 4.01, elle nécessite des guillements en XHTML 1.0 Transitionnal et est interdite en XHTML 1.1, pourtant elle est interprétée exactement de la même manière sur l’ensemble des navigateurs.
L’accessibilité ne s’intéresse pas directement au code source, elle s’intéresse au DOM. L’important est que le DOM soit compréhensible par les différents navigateurs. Si l’on reprend notre exemple du target=_blank, l’information sera comprise par l’ensemble des navigateurs ce n’est donc pas un problème d’accessibilité. Pour l’accessibilité, il suffira d’indiquer que le lien s’ouvre dans une nouvelle fenêtre.
l’accessibilité : la sémantique
L’accessibilité s’intéresse également à la sémantique des éléments. Elle fait par exemple la différence entre les tableaux de données et les tableaux de mises en pages. Cette distinction bien que déductible par définition même du HTML n’est pas identifiable par les outils de validations. Les 2 exemples suivants montrent 2 codes sources parfaitement valides avec les mêmes données. Le premier ne tient pas compte des critères d’accessibilité, on utilise un tableau de mise en pages pour un tableau de données, le deuxième est le même tableau qui respectent les critères d’accessibilité et utilisent la bonne sémantique.
<h3>Titre</h3> <p>Résumé</p> <table> <tbody><tr> <td>Titre 1</td> <td>Titre 2</td> </tr> <tr> <td>Contenu 1</td> <td>Contenu 2</td> </tr> </tbody></table>
<table summary="Résumé"> <caption>Titre</caption> <tbody><tr> <th scope="col">Titre 1</th> <th scope="col">Titre 2</th> </tr> <tr> <td>Contenu 1</td> <td>Contenu 2</td> </tr> </tbody></table>
Bien sûr, un code source valide et notamment dans les variantes strictes, permet d’améliorer la qualité des pages. Certaines erreurs n’ont pas de grandes conséquences pour l’accessibilité d’un site Web, d’autres sont beaucoup plus gênantes.
>Le paradoxe ARIA
ARIA (Accessible Rich Internet Application) est une spécification technique du W3C pour augmenter l’accessibilité des interfaces riches écrites avec HTML, Javascript et autres technologies associées.
ARIA décrit comment ajouter de la sémantique et des métadonnées aux contenus HTML afin de rendre les contrôles d’interface et les contenus dynamiques plus accessibles. Par exemple, il devient possible d’identifier une liste de liens en tant que menu de navigation et d’indiquer si son état est plié ou déplié.
Initialement prévu pour être un module XHTML avec un namespace particulier, et devant le faible engouement de l’industrie du Web pour la modularisation XHTML, les propriétés s’écrivent désormais sous la forme d’attribut traditionnel : tabindex, role, aria-valuemin, aria-valuemax, aria-valuenow, aria-valuetext, aria-labelledby, aria-live, … sont autant de propriété que ne sont pas valides dans n’importe quelles variantes XHTML ou HTML et qui apporte un réel plus du point de vue de l’accessibilité.
La validité du code source est importante mais elle ne garantit en rien l’accessibilité d’un site Internet. Avec ARIA, on peut voir que certaines erreurs XHTML sont en fait des apports supplémentaires à l’accessibilité d’un site Web.