Accessibilité des applications web (Handicap) et HTML5

L’objectif de cet article est de faire un point sur les points de vigilance dans le développement d’applications et sites web pour les rendre le plus accessibles possible avec les différents profils de handicap.

L’accessibilité dans les applications et sites web est très complexe à mettre en oeuvre. Cet article ne prétend pas faire un état des lieux exhaustif de ce qu’il est nécessaire de faire mais tente modestement de lister quelques points de vigilance à destination des développeurs web. Le but est également de montrer qu’il est possible d’améliorer significativement l’accessibilité de nos applications et sites web en appliquant quelques règles simples. Qui plus est, l’amélioration de l’accessibilité bénéficie à tous les utilisateurs, car une application accessible est souvent une application bien pensée!

Pour permettre une accessibilité la plus correcte possible, nous avons séparé l’article en trois types de déficience : visuelle, moteur et cognitive.

Handicap et déficience visuelle

Fonctionnement de la relecture pour personne déficiente visuelle : les personnes mal voyantes utilisent souvent des interpréteurs vocaux de la page. Ces lecteurs audios sont assez basiques et se contentent le plus souvent de lire le texte dans le sens où ils le trouvent dans la page. Ils n’interprètent évidement pas le CSSFeuilles de style qui permettent de mettre en forme des pages web. et se contentent donc de la représentation HTMLHTML (HyperText Markup Language) est un langage permettant de décrire le découpage d'une page web. de la page. Ils sont en revanche (de plus en plus) sensibles à la sémantique contenue dans le HTML. L’accessibilité de votre site web va donc se jouer majoritairement sur la structure HTML de vos pages.

Le HTML propose un grand nombre de balises, dont beaucoup sont méconnues, peu ou pas utilisées. Il est toujours tentant pour un développeur de construire ses pages HTML avec seulement des div et des span. Ce sont pourtant des balises n’offrant aucune valeur sémantique. Leur seule valeur est structurelle : une div est un bloc, une span est un élément de ligne. Il est pourtant possible de donner de la valeur sémantique aux éléments, surtout pour les blocs : un bloc de texte doit être une balise p, une liste d’éléments peut presque toujours être une ul, une ol ou une dl, du texte mis en valeur par du CSS et imbriqué dans une div doit être un titre h. La structure HTML d’une page doit refléter son contenu sémantique. Il est donc avant tout important d’avoir une idée claire du sens du contenu de votre page, dans la mesure où le HTML reflète ce dernier (ce n’est pas le HTML qui donne du sens à votre texte !). Vous pouvez trouver une liste des balises avec leur description structurelle, technique et sémantique, ainsi que leur compatibilité sur le site du W3C Schools.

Le HTML5 introduit quelques nouvelles balises très intéressantes pour la structure sémantique de vos pages : header, footer, section, article, aside, nav. Le lien précédent pourra vous éclairer plus précisément sur le sens de ces éléments et la meilleure façon de les utiliser. Un très bon article en français sur le site AlsaCreations pourra également vous renseigner. De plus, le W3C définit la notion d’outline qui permet, par l’analyse du code HTML d’une page, d’établir un plan de celle-ci en fonction de ses éléments sectionnant imbriqués et de ses titres. En fonction de la outline obtenue, vous pouvez évaluer la pertinence de la structure de votre page : si le plan ne correspond pas à ce que vous avez voulu dire, ou si aucun titre ne ressort, il faut retravailler tout ça. Plusieurs outils en ligne existent pour générer la outline comme celui-là.

Toutefois, si la tentation est grande d’utiliser massivement les nouvelles balises, leur mise en oeuvre « accessible » nécessite la plus grande prudence et l’application d’une certaine méthodologie pour conserver la compatibilité sur les principaux navigateurs. En effet, comme vous pouvez le constater sur la documentation du W3C Schools, les nouvelles balises HTML5 ne sont reconnues par IE (Internet Explorer) qu’à partir de la version 9. Or IE8 a encore à l’heure actuelle une part de marché non négligeable : à peine moins de 8% sur le baromètre 2013. Les versions antérieures peuvent raisonnablement être ignorées, IE7 ne recueillant plus que 0.6% des suffrages sur ce même baromètre. Mais un site web accessible est avant tout un site web compatible sur les principaux navigateurs, et donc la compatibilité IE8 (pour l’instant) ne peut pas se concevoir comme une option dans une démarche d’accessibilité.

