Le positionnement en CSS est inefficace sur les lecteurs d’écran

C’est en tout cas ce que nous révèle les conclusion d’une étude réalisée par le site Acces Matters : Screen Readers and CSS Layout. Cette étude porte sur les principaux logiciels de lecture d’écran (Jaws, Window Eyes, IBM Home Page Reader) et la conclusion est sans appels : le contenu d’une page web est lu dans l’ordre dans lequel il apparaît dans le code source HTML, peut importe la mise en forme qui lui est apporté à l’aide des feuilles de styles CSS.

Et l’auteur de rajouter que le positionnement à l’aide de styles (CSS-P) n’est donc pas pertinent. Au contraire ! C’est justement parce que les lecteurs d’écran interprètent le contenu dans l’ordre dans lequel il apparaît dans le code source que les styles CSS prennent toute leur importance.

Je m’explique : Si vous avez une page web avec une mise en page en deux colonnes (la navigation à gauche et le contenu à droite), le seul moyen de rendre cette page accessible est d’utiliser le positionnement CSS. Je précise ici qu’une des règles d’accessibilité est que l’ordre de lecture du contenu doit être le même quelque soit l’appareil utilisé. Deux solutions s’offrent à vous : soit vous passez voter menu à droite (comme sur ce site), soit vous positionnez votre menu de navigation à gauche à l’aide des styles CSS (float ou position : absolute).

Quelqu’un a-t-il un retour d’expérience là-dessus ?

