Rendre nos sites accessibles : oui, mais comment ?

 Par Françoise Fontaine-Martinelli, rédactrice invitée sur "Nouvelles Lectures".

Dans un précédent billet sur le blog l'Alambic Numérique, j’ai essayé d’aborder la thématique de l’accessibilité numérique en précisant qu’elle ne concernait pas uniquement le web. Aujourd’hui, je souhaiterai me recentrer sur cette question de l’internet, en particulier parce que nos sites ou nos portails documentaires sont un moyen incontournable de diffusion (et donc d’accès) à l’ensemble de nos services et qu’ils sont des sites de communication publics donc soumis à l’obligation légale d’accessibilité.

Alors, oui, bien sûr, tous, bibliothécaires (du moins je l’espère), nous sommes prêts à œuvrer pour l’accessibilité mais comment ? Par quel(s) bout(s), prendre ces chantiers ? D’autant plus qu’aujourd’hui nous ne partons plus de zéro, en tout cas, en bibliothèque universitaire, les sites ou portails documentaires ont une histoire et les équipes qui les ont conçues aussi. Très concrètement, que faire ?

 

La cible : à qui l’accessibilité d’un site profite-t-elle ?

C’est essentiel : ne jamais perdre de vue, pourquoi ou plutôt pour qui il faut rendre nos sites accessibles. Pour Abdel, jeune homme aveugle, qui ne peut avoir de vision d’ensemble de la page et a besoin d’informations structurées. Il se retrouve, bloqué, sans plus savoir où il en est de sa navigation, car sa plage braille ne lui renvoie plus aucune information. Pour Céline, étudiante malvoyante en sciences sociales, qui utilise une synthèse vocale (on dit aussi logiciel de revue d’écran) et ne peut deviner que « l’image 456 » est un graphique représentant l’évolution du taux de fécondité en France depuis 1965. Mais aussi, pour Fatoumata, malentendante, qui doit venir faire ses études en France et qui aimerait bien, que la vidéo qui présente la bibliothèque soit sous-titrée. Cela lui éviterait de demander à son père, sa mère ou sa soeur. Ou encore pour David, qui ne peut utiliser une souris et aimerait pouvoir naviguer facilement grâce à son clavier adapté.

La liste n’est évidemment pas close mais il ne faut jamais, jamais, oublier les utilisateurs.

 

Le nerf de la guerre

Ensuite, se dire que le noyau dur de l’accessibilité des sites Web, ce sont les spécifications techniques que contiennent les référentiels et les éléments de programmation. Je ne suis pas informaticienne, et ma culture informatique d’un point de vue technique est limitée mais je pourrais veiller, dans un projet web, à ce que cette dimension soit prise en considération à toutes les étapes du projet (création, modifications marginales ou reconfiguration totale). Et c’est là tout l’enjeu d’un site accessible : faire entrer la notion d’accessibilité à toutes les étapes et dans tous les esprits. Il faut que quelqu’un s’en charge très tôt.

Le web reste toujours une mine de documentation. Une série de fiches synthétisent de manière très opérationnelle (et c’est leur grand intérêt) les exigences d’accessibilité. En effet, le site AcceDe Web propose un ensemble de notices adaptées à la gestion de projet web. L’intérêt de ces quatre notices est qu’elles ciblent, chacune, un professionnel comme dans un jeu des 4 familles : dans la famille projet web, je voudrais le graphiste, je voudrais le développeur, je voudrais le contributeur et je voudrais le chef de projet. A chacun dans son domaine de compétences d’intégrer cette dimension. Ce projet, coordonné par Atalan, a été nommé aux Trophées de l’accessibilité 2013.

 

Les grands principes : à quoi reconnaît-on un site accessible ?

Revenons maintenant aux principes tels qu’ils sont exprimés dans les référentiels. Le Référentiel Général de l’Accessibilité pour les Administrations (RGAA), qui s’applique aux sites de communication publics, reprend l’organisation du WCAG 2.0, en 4 grands principes. Il est facile d’en prendre connaissance grâce à cette traduction en français assurée par Braillenet :

• Premier principe : il faut que les contenus soient perceptibles. C’est à dire que « L’information et les composants de l’interface utilisateur doivent être présentés à l’utilisateur de façon à ce qu’il puisse les percevoir. » . Sous ce critère, on retrouve les alternatives textuelles aux images, aux boutons graphiques, description textuelle d’un graphique… ; captcha audio, structuration d’un document de traitement de texte ou .pdf, alternatives à des contenus audios ou vidéos (sous-titrage, audiodescription). Il s’agit également de séparer le contenu de la présentation via l’utilisation de feuilles de style .

