La solution la plus immédiate, et la plus logique en fait, serait l'ajout d'un simple display:none; dans une feuille de style media="screen", donc réservée à l'affichage graphique. Les feuilles de style étant ignorées par les navigateurs textes, et les lecteurs d'écran ne devant prendre en compte que les media all et aural... tout irait pour le mieux dans le meilleur des mondes.

Mais nous ne vivons pas dans le meilleur des mondes, et cette solution n'en est pas une : Jaws, Window Eyes et IBM Home Page Reader, pour ne citer qu'eux, ont une implémentation erronée des CSS qui leur fait le plus souvent appliquer les règles de display:none; et de visibility: hidden. Le contenu prévu spécifiquement pour les lecteurs d'écran se retrouve donc fréquemment masqué dans ceux-ci.

Dans une série de test approfondis, ScreenreaderVisibility, Bob Easton a montré que lorsqu'on cache du contenu dans le rendu graphique sur l'écran d'un PC, on le cache aussi presque toujours aux lecteurs d'écran. Paul Bohman (An Accessible Method of Hiding HTML Content) propose donc une autre solution de masquage CSS, selon lui assurée de ne pas se tromper de cible :

.hidden
{
position:absolute;
 left:0px;
 top:-500px;
 width:1px;
 height:1px;
 overflow:hidden;
}

Si ce code vous semble truffé de redondances, c'est qu'il cumule les précautions pour être sûr qu'aucun navigateur graphique ne rendra visible le contenu masqué par accident :

• La position absolue déplace le contenu masqué hors de la fenêtre de visualisation du navigateur, en l'expédiant au-dessus de celle-ci (au-dessus, et non quelque-part à gauche ou à droite, ce qui serait selon Bohman moins assuré de succès) ;
• Si cette première règle échoue, le dimensionnement réduit notre contenu masqué à 1px quasi-invisible (0px masquerait le contenu dans certains lecteurs d'écran) ;
• Enfin, l'overflow:hidden fait disparaître ce qui émergerait encore, en cas de recouvrement avec le reste du contenu.

Paul Bohman affirme qu'ensemble, ces méthodes fonctionnent dans un large éventail de navigateurs, de plates-formes et de lecteurs d'écran. Il nous propose, exemples de code à l'appui, de les utiliser pour :

• générer des titres en images via les arrières-plans CSS, le texte du titre restant toujours accessibles aux lecteurs d'écran (ce qui n'est pas le cas notamment dans la très connue méthode de Todd Fahrner) ;
• masquer les liens d'évitement de la navigation ;
• ajouter des labels masqués dans un formulaire structuré à l'aide d'un tableau ;
• ajouter des labels masqués dans une série de champs de saisie associés (saisie d'un numéro de téléphone ou d'un numéro de licence par blocs de chiffres) ;
• ajouter dans une page des titres ou des indications permettant de mieux s'y repérer depuis un lecteur d'écran (« Menu de navigation » par exemple) ;

En conclusion, cette méthode paraît tout à fait correcte. Mais j'y ferais cependant une réserve sur le fond : y a-t-il autant de cas que cela où il est vraiment justifié de distinguer deux contenus, dont l'un serait réservé aux lecteurs d'écran ?

• Les formulaires présentés à l'aide d'un tableau doté d'en-tête de lignes et de colonnes en guise de labels... gagneraient à n'utiliser que l'élément label : après tout, ce n'est jamais que l'élément structurel prévu par les spécifications pour étiquetter les éléments de formulaires ;
• Les titres du type « Menu de navigation » n'ont-ils pas leur place sur nos écrans, avec des intitulés plus habiles sans doute, pour une meilleure ergonomie de la page ?
• Même les liens d'évitement de la navigation peuvent avoir leur utilité dans un rendu graphique, pour qui navigue à l'aide du clavier ou d'un dispositif spécifique...

Certes, dans le cas des textes mis en image pour les titres, il y a clairement deux contenus distincts. Mais il me semble qu'étendre cette démarche et commencer à distribuer son contenu selon les medias... a quelque-chose d'un peu Tartuffe.