J'ai utilisé le Web pendant une journée à l'aide d'un lecteur d'écran

Un utilisateur malvoyant se met dans la peau d'un utilisateur non malvoyant. Chris Ashton rencontre des difficultés directes rencontrées par les utilisateurs malvoyants et décrit ce que nous pouvons faire pour aider les développeurs Web.

Cet article fait partie d'une série dans laquelle je tente d'utiliser le Web sous différentes contraintes, représentant un groupe démographique donné d'utilisateurs. J'espère mettre en relief les difficultés rencontrées par de vraies personnes, qui sont évitables si nous concevons et développons nos ressources de manière à répondre à leurs besoins. La dernière fois, j'ai navigué sur le Web pendant une journée avec juste mon clavier . Cette fois-ci, j'évite l'écran et utilise Internet avec un lecteur d'écran.

Qu'est-ce qu'un lecteur d'écran?

Un lecteur d'écran est un logiciel qui interprète les éléments à l'écran (texte, images, et ainsi de suite) et les convertit en un format que les personnes malvoyantes sont en mesure de consommer et avec lesquelles elles peuvent interagir. Les deux tiers des utilisateurs de lecteurs d'écran choisissent la parole comme sortie de lecteur d'écran et un tiers des utilisateurs de lecteurs d'écran choisissent le braille .

Les lecteurs d'écran peuvent être utilisés avec des programmes tels que traitement de texte, clients de messagerie, et les navigateurs Web. Ils travaillent en mappant le contenu et l'interface de l'application sur une arborescence d'accessibilité qui peut ensuite être lue par le lecteur d'écran. Certains lecteurs d'écran doivent mapper manuellement des programmes spécifiques dans l'arborescence tandis que d'autres sont plus génériques et devraient fonctionner avec la plupart des programmes.

Sous Windows, le lecteur d'écran le plus populaire est JAWS avec près de la moitié du marché total des lecteurs d'écran. C'est un logiciel commercial qui coûte environ mille dollars pour l'édition à domicile. Une alternative open-source pour Windows est NVDA utilisée par un peu moins du tiers des utilisateurs de lecteurs d'écran sur le bureau.

Il existe d'autres alternatives, notamment Microsoft Narrator . Accès au système Window-Eyes et ZoomText (pas un lecteur plein écran, mais une loupe qui a des capacités de lecture); la somme combinée de ces éléments équivaut à environ 6% de l'utilisation du lecteur d'écran. Sous Linux, Orca est associé par défaut à un certain nombre de distributions

Le lecteur d'écran fourni avec macOS, iOS et tvOS est VoiceOver . VoiceOver représente 11,7% des utilisateurs de lecteurs d'écran de bureau et s'élève à 69% des utilisateurs de lecteurs d'écran sur mobile. Les autres principaux lecteurs d'écran de l'espace mobile sont Talkback sur Android (29,5%) et Voice Assistant sur Samsung (5,2%), lui-même basé sur Talkback, mais avec des gestes supplémentaires .

J'ai un MacBook et un iPhone, j'utiliserai donc VoiceOver et Safari pour cet article. Safari est le navigateur recommandé à utiliser avec VoiceOver car ils sont tous deux mis à jour par Apple et devraient bien fonctionner ensemble. L'utilisation de VoiceOver avec un autre navigateur peut entraîner des comportements inattendus.

Comment activer et utiliser votre lecteur d'écran

Mes instructions s'appliquent à VoiceOver, mais le lecteur de votre choix doit comporter des commandes équivalentes.

VoiceOver On Bureau

Si vous n’avez jamais utilisé de lecteur d’écran auparavant, cela peut être une expérience décourageante. C’est un choc culturel majeur pour une expérience uniquement auditive, et ne pas savoir comment contrôler l’attaque du bruit est déconcertant. Pour cette raison, la première chose que vous voudrez apprendre, c'est comment le désactiver.

Le raccourci pour désactiver VoiceOver est identique à celui utilisé pour l'activer: + F5 ( est également appelée clé Cmd ). Sur les nouveaux Mac dotés d'une barre tactile, le raccourci est de maintenez la touche Commande enfoncée et appuyez trois fois sur le bouton Touch ID . VoiceOver parle-t-il trop vite? Ouvrez VoiceOver Utility, cliquez sur l’onglet 'Discours', puis ajustez le débit en conséquence.

