cbsch.net

Le menu accessible, qu'est-ce que c'est?

Par ce terme, j'entends tout type de menu qui s'adresse spécifiquement à des internautes souffrant de handicaps. Ceux que l'on rencontre le plus fréquemment proposent généralement les options suivantes:

• taille du texte
• lien pour accéder au contenu
• lien pour aller au menu
• feuille de style alternative plus contrastée
• désactivation de la feuille de style

Les web designers proposent généralement ce menu en haut de leur site, parfois inclus dans le bandeau, parfois à droite, parfois à gauche. Par contre, la constante est son apparition en haut de la page. Graphiquement parlant, cet élément est très fréquemment isolé du reste du contenu de la page: il est souvent inclus sous la forme d'une bande horizontale grise au sommet de la page, ou parfois comme un petit menu se découpant sur la couleur de fond du bandeau. La plupart de ces menus sont de petite taille (de dix à douze points) et se font discrets en termes de graphisme.

Le menu accessible: buts et fondements.

La pratique consistant à procurer un menu accessible a émergé il y a quelques années avec les premières applications des guidelines de la WAI. En lisant les "core techniques", et notamment leur quatrième point, on comprend un des fondements de ce type de menus: fournir une navigation qui satisfasse à la fois l'homogénéité du site et sa structure tout en fournissant une alternative aux personnes ne pouvant pas visualiser la page telle quelle (cf. le point 3 des WCAG 1.0). Certains éléments spécifiques (comme la taille de la police de caractères employée, par exemple) répondent à d'autres recommandations, mais l'esprit reste le même: en une navigation, répondre à différentes bonnes pratiques.

Pour résumer, les buts recherchés en créant des menus accessibles sont les suivants:

• fournir une alternative à la page (possibilité de la visionner sans CSS, sans JavaScript, en texte pur, etc.)
• contourner le problème des unités relatives
• proposer des liens d'accès rapide aux différentes sections de la page
• être le plus rapidement et le plus facilement accessible
• accessoirement, montrer que son site a été "bien pensé": les voyant trouvant une telle navigation ont tendance à surestimer les capacités du webdesigner

Comment mieux faire?

Comme je le montrerai ci-dessous, certains problèmes demeurent, et un simple menu en haut de page pose autant de problèmes qu'il en résout. Je vais donc commencer par énumérer ceux-ci, puis proposer des solutions techniques faciles à mettre en oeuvre. Celles-ci proposent d'aborder le problème sous un angle différent, en faisant disparaître certains des défauts du menu accessible tel qu'il est pratiqué. Car, trop souvent, l'intégration de ces menus part d'une bonne intention, mais manque cruellement ses buts. Je vais mettre en lumière quelques-uns de ses problèmes: place du menu dans le code et graphiquement, adaptation de la taille des polices et accès au contenu et au menu.

Une affaire d'audience.

Très fréquemment, les développeurs élaborant un site internet auront tendance à inclure le menu accessible d'une manière logique, "là où il va apparaître". Pourtant, c'est là la plus funeste erreur à ne pas commettre. En effet, l'internaute aveugle, en arrivant sur la page, sera confronté à trois cas de figures: il navigue soit par niveau de titre, soit par lien, soit de manière classique en écoutant la page du début à la fin. Dans le premier cas, le menu accessible sera simplement ignoré, à moins qu'on ne lui ait adjoint un niveau de titre (h2, de préférence, car la navigation dépend logiquement du titre de la page en h1). Du coup, l'aveugle peut perdre le bénéfice des lien "aller au contenu" et "aller au menu". Dans le deuxième cas, l'aveugle va systématiquement avoir des liens redondants qui vont être lus en premier à chaque page appelée. Inutile de dire qu'il est particulièrement pénible de devoir appuyer plusieurs fois sur la touche de tabulation pour passer des liens qui ne le concernent pas (agrandir la police de caractère ou changer de feuille de style n'est pas déterminant pour un aveugle). Dans le troisième cas, enfin, l'internaute aveugle va devoir écouter avant chaque page ou article un menu répétitif, dont la moitié des options sont inutilisables par lui. Pour ceux parmi vous qui ont déjà écouté une page, il y a de quoi s'énerver assez rapidement et quitter le site en question.