Un commentaire sur “Le positionnement en CSS est inefficace sur les lecteurs d’écran

  1. Uhm, je pense qu’une petite astuce pourrait s’appliquer pour contourner ce problème. On peut en effet prévoir d’ajouter une zone cachée (à l’aide des CSS avec un display: none par les navigateurs dans lequel on insère un menu visible uniquement par les screen readers. Dans ce menu on place les liens vers par exemple le menu principal et vers la zone du contenu. L’utilisateur pourra de ce fait se déplacer toute suite vers la zone qui lui intéresse.

  2. Pourquoi utiliser un menu caché qui va demander plus de travail à mettre en oeuvre et à maintenir ? Il suffit juste de coder sa page de telle façon que le contenu apparaisse dans le bon ordre avec et sans les styles CSS. On peut également avoir recours aux raccourcis du type « Sauter la navigation » mais ce n’est pas réellement ce que stipule les règles d’accessibilité, non ? /Fred

  3. et les display:none sont invisible pour les lecteurs d’écran malheureusement. Il faut utiliser une technique de positionnement absolue en dehors de l’écran. Quand à l’ordre de lecture c’est ce que prone accessiweb dans ces critères contre vent et marée depuis déjà pas mal de temps

  4. Dans la pratique, j’ai tendance à transposer le problème en termes d’usabilité. Soit avant de créer une page, répondre à la question suivante: « Quelles éléments doivent être vus et dans quel ordre? ». Mon ordre favori, sorte de scénario utilisateur est: 1) Le titre (où suis-je et quel est le contenu de la page). Ainsi, je sais de suite si la page contient les éléments que je souhaitais y trouver. Je décide alors d’y rester ou non. Si la page correspond à ce que j’en attends, je la lis, donc: 2) le contenu Si ce n’est pas le cas, ou si j’ai fini la lecture (ou le survol) du contenu, je dois pouvoir naviguer, sans avoir à chercher, donc: 3) le menu Seulement le passage directe de l’étape 1 à 3 nécessite de pouvoir passer directement du titre à la navigation. Visuellement cela est simple (les menus de navigation sont de coutume toujours aux mêmes endroits, à savoir gauche ou droite). Quand aux lecteurs d’écran, il suffit en effet de définir la zone de navigation juste après le titre, via un lien interne à la page par exemple. L’ordre idéal du code m’a toujours paru être titre – contenu – navigation. Et cela n’empêche nullement de placer chacun de ces éléments visuellement dans un ordre différent, tant que cela répond bien à l’attente du visiteur. Et il n’est pas nécessaire pour cela d’utiliser des « hacks » du type display:none ou autre positions absolues (qui sont un cauchemar de compatibilité). Une question posée régulièrement est « les aveugles préfèrent-ils avoir le contenu ou le menu en premier? ». Et ma réponse est en général « peu importe, comme tout le monde il doivent pouvoir trouver (voir…) sans chercher ce qu’ils cherchent sur une page! ».

  5. On peut également avoir recours aux raccourcis du type « Sauter la navigation » mais ce n’est pas réellement ce que stipule les règles d’accessibilité, non ? Les liens d’évitements sont des recommandations du W3C (WAI) et de l’ADAE… Ce sont le critère : 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. Priority 3 du WAI et le critère 12.4 d’Accessiweb/ADAE

  6. Mouaip. Le problème du CSS et des standards en général c’est que les navigateurs « interprètent » les spécifications. Donc utiliser du CSS dernier cri c’est bien joli mais faut gérer tous les cas tordus alors que l’intérêt du CSS était de standardiser un peu tout çà … On peut utilser les positionnement flottant qui sont pas mal mais dans certains cas (redimensionnement automatique, taille ésotérique de l’écran) fonctionnent mal. On peut utiliser le positionnement absolu mais le problème est que cela suppose des objets à taille fixe. On perd tout l’intérêt du dimensionnement et on ne sait pas gérer la taille des barre d’outils. Pour info on peut faire tout çà avec une balise <TABLE> … Côté CSS, l’attribut « display: » permet les valeurs « table,row,column,… » mais je n’ai jamais essayé.

  7. Il me semble que certains lecteurs d’écran (comme le IBM Screen Reader) se servent des balises <link section="..."> pour générer des sommaires automatiques. Ce qui pourrait résoudre le problème de l’ordre des éléments (le contenu en premier)… à condition que les autres lecteurs d’écran puissent faire de même ! /Fred

  8. Je suis toujours effaré de voir à quel point les mêmes questions reviennent à l’infini. J’ai déjà parlé de ces problèmes régulièrement depuis 2002, avec les mêmes conclusions que celle de l’article que tu cites, le problème du display:none, le non support des CSS vocales, etc. Sans doute est-ce dû au fait que l’on s’attend à ce que ces outils progressent. :-( Quelques précisions: les lecteurs d’écran/navigateurs vocaux sont basés sur MSIE, avec tout ce que ça implique. Une solution possible est donc de mettre des liens de navigation (pas d’évitement) au tout début du code: politique d’accessibilité, aller au contenu, aller au menu, aller à la recherche. La page de politique d’accessibilité donnera les raccourcis clavier pour ces éléments (et d’autres), permettant ainsi de naviguer facilement et de partout. Il est ensuite très simple de respecter la recommandation sur l’ordre d’apparition dans le code et à l’écran. Pour finir, si ces liens gênent visuellement, un simple positionnement absolu en dehors de la page suffit. Pour un point sur les raccourcis possibles, voir la conclusion de cet article sur OpenWeb. Après, il reste possible de préciser ces touches dans le title des liens et/ou de prévoir une feuille de style alternative faisant apparaître la touche après le lien (un classique :after et content). Mais là encore, les lecteurs vocaux n’en profiteront pas.

  9. Bonjour, Je précise ici qu’une des règles d’accessibilité est que l’ordre de lecture du contenu doit être le même quelque soit l’appareil utilisé. Attention a cette erreur d’interprétation des règles d’accessibilité.
    Il n’existe aucune règle du WCAG qui recommande cette pratique.
    Cette erreur est né d’une mauvaise interprétation de l’item 5.3 du WCAG sur l’effet de la linéarisation, nottamment par le référentiel accessiweb.
    Dans un tableau de donnée ou de mise en page, il conviens en effet de s’assurer que la linéarisation du tableau ne provoque pas d’incohérence de restitution du sens de la lecture, particulièrement lorsqu’interviens du multicolonnage. En revanche, le recours au positionnement CSS, permets de s’affranchir totalement de cet effet, si on prends soin d’offrir à la restitution vocale et tabulaire un ensemble logiquement structuré et cohérent. En terme plus clairs, peut importe que le menu soit à gauche, à droite ou n’importe où ailleurs, la seule chose qui doit compter c’est son ordre d’apparition dans le flux html et la cohérence de la tabulation de liens en liens. Remarque évidemment valable pour tout autre élément du document.

Laisser un commentaire