Les lecteurs d'écran lisent-ils simplement le contenu sans prêter attention au CSS?

Ma raison de demander est que je voudrais utiliser LESS.js pour certains de mes CSS (donc pas tous). En ce qui me concerne, les utilisateurs avec JS désactivé bénéficieront de toute façon d'une expérience de base afin de ne pas manquer une partie de mon CSS de présentation.

Cependant, qu'en est-il des lecteurs d'écran ... vont-ils manquer mon CSS supplémentaire qui est servi via Javascript?

P.S. aucune suggestion de compilateur s'il vous plaît, je ne suis pas intéressé - ils ralentissent mon flux de travail.

Merci

3
SparrwHawk 23 nov. 2011 à 01:39

3 réponses

Meilleure réponse

Ils sont censés s'inspirer des propriétés CSS définies dans le module vocal pour comprendre comment lire du texte de style CSS.

Le rendu auditif d'un document combine la synthèse vocale (également connue sous le nom de "TTS", l'acronyme de "Text to Speech") et les icônes auditives (que nous appelons "signaux audio" dans cette spécification). La présentation auditive de l'information est courante dans les communautés d'utilisateurs aveugles ou malvoyants. Par exemple, les "lecteurs d'écran" permettent de contrôler les interfaces utilisateur visuelles qui seraient autrement inaccessibles. Il existe d'autres cas où l'écoute d'informations textuelles (par opposition à leur lecture) est une nécessité. Les exemples typiques incluent l'utilisation en voiture d'un lecteur de livre électronique, les systèmes de documentation industrielle et médicale, le divertissement à domicile, l'aide aux utilisateurs pour apprendre à lire ou le soutien aux utilisateurs qui ont des difficultés de lecture (incapacité à imprimer).

En ce qui concerne les documents, la qualité du rendu de la parole dépend de la structure et de la sémantique créées dans le contenu lui-même. Le module CSS Speech fournit des propriétés qui permettent aux auteurs de contrôler de manière déclarative les aspects de présentation de la dimension auditive (par exemple, la voix TTS, la hauteur, le taux et les niveaux de volume). Ces propriétés de feuille de style peuvent être utilisées avec des propriétés visuelles (supports mixtes), ou comme alternative sonore complète à une présentation visuelle.

Les créateurs de contenu peuvent inclure conditionnellement des propriétés CSS dédiées aux user-agents avec des capacités de synthèse texte-parole, en spécifiant le type de média "speech" via l'attribut media de l'élément link, ou avec la règle @media at, ou dans un @import déclaration. Ce faisant, les styles créés dans le cadre de ces instructions conditionnelles sont ignorés par les agents utilisateurs qui ne prennent pas en charge ce module.

1
Mike Samuel 22 nov. 2011 à 21:44

Le problème le plus important à comprendre ici est qu'un lecteur d'écran n'est pas un navigateur: c'est une application qui lit l'interface utilisateur d'autres applications, soit par la parole, le braille, une combinaison ou les deux - ou peut-être même par d'autres moyens.

Lors de la lecture du Web, le lecteur d'écran ne charge ou n'analyse pas réellement HTML ou CSS: le navigateur le fait, et le lecteur d'écran lit ce qui est affiché par le navigateur, généralement en accédant directement au DOM sous-jacent (par exemple sur Win32 avec IE , via les différentes interfaces IHTML *) ou via une API d'accessibilité.

(Notez que cela signifie que la prise en charge peut varier en fonction de la combinaison du lecteur d'écran et du navigateur; JAWS peut fonctionner contre IE ou Firefox, mais pas actuellement Chrome, Opera ou Safari; et peut dans certains cas lire les choses différemment contre IE vs Firefox.)

Habituellement, cela signifie que les lecteurs d'écran ignorent la plupart des CSS - ils ignorent à peu près la plupart du formatage et de la mise en page et se concentrent sur le contenu; mais tous les lecteurs d'écran modernes prennent au moins en compte l'affichage: et la visibilité: ils ne liront donc pas le contenu qu'un utilisateur voyant ne verrait pas. Par exemple, un lecteur d'écran ne voudrait pas lire le texte "réduit" - jusqu'à ce qu'il soit approprié de le faire. Le problème clé ici est que ces deux attributs CSS ont en fait une signification sémantique, il est donc important que les lecteurs d'écran le transmettent.

Étant donné que les lecteurs d'écran obtiennent ces valeurs généralement à partir du DOM (directement ou indirectement), peu importe si elles ont été définies via des styles en ligne, une feuille de style externe ou lors de l'exécution via javascript.

-

Une note rapide sur les feuilles de style auditif: pour le moment, elles ne sont tout simplement pas pertinentes du tout pour le scénario du lecteur d'écran.

Tout d'abord, il y a le problème qu'un utilisateur de lecteur d'écran pourrait ne pas utiliser la sortie vocale en premier lieu.

Deuxièmement, la plupart des utilisateurs de lecteurs d'écran ont leur voix définie sur une voix très spécifique - généralement une voix neutre que l'utilisateur peut bien comprendre à des vitesses élevées - puis ils augmenteront la vitesse à une vitesse très rapide que la plupart des gens ne seront pas capable de comprendre du tout. La dernière chose qu'un utilisateur de lecteur d'écran souhaite, c'est qu'une page commence à remplacer ses paramètres vocaux.

Cela rend l'expérience du lecteur d'écran fondamentalement différente d'une interface utilisateur basée sur la parole (où une feuille auditive pourrait être appropriée). L'interface utilisateur est vraiment toujours basée sur l'affichage; il se trouve que l'utilisateur y accède de manière indirecte; et cette indirection peut être via la parole, le braille ou une combinaison. Mais vous ne devriez pas avoir à vous soucier de cela, tant que vous avez un bon balisage sémantique dans votre page en premier lieu.

7
BrendanMcK 23 nov. 2011 à 00:11

Oui et non. CSS doit être analysé pour que le lecteur d'écran sache s'il faut lire ou non un élément. Les éléments avec display: none ne seront pas lus par un lecteur d'écran, mais il existe encore d'autres moyens de masquer le contenu qui ne peut être observé qu'avec un lecteur d'écran.

Je recommande fortement de télécharger une copie de développement de JAWS ou Window Eyes et d'effectuer un test d'utilisation réel de votre site.

1
zzzzBov 22 nov. 2011 à 21:42