Rappelons tout d'abord que les descripteurs de media CSS permettent de différencier les styles appliqués à un document (X)HTML selon le dispositif de rendu :

• Les plus utilisés aujourd'hui concernent le rendu visuel : les medias screen (grossièrement, la fenêtre d'affichage des classiques navigateurs graphiques pour desktop), print (l'impression de la page Web, généralement à partir d'un navigateur) et projection (dispositifs de projection et mode plein écran d'Opera) ;
• D'autres correspondent à des dispositifs d'accès au Web émergeants, toujours visuels : tv (dispositifs Web-tv et Opera for Home Media), ainsi que handheld (Mode Small-Screen Rendering d'Opera, futur Minimo, Openwave, NetFront et autres navigateurs pour mobiles et dispositifs à écran de petite taille) ;
• Enfin, ceux qui concernent les dispositifs tactiles braille restent théoriques, faute d'implémentation actuelle : braille (tablettes brailles) et embosssed (impression braille).

Qu'en est-il des dispositifs d'accès vocaux au Web ? Ceux-ci peuvent être en particulier :

• Des navigateurs vocaux, qui permettent d'accéder au document Web et d'interagir avec lui de manière orale, par exemple par l'intermédiaire d'un classique téléphone. On peut également ranger dans cette catégorie le nouvel Opera 8.0 bêta, qui permet, ou la lecture des pages HTML, l'interaction vocale avec les documents au format X-Voice, et que l'utilisateur peut plus généralement piloter à la voix pour utiliser ses signets, naviguer, consulter ses mails, etc.
• Des lecteurs d'écrans, qui présentent à la fois au moins un rendu visuel et un rendu auditif, et avec lesquels l'utilisateur agit par l'intermédiaire du clavier ou d'autres périphériques de saisie ou de pointage manuels. Parmi ceux-ci :
  • Certaines applications sont destinées uniquement à la navigation sur le Web. La plupart s'appuient pour cela sur un navigateur graphique, dont elles utilisent le moteur HTML. C'est le cas par exemple d'IBM Home Page Reader, qui nécessite la présence d'Internet Explorer 5+. D'autres, comme pwWebSpeak, ne nécessitent pas la présence d'un navigateur graphique mais jouent le même rôle en gérant simultanéement le rendu visuel magnifié et la lecture.
  • D'autres applications ne se limitent pas à l'accès au Web, mais agissent plus généralement comme un interface auditif entre l'utilisateur et son poste de travail. C'est le cas de Jaws, conçu pour être utilisé aussi bien avec des navigateurs (Internet Explorer, Firefox) qu'avec des suites bureautiques (Microsoft Office), etc.
• Il faut y ajouter potentiellement les futurs navigateurs multimodaux pour mobile, pour le Web-TV ou pour tout autre vertical du type de ceux embarqués dans un véhicule par exemple, qui sont appelés à l'avenir à implémenter des fonctionalités vocales pour améliorer le confort d'interaction compte tenu de leurs limites en matière de clavier et de dispositifs de pointage. L'avenir des applications vocales dépasse en effet de très loin le champ unique de l'accessibilité Web.

Toutes ces applications sont rassemblées, du point de vue CSS, dans un unique media auditif, permettant de styler le rendu oral des documents Web : avec quel voix, quelle intonation, quelle vitesse d'élocution ce contenu sera-t-il lu ? Quel contenu sera-t-il éventuellement masqué ou omis à la lecture ? Quel contenu audio sera-t-il éventuellement généré pour ponctuer la lecture ? Tout cela est parfaitement similaire aux styles d'affichage d'un document à l'écran (Polices de caractère, tailles, couleurs, graphismes décoratifs, etc.).

Mais une certaine confusion règne en raison de la coexistence sur le papier d'au moins deux descripteurs de media :

• Les spécification HTML4.01 et CSS2.0 définissaient un media aural, destiné aux synthétiseurs de parole de tous types. Un ensemble de propriétés de style propres à ce media aural était également défini dans un chapitre spécifique de CSS2.0.

  Mais ce descripteur de media aural, ainsi que les propriétés qui lui sont associées, sont restés largement théoriques, faute d'implémentation suffisante dans les dispositifs de rendu auditifs concernés.

  En d'autres termes, il n'existe aucun navigateur ou lecteur d'écran qui reconnaisse une feuille de style aural, à l'exception notable d'Emacspeak, un interface auditif destiné aux systèmes linux, qui reconnaît quelques propriétés CSS2.0 auditives. Cette situation apparemment surprenante s'explique par l'ambitieuse complexité des propriétés auditives CSS2.0, mais surtout par la démarche traditionnelle des principaux acteurs du marché des lecteurs d'écran (Jaws, IBM HPR, Windows Eyes, etc.), avant tout soucieux de restituer le "Web réel", qui a été (et est encore) lui même largement indifférent aux standard CSS.

• C'est là qu'intervient CSS2.1, actuellement au stade de Candidate Recommendation , c'est à dire sur le point de devenir une recommandation finale : destinée à supprimer les dispositifs CSS2 qui peuvent être considérées comme rejettés par la communauté CSS en raison de leur manque d'implémentation (...) Supprimer les mécanismes CCS2 qui seront rendus obsolètes par CSS3, et encourager ainsi l'adoption de mécanismes CSS3 à leur place, elle tire la leçon des difficultés rencontrées à propos du media aural et des propriétés qui lui étaient associées. Le descripteur de media aural est donc déprécié, et avec lui l'ensemble des styles auditifs CSS2.0. CSS2.1 réserve un nouveau descripteur de media auditif nommé speech, sans en définir plus avant les propriétés spécifiques ;
• Celles-ci sont en effet du ressort de CSS3.0, à travers le module CSS Speech.

Le navigateur Opera 8.0 (bêta 2) implémente le descripteur speech, ainsi qu'une partie des propriétés auditives CSS3 (bien que celles-ci soient encore actuellement à l'état de document de travail du W3C), et ouvre ainsi la voie aux lecteurs d'écran classiques. Rappelons que ceux-ci, à l'heure actuelle, ne reconnaissent aucun des deux types de media aural et speech, et n'implémentent aucune propriété CSS2 ou CSS3 auditives. De manière passablement problématique, ils appliquent même en fait partiellement certains styles réservés au media screen.

En conclusion :

• Un lecteur d'écran, par opposition à un navigateur vocal ou multimodal, ne fait que lire ce qui est affiché, sans permettre d'interaction vocale ;
• Le media aural est à peu près mort-né ;
• Le media speech est appelé à se généraliser et peut dès aujourd'hui être expérimenté par les développeur Web dans quelques applications pionnières.

Note: Nous avons volontairement laissé de côté l'hypothétique media reader, destiné aux lecteurs d'écrans, dont la définition problématique est actuellement à l'état de document de travail du W3C, et qui n'est implémenté ou en voie d'implémentation par aucune application.