Une fois que vous avez maîtrisé son activation et sa désactivation, vous devez apprendre à utiliser la “touche VoiceOver” (qui est en fait deux clés). enfoncée en même temps): Ctrl et (cette dernière touche est également appelée "Option" ou la touche Alt ). En utilisant la touche VO en combinaison avec d'autres touches, vous pouvez naviguer sur le Web.

Par exemple, vous pouvez utiliser VO + A pour lire le page Web à partir de la position actuelle; en pratique, cela signifie que vous maintenez Ctrl + + A . Se souvenir de ce à quoi VO correspond est déroutant au début, mais la notation VO est pour plus de concision et de cohérence. Il est possible de configurer la clé VO pour qu'elle soit autre chose, il est donc logique de disposer d'une notation standard que tout le monde peut suivre.

Vous pouvez utiliser VO et les touches de direction ( VO + → et VO + ← ) pour parcourir successivement chaque élément du DOM. Lorsque vous tombez sur un lien, vous pouvez cliquer sur VO + Space pour les utiliser: vous utiliserez également ces touches pour interagir avec les éléments de formulaire.

Huzzah! Maintenant, vous en savez assez sur VoiceOver pour naviguer sur le Web.

VoiceOver On Mobile

Le raccourci mobile / tablette pour activer VoiceOver varie en fonction du périphérique, mais correspond généralement à un «triple clic» du bouton d'accueil (après activant le raccourci dans les paramètres ).

Vous pouvez tout lire depuis la position actuelle avec une commande Balayer vers le bas à deux doigts et vous pouvez sélectionner chaque élément du DOM en ordre séquentiel. a Balayez vers la droite ou la gauche .

Vous en savez désormais autant sur iOS VoiceOver que sur votre bureau!

Navigation par type de contenu

Réfléchissez à la manière dont vous utilisez le Web, en tant qu'utilisateur averti. Est-ce que vous lisez chaque mot attentivement, en séquence, de haut en bas? Les utilisateurs sont paresseux de par leur conception et ont appris à "numériser" les pages pour trouver des informations intéressantes aussi rapidement que possible.

Les utilisateurs de lecteurs d’écran ont le même besoin d’efficacité, de sorte que la plupart des utilisateurs navigueront dans la page par type de contenu, par exemple. rubriques, liens ou contrôles de formulaire. Pour ce faire, ouvrez le menu des raccourcis avec VO + U naviguez jusqu'au type de contenu souhaité avec les ← et → puis naviguez dans ces éléments à l'aide des touches ↑ 90 .

Une autre façon de procéder consiste à activer la ‘Navigation rapide’ (en tenant simultanément ← avec → ). Lorsque la navigation rapide est activée, vous pouvez sélectionner le type de contenu en maintenant la flèche ↑ aux côtés de ← ou → . Sur iOS, vous procédez ainsi avec un geste Pivoter à deux doigts .

Une fois votre type de contenu sélectionné, vous pouvez ignorer chaque élément du rotor à l’aide des touches ↑ (ou Balayer vers le haut ou le bas sur iOS). Si cela vous semble beaucoup à retenir, il vaut la peine de mettre en référence ce super handy VoiceOver à des fins de référence.

Une troisième façon de naviguer via des types de contenu consiste à utiliser les gestes du trackpad. Cela rapproche l'expérience de l'utilisation possible de VoiceOver sur iOS sur un iPad / iPhone, ce qui signifie que vous ne devez mémoriser qu'un jeu de commandes de lecteur d'écran!

Vous pouvez vous exercer à la navigation par gestes et à de nombreuses autres techniques VoiceOver dans le programme de formation intégré à OSX. Vous pouvez y accéder via Préférences Système → Accessibilité → VoiceOver → Ouvrir une formation VoiceOver.

Une fois le didacticiel terminé, j'étais impatient d'y aller!

Étude de cas 1: YouTube

Recherche sur YouTube

