Accessibilité bureaucratique

Traductions : Bureaucratic accessibility

28 février,
par Romy Têtue

Mots-clefs associés à cet article :

Mais pourquoi reste-t-il si difficile d’avoir des alternatives textuelles aux images ? Encore faudrait-il savoir faire un site web…

En matière d’accessibilité, vous avez tous et toutes entendu parler du besoin de fournir une alternative textuelle aux images. C’est très loin d’être suffisant pour rendre un site web accessible, mais c’est l’exemple qui revient toujours à ce sujet. Parce que c’est le plus simple à comprendre et à expliquer.

Pour rappel, le premier critère d’accessibilité — depuis des années, quelque soit le référentiel en vigueur — exige que chaque image soit pourvue d’un attribut HTML « alt ». C’est extrêmement simple. Ça fait pouffer les dev tellement c’est facile.

Le deuxième critère concerne le contenu de cet attribut, dit « alternative textuelle » et le troisième, s’inquiète que celle-ci soit pertinente. Ça se complique un peu. C’est sémantique. Les dev rigolent moins, parce que la sémantique c’est pas trop leur truc : tout dépend de ce que raconte le reste de la page, faut lire, comprendre (ou demander aux auteur·e·s). Bref, comme souvent en accessibilité, la technique compte, beaucoup, mais pas seulement.

Sur les 133 critères obligatoires, ces trois premiers, qui sont parmi les plus simples, relativement à la complexité des autres, demeurent pourtant copieusement maltraités de par le Web. Pourquoi ?

Voici la réalité à laquelle je suis confrontée, en tant que formatrice à l’accessibilité web :

— Rendre nos sites web accessibles est une obligation et une priorité pour nous. Nous souhaitons obtenir le label d’accessibilité d’ici la fin de l’année. Nous avons donc besoin de former nos équipes pour progresser rapidement.
— D’accord. Quels sont les profils concernés ?
— Les contributeurs, les développeurs et surtout les chefs de projet.
— Très bien ! former tous les intervenants de la chaîne de production est une très bonne approche. Quels sont les besoins spécifiques pour vos publications web ?
— Apprendre à faire des PDF accessibles.
— Des PDF ? Ah. On va voir ce qu’on peut faire. Quoi d’autre ?
— Les mails ! Comment faire des mails accessibles ? Comment les mettre en page ? Parce qu’on a souvent des retours comme quoi c’est illisible…
— Les mails… euh… OK, je note. Et pour vos sites web ?
— …
— Prenons un exemple : pour les alternatives textuelles aux images…
— Ah oui ! Ça nous savons faire ! On les renseigne déjà, dans Word. Pour les personnes aveugles.
— Word ? Est-ce le nom de votre CMS ?
— Non, voyons : Microsoft Word, le traitement de texte !
— Oups ! Si je comprends bien, vous préparez vos contenus dans Word. Comment sont-ils ensuite mis en ligne ?
— Nous utilisons plusieurs outils…
— De type CMS ? avec éditeur WYSIWYG ?
— Oui, entre autre… Pourquoi ?
— Les personnes qui rédigent dans ces outils agissent sur l’accessibilité du site final. S’agit-il bien là des profils « contributeurs » que vous souhaitez former ?
— Oui, mais attention, il ne rédigent pas. Eux ne font que saisir. Tout est rédigé avant.
— Avant ? Comment ça ?
— Par nos rédacteurs. Au service communication.
— Ah… Dans ce cas, davantage que les opérateurs de saisie, il faudrait plutôt former les « rédacteurs », bref celleux qui produisent les contenus.
— Mais pourquoi ?
— Reprenons l’exemple des alternatives d’images : celui qui la rédige doit savoir comment le faire de façon pertinente, tandis celui qui saisit doit s’assurer de sa présence au bon endroit, dans l’attribut alt…
— Ah non, ne leur parlez pas d’attribut alt ! Attention à ne pas les effrayer avec du code.
— D’accord, je note. Une formation pour savoir rédiger et contribuer de façon accessible. Sans code.
— Oui. Pour réaliser des documents Word accessibles. Sans oublier Excel, pour les tableaux !


webAgencyFAIL : [fichier] — Logo.doc

J’ai plus de 15 ans d’expérience web et on me demande de faire… de la bureautique ? J’aimerais que soit une blague, mais non. Ils y tiennent, à l’accessibilité de leurs documents bureautiques, Word, Excel et PDF. Or toute experte que je sois, mon domaine est le Web et je suis démunie face aux documents bureautiques. Et, soyons honnête : ça ne m’intéresse pas. Puissamment pas. Ce n’est pas mon métier. J’ignore l’affront et je poursuis.

— Euh… soit. Mais il s’agit de documents bureautiques. Les publiez-vous en ligne tels quels ?
— Uniquement les PDF, mais pour les reste, non : ce sont des documents internes.
— Dans ce cas, à part les PDF, ça n’a aucune incidence sur l’accessibilité de vos sites web.
— Mais… les alternatives aux images ?
— Reprenons : le rédacteur la rédige, dans Word, puis le contributeur la saisit, dans un CMS. Mais qui s’occupe de la coder, dans l’attribut alt ? À quel moment vos contenus deviennent des pages web ? Comment sont fabriqués vos sites web ?
— Je ne sais pas trop… Est-ce important ?
— Oui, très. L’essentiel de l’accessibilité d’un site web dépend de sa fabrication, c’est-à-dire de son codage, disons à 60 % environ. J’ai donc besoin d’identifier quand et comment a lieu le développement web front et quels sont les personnes qui interviennent en cela. Car c’est eux qu’il faut former. Essentiellement. Qui s’occupe de coder en HTML ? Est-ce que vos développeurs…
— Ah non, il ne faudra pas leur parler de HTML !
— Ils ne codent pas en HTML ?
— Non, ce sont des développeurs. Nous souhaitons seulement qu’ils soient formés au RGAA.
— Justement… ce référentiel s’exprime beaucoup en HTML. Ce sera difficile d’en faire abstraction.