Le premier problème d'une navigation accessible est donc celui de l'amalgame: on tente de pallier plusieurs défauts d'accessibilité qui n'ont rien de commun en les groupant au sein d'une même navigation. Pourtant, les audiences visées sont radicalement différentes: les aveugles, d'une part, et les autres utilisateurs de l'autre. Il n'est pas possible de conjuguer les deux: tandis que l'aveugle sera agacé par des répétitions dont il n'a cure, les autres l'internautes auront sous les yeux un menu redondant et sans aucune option véritablement utile (voir ci-dessous pour les options de taille de polices et d'accès rapide).

Comment coder un menu accessible?

Le premier problème posé par ce type de menus est donc la place à lui accorder dans le code. Personnellement, j'ai tendance à pratiquer de la sorte pour concevoir un menu accessible spécifique aux aveugles:

• insérer une navigation masquée (avec la valeur hidden de l'attribut overflow) qui ne propose que les options pour les aveugles (aller au menu, au contenu et, optionnellement, à l'accueil)
• placer cette navigation après le titre de la page et avant tout autre élément
• donner au menu un titre immédiatement inférieur à celui de la page (généralement h2, donc)

Par cette pratique, nous avons donc un menu:

• qui est masqué pour les internautes voyants
• qui est facilement indentifiable par un aveugle: il comporte un titre, et ses options sont peu nombreuses et pratiques
• dont la répétition n'est pas un handicap, puisqu'il permet facilement d'être ignoré lors de la lecture de la page
• débarrassé des options d'accessibilité qui s'adressent à des personnes mal voyantes par opposition aux aveugles

On me rétorquera que, du coup, les autres options fournies par le menu accessible disparaissent ou, pire encore, que certains mal voyants voudront avoir une option pour aller au contenu. Avant d'entrer dans ce débat, nous examinerons de plus près les autres options des menus accessibles généralement proposées par les sites, et la place qu'elles doivent occuper au sein du code.

Comme on l'a vu, les options qui s'adressent aux voyants devraient être séparées de celles pour les aveugles. Elles devraient toutefois de préférence apparaître tout en haut de la page et être exclues du menu qui s'adresse aux aveugles. La réponse à ce petit problème est simple: il suffit d'inclure la navigation accessible destinée aux voyants en bas de page, après les crédits, les liens de validation ou les sponsors. Placée là, elle ne sera presque jamais lu par les aveugles, tout en pouvant être placé en haut de la page (par une instruction du type position: absolute;).

Pour résumer, voici un code d'exemple pour un menu accessible spécifique aux aveugles:

h2, ul {
     height: 0;
     overflow: hidden;
     }

<h2>Navigation</h2>
<ul>
     <li>Accueil</li>
     <li>Accéder au contenu</li>
     <li>Accéder au menu</li>
</ul>

et un exemple d'un menu visible conçu pour les voyants

h2 {
     height: 0;
     overflow: hidden;
     }
ul {
     position: absolute;
     top: 0;
     }
li {
     display: inline;
     }

...ici prend place le pied de page...
<h2>Options</h2>
<ul>
     <li>Texte plus grand</li>
     <li>Texte plus petit</li>
     <li>Style contrasté</li>
</ul>

Taille des polices.

On trouve fréquemment ce type d'options sur les sites accessibles. Le but avoué est d'offrir un moyen simple de changer la taille des caractères. Toutefois, il s'agit aussi d'un biais pour contourner la question des unités relatives (point 3.4 des WCAG 1.0): en effet, ce type de mise en page est souvent très exigeant en termes de développement, et rebute plus d'un développeur (sans compter que, pour des raisons graphiques, un tel principe peut parfois poser de gros problèmes). Toutefois, il est indispensable de se demander à qui s'adresse un tel menu. En y répondant, nous verrons également qu'il est redondant et inutile.