J'ai navigué vers la page d'accueil YouTube de la barre d'outils Safari, sur laquelle VoiceOver m'a dit de "pénétrer" dans le contenu Web avec Ctrl + + Shift + . Je me suis vite habitué à entrer dans le contenu Web, car le même mécanisme s'applique au contenu incorporé et à certains contrôles de formulaire.

À l'aide de Quick Nav, j'ai pu naviguer dans les contrôles de formulaire pour passer facilement à la section de recherche en haut.

J'ai cherché du contenu de qualité:

Et j'ai navigué jusqu'au bouton de recherche:

Cependant, lorsque j'ai activé le bouton avec VO + Space rien n'a été annoncé.

J'ai ouvert les yeux. La recherche avait eu lieu et la page était remplie de résultats.

Intrigué, j’ai reproduit mes actions avec devtools ouvert et jeté un œil sur l’onglet du réseau.

Comme on le soupçonnait, YouTube utilise une technique de performance appelée « «rendu côté client», ce qui signifie que JavaScript intercepte la soumission du formulaire et restitue les résultats de la recherche sur place, pour éviter de devoir repeindre la page entière. Si les résultats de la recherche avaient été chargés dans une nouvelle page comme un lien normal, VoiceOver m'aurait annoncé la nouvelle page de navigation.

Des articles entiers sont consacrés à l'accessibilité pour les applications rendues par les clients ; dans ce cas, je recommanderais à YouTube de mettre en œuvre une région aria-live qui indiquerait le moment de la réussite de la recherche.

Conseil n ° 1: Utilisez les régions aria-live . modifications du client dans le DOM.

  
     Rechercher une vidéo 
    
  
  
  

Maintenant que j'avais triché et que je savais qu'il y avait des résultats de recherche à regarder, j'ai fermé les yeux et j'ai navigué vers la première vidéo des résultats, en basculant sur le mode "En-têtes" de Quick Nav, puis en parcourant les résultats à partir de là. .

Lecture d'une vidéo sur YouTube

Dès que vous chargez une page vidéo sur YouTube, la vidéo se lit automatiquement. C’est quelque chose que j’attache à l’utilisation quotidienne, mais c’est une expérience douloureuse lorsqu’elle est mélangée à VoiceOver. Je ne pouvais pas trouver un moyen de désactiver la lecture automatique pour les vidéos suivantes. Tout ce que je pouvais faire, c’était de charger ma vidéo suivante et d'appuyer rapidement sur CTRL pour arrêter les annonces du lecteur d'écran.

Conseil n ° 2: Fournissez toujours un moyen de supprimer la lecture automatique et rappelez-vous le choix de l'utilisateur. .

La ​​vidéo elle-même est traitée comme un "groupe" dans lequel vous devez entrer pour interagir. Je pouvais naviguer dans chacune des options du lecteur vidéo, ce qui m'a agréablement surpris – je doute que ce fût le cas à l'époque de Flash!

Cependant, j'ai constaté que certaines des commandes du lecteur n'avaient pas de label. Ainsi, le "mode cinéma" était simplement lu comme un "bouton".

Conseil n ° 3: étiquetez toujours vos contrôles de formulaire.

Bien que les utilisateurs de lecteurs d'écran soient principalement aveugles, environ 20% d'entre eux sont classés dans la catégorie «Basse vision». Par conséquent, un utilisateur de lecteur d'écran peut toujours apprécier de pouvoir activer le «mode Cinéma».

Ces conseils ne sont pas énumérés par ordre d'importance, mais s'ils l'étaient, ce serait mon numéro un:

Conseil n ° 4: les utilisateurs de lecteurs d'écran devraient avoir une parité fonctionnelle avec les utilisateurs voyants.

En négligeant de désigner l'option «mode cinéma», nous excluons les utilisateurs de lecteurs d'écran d'une fonctionnalité qu'ils pourraient autrement utiliser.

Cela dit, il existe des cas dans lesquels une fonction ne ne serait pas applicable à un lecteur d'écran, par exemple un graphique à lignes SVG détaillé qui se lirait comme un gobbledygook de nombres sans contexte. Dans de tels cas, nous pouvons appliquer l'attribut spécial aria-hidden = "true" à l'élément de sorte qu'il soit totalement ignoré par les lecteurs d'écran. Notez que nous aurions toujours besoin de fournir un texte ou un tableau de données alternatif hors écran comme solution de secours.

