Webdesign Friday (#wdfr) - La communauté des webdesigners francophones

Les vendredis Webdesign !Chaque semaine, un nouvel article par un professionnel du Web.

Prendre en compte l’accessibilité dans vos projets

Prendre en compte l’accessibilité dans vos projets

Vous êtes designer, intégrateur, concepteur d’interfaces ou chef de projet. De votre compétence dépend l’accessibilité des services et applications que vous développez. Faisons un point sur cette notion et voyons comment vous allez pouvoir la prendre en compte.

L’objectif de cet article n’est pas de faire de vous un expert : il s’agit simplement de vous donner une vision simple et claire du sujet. Je vais vous indiquer quelques fondamentaux à connaître, puis vous proposer un bref parcours de quelques ressources utiles.

Ce qu’il faut absolument savoir

Pour commencer, nous allons essayer de déterminer quelques éléments à comprendre absolument :

  • L’accessibilité est l’une des exigences fondamentales qui s’appliquent aux projets web. C’est une obligation légale pour la plupart des sites publics à travers le monde. Pour des sites privés, la non accessibilité d’un contenu web est un risque juridique important, en raison des possibles mises en cause pour discrimination — par exemple, une rubrique ressources humaines, jobs ou recrutements présentant de graves défauts d’accessibilité fait courir de réels risques juridiques à ses auteurs.
     
  • L’accessibilité a pour objectif l’« ouverture » des contenus et services en ligne aux personnes handicapées, c’est à dire plus largement à toutes les machines logicielles ou matérielles qu’elles utilisent.
     
  • L’accessibilité a un intérêt particulièrement immédiat pour toutes les personnes qui ont des difficultés à se déplacer pour effectuer une démarche hors de leur cadre familier. Cela concerne au premier chef toutes les personnes ayant des déficiences cognitives, motrices ou sensorielles, de manière permanente ou temporaire, qu’elles soient reconnues comme handicapées ou non. Par extension, toutes les personnes âgées sont également concernées.
     
  • Des standards techniques internationaux ont été définis pour atteindre cet objectif d’accessibilité, sous l’égide du W3C. Il s’agit en particulier des Web Content Accessibility Guidelines (recommandations pour l’accessibilité des contenus Web, WCAG).
     
  • Ces standards internationaux définissent un certain nombre de choses à faire et à ne pas faire sur un site. Ces pratiques sont d’ordre ergonomiques, techniques ou éditoriales.
     

Des critères bloquants, ou au contraire facilitants

Les pratiques ergonomiques, techniques et éditoriales dont je parle ci-dessus vont conduire selon les cas à :

  • Lever un blocage total à l’accès aux contenus :
    Exemple : le déclenchement automatique d’un son au chargement d’une page va venir empêcher la vocalisation d’une page par un lecteur d’écran. Il ne faut pas déclencher automatiquement de son au chargement d’une page.
     
  • Supprimer des difficultés majeures d’accès aux contenus :
    Exemple : le rafraîchissement automatique des pages va vous renvoyer constamment en début d’article alors que vous êtes en pleine lecture. Pour des personnes qui vocalisent les pages via un lecteur d’écran, cela rendra très pénible la consultation de l’article. Il ne faut donc pas rafraîchir automatiquement vos pages.
     
  • Faciliter l’accès aux contenus :
    Exemple : la présence d’un moteur de recherche va aider à trouver les contenus sans avoir à passer par des menus dynamiques éventuellement difficiles à consulter, ni avoir à explorer le site page après page.

Si vous décidez de faire en sorte que vos maquettes graphiques et intégrations ne contiennent pas de défauts susceptibles de dégrader l’accessibilité du site dans lequel ils seront utilisés, vous allez devoir respecter un certain nombre de critères. Le respect de ces critères ne garantira pas que le site en question sera visible partout et par tout le monde, mais au moins, vous aurez fait le maximum pour que ce soit le cas, et vous n’aurez pas introduit de défaut par le manque de qualité de votre travail.

Voyons un peu comment il faut procéder.

Utiliser les standards internationaux ou une méthode d’application ?

Votre objectif final va être la mise en conformité de vos développements aux standards internationaux WCAG. A cet effet, vous pouvez évidemment décider d’utiliser les standards internationaux eux-mêmes. Voici la traduction française de ces standards.

Regardez le sommaire.
Les standards sont structurés en 4 principes génériques (des contenus perceptibles, compréhensibles, utilisables et robustes), puis déclinés sous forme de règles. À la lecture de ces règles, vous devez comprendre à peu près de quoi ces standards parlent. Mais cela semble immédiatement assez abstrait s’il s’agit à présent d’améliorer directement des maquettes graphiques ou des intégrations HTML/CSS, n’est-ce pas ?

C’est pour cette raison qu’il existe des méthodes d’application, qui rendent la mise en conformité plus simple grâce à la mise à disposition de tests unitaires.

En France, ces méthodes d’applications sont le RGAA et AccessiWeb ; au Québec, c’est la norme SGQRI-008. Voici quelques liens à visiter :

  • Le RGAA V2.2.1 (obligatoire pour les sites publics) : 187 tests, classés sous 12 thématiques.
  • AccessiWeb (proposé par l’association braillenet, associé à un groupe de travail et à un système de labellisation) : 300 tests.

Ces deux méthodes d’application reposent sur des listes de tests (ou de critères). Si le nombre de critères RGAA et Accessiweb est différent, ce sont bien les mêmes objectifs qui sont visés, à savoir le respect des standards internationaux (WCAG).
Certains de ces critères sont techniques, d’autres ergonomiques et d’autres éditoriaux. Certains sont simples, d’autres sont complexes. Quand vous serez un ninja de l’accessibilité, vous maîtriserez le pourquoi de chaque règle. Mais pour l’instant, contentons-nous de les examiner.

Prendre en compte tout au long du processus

Les méthodes d’applications nous invitent à évaluer le résultat obtenu, mais ce n’est pas forcément le meilleur moyen d’y arriver.

En effet, vous risquez de commencer en effectuant le contrôle de votre site en fin de fabrication pour vous assurer de votre conformité à votre objectif d’accessibilité, pour voir ce qui ne conviendrait pas. Au vu des résultats de cette évaluation, vous allez rapidement vous rendre compte qu’il est très coûteux de corriger les erreurs liées à certains critères. En pratique, cela conduit généralement à dire : « c’est trop cher, je prendrai cela en compte lors de ma prochaine refonte ».

Par exemple, si vous vous rendez compte lors de l’analyse finale d’un site déjà en ligne que les contrastes sont insuffisants, cela risque de vous conduire à revenir sur le design, les images,… bref, des éléments qui sont censés être validés depuis bien longtemps.

Voilà pourquoi il est fort conseillé de prendre en compte l’accessibilité bien avant, c’est à dire tout au long du processus de production.

Dès l’étape du cahier des charges et des spécifications, de grosses erreurs peuvent en effet être commises :

  • Le choix d’une technologie fondamentalement inaccessible ou très chère à rendre accessible.
  • le choix d’une architecture de l’information ou de principes ergonomiques en dépit du bon sens qui rendront de toute façon l’accès aux contenus très compliqués.
  • Le choix d’un système de gestion de contenu (CMS) qui ne permettra pas aux rédacteurs quotidiens du site de produire des contenus accessibles.

Par la suite, les phases de prototypage et de design nécessitent également de prendre en compte certains critères. Ce sera le cas des contrastes, par exemple, mais aussi de nombreux éléments ergonomiques (signalement des liens, des menus, liens d’évitement, zonage des formulaires).

La phase d’intégration HTML/CSS est absolument fondamentale, car c’est de ce niveau que va dépendre une très grande partie de l’accessibilité technique.

Pour finir, la phase d’ajout des contenus n’est pas moins fondamentale, au contraire : en fonction du CMS choisi et de la façon dont il sera configuré (via ses extensions, notamment), il sera plus ou moins possible pour les rédacteurs de rendre les contenus accessibles. Mais encore faudra-t-il qu’ils aient été au moins sensibilisé à cet aspect souvent méconnu de leur travail.

Il est maintenant temps de regarder vos maquettes graphiques, vos intégrations HTML/CSS, puis de les corriger, de les améliorer, de comprendre. Et cela tombe bien en France, d’excellentes ressources documentaires sont apparues depuis peu. Nous allons notamment citer les notices AcceDeWeb, produites sous licence ouverte par la société Atalan ; elles vont particulièrement vous intéresser pour les phases de design et d’intégration.

Détecter les erreurs et les risques d’erreur

Je m’occupe depuis plusieurs années d’un projet appelé Opquast (Open Quality Standards). Dans le cadre de ce projet, Aurélien Levy a lancé la conception de deux listes de critères appelées « Steps ». Ces checklists ne rendront pas votre site totalement accessible ni conforme aux normes WCAG. Elles permettront en revanche de traiter un socle vital d’erreurs et risques d’erreurs techniques (mais pas éditoriales ou ergonomiques) :

  • « First step » permet de détecter une série d’erreurs sur une intégration ou un site. Exemple : il ne faut pas utiliser l’attribut bgsound ;
  • « Second step » permet de détecter des risques d’erreurs d’accessibilité.
    Exemple : si vous ne faites pas un target blank, votre contenu ne sera pas forcément inaccessible, mais si vous ne mentionnez pas l’ouverture en nouvelle fenêtre, ce sera le cas.

Ces deux checklists sont disponibles en téléchargement et sous licence libre. Et j’ai encore une meilleure nouvelle : vous pouvez télécharger l’extension Opquast desktop pour firefox qui va vous permettre de tester directement vos pages selon les critères des checklists Steps.

Pour aller plus loin

Pour bien comprendre l’accessibilité, vous pouvez acheter le récent livre d’Armony Altinier sur l’accessibilité Web.

Vous pouvez également consulter le site OpenWeb.eu.org, qui parle d’accessibilité dans de nombreux articles.

Enfin, dans votre apprentissage de l’accessibilité, vous voudrez peut-être à un moment vous intéresser à d’autres aspects de la qualité Web. Dans ce cas, vous pouvez également consulter les différentes briques du projet Opquast. Vous y trouverez différentes checklists en licence libre, un outil de management de la qualité et de l’accessibilité Web en SaaS (Opquast reporting) et Opquast desktop, l’extension open source pour firefox déjà signalée plus haut.

Maintenant, c’est à vous ! Avez-vous déjà pris en compte l’accessibilité dans vos projets, Web ou non d’ailleurs ? Connaissez-vous d’autres ressources utiles ? Partagez votre expérience !

A propos de l'auteur : Elie Sloïm

Élie Sloïm est Président de la société Temesis, spécialisée sur la qualité et l'accessibilité des sites Internet. Il dirige depuis 2004 le projet Opquast. Il est également consultant, formateur et conférencier, et assure la direction actuelle du projet OpenWeb. Vous pouvez le suivre sur Twitter.

  • http://twitter.com/verobouvier Véronique Bouvier

    Bonjour
    Le livre d’Armony Altinier est vraiment passionnant. Pour moi qui débute dans l’accessibilité c’est une mine d’or. Je le conseille à tous les pros du web, particulièrement les chefs de projets et les intégrateurs, car je pense que cette thématique est cruciale dès les prémices d’un projet.
    Merci pour cet article :)

Live Tweet

Dans le Blog

Newsletter

Vous souhaitez être tenu au courant des dernières nouvelles concernant le WDfriday, événements, conférences, barcamps, etc… ?

N'hésitez pas à vous inscrire à notre newsletter !