L'option d'augmenter ou diminuer la taille des polices de caractère s'adresse:

• aux malvoyants
• aux personnes âgées ou qui souffrent de certains handicaps visuels précis
• aux personnes souffrant de petits soucis de contraste dans certains cas de figure

En fait, l'audience principale pour ce type de features est massivement représenté par les personnes souffrant de gros déficits visuels. De tels utilisateurs se servent généralement d'un agrandisseur d'écran. Or, ce logiciel est bien entendu actif en permanence: les icônes sur le bureau ne sont pas plus visibles a priori que du texte sur une page internet. Ainsi, ces utilisateurs, en arrivant sur le site, auront déjà leur agrandisseur d'écran en fonction. Ils n'utiliseront donc pas la fonction proposée par le site (sans compter que l'effet de ce genre d'option peut difficilement être prévu avec précision: va-t-il y avoir des conséquences sur la position des blocs? Sur l'agencement du texte? Les retours à la ligne? La lisibilité des titres? Les couleurs de fond? et j'en passe...). Je mentionnerai aussi en passant un détail à ne pas omettre, vu qu'on m'en fait souvent la remarque: non, le lien "accéder au contenu", s'il est présent dans la navigation accessible, ne sera pas employé par de tels internautes. En effet, il sera tout aussi fastidieux pour eux de faire défiler la fenêtre pour atteindre le lien que d'aller directement au contenu. Ce n'est pas une option "satisficing", selon le terme consacré (la même remarque est valable pour le lien menant au menu).

SI l'option d'agrandissement ou de diminution de la taille des caractères n'est pas utile aux internautes qui en auraient le plus besoi, à qui s'adresse-t-il? Est-il totalement superficiel? Non, pas tout-à-fait, bien que certaines nuances doivent être apportées à cette analyse. D'une part, le menu d'agrandissement peut être utile dans certains cas bien précis et pour des individus bien précis. Quantifier son utilisation serait trop fastidieux, mais on pourrait évaluer à moins de 1% des utilisateurs d'un site la proportion de ceux qui emploieront cette option. Elle n'est donc pas totalement inutile. Là où elle devient dangereuse, c'est dans sa conception ergonomique, comme je l'ai rapidement signalé auparavant: il est difficile d'évaluer prospectivement cette fonction d'une manière précise. Son effet sur l'intégrité du layout n'est pas déterminable a priori. De même, certaines expériences fâcheuses peuvent refroidir l'utilisateur (que celui qui n'a jamais eu de souci en employant une fonction de zoom lance la première pierre).

Ainsi, bien que fort contestable, on ne peut pas condamner définitivement ce type d'options. L'accessibilité est une question de minorités, et il ne fait pas de doute qu'une maigre frange d'utilisateurs emploie ce type de fonctions. En créant de tels menus, il est impératif de se poser les bonnes questions, et de bien évaluer l'audience qui l'emploiera.

La question des accès rapides.

Pour finir ce petit tour d'horizon de la question du menu accessible, un dernier mot s'impose sur les liens pointant vers les blocs de contenu ou de titre de la page. De tels raccourcis sont fort pratiques pour les aveugles mais, dans ce cas, ils doivent être bien pensés. Le mieux que l'on puisse faire, c'est d'imiter Flaubert dans son gueuloir: lisez votre page à haute voix. Si le nombre de "accéder au menu" ou "accéder au contenu" vous dérangent, alors il y a de fortes chances que cela dérange également un aveugle.

Il n'y a pas de méthode miracle pour déterminer le nombre et la position de ce type de raccourcis. Ils dépendent en effet:

• de la longueur des articles
• de la nature du contenu
• de la place du menu
• de la complexité du plan du site

Les seuls points indispensables lorsque l'on conçoit ce type de menus sont:

• les intégrer correctement à la structure du document en leur donnant un titre
• ne pas employer l'instruction display: none; pour les masquer (ils pourraient être ignorés par un navigateur vocal, ce qui serait le comble)
• employer des éléments de liste (ils seront ainsi beaucoup plus facilement lisibles par un aveugle)
• éviter les redondances