Conseil n ° 5: utilisez aria-hidden pour masquer le contenu non applicable à screen. lecteurs.

Il m’a fallu beaucoup de temps pour comprendre comment ajuster la position de lecture pour pouvoir rembobiner du contenu. Une fois que vous êtes «intervenu» dans le curseur ( VO + Shift + ↓ ), vous maintenez + ↑ ↓ à ajuster. Cela me semble peu intuitif, mais ce n’est pas la première fois que Apple prend des décisions de raccourci clavier controversées .

La lecture automatique à la fin de la vidéo YouTube

À la fin de la vidéo, j’ai automatiquement été redirigé.

J'ai rapidement appris à naviguer vers les commandes de lecture automatique et à les désactiver:

Cela n'empêche pas la lecture automatique d'une vidéo lorsque je charge une page vidéo, mais empêche cette page de la redirection automatique vers la vidéo suivante.

Étude de cas 2: BBC

Consommé passivement plutôt que par la recherche de quelque chose de spécifique, j'ai décidé de naviguer dans BBC News par rubriques. Il convient de noter que vous n’avez pas besoin d’utiliser Quick Nav pour cela: VoiceOver fournit des commandes de recherche d’éléments qui peuvent faire gagner du temps à l’utilisateur expérimenté. Dans ce cas, je pouvais naviguer dans les vedettes avec les clés VO + ⌘ + H .

La ​​première position était la mention de cookie, et la seconde. était un

intitulé «Liens d’accessibilité». Sous cette deuxième rubrique, le premier lien était un lien "Passer au contenu" qui me permettait de passer toutes les autres navigations.

Grand aperçu )

Les liens «Passer au contenu» sont très utiles, et pas seulement pour les utilisateurs de lecteurs d’écran; voir mon précédent article « J'ai utilisé le Web pendant une journée avec juste un clavier ».

Conseil n ° 6: Fournissez des liens de type "passer au contenu" pour les utilisateurs de votre clavier et de votre lecteur d'écran.

La ​​navigation par en-têtes était une bonne approche: chaque nouvelle a son propre en-tête. Je pouvais donc entendre le titre avant de décider s'il fallait en savoir plus sur une histoire donnée. Et comme le titre lui-même était placé dans une balise d'ancrage, je n'avais même pas besoin de changer de mode de navigation lorsque je voulais cliquer; Je pouvais juste VO + Espace charger mon choix d'article actuel .

