Accessibilité : définir les limites de la démarche
Par Victor Brito, le vendredi 26 février 2010, à 22h34 - Catégorie Accessibilité - Lien permanent
Accessibilité : où s'arrêter ? Tel est l'intitulé du dernier billet du blog de Temesis, un billet rédigé à quatre mains par Laurent Denis et Élie Sloïm (à moins de l'avoir été avec une seule main chacun, l'autre étant crispée sur la souris
), qui discutent de l'accessibilité, plus précisément de la question de savoir où s'arrêter quand on prend en compte l'accessibilité dans un projet Web.
Cette discussion m'inspire les propos suivants.
Ne pas se reposer sur ses lauriers
Il y a de ces projets qui prennent l'accessibilité comme un saint Graal, objet d'un formidable potentiel de communication ou de légitimité
, déclare Laurent Denis. Autrement dit, certains acteurs impliqués dans des projets Web et soucieux de l'accessibilité du Web peuvent être tentés de considérer l'accessibilité comme un objectif à atteindre, un objectif relevant d'une sorte d'obsession telle qu'ils n'auront pas de cesse que la pleine accessibilité — ou, du moins, ce qu'ils considèrent comme le stade ultime qui leur fait dire que leur projet est 100 % accessible selon eux — soit atteinte. Et une fois le projet enfin considéré comme accessible, ils se reposent sur leurs lauriers : puisque l'objectif d'accessibilité est atteinte, il n'y a plus rien à faire.
Or, le fait de se reposer sur ses lauriers peut être une attitude à risque : une fois l'objectif d'accessibilité considérée comme atteinte, on n'est jamais à l'abri d'une imprudence au stade de la production ou de la maintenance du projet à l'origine d'une régression en termes d'accessibilité. Si l'obtention du label Accessiweb comporte une visite de contrôle obligatoire du site bénéficiaire un an après son obtention (sans oublier deux autres visites inopinées de même nature pendant la durée de validité du label, ainsi que le canal de plainte), ce n'est pas pour rien : un label de qualité se doit de prévenir toute régression en termes d'accessibilité qui pourrait se produire après l'effort de mise en conformité avec les critères d'Accessiweb (selon le niveau visé) consenti par le propriétaire du site et les prestataires qu'il a sollicités.
Viser l'objectif qui consiste à dire que ses contenus sont accessibles est un non-sens
: il est très difficile d'atteindre une accessibilité à 100 % et même les WCAG 2.0 préviennent que ses critères de succès de niveau AAA placent le confort maximal d'accessibilité à une barre trop haute pour que les perchistes de l'accessibilité les plus doués du moment puissent sauter sans la faire tomber, pour ainsi dire. En revanche, on peut s'appuyer sur les moyens de production pour établir une démarche d'accessibilité.
Les moyens de l'accessibilité et leurs limites
Plutôt que viser l'accessibilité comme une fin en soi risquant de compromettre l'efficacité de la communication autour de l'accessibilité, il vaut mieux s'interroger sur les moyens de production à sa disposition pour y parvenir, certes, mais surtout pour établir une démarche d'accessibilité, qui peut être progressive, mais continue. Ces moyens existent et sont documentés aussi bien par les techniques des WCAG 2.0 que par les méthodologies d'évaluation employées par les référentiels qui s'appuient sur les WCAG 2.0.
Ces moyens de production, utilisés à bon escient, permettent l'accessibilité. Toutefois, s'ils peuvent garantir une démarche minimale, voire décente, d'accessibilité, ils ne peuvent garantir un confort d'accessibilité extrême (ou l'accessibilité à 100 % si vous préférez).
Prenons le cas des médias temporels (vidéos, bandes sonores, succession d'images ou de photos en mouvement ou en séquence, par exemple) : les WCAG 2.0 exigent, par exemple, la présence, si nécessaire, de sous-titres synchronisés pour les médias temporels comportant du contenu audio, cette exigence s'appliquant aux contenus audio pré-enregistrés dès le niveau A et aux contenus audio diffusés en direct à partir du niveau AA. Pour une vidéo où l'on entend des personnes ou des voix hors champ parler, il y a moyen d'y ajouter des sous-titres sans difficulté lorsque la vidéo a été préalablement enregistrée et montée en studio : il suffit de noter tout ce qui s'y dit, de formater la transcription des paroles et de synchroniser, le SMIL facilitant la tâche ; en revanche, c'est beaucoup plus difficile lorsqu'il s'agit de sous-titrer un entretien vidéo en direct : cela demande un investissement considérable en moyens financiers et en matériel de pointe tels qu'à l'heure actuelle, seuls les grands groupes de l'audiovisuel peuvent le faire. Voilà donc un exemple de moyen de production dont les limites peuvent compromettre une accessibilité accrue.
Faire du bon Web et viser l'efficacité
Gilles Chagnon, en commentant le billet évoqué, dit, entre autres : Si je devais produire des contenus respectant systématiquement à la lettre tous les normes et critères d'accessibilité, je perdrais grandement en efficacité, au détriment de l'ensemble de mon travail.
Cela ne veut pas dire, pour autant, qu'il faille se moquer de l'accessibilité, bien au contraire. L'essentiel est de considérer l'esprit de l'accessibilité, non seulement en tâchant de comprendre les enjeux des points sur lesquels s'attardent les critères de succès des WCAG 2.0, mais aussi en cherchant à contourner les limites des moyens de production, en procédant autrement. Ne peut-on pas, faute de moyens financiers et matériels, sous-titrer une vidéo diffusée en direct ? On ne la diffuse pas en direct et l'on profite de son montage pour la sous-titrer tranquillement, ce qui permet de proposer du contenu efficacement accessible : les utilisateurs sourds ou malentendants y gagneront, ainsi ceux qui n'ont pas de haut-parleurs ou utilisent un ordinateur dont la carte son n'est pas au meilleur de sa forme, sans qu'on ait eu à trop se sacrifier le portefeuille et le matériel pour un résultat moins garanti.
Un autre point où l'accessibilité efficace peut entrer en jeu est la maîtrise de l'environnement technique de l'utilisateur. Le JavaScript, le Flash, voire les CSS, sont des technologies facultatives, en ce sens qu'elles peuvent être désactivées, ignorées ou mal prises en charge, ce qui signifie que le contenu du Web doit être accessible, lisible et compréhensible sans elles, tout en fournissant des alternatives aux fonctionnalités similaires à celles proposées, notamment, par le JavaScript ou le Flash. Dans l'absolu, cette règle est, et demeure, à observer. Mais, si le projet Web sur lequel on intervient cible un environnement technique maîtrisé, on peut y déroger sans pour autant perdre forcément en accessibilité : une application Intranet dont on sait avec certitude qu'elle sera utilisée sur des postes où JavaScript et Flash sont obligatoirement activés et que les utilisateurs de ladite application ne peuvent les désactiver (faute de droits sur leurs machines sur la décision d'un administrateur réseau, par exemple) peut se passer d'alternative au JavaScript et au Flash, d'autant moins qu'on peut produire du JavaScript, et même du Flash, accessible ; et si les utilisateurs de cette application Intranet peuvent tous lire un document PDF, sachez qu'on peut également produire des documents PDF aussi accessibles qu'une simple page Web.
Enfin, penser à l'accessibilité, c'est très bien ; mais, il ne faut pas perdre de vue que l'accessibilité fait partie d'un ensemble de bonnes pratiques qui font un Web de qualité. Cherchez à faire du bon Web
, résume Laurent Denis.
Cela dit, pour la qualité Web en général, je préfère laisser la parole à Laurent Denis et, surtout, à Élie Sloïm, qui auraient pu baliser leur dialogue dans leur billet sous forme de liste de définitions. 
