Chose promise, chose due (même avec un peu de retard), voici quelques enseignements ou confirmations de bonnes habitudes à prendre, suite à la Conférence Romande sur l'accessibilité. Elles ne sont pas très difficiles à faire, donc n'hésitez pas. J'ai pu en voir le bénéfice direct et net en démonstration durant la conférence.
J'espère sincèrement enfoncer des portes ouvertes pour la plupart des points ci-dessous.
Les synthèses vocales proposent plusieurs façons d'aborder un document web (et ce afin de faciliter et d'accélérer la navigation), notamment via la structure des titres et des sous-titres. Si vous doutiez encore de l'utilité d'avoir une structure Hx correcte et explicite, ne doutez plus.
Autre possibilité, ces synthèses vocales peuvent sortir la liste des liens de la page. Hors contexte, l'utilité d'avoir des liens avec des énoncés pertinents est donc importante dans ce cas (imaginez si tous les liens sont de type « lire la suite ».
Côté navigation, il est également possible de naviguer en utilisant la touche de tabulation, j'en ai déjà parlé plusieurs fois ici. Il faut garder à l'esprit qu'une synthèse vocale va lire séquentiellement chaque page, donc pour le dire simplement, la personne va devoir supporter à chaque changement de page la lecture de tout le contenu ! C'est également valable pour ceux qui naviguent au clavier bien sûr. On parle dans ce cas de navigation séquentielle (littéralement « à la suite »).
Si vous doutiez de l'utilité des liens d'évitements, n'en doutez plus. Dans le cas de sites ayant un nombre de liens conséquent en navigation (notamment les sites d'e-commerce), l'économie de tabulations (et donc de temps) peut être vraiment importante. Certains sites pourraient faire économiser pas moins de 4 à 500 tabulations à leurs visiteurs en ajoutant quelques « pauvres » liens d'évitement.
Une bonne habitude toute simple pour les formulaires : quand un utilisateur de synthèse vocale soumet un formulaire, et en supposant que certains champs n'aient pas été remplis correctement, le formulaire va indiquer dans son contenu un message du style « les champs suivants doivent être remplis ». Seul souci, l'utilisateur de synthèse vocale n'a pas de retour immédiat sur ce problème (en supposant qu'il en ait un, de retour !), il doit attendre que sa synthèse arrive sur ce message d'erreur, ce qui risque d'être gênant : l'utilisateur peut croire que son formulaire a été correctement soumis. Pour éviter ce risque, une solution toute simple existe : il faut indiquer clairement dans la balise title de la page qu'il y a une erreur, ainsi, l'utilisateur est tout de suite prévenu qu'il existe un problème. C'est également valable si le formulaire a été correctement soumis : il faut informer rapidement l'utilisateur.
Une autre bonne idée : parfois, on vous impose un bouton submit pas très explicite, le classique « envoyer ». Il pourra être intéressant d'ajouter un attribut title sur ce submit indiquant un complément d'action, par exemple, « envoyer mon message ».
Côté ARIA, des possibilités assez simples sont d'ores et déjà implémentables, et notamment une : les landmarks.
Sous ce nom bizarre se cache quelque chose d'extrêmement simple et pourtant très puissant : ce sont des attributs role qui permettent de définir le… rôle (!) de certaines portions de codes. ainsi, cela permet à l'utilisateur d'une synthèse vocale de pouvoir mieux appréhender la précieuse vue d'ensemble qui lui manque. En pratique, cela consiste à indiquer par exemple les rôles suivants :
role="contentinfo"indique des notes de pages, un copyright, un lien vers la déclaration de confidentialité, etc.role="main"indique le contenu principal du document.role="navigation", comme son nom l'indique, indique des liens de navigation (internes ou externes).
Pour une liste beaucoup plus complète, je vous invite à consulter : Introduction à WAI-ARIA.
C'est par exemple implémenté sur ce site, et c'est très facile à prévoir sur un site, il suffit d'ajouter quelques attributs sur son template de base.
Autre idée facile à prévoir, il arrive d'avoir une zone qui se met à jour toute seule (une zone qui affiche des nouvelles, etc.). Pour l'indiquer à la synthèse vocale, il suffit d'utiliser l'attribut aria-live. La valeur spécifiée indique à la synthèse quand elle doit notifier le changement à l'internaute, aria="polite" va attendre que l'utilisateur ait fini ce qu'il est en train de faire pour indiquer le changement.
La liste est très loin d'être exhaustive, toutefois, je me suis limité à des choses vraiment très faciles à implémenter. Ce ne sont que quelques bonnes habitudes à prendre, et quelques choses à savoir. Chose intéressante, le bénéfice est immédiat pour les utilisateurs d'aides techniques, donc faites-le !
Quant aux liens d'évitement, ils sont également utiles à des utilisateurs de téléphones mobiles, surtout si les liens de navigation demeurent grosso modo à la même place, quand bien même les CSS seraient un minimum adaptées aux contraintes du média. Il suffit de songer à ceux qui ont l'index fatigué de tant balayer l'écran ou qui ont un mobile à clavier sans interaction tactile possible, comme certains modèles Blackberry.
Enfin, tu as oublié de signaler qu'il faut réserver la valeur "rude" de l'attribut aria-live aux messages d'alerte et éviter d'en abuser pour les bannières et autres fenêtres modales publicitaires, le cauchemar de Jean-Pierre Villain.