Alors que le raccourci vers le contenu de la page d'accueil est bien lié à une ancre #, il saute le lien de la page de l'article a été cassé. Elle était liée à un identifiant différent ( #page ) qui m'emmenait dans le groupe entourant le contenu de l'article, plutôt que de lire le titre.

À ce stade, j'ai frappé VO + A pour que VoiceOver me lise l'intégralité de l'article.

Il s'est bien débrouillé jusqu'à ce qu'il soit intégré à Twitter, où ça commençait à devenir assez verbeux. À un moment donné, il a lu inutilement «Link: 1068987739478130688».

Cela semble résulter en un balisage légèrement louche dans la partie vidéo intégrée du tweet:

Il semble que VoiceOver ne lit pas l'attribut alt de l'image imbriquée et il n'y a pas d'autre texte à l'intérieur de l'ancre. VoiceOver fait donc la chose la plus utile qu'il puisse faire: lire une partie de l'URL elle-même.

D'autres lecteurs d'écran peuvent fonctionner correctement avec ce balisage – votre kilométrage peut varier. Mais une implémentation plus sûre consisterait en une balise d'ancrage ayant un aria-label ou du texte masqué visuellement hors écran, pour porter le texte de remplacement. Même si nous sommes ici, je changerais probablement «vidéo intégrée» en quelque chose d’un peu plus utile, par exemple. “Embedded video: click to play”).

Les problèmes de lien ne se trouvaient pas là-bas:

Sous le contenu principal du tweet, il y a un bouton "J'aime" qui sert également de compteur "J'aime". Visuellement, c’est logique, mais du point de vue du lecteur d’écran, il n’ya pas de contexte ici. Cette expérience de lecture d'écran est mauvaise pour deux raisons:

1. Je ne sais pas ce que signifie “1 887”.
2. Je ne sais pas qu'en cliquant sur le lien, j'aimerai le tweet.

Les utilisateurs de lecteurs d'écran devraient avoir plus de contexte, par exemple “1 887 utilisateurs ont aimé ce tweet. Cliquez pour aimer. ”Cela pourrait être obtenu avec un texte attentif hors écran:

   1 887 utilisateurs aiment ce tweet. Cliquez pour ainsi aimer 
   1 887 

Conseil n ° 7: Assurez-vous que chaque lien a un sens lorsqu'il est lu séparément

J'ai lu quelques articles supplémentaires sur la BBC, dont un long métrage.

Lecture de longs articles

Regardez la capture d'écran suivante d'un autre Article détaillé de la BBC – Combien d'images différentes pouvez-vous voir et quels devraient être leurs attributs alt ?

Voyons d’abord l’image de premier plan de Lake Havasu au centre de l’image. La légende se trouve en dessous: «Lake Havasu a été créé après l'achèvement du barrage Parker en 1938, qui a retenu le fleuve Colorado».

Il est recommandé de fournir un attribut alt même la légende est fournie. Le texte alt devrait décrire l'image, tandis que la légende devrait en fournir le contexte. Dans ce cas, l'attribut alt pourrait être quelque chose comme "Vue aérienne du lac Havasu par une journée ensoleillée".

Notez que nous ne devrions pas préfixer notre texte alt avec " Image: ”ou“ Image de ”ou quelque chose comme ça. Les lecteurs d'écran fournissent déjà ce contexte en annonçant le mot «image» avant notre texte alt . Gardez aussi alt texte court (moins de 16 mots). Si un texte plus long alt est nécessaire, par ex. une image a beaucoup de texte dessus qui doit être copiée, examinez l'attribut longdesc .

Conseil n ° 8: rédigez un descriptif mais efficace alt. textes.

Sémantiquement, l'exemple de capture d'écran doit être annoté avec

et :

Voyons maintenant l’arrière-plan de cette capture d’écran (celle qui transporte divers verres à boire et équipements). En règle générale, les images d'arrière-plan ou de présentation telles que celles-ci doivent avoir un attribut vide alt ( alt = "" ), afin que VoiceOver soit explicitement informé qu'il n'existe aucun texte alternatif. ne tente pas de le lire.

Notez qu'un vide alt = "" n'est PAS la même chose que de ne pas avoir alt attribut, ce qui est un gros no-no. Si un attribut alt est manquant les lecteurs d'écran liront les noms de fichiers d'image, qui ne sont souvent pas très utiles!

Conseil n ° 9: N'ayez pas peur d'utiliser des attributs vides alt pour le contenu de présentation.

Étude de cas 3: Facebook

Je me dirigeais maintenant vers Facebook. ayant des symptômes de sevrage antérieurs, je suis donc parti à la recherche de plus de Impractical Jokers .

Facebook pousse les choses un peu plus loin que les autres sites que j'ai essayés jusqu'à présent, et au lieu d'un 'Skip to contenu ", nous avons pas moins de deux listes déroulantes qui renvoient respectivement à des pages ou à des sections de pages.

Facebook définit également un certain nombre de touches de raccourci pouvant être utilisées n'importe où dans la page:

J’ai eu une pièce avec eux et ils fonctionnent assez bien avec VoiceOver – une fois que vous savez qu’ils sont là. Le seul problème que je vois, c’est qu’ils sont propriétaires (je ne peux pas espérer que ces mêmes raccourcis fonctionnent en dehors de Facebook), mais c’est bien que Facebook essaie vraiment fort ici.

Bien que ma première impression de l’accessibilité de Facebook fût un bon, j’ai vite repéré de petites bizarreries qui rendaient le site plus difficile à naviguer.

Par exemple, j’ai été très confus en essayant de naviguer sur cette page via les en-têtes:

Le tout premier en-tête de la page est un en-tête de niveau 3, niché dans la barre latérale. Ceci est immédiatement suivi du niveau d'en-tête SIX dans la colonne de contenu principal, ce qui correspond à un statut partagé par la page.

Ceci peut être visualisé avec le plug-in de développeur Web pour Chrome / Firefox .

En règle générale, il est judicieux d’avoir en-têtes séquentiels avec une différence ne dépassant pas 1 . Si vous ne le faites pas, ce n'est pas un briseur de transaction, mais il est certainement déroutant d'y accéder du point de vue d'un lecteur d'écran et vous inquiétez du fait que vous ayez accidentellement omis certaines informations importantes, car vous êtes passé d'un h1 à un h6 .

Conseil n ° 10: Validez la structure de votre rubrique.

Maintenant, passons à la viande sur le site Web: les messages. Facebook consiste à rester en contact avec les gens et à voir ce qu’ils font. Mais nous vivons dans un monde où le texte alt est un concept inconnu pour la plupart des utilisateurs, alors comment Facebook traduit-il ces selfies et photos de chiens pour un public de lecteurs d'écran?

Facebook a un Automatic. Générateur Alt Text qui utilise la technologie de reconnaissance d’objets pour analyser ce qui est (ou qui) dans une photo et en générer une description textuelle. Alors, comment ça marche?

Le texte de alt était le suivant: "L'image contient peut-être: ciel, l'herbe et le plein air". C'est loin d'être la "Cathédrale de Cambridge au crépuscule", mais c'est définitivement un pas dans la bonne direction

J'ai été extrêmement impressionné par la précision de certaines descriptions. Une autre image que j'ai essayée est sortie comme “L'image peut contenir: 3 personnes, dont John Smith, Jane Doe et Chris Ashton, des personnes souriantes, rapprochées et à l'intérieur” – très descriptif, et tout à fait raison!

Mais ça ne me dérange pas que ces mèmes et les blagues virales sur les médias sociaux sont par nature inaccessibles; Facebook considère ce qui suit comme «l'image peut contenir: oiseau et texte», ce qui, bien que vrai, est éloigné du vrai portrait!

Heureusement, les utilisateurs peuvent écrire leur propre texte alt s'ils le souhaitent .

Étude de cas 4: Amazon

Quelque chose que j'ai remarqué sur Facebook se passe aussi sur Amazon . Le bouton de recherche apparaît avant le champ de saisie de la recherche dans le DOM. C'est malgré le fait que le bouton apparaît visuellement après le champ de saisie .

Votre site Web est susceptible d'être visuellement dans un ordre logique. What if somebody randomly moved parts of your webpage around — would it continue to make sense?

Probably not. That’s what can happen to your screen reader experience if you aren’t disciplined about keeping your DOM structure in sync with your visual design. Sometimes it’s easier to move content with CSS, but it’s usually better to move it in the DOM.

Tip #11: Make the DOM order match the visual order.

Why these two high profile sites choose not to adopt this best practice guideline with their search navigation baffles me. However, the button and input text are not so far apart that their ordering causes a big accessibility issue.

Headings On Amazon

Again, like Facebook, Amazon has a strange headings order. I searched via headings and was most confused that the first heading in the page was a heading level 5 in the “Other Sellers on Amazon” section:

I thought this must be a bug with the screen reader, so I dug into Amazon’s source code to check:

The h1 of the page appears almost 10,000 lines down in the source code.

Not only is this poor semantically and poor for accessibility, but this is also poor for SEO. Poor SEO means fewer conversions (sales) — something I’d expect Amazon to be very on top of!

Tip #12: Accessibility and SEO are two sides of the same coin.

A lot of what we do to improve the screen reader experience will also improve the SEO. Semantically valid headings and detailed alt text are great for search engine crawlers, which should mean your site ranks more highly in search, which should mean you’ll bring in a wider audience.

If you’re ever struggling to convince your business manager that creating accessible sites is important, try a different angle and point out the SEO benefits instead.

Miscellaneous

It’s hard to condense a day’s worth of browsing and experiences into a single article. Here are some highlights and lowlights that made the cut.

You’ll Notice The Slow Sites

Screen readers cannot parse the page and create their accessibility tree until the DOM has loaded. Sighted users can scan a page while it’s loading, quickly determining if it’s worth their while and hitting the back button if not. Screen reader users have no choice but to wait for 100% of the page to load.

It’s interesting to note that whilst making a performant website benefits all, it’s especially beneficial for screen reader users.

Do I Agree To What?

Form controls like this one from NatWest can be highly dependent on spacial closeness to denote relationships. In screen reader land, there is no spacial closeness — only siblings and parents — and guesswork is required to know what you’re ticking ‘yes’ to.

I would have known what I was agreeing to if the disclaimer had been part of the label:

  Important: We can only hold details of one trip at a time.
   Tick to confirm you have read this. *

Following Code Is A Nightmare

I tried reading a technical article on CSS Tricks using my screen readerbut honestly, found the experience totally impossible to follow. This isn’t the fault of the CSS Tricks website — I think it’s incredibly complex to explain technical ideas and code samples in a fully auditory way. How many times have you tried debugging with a partner and rather than explaining the exact syntax you need, you give them something to copy and paste or you fill it in yourself?

Look how easily you can read this code sample from the article:

But here is the screen reader version:

slash slash first we get the viewport height and we multiple it by one [pause] percent to get a value for a vh unit let vh equals window inner height star [pause] zero zero one slash slash then we set the value in the [pause] vh custom property to the root of the document document document element style set property [pause] vh dollar left brace vh right brace px

It’s totally unreadable in the soundscape. We tend not to have punctuation in comments, and in this case, one line flows seamlessly into the next in screen reader land. camelCase text is read out as separate words as if they’d been written in a sentence. Periods such as window.innerHeight are ignored and treated as “window inner height”. The only ‘code’ read out is the curly brackets at the end.

The code is marked up using standard

 and  HTML elements, so I don’t know how this could be made better for screen reader users. Any who do persevere with coding have my total admiration.

Otherwise, the only fault I could find was that the logo of the site had a link to the homepage, but no alt text, so all I heard was “link: slash”. It’s only in my capacity as a web developer that I know if you have a link with an attribute href="/" then it takes you to the website homepage, so I figured out what the link was for — but “link: CSS Tricks homepage” would have been better!












		

	
		
VoiceOver On iOS Is Trickier Than OSX

Using VoiceOver on my phone was an experience!

I gave myself the challenge of navigating the Twitter app and writing a Tweet, with the screen off and using the mobile keyboard. It was harder than expected and I made a number of spelling mistakes.

If I were a regular screen reader user, I think I’d have to join the 41% of mobile screen reader users who use an external keyboard and invest in a Bluetooth keyboard. Clara Van Gerven came to the same conclusion when she used a screen reader for forty days in 2015.

It was pretty cool to activate Screen Curtain mode with a triple-tap using three fingers. This turned the screen off but kept the phone unlocked, so I could continue to browse my phone without anyone watching. This feature is essential for blind users who might otherwise be unwittingly giving their passwords to the person watching over their shoulder, but it also has a side benefit of being great for saving the battery.

Summary

This was an interesting and challenging experience, and the hardest article of the series to write so far.

I was taken aback by little things that are obvious when you stop and think about them. For instance, when using a screen reader, it’s almost impossible to listen to music at the same time as browsing the web! Keeping the context of the page can also be difficult, especially if you get interrupted by a phone call or something; by the time you get back to the screen reader you’ve kind of lost your place.

My biggest takeaway is that there’s a big cultural shock in going to an audio-only experience. It’s a totally different way to navigate the web, and because there is such a contrast, it is difficult to even know what constitutes a ‘good’ or ‘bad’ screen reader experience. It can be quite overwhelming, and it’s no wonder a lot of developers avoid testing on them.

But we shouldn’t avoid doing it just because it’s hard. As Charlie Owen said in her talk, Dear Developer, the Web Isn’t About You: This. Is. Your. Job. Whilst it’s fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can’t just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let’s make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I’ve tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I’d have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.


  (rb, ra, yk, il)