Le Séminaire Accessiweb de janvier 2005 portait principalement sur l’incitation à faire des sites accessibles, et l’approche légale adoptée dans différents pays d’Europe : les lois déjà en place, les démarches de fédération, les bonnes pratiques appliquées ici ou là. Vu à travers mon oeil de développeur web, voilà un résumé de la journée.
Définir l’accessibilité : pas si évident
Alistair Garrison montre qu’il n’existe pas qu’une définition de l’accessibilité, et que selon le public à qui la question est posée, la définition peut varier grandement. J’ai fait le test il y a peu avec une collègue en contrat de qualification dans nos services [1], pour elle l’accessibilité est un synonyme d’interopérabilité. Nous souffrons donc d’une myopie de praticiens : nous oublions que tout le monde n’a pas un « référentiel » commun quand on parle d’une des bases de notre activité.
État des lieux de quatre pays européens
Barry McMullin a tenté d’établir une étude comparative de l’accessibilité de plusieurs pays d’Europe. Les résultats montrent qu’il n’existe pas de différences significatives entre les états, soit parce qu’ils ont été mal choisis (le panel est très restreint et ne considère que des pays proches culturellement, Irlande, Royaume-Uni, Allemagne et France), soit parce que le web non accessible est une réalité que ce genre d’étude met bien en avant. Pour lui, le niveau AA aux WCAG est le niveau minimum qu’on peut (doit ?) attendre d’un site professionnel.
Accessibilité et standards : gains cumulés
Gerrit Berkouwer résume avec un certain nombre de « phrases choc » ce qu’il retient du passage aux standards et à un code accessible du site du Ministère de la Santé des Pays-Bas : des visiteurs satisfaits, une meilleure indexation dans les moteurs de recherche, une meilleure vitesse d’affichage, le développement et la maintenance de site sont facilités, l’hébergement coûte moins cher (bande passante réduite), la qualification se fait plus aisément. Pour le citer : « less code, less costs, less chaos, less stress ».
Jean-Louis Carves, d’IBM, a quant à lui montré, exemples à l’appui, que la standardisation du code des pages, non seulement les a rendues naturellement plus accessibles, mais a permis des économies non négligeables : le poids des pages a baissé de 20 à 25%, et sachant que 45% du budget informatique d’IBM portent sur les coûts liés au réseau, cette baisse est loin d’être négligeable.
Gain indirect : des pages plus rapides à afficher font des salariés plus efficaces. Une enquête interne auprès des utilisateurs fait ressortir qu’ils estiment gagner entre un quart d’heure et une heure par semaine avec le nouveau portail intranet [2].
J’ai été frappé de noter qu’à un précédent séminaire Accessiweb Tristan Nitot et quelques autres (dont j’étais évidemment, sans oublier Élie Sloïm) ne tarissaient pas de remarques insistantes sur la conformité du code, et qu’à l’époque cette notion ne semblait pas du tout aussi importante qu’aujourd’hui. J’ai vraiment l’impression que le lien entre code conforme et accessibilité a fait son chemin dans la tête des décideurs (et des intervenants), et c’est une très bonne chose.
Diverses méthodes d’incitation
Quelques autres intervenants intéressants : Donal Rice, de la National Disability Authority (Irlande) a bien montré que la sanction légale n’est pas suffisante, et qu’il peut être intéressant de motiver les sites par un prix d’excellence. Dans le contexte actuel de développement durable c’est tout-à-fait bien vu.
L’Espagne quant à elle a institué la notion d’interfaces et d’outils « sans barrières », afin que tous les utilisateurs puissent s’en servir normalement quel que soit leur handicap.
L’Autriche, la Suède et la Belgique fournissent de leur côté une assistance technique aux sites officiels, les deux premières par une centralisation de toute l’information administrative (et donc une simplification de la recherche), la dernière (la Belgique) par un site d’aide aux développeurs web : Marc Walraven, de la société ASCII, explique que le but de cette démarche est de permettre une véritable assurance qualité sur le long terme.
De plus, la Suède a publié des recommandations pour les sites publics, livret constitué de neuf chapitres, chacun ciblé sur un public différent (décideur, développeur, etc), et fournissant des listes de points à vérifier (« checklist ») pour les marchés publics (le Danemark présente aussi un « kit de marchés publics » du même ordre).
Fédération des pratiques à l’échelle européenne
Pour terminer, Pierre Guillou (Braillenet) a présenté la nécessité d’un critère européen commun, une « eAccessibility Mark » (marque de qualité pour l’accessibilité numérique), d’où la création du projet Support-EAM. Pour ma part, je ne comprends toujours pas la création de ce nouveau label, EAM, alors que le consortium EuroAccessibility travaillait justement à l’élaboration d’une labélisation commune [3].
Enfin, Per Blixt, de la Commission Européenne, a expliqué que l’année prochaine verra se faire une enquête législative, en vue de fédérer trois points-clés de la politique européenne numérique (« eEuropean policy ») :
- des cahiers des charges harmonisés pour les marchés publics
- une certification commune
- une généralisation à l’ensemble de l’Europe des lois existant déjà dans certains pays
Le but final de cette harmonisation est bien sûr l’intégration complète des handicapés dans la société numérique (ou « eInclusion »).
Conclusion : de l’aspect légal à l’aspect technique, que manque-t-il ?
J’ai été frappé en cours de journée d’une intervention dans l’assistance de Helle Bjarnø (membre de EAC), qui pose la redoutable mais très pertinente question de l’efficacité de tous les efforts déployés jusqu’ici dans le domaine de l’accessibilité. Après toutes ces années pendant lesquelles les WCAG ont été disponibles, après la mise en place de tous ces moyens légaux et incitatifs, pourquoi les sites web restent-ils si majoritairement inaccessibles ?
J’en ai discuté avec elle, et une des réponses que j’évoque à chaque fois (pour ceux qui me connaissent, vous allez retrouver un de mes plus vieux chevaux de bataille) a directement à voir avec l’ingénierie web client : c’est le manque de professionnalisme des développeurs web côté client (ce qu’on résume souvent au « design » ou au HTML).
Chez mon employeur (comme dans nombre de grandes sociétés sans doute), le web côté client est considéré comme facile et non stratégique :
- facile, parce que les outils WYSIWYG du marché donnent l’impression que c’est à la portée de tout le monde de monter une page. Oui, c’est à la portée de tout le monde de taper du contenu et de le voir presque par magie transformé en HTML. Mais c’est tout aussi réducteur que de croire que les logiciels grand public de mise en page peuvent rivaliser avec le talent et le matériel des graphistes des agences de communication.
- non stratégique au sens où il ne sert à rien de concentrer des forces de travail importantes sur l’aspect présentationnel d’un site (et l’accessibilité n’est bien souvent perçue que via la couche présentationnelle, du moins c’est l’impression que j’ai eue jusqu’ici). On préfère mettre la force de production sur le développement « lourd » (côté serveur), et laisser la couche de présentation à une agence de communication auprès de laquelle on aura externalisé le processus de design.
Or on a bien constaté lors d’un gros projet auquel j’ai participé en 2004 pendant quatre mois que le meilleur travail d’intégration par les développeurs « lourds » des consignes relatives à l’accessibilité a été réalisé par l’équipe avec laquelle nous avions un contact direct (nous sommes dans les mêmes locaux). Les deux couches (applicative et présentationnelle) sont donc étroitement liées dans des processus de développement web, et nécessitent un accompagnement de tous les instants sous peine de risquer une déperdition importante de la qualité des pages produites.
Cette fausse perception du design web induit que les personnes qui font ce métier n’y restent pas longtemps. Par exemple, je me suis entendu dire en arrivant dans mon poste actuel que dans mon nouvel environnement j’allais pouvoir apprendre Java et « un vrai métier » (par opposition à celui que j’avais déjà). Je n’incrimine évidemment pas l’auteur de cette phrase assassine : elle n’est que le révélateur de la méconnaissance par les instances managériales de notre domaine d’activité.
Pire encore, le montage de pages web est bien souvent réduit à un travail de stagiaire (pour les raisons évoquées plus haut : c’est facile et non-stratégique). Au final, le résultat n’a pas bénéficié de suffisamment d’expérience/expertise, et le stagiaire, une fois qu’il a acquis les rudiments, arrive assez vite à la fin de son stage. Tout reste donc à refaire avec le suivant.
Pour moi, si nous voulons inscrire la qualité du code produit dans un processus d’assurance qualité durable, il ne suffit pas de se conformer à des labels, ou d’atteindre le zéro faute sur un outil de validation, mais bien de travailler sur le long terme en valorisant ces métiers dans les référentiels d’activité. Il faut changer, définitivement, l’image de notre métier : en un mot, le professionnaliser.