Voici la situation : d’un côté nous disposons d’un référentiel d’accessibilité formulé pour le Web — c’est-à-dire avec des critères parlant de balises et attributs HTML, de CSS, de JavaScript, bref des langages qui font le Web, logique non ? — pour, de l’autre côté, les commanditaires qui doivent le respecter, mais ne veulent pas entendre parler des langages constitutifs des pages web, lesquelles ne sont pas des PDF, encore moins des documents Microsoft. Autant essayer de construire une maison avec des moules à cupcakes.

— Je ne comprends pas…
— Les sites web sont avant tout fait de HTML. Beaucoup de problèmes d’accessibilité sont dus à un mauvais codage. Si vous avez l’ambition de labelliser vos sites web, c’est bien aux langages HTML, CSS et JS accessibles qu’il faut former vos équipes.
— Mais ce n’est pas le rôle de nos développeurs !
— Dans ce cas inutile de les former à l’accessibilité. Mais alors, qui produit le HTML chez vous ?
— Ce n’est pas nous, mais notre agence digitale. Elle fournit les maquettes graphiques. Au format HTML.
— Ah… euh… d’accord. Et vous n’intervenez pas sur le code HTML ? Du tout ?
— Non. Tout se fait en externe.
— Et vos prestataires sont-ils spécialisés en accessibilité ?
— Pas que je sache…
— Est-il prévu qu’ils soient formés ?
— Euh… non… pourquoi ?
— Parce que si vous souhaitez que vos sites soient accessibles, et à plus forte raison labellisés, ils faut les fabriquer de façon accessible, c’est-à-dire les confier à des prestataires compétents en cela. C’est eux qui doivent être formés. Prioritairement.
— Il faudra faire sans. Et pour nos formations ?
— Bin… c’est-à-dire… Vous former à l’accessibilité des mails, des PDF et autres documents bureautiques, n’a quasi pas d’incidence sur l’accessibilité de vos sites web. Ces formations ne serviront pas à grand chose, pour atteindre l’objectif que vous vous êtes fixé.
— Pourquoi ?
— Mail, PDF, Word… ce n’est pas du Web ! La seule chose qui compte, en accessibilité web, pour reprendre notre exemple, c’est le contenu de l’attribut alt, dans la page web, celle qui s’affiche dans le navigateur de l’internaute. Si vous le mettez ailleurs, dans Word ou autre, ça ne sert à rien…
— Mais nous obtiendrons quand même le label ?

Encore faudrait-il savoir faire un site web. Car la plus grande difficulté en accessibilité web, n’est pas tant l’accessibilité elle-même, que le mot accolé, « web », qui est lui abyssalement méconnu. Voilà la réalité : celleux qui sont responsables des sites web, commanditaires, chefs de projets, éditeurs… ne connaissent que les documents bureautiques et plus précisément Microsoft comme horizon indépassable. Ils font tout avec ça. Tout. Y compris leurs sites web.


webAgencyFAIL : [sic] — Les images sur le site, il faut les mettre en PDF ?

Je ne sais par quel miracle, dans ces conditions, leurs sites arrivent un beau jour en ligne. En fait, il y a fort à parier que personne ne sache vraiment. Le Web est ici une patate chaude qu’on se refile en fermant les yeux.

Au final, histoire de prouver s’être soucié d’accessibilité, et pour pouvoir afficher fièrement un label malgré tout, il sera fait appel à un « expert » — parce qu’au royaume des bureaucrates, les experts sont rois — qui va s’esquinter à recenser toutes les occurrences d’attribut alt manquant pour les consigner scrupuleusement, non pas dans un outil de bug tracking ou autre truc approprié au développement, mais dans un fichier, je vous le donne en mille, Word ou Excel, pompeusement appelé « rapport d’audit ». À défaut d’être efficace, ça fait sérieux.

{#TITRE,#URL_ARTICLE,#INTRODUCTION}

Vos commentaires

  • Le 28 février à 09:36, par Le Monolecte En réponse à : Accessibilité bureaucratique

    Oui, je commence à comprendre des choses quant à certaines difficultés de communication avec beaucoup de mes interlocuteurs…

  • Le 28 février à 10:09, par Tomek En réponse à : Accessibilité bureaucratique

    J’ai dû tomber pour l’instant sur des personnes un peu moins « microsoftisées » que la moyenne, je n’ai pas eu ces retours quand je les forme sur l’édition au sein du CMS et sur l’accessibilité des contributions pour leur site web.

  • Le 28 février à 11:24, par Pierrot En réponse à : Accessibilité bureaucratique

    Bonjour,
    Le fait qu’aucune image de cette page n’ait d’attribut « alt » rempli, c’est à titre d’exemple ?
    Ok je sors :-)

    Enfin pour être exact on a un « logo.doc » quelque part et un « Les images sur le site, il faut les mettre en PDF ? » dont je ne suis pas sûr de la pertinence sémantique ... et aussi, doubler le « alt » avec un « title » n’est pas forcément considéré comme une bonne chose, les malvoyants finissent par être exaspérés du doublement voire triplement des textes explicatifs pour un contenu.

    Pierre.

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Raccourcis : {{gras}} {italique} -liste [bla->url] <q> <quote> <code>.

Suivre les commentaires : RSS 2.0 | Atom