La mise en oeuvre conjointe de la sémantique HTML5 et de la compatibilité IE8 passe par deux actions. D’abord la mise en place du script JS éprouvé qui modifira votre HTML à la volée. Ensuite la prise en compte de ces modifications dans votre feuille de style. Le mieux est de tester son site sur IE8 avec le script pour se rendre compte des changements provoqués. Pour le CSS, cela implique 2 choses (outre le fait de ne pas utiliser de sélecteurs CSS3 non reconnus par IE8 : pour cela voir le W3 Schools) :

1. ne pas appliquer de style aux balises non-compatibles ;
2. tenir compte de la modification du DOM par le script JS dans ses sélecteurs CSS pour les éléments à l’intérieur des balises non-compatibles : par exemple, un élément à l’intérieur d’une balise section va se retrouver un niveau plus haut et après une balise que l’on ne peut pas cibler par son nom en CSS ;

Pour le deuxième point, on pourrait argumenter qu’il suffit d’appliquer une classe CSS à l’élément imbriqué. C’est vrai. Il est néanmoins intéressant de chercher à limiter le nombre de classes CSS déclarées de façon à en débarrasser au maximum de code HTML, afin que ce dernier soit plus lisible.

Le choix des balises n’est cependant pas la seule manière d’introduire de la sémantique dans le HTML. Une autre façon, particulièrement bien reconnue par IE et Firefox, est d’avoir recours à la spécification ARIA (Accessible Rich Internet Applications), autre production du W3C. Elle permet entre autres de définir des rôles pour chaque bloc, par le simple ajout d’un attribut role sur la balise concernée. Vous trouverez plus d’informations et la liste des rôles sur la documentation technique.

Pour aller plus loin, il est intéressant d’utiliser vous-même des lecteurs d’écrans pour vous rendre compte de ce que ces logiciels font de vos pages. On peut citer JAWS et Window-Eyes. Vous constaterez par exemple si vous utilisez des caractères tels que les chevrons ou le pipe en guise de séparateur qu’ils sont lus par les lecteurs d’écran. Une solution peut être de placer ces séparateurs dans la propriété CSS content. D’autres situations comme celle-ci existent, c’est pourquoi il est utile d’essayer soi-même les lecteurs d’écran.

Accessibilité: Points de vigilance

• le code HTML doit valider sur le site du W3C (http://validator.w3.org/)
• les pages doivent être compatibles IE8 minimum (http://www.w3schools.com/tags/default.asp)
• le code HTML doit utiliser au maximum la diversité des tags existants
• l’utilisation des différents tags HTML doit se faire judicieusement selon leur valeur sémantique
• la structure des pages HTML doit avoir une outline cohérente avec leur contenu sémantique
• les caractères utilisés comme éléments de décoration doivent être soit déplacés dans une CSS (attribut content) soit remplacés par des images
• l’utilisation des sélecteurs CSS doit conserver la compatibilité IE8

Handicap et déficience moteur

Un des problèmes les plus souvent négligés est le handicap moteur. En effet, une personne qui possède des difficultés avec sa main par exemple aura du mal à scroller pendant des heures sur des pages particulièrement longues. Pour pallier ce problème, il est nécessaire de mettre de nombreux liens vers les différentes sections de la page. Par exemple, un lien remonter en haut de la page permet à l’utilisateur de ne pas avoir à scroller, ce qui est reposant.

Handicap et déficience cognitive

Le handicap cognitif est probablement l’un des plus négligés et aussi sûrement l’un des plus difficiles à appréhender. Le problème est que trop d’information rend généralement l’application ou le site complètement inaccessible pour une personne déficiente cognitive. C’est souvent le cas dans les applications ou de nombreuses fonctionnalités sont accessibles sur la même page.