• Deuxième principe : Les « composants de l’interface utilisateur et de navigation ». doivent être utilisables. Très concrètement, toutes les fonctionnalités doivent être accessibles au clavier, des éléments d’orientation (pour naviguer, se situer dans le site, s’orienter) doivent être présents. Un lecteur qui utilise une synthèse vocale lit de manière séquentielle, chronologique. Il ne lui est pas possible d’avoir une appréhension globale des informations. Des éléments d’orientation doivent donc lui permettre de repérer la hiérarchie des informations, pour aller directement à l’information qui l’intéresse et éviter s’il le souhaite certaines informations. Il est également important de laisser suffisamment de temps à l’utilisateur pour lire le contenu et pour mener les actions nécessaires. Il est également conseiller d’éviter les flashs (brusques changements de luminosité à l’écran) susceptibles de déclencher des crises d’épilepsie chez certains utilisateurs.

• Troisième principe : Les informations et l’utilisation de l’interface utilisateur doivent être compréhensibles. Ainsi, par exemple, il est essentiel qu’un dispositif technique de lecture sache si le texte est dans une langue étrangère (utilisation de l’attribut lang) au risque de produire un texte incompréhensible type yaourt. Faire en sorte que la structuration se répète afin de rendre la navigation prévisible est également un point à prendre en compte.

• Quatrième principe : Le contenu doit être suffisamment robuste pour être interprété de manière fiable par une large variété d’agents utilisateurs, y compris les technologies d’assistance. Il faut donc veiller à ce que les technologies d’assistance utilisent correctement les contenus balisés en spécifiant la DTD utilisée.

Ce qui se joue, c’est une nécessaire prise en compte des questions d’accessibilité par chacun des membres de l’équipe projet web, que ce soit sur le plan de la conformité à la loi, des exigences techniques et du service aux utilisateurs. Ainsi, parmi les membres de l’équipe du Pôle, du Centre, de la Division, Direction, des Systèmes d’information de l’Université et de la Bibliothèque, que sais-je, la présence de développeurs et de webmestres formés aux questions d’accessibilité est nécessaire. Sans eux, rien n’est possible.

 

Les labels : Comment certifier qu’un site est accessible ?

Les recommandations WCAG 2.0 se répartissent selon 3 niveaux :

1. le niveau A : niveau fondamental satisfaisant tous les critères d’accessibilité de priorité 1. Pour une conformité de niveau A (le niveau minimal), la page Web satisfait à tous les critères de succès de niveau A ou une version de remplacement est fournie. Par exemple, un texte explique une vidéo ou  une image.
2. le niveau AA : niveau satisfaisant tous les critères d’accessibilité de priorité 1 et 2. Le site offre un accès « correct » aux informations contenues dans les documents Web. Par exemple,  la possibilité  de recourir à l’agrandissement des textes sans perte d’information et sans avoir recours à une technologie d’assistance.
3. le niveau AAA : niveau satisfaisant tous les critères d’accessibilité de priorité 1, 2 et 3. Le site offre un accès excellent aux informations contenues dans les documents Web. Par exemple, une description audio étendue met en pause la vidéo pour expliquer l’ensemble des informations nécessaires à la compréhension de l’élément.
   (les exemples sont tirés du guide “Un site web accessible pour ma collectivité“  réalisé par le Syndicat mixte e-mégalis Bretagne en 2012).

Le niveau recommandé au niveau européeen est le niveau AA et c’est également le niveau de conformité que doivent atteindre les sites publics français. Le niveau AAA ne peut s’appliquer dans tous les contextes. La méthodologie qui accompagne le RGAA prévoit, lors de l’étape finale, la rédaction d’une attestation de conformité, établie par l’éditeur du site lui-même. C’est le principe de l’auto-évaluation.

Il est bien spécifié dans le décret n° 2009-546 du 14 mai 2009 que la vérification de la conformité au RGAA est assurée par le ministère chargé des personnes handicapées. Un dispositif de veille et de contrôle devait être mis en place fin 2010. Mais je n’en ai pas trouvé trace …

S’il n’y a pas d’obligation de faire expertiser son site, en France, à ma connaissance, il existe deux labels :

Le label Accessiweb, décerné par l’association Braillenet, c’est un peu comme participer aux Jeux Olympiques de l’accessibilité avec la possibilité de gagner l’or, l’argent ou le bronze selon la performance de son site. On garde sa médaille (euh, non, son label pour 2 ans) et ensuite, il faut recommencer la démarche. Problème, nombre de sites n’ont pas renouvelé la démarche et, dans la Galerie des sites labellisés, la mention « Ce site n’a plus à ce jour le label Accessiweb » est fréquente. Aucun des sites labellisés avant 2010 n’a réobtenu le label. Cela ne veut pas dire que ces sites ne sont plus accessibles mais simplement qu’aucun audit externe ne le valide. Le label Accessiweb (qui repose sur une liste de 95 critères AccessiWeb et une méthodologie d’évaluation). est payant, ceci explique peut-être cela !

Il existe un autre label e-accessibility, valable 18 mois et qui propose également un label pour les documents .pdf. Très franchement, vous étiez vous déjà posé la question de l’accessibilité de tous ces documents en .pdf que vous déposiez sur votre site ? Non, alors vite, lisez la fiche AcceDE pdf . Problème :  la médiathèque d’e-accessibility, rubrique site web labellisés propose … 3 sites. Maigres résultats.
Au niveau européen, le label Euracert est attribué à un site web, en complément du label déjà obtenu par un organisme agréé dans son pays d’origine. A ma grande surprise, la France, la Belgique et l’Espagne sont les seuls pays qui comptent un organisme agréé. Trois ? Le chiffre clé d’une accessibilité déficiente ?
Alors labellisation, pas labellisation ? Ce qui semble poser problème c’est que la labellisation est plutôt liée, pour les organisations qui en font la démarche, à un effet marketing de court terme et ne prennent pas en compte la volatilité et la reconfiguration permanente des contenus. La règle devrait être : concevoir systématiquement des sites web accessibles. On en est loin malgré l ‘obligation législative.

 

Les stratégies : à quel moment s’y prendre ?

Il faut intervenir très en amont, au moment de la phase de conception, qu’elle porte sur une création de site ou sur une évolution. Les modalités d’application du RGAA définissent clairement les différentes étapes. Dans le cas où la création du site web fait l’objet d’un prestataire extérieur, je vous recommande la lecture de la « Recommandation sur l’accessibilité des sites web publics » du Groupe d’études des marchés d’informatique et communications électroniques qui dépend du Ministère de l’économie et des finances. Ce document de 6 pages, daté d’avril 2012, est un outil précieux pour qui doit lancer un appel d’offres puisqu’il détaille tous les points à notifier : quelle est la méthodologie suivie par le prestataire pour intégrer l’accessibilité aux choix techniques, quels seront pour chaque livrable les paramètres d’accessibilité, quelles sont les compétences en terme d’accessibilité de l’équipe du prestataire, en cas de reprise de contenus, quelle sera la démarche suivie, quels contenus pourront être rendus accessibles, quels seront les tests pratiqués, quelle sera la forme de la restitution, quelle formation pour garantir dans la durée l’accessibilité ? Il est d’autant plus précieux qu’il indique explicitement que la politique d’accessibilité qui guidera le travail du prestataire est de la responsabilité du maître d’ouvrage.

Il faut  rappeler que l’accessibilité ne se vérifie pas à l’œil nu. L’expérience Avant/Après (type “Nouveau look pour une nouvelle vie” à la sauce Web) se trouve sous un vilain nom BAD , pour Before and After Demonstration.  Le consortium W3C a mis en ligne deux versions d’un même site, l’une accessible et l’autre pas. En cliquant sur Show annotations vous aurez, au fil du site, des explications sur les erreurs commises. C’est en anglais, mais ça vaut le coup.

Dans un projet Web, il est toujours intéressant de procéder à des test utilisateurs. L’inaccessibilité se cache dans les détails. J’ai le souvenir, d’un changement de catalogue d’une bibliothèque, pourtant  affiché accessible, (car cette exigence était spécifiée dans le cahier des charges) et qui en réalité s’est révélé inutilisable par un lecteur aveugle à cause d’une toute petite chose : dans l’interface graphique, des flèches droite et gauche de navigation restaient sans équivalence pour un logiciel de revue d’écran.

Alors prêts à se lancer dans l’aventure ? Réaliser un site accessible est un itinéraire qu’il faut baliser très en amont. Ne perdez pas patience, restez zen, ne vous trouvez pas « 5 bonnes raisons de coller une droite à un expert accessibilité » mais lisez plutôt le billet éponyme sur Accessiblog.fr. Soyez plutôt sur le mode « Vingt fois sur le métier remettez votre ouvrage », persévérez car la mise en accessibilité n’est sans doute pas un long fleuve tranquille mais c’est un flux nécessaire.

Billet initialement publié sur l'Alambic Numérique et reproduit avec l’aimable autorisation de son auteur.