Usei a Web por um dia usando um leitor de tela

Este artigo faz parte de uma série em que tento usar a web sob várias restrições, representando um determinado demográfico de usuário. Espero aumentar o perfil das dificuldades enfrentadas por pessoas reais, que são evitáveis ​​se projetarmos e desenvolvermos de uma forma que seja simpática às suas necessidades. Da última vez, naveguei na web por um dia apenas com meu teclado. Desta vez, estou evitando a tela e estou usando a web com um leitor de tela.

O que é um leitor de tela?

Um leitor de tela é um aplicativo de software que interpreta coisas na tela (texto, imagens, links e assim por diante) e as converte em um formato que pessoas com deficiência visual podem consumir e interagir. Dois terços dos usuários de leitores de tela escolhem a fala como saída do leitor de tela e um terço dos usuários de leitores de tela escolhem braille.

Os leitores de tela podem ser usados ​​com programas como processadores de texto, clientes de e-mail e navegadores da web. Eles funcionam mapeando o conteúdo e a interface do aplicativo para uma árvore de acessibilidade que pode ser lida pelo leitor de tela. Alguns leitores de tela precisam mapear manualmente programas específicos para a árvore, enquanto outros são mais genéricos e devem funcionar com a maioria dos programas.

No Windows, o leitor de tela mais popular é o JAWS, com quase metade do mercado geral de leitores de tela. É um software comercial, custando cerca de mil dólares para a edição caseira. Uma alternativa de código aberto para o Windows é o NVDA, que é usado por pouco menos de um terço de todos os usuários de leitores de tela no desktop.

Existem outras alternativas, incluindo Microsoft Narrator , System Access , Window-Eyes e ZoomText (não um leitor de tela cheia, mas um ampliador de tela que possui habilidades de leitura); a soma combinada destes equivale a cerca de 6% do uso do leitor de tela. No Linux, o Orca é empacotado por padrão em várias distribuições.

O leitor de tela incluído no macOS, iOS e tvOS é o VoiceOver . O VoiceOver representa 11,7% dos usuários de leitores de tela de desktop e sobe para 69% dos usuários de leitores de tela em dispositivos móveis. Os outros principais leitores de tela no espaço móvel são o Talkback no Android (29,5%) e o Voice Assistant na Samsung (5,2%), que é baseado no Talkback, mas com gestos adicionais.

Eu tenho um MacBook e um iPhone, então usarei o VoiceOver e o Safari para este artigo. O Safari é o navegador recomendado para usar com o VoiceOver, pois ambos são mantidos pela Apple e devem funcionar bem juntos. Usar o VoiceOver com um navegador diferente pode levar a comportamentos inesperados.

Como ativar e usar seu leitor de tela

Minhas instruções são para o VoiceOver, mas deve haver comandos equivalentes para o leitor de tela de sua escolha.

VoiceOver na área de trabalho

Se você nunca usou um leitor de tela antes, pode ser uma experiência assustadora. É um grande choque cultural ir para uma experiência apenas auditiva, e não saber como controlar o ataque de ruído é enervante. Por esse motivo, a primeira coisa que você vai querer aprender é como desativá-lo.

O atalho para desativar o VoiceOver é o mesmo que o atalho para ativá-lo: ⌘ + F5 ( ⌘ também é conhecida como tecla Cmd ). Em Macs mais recentes com uma barra de toque, o atalho é manter a tecla de comando pressionada e pressionar três vezes o botão Touch ID. O VoiceOver está falando muito rápido? Abra o Utilitário VoiceOver, clique na guia 'Fala' e ajuste a taxa de acordo.

Depois de dominar a ativação e desativação, você precisará aprender a usar a “tecla VoiceOver” (que na verdade são duas teclas pressionadas ao mesmo tempo): Ctrl e ⌥ (a última tecla também é conhecida como “Option ” ou a tecla Alt ). Usando a tecla VO em combinação com outras teclas, você pode navegar na web.

Por exemplo, você pode usar VO + A para ler a página da web a partir da posição atual; na prática, isso significa segurar Ctrl + ⌥ + A . Lembrar a que VO corresponde é confuso no início, mas a notação VO é para brevidade e consistência. É possível configurar a tecla VO para ser outra coisa, então faz sentido ter uma notação padrão que todos possam seguir.

Você pode usar VO e teclas de seta ( VO + → e VO + ← ) para percorrer cada elemento do DOM em sequência. Ao encontrar um link, você pode usar VO + Espaço para clicar nele - você também usará essas teclas para interagir com os elementos do formulário.

Huzá! Agora você sabe o suficiente sobre o VoiceOver para navegar na web.

VoiceOver no celular

O atalho do celular/tablet para ativar o VoiceOver varia de acordo com o dispositivo, mas geralmente é um 'clique triplo' do botão home (depois de habilitar o atalho nas configurações).

Você pode ler tudo da posição atual com um comando Two-Finger Swipe Down e selecionar cada elemento no DOM em sequência com Swipe Right or Left .

Agora você sabe tanto sobre o iOS VoiceOver quanto sobre a área de trabalho!

Navegando por tipo de conteúdo

Pense em como você usa a web como um usuário com visão. Você lê cada palavra cuidadosamente, em sequência, de cima para baixo? Não. Os humanos são preguiçosos por design e aprenderam a 'digitalizar' as páginas em busca de informações interessantes o mais rápido possível.

Os usuários de leitores de tela têm essa mesma necessidade de eficiência, portanto, a maioria navegará na página por tipo de conteúdo, por exemplo, títulos, links ou controles de formulário. Uma maneira de fazer isso é abrir o menu de atalhos com VO + U , navegar até o tipo de conteúdo desejado com as teclas de seta ← e → e navegar por esses elementos com as teclas ↑↓ .

Outra maneira de fazer isso é habilitar 'Quick Nav' (mantendo ← junto com → ao mesmo tempo). Com o Quick Nav ativado, você pode selecionar o tipo de conteúdo segurando a seta ↑ ao lado de ← ou → . No iOS, você faz isso com um gesto Two-Finger Rotate .

Depois de selecionar seu tipo de conteúdo, você pode pular cada item do rotor com as teclas ↑↓ (ou Swipe Up or Down no iOS). Se isso parece muito para lembrar, vale a pena marcar esta folha de dicas super útil do VoiceOver para referência.

Uma terceira maneira de navegar pelos tipos de conteúdo é usar os gestos do trackpad. Isso aproxima a experiência de como você pode usar o VoiceOver no iOS em um iPad/iPhone, o que significa ter que lembrar apenas um conjunto de comandos do leitor de tela!

Você pode praticar a navegação baseada em gestos e muitas outras técnicas do VoiceOver no programa de treinamento integrado no OSX. Você pode acessá-lo em Preferências do sistema → Acessibilidade → VoiceOver → Abrir treinamento do VoiceOver.

Depois de completar o tutorial, eu estava ansioso para ir!

Estudo de caso 1: YouTube

Pesquisando no YouTube

Naveguei até a página inicial do YouTube na barra de ferramentas do Safari, na qual o VoiceOver me disse para “entrar” no conteúdo da web com Ctrl + ⌥ + Shift + ↓ . Eu logo me acostumaria a entrar no conteúdo da web, pois o mesmo mecanismo se aplica ao conteúdo incorporado e a alguns controles de formulário.

Usando o Quick Nav, consegui navegar pelos controles de formulário para pular facilmente para a seção de pesquisa na parte superior da página.

Procurei algum conteúdo de qualidade:

E naveguei até o botão de pesquisa:

No entanto, quando ativei o botão com VO + Space , nada foi anunciado.

Abri os olhos e a busca aconteceu e a página foi preenchida com resultados, mas eu não tinha como saber apenas pelo áudio.

Intrigado, reproduzi minhas ações com o devtools aberto e fiquei de olho na aba de rede.

Como suspeito, o YouTube está fazendo uso de uma técnica de desempenho chamada “renderização do lado do cliente”, o que significa que o JavaScript intercepta o envio do formulário e renderiza os resultados da pesquisa no local, para evitar a necessidade de repintar a página inteira. Se os resultados da pesquisa tivessem sido carregados em uma nova página como um link normal, o VoiceOver teria anunciado a nova página para eu navegar.

Existem artigos inteiros dedicados à acessibilidade para aplicativos renderizados pelo cliente; neste caso, eu recomendaria que o YouTube implemente uma região aria-live que anunciaria quando o envio da pesquisa for bem-sucedido.

Dica #1: Use regiões aria-live para anunciar mudanças do lado do cliente para o DOM.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

Agora que eu tinha trapaceado e sabia que havia resultados de pesquisa para ver, fechei os olhos e naveguei para o primeiro vídeo dos resultados, alternando para o modo “cabeçalhos” do Quick Nav e depois percorrendo os resultados a partir daí.

Reproduzindo vídeo no YouTube

Assim que você carrega uma página de vídeo do YouTube, o vídeo é reproduzido automaticamente. Isso é algo que valorizo ​​no uso diário, mas foi uma experiência dolorosa quando misturada com o VoiceOver falando sobre isso. Não consegui encontrar uma maneira de desativar a reprodução automática para vídeos subsequentes. Tudo o que eu podia fazer era carregar meu próximo vídeo e rapidamente apertar CTRL para parar os anúncios do leitor de tela.

Dica 2: Sempre forneça uma maneira de suprimir a reprodução automática e lembre-se da escolha do usuário.

O vídeo em si é tratado como um “grupo” no qual você precisa entrar para interagir. Eu podia navegar em cada uma das opções no player de vídeo, o que me surpreendeu agradavelmente - duvido que fosse o caso nos dias do Flash!

No entanto, descobri que alguns dos controles do player não tinham rótulo, então 'Modo Cinema' era simplesmente lido como “botão”.

Dica #3: Sempre rotule seus controles de formulário.

Enquanto os usuários de leitores de tela são predominantemente cegos, cerca de 20% são classificados como “baixa visão”, então podem ver parte da página. Portanto, um usuário de leitor de tela ainda pode gostar de poder ativar o “modo Cinema”.

Essas dicas não estão listadas em ordem de importância, mas se estivessem, esta seria a minha número um:

Dica #4: Os usuários de leitores de tela devem ter paridade funcional com os usuários com visão.

Ao deixar de rotular a opção “modo de cinema”, estamos excluindo os usuários de leitores de tela de um recurso que eles poderiam usar de outra forma.

Dito isso, há casos em que um recurso não será aplicável a um leitor de tela - por exemplo, um gráfico de linhas SVG detalhado que seria lido como um gobbledygook de números sem contexto. Em casos como esses, podemos aplicar o atributo especial aria-hidden="true" ao elemento para que seja completamente ignorado pelos leitores de tela. Observe que ainda precisaríamos fornecer algum texto alternativo fora da tela ou tabela de dados como substituto.

Dica #5: Use aria-hidden para ocultar conteúdo que não seja aplicável a usuários de leitores de tela.

Levei muito tempo para descobrir como ajustar a posição de reprodução para que eu pudesse retroceder algum conteúdo. Depois de “entrar” no controle deslizante ( VO + Shift + ↓ ), segure ⌥ + ↑↓ para ajustar. Parece pouco intuitivo para mim, mas, novamente, não é a primeira vez que a Apple toma algumas decisões controversas sobre atalhos de teclado.

Reprodução automática no final do vídeo do YouTube

No final do vídeo, fui redirecionado automaticamente para um novo vídeo, o que foi confuso – nenhum anúncio aconteceu.

Logo aprendi a navegar até os controles de reprodução automática e desativá-los:

Isso não impede que um vídeo seja reproduzido automaticamente quando carrego uma página de vídeo, mas impede que essa página de vídeo seja redirecionada automaticamente para o próximo vídeo.

Estudo de caso 2: BBC

Como as notícias são algo consumido passivamente, em vez de procurar algo específico, decidi navegar pela BBC News por títulos. Vale a pena notar que você não precisa usar o Quick Nav para isso: o VoiceOver fornece comandos de busca de elementos que podem economizar tempo para o usuário avançado. Nesse caso, eu poderia navegar pelos cabeçalhos com as teclas VO + ⌘ + H.

O primeiro título era o aviso de cookie, e o segundo título era um <h2> intitulado 'Links de acessibilidade'. Sob esse segundo título, o primeiro link era um link “Pular para o conteúdo” que me permitia pular todas as outras navegação.

Os links 'Pular para o conteúdo' são muito úteis, e não apenas para usuários de leitores de tela; veja meu artigo anterior “Usei a web por um dia com apenas um teclado”.

Dica #6: Forneça links 'pular para o conteúdo' para seus usuários de teclado e leitor de tela.

Navegar por títulos foi uma boa abordagem: cada notícia tem seu próprio título, para que eu pudesse ouvir a manchete antes de decidir se deveria ler mais sobre uma determinada história. E como o próprio título estava dentro de uma marca âncora, nem precisei alternar os modos de navegação quando queria clicar; Eu poderia apenas VO + Espaço para carregar minha escolha de artigo atual.

Enquanto o atalho de pular para o conteúdo da página inicial se vinculava bem a uma âncora #skip-to-content-link-target (que então lia a manchete da notícia principal), o link para pular a página do artigo estava quebrado. Ele vinculou a um ID diferente ( #page ) que me levou ao group em torno do conteúdo do artigo, em vez de ler o título.

Neste ponto, apertei VO + A para que o VoiceOver lesse o artigo inteiro para mim.

Ele lidou muito bem até chegar à incorporação do Twitter, onde começou a ficar bastante detalhado. Em um ponto, ele lê inutilmente “Link: 1068987739478130688”.

Isso parece ser uma marcação um pouco desonesta na parte de incorporação de vídeo do tweet:

Parece que o VoiceOver não lê o atributo alt da imagem aninhada e não há outro texto dentro da âncora, então o VoiceOver faz a coisa mais útil que sabe: ler uma parte da própria URL.

Outros leitores de tela podem funcionar bem com essa marcação – sua milhagem pode variar. Mas uma implementação mais segura seria a marca âncora com um aria-label , ou algum texto visualmente oculto fora da tela, para carregar o texto alternativo. Enquanto estamos aqui, eu provavelmente mudaria “Vídeo incorporado” para algo um pouco mais útil, por exemplo, “Vídeo incorporado: clique para reproduzir”).

Os problemas de link não estavam lá:

Sob o conteúdo principal do tweet, há um botão 'curtir' que funciona como um contador de 'curtidas'. Visualmente faz sentido, mas do ponto de vista do leitor de tela, não há contexto aqui. Essa experiência do leitor de tela é ruim por dois motivos:

1. Não sei o que significa “1.887”.
2. Não sei se clicando no link vou curtir o tweet.

Os usuários de leitores de tela devem receber mais contexto, por exemplo, “1.887 usuários gostaram deste tweet. Clique para curtir.” Isso pode ser alcançado com algum texto fora da tela atencioso:

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

Dica #7: Certifique-se de que cada link faça sentido quando lido isoladamente.

Li mais alguns artigos na BBC, incluindo um artigo de 'forma longa'.

Lendo os artigos mais longos

Veja a captura de tela a seguir de outro artigo longo da BBC - quantas imagens diferentes você pode ver e quais devem ser seus atributos alt ?

Em primeiro lugar, vamos olhar para a imagem em primeiro plano do Lago Havasu no centro da imagem. Tem uma legenda abaixo: “Lake Havasu foi criado após a conclusão da represa Parker em 1938, que reteve o rio Colorado”.

É uma prática recomendada fornecer um atributo alt mesmo se uma legenda for fornecida. O texto alt deve descrever a imagem, enquanto a legenda deve fornecer o contexto. Nesse caso, o atributo alt pode ser algo como “Vista aérea do Lago Havasu em um dia ensolarado”.

Observe que não devemos prefixar nosso texto alt com “Image: ”, ou “Picture of” ou qualquer coisa assim. Os leitores de tela já fornecem esse contexto anunciando a palavra “imagem” antes do nosso texto alt . Além disso, mantenha o texto alt curto (menos de 16 palavras). Se for necessário um texto alt mais longo, por exemplo, uma imagem tem muito texto que precisa ser copiado, verifique o atributo longdesc .

Dica #8: Escreva textos alt descritivos, mas eficientes.

Semanticamente, o exemplo de captura de tela deve ser marcado com os elementos <figure> e <figcaption> :

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

Agora vamos olhar para a imagem de fundo nessa captura de tela (a que transmite vários copos e equipamentos). Como regra geral, imagens de fundo ou de apresentação como essas devem ter um atributo alt vazio ( alt="" ), para que o VoiceOver seja explicitamente informado de que não há texto alternativo e não tente lê-lo.

Observe que um alt="" vazio NÃO é o mesmo que não ter nenhum atributo alt , que é um grande não-não. Se um atributo alt estiver ausente , os leitores de tela lerão os nomes dos arquivos de imagem, que geralmente não são muito úteis!

Dica #9: Não tenha medo de usar atributos alt vazios para conteúdo de apresentação.

Estudo de caso 3: Facebook

Indo para o Facebook agora, e eu estava tendo sintomas de abstinência de antes, então fui procurar mais alguns Coringas Impraticáveis .

O Facebook leva as coisas um passo ou dois além dos outros sites que experimentei até agora e, em vez de um link 'Pular para o conteúdo', temos nada menos que dois menus suspensos que vinculam a páginas ou seções de páginas, respectivamente.

O Facebook também define várias teclas como teclas de atalho que podem ser usadas em qualquer lugar da página:

Eu brinquei com eles, e eles funcionam muito bem com o VoiceOver - quando você sabe que eles estão lá. O único problema que vejo é que eles são proprietários (não posso esperar que esses mesmos atalhos funcionem fora do Facebook), mas é bom que o Facebook esteja realmente se esforçando aqui.

Embora minha primeira impressão da acessibilidade do Facebook tenha sido boa, logo descobri pequenas esquisitices que dificultavam a navegação no site.

Por exemplo, fiquei muito confuso ao tentar navegar nesta página por meio de títulos:

O primeiro título da página é um título de nível 3, escondido na barra lateral. Isso é imediatamente seguido pelo nível de cabeçalho SEIS na coluna de conteúdo principal, que corresponde a um status que foi compartilhado pela Página.

Isso pode ser visualizado com o plug-in Web Developer para Chrome/Firefox.

Como regra geral, é uma boa ideia ter títulos sequenciais com uma diferença não superior a 1. Não é um problema se você não fizer isso, mas certamente é confuso chegar a ele da perspectiva do leitor de tela e se preocupar que você Você acidentalmente pulou algumas informações importantes porque você pulou de um h1 para um h6 .

Dica #10: Valide sua estrutura de título.

Agora, para a carne do site: os posts. O Facebook tem tudo a ver com manter contato com as pessoas e ver o que elas estão fazendo. Mas vivemos em um mundo onde o texto alt é um conceito desconhecido para a maioria dos usuários, então como o Facebook traduz essas selfies presunçosas e fotos de cães para um público leitor de tela?

O Facebook tem um gerador automático de Alt Text que usa a tecnologia de reconhecimento de objetos para analisar o que (ou quem) está em uma foto e gerar uma descrição textual dela. Então, quão bem isso funciona?

O texto alt desta imagem era "A imagem pode conter: céu, grama e atividades ao ar livre." Está muito longe de reconhecer a “Catedral de Cambridge ao entardecer”, mas é definitivamente um passo na direção certa.

Fiquei incrivelmente impressionado com a precisão de algumas descrições. Outra imagem que experimentei saiu como “A imagem pode conter: 3 pessoas, incluindo John Smith, Jane Doe e Chris Ashton, pessoas sorrindo, close-up e área interna” — muito descritiva e absolutamente correta!

Mas me incomoda que memes e piadas que se tornam virais nas mídias sociais sejam inerentemente inacessíveis; O Facebook trata o seguinte como “A imagem pode conter: pássaro e texto”, o que, embora seja verdade, está muito longe da verdadeira representação!

Felizmente, os usuários podem escrever seu próprio texto alt , se desejarem.

Estudo de caso 4: Amazônia

Algo que notei no Facebook também acontece na Amazon. O botão de pesquisa aparece antes do campo de entrada de pesquisa no DOM. Isso apesar do botão aparecer visualmente após o campo de entrada.

É provável que seu site esteja em uma ordem lógica visualmente. E se alguém movesse aleatoriamente partes de sua página da web – isso continuaria a fazer sentido?

Provavelmente não. Isso é o que pode acontecer com sua experiência de leitor de tela se você não for disciplinado em manter sua estrutura DOM em sincronia com seu design visual. Às vezes é mais fácil mover conteúdo com CSS, mas geralmente é melhor movê-lo no DOM.

Dica #11: Faça a ordem do DOM corresponder à ordem visual.

Por que esses dois sites de alto perfil optam por não adotar essa diretriz de práticas recomendadas com sua navegação de pesquisa me deixa perplexo. No entanto, o botão e o texto de entrada não estão tão distantes que sua ordenação cause um grande problema de acessibilidade.

Títulos na Amazon

Novamente, como o Facebook, a Amazon tem uma ordem de títulos estranha. Pesquisei por meio de títulos e fiquei mais confuso porque o primeiro título da página era um título de nível 5 na seção “Outros vendedores na Amazon”:

Eu pensei que isso deveria ser um bug com o leitor de tela, então eu cavei no código-fonte da Amazon para verificar:

O h1 da página aparece quase 10.000 linhas abaixo no código-fonte.

Isso não é apenas semanticamente ruim e ruim para acessibilidade, mas também é ruim para SEO. SEO ruim significa menos conversões (vendas) – algo que eu esperaria que a Amazon estivesse no topo!

Dica #12: Acessibilidade e SEO são dois lados da mesma moeda.

Muito do que fazemos para melhorar a experiência do leitor de tela também melhorará o SEO. Cabeçalhos semanticamente válidos e texto alt detalhado são ótimos para rastreadores de mecanismos de pesquisa, o que deve significar que seu site tem uma classificação mais alta na pesquisa, o que deve significar que você atrairá um público mais amplo.

Se você está lutando para convencer seu gerente de negócios de que criar sites acessíveis é importante, tente um ângulo diferente e aponte os benefícios de SEO.

Diversos

É difícil condensar um dia de navegação e experiências em um único artigo. Aqui estão alguns destaques e lowlights que fizeram o corte.

Você notará os sites lentos

Os leitores de tela não podem analisar a página e criar sua árvore de acessibilidade até que o DOM seja carregado. Usuários com visão podem escanear uma página enquanto ela está carregando, determinando rapidamente se vale a pena e apertando o botão Voltar se não. Os usuários de leitores de tela não têm escolha a não ser esperar que 100% da página seja carregada.

É interessante notar que, embora fazer um site de alto desempenho beneficie a todos, é especialmente benéfico para os usuários de leitores de tela.

Concordo com o quê?

Controles de formulário como este do NatWest podem ser altamente dependentes da proximidade espacial para denotar relacionamentos. Na terra do leitor de tela, não há proximidade espacial - apenas irmãos e pais - e é necessário adivinhar para saber para o que você está marcando 'sim'.

Eu saberia com o que estava concordando se o aviso de isenção de responsabilidade fizesse parte do rótulo:

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

Seguir o código é um pesadelo

Tentei ler um artigo técnico sobre CSS Tricks usando meu leitor de tela, mas honestamente, achei a experiência totalmente impossível de seguir. Isso não é culpa do site CSS Tricks — acho incrivelmente complexo explicar ideias técnicas e amostras de código de uma forma totalmente auditiva. Quantas vezes você tentou depurar com um parceiro e em vez de explicar a sintaxe exata que você precisa, você dá a eles algo para copiar e colar ou você mesmo preenche?

Veja com que facilidade você pode ler este exemplo de código do artigo:

Mas aqui está a versão do leitor de tela:

barra barra primeiro obtemos a altura da janela de visualização e multiplicamos por um [pausa] por cento para obter um valor para uma unidade vh deixe vh igual à altura interna da janela estrela [pausa] zero zero uma barra barra então definimos o valor na [pausa ] vh propriedade personalizada para a raiz do documento documento documento elemento estilo set propriedade [pausa] vh dólar chave esquerda vh chave direita px

É totalmente ilegível na paisagem sonora. Nós tendemos a não ter pontuação nos comentários e, neste caso, uma linha flui perfeitamente para a próxima no leitor de tela. O texto do camelCase é lido como palavras separadas, como se tivessem sido escritas em uma frase. Períodos como window.innerHeight são ignorados e tratados como “window internal height”. O único 'código' lido são os colchetes no final.

O código é marcado usando elementos HTML padrão <pre> e <code> , então não sei como isso poderia ser melhorado para usuários de leitores de tela. Qualquer um que persevere com a codificação tem minha total admiração.

Caso contrário, a única falha que encontrei foi que o logotipo do site tinha um link para a página inicial, mas nenhum texto alt , então tudo o que ouvi foi “link: slash”. É apenas na minha capacidade de desenvolvedor web que eu sei que se você tem um link com um atributo href="/" então ele leva você para a página inicial do site, então eu descobri para que servia o link - mas “link: CSS Tricks homepage” teria sido melhor!

VoiceOver no iOS é mais complicado que o OSX

Usar o VoiceOver no meu telefone foi uma experiência!

Me dei o desafio de navegar no aplicativo do Twitter e escrever um Tweet, com a tela desligada e usando o teclado do celular. Foi mais difícil do que o esperado e cometi vários erros de ortografia.

Se eu fosse um usuário regular de leitor de tela, acho que teria que me juntar aos 41% dos usuários de leitor de tela móvel que usam um teclado externo e investem em um teclado Bluetooth. Clara Van Gerven chegou à mesma conclusão quando usou um leitor de tela por quarenta dias em 2015.

Foi muito legal ativar o modo Screen Curtain com um toque triplo usando três dedos. Isso desligou a tela, mas manteve o telefone desbloqueado, para que eu pudesse continuar navegando no meu telefone sem ninguém assistir. Esse recurso é essencial para usuários cegos que, de outra forma, poderiam estar inadvertidamente fornecendo suas senhas para a pessoa que está assistindo por cima do ombro, mas também tem um benefício colateral de ser ótimo para economizar bateria.

Resumo

Esta foi uma experiência interessante e desafiadora, e o artigo mais difícil da série para escrever até agora.

Fiquei surpreso com pequenas coisas que são óbvias quando você para e pensa sobre elas. Por exemplo, ao usar um leitor de tela, é quase impossível ouvir música ao mesmo tempo que navega na web! Manter o contexto da página também pode ser difícil, principalmente se você for interrompido por um telefonema ou algo assim; no momento em que você volta para o leitor de tela, você meio que perdeu o seu lugar.

Minha maior conclusão é que há um grande choque cultural em ir a uma experiência somente de áudio. É uma maneira totalmente diferente de navegar na web e, como há um contraste tão grande, é difícil até mesmo saber o que constitui uma experiência de leitor de tela 'boa' ou 'ruim'. Pode ser bastante esmagador, e não é de admirar que muitos desenvolvedores evitem testá-los.

Mas não devemos evitar fazê-lo só porque é difícil. Como Charlie Owen disse em sua palestra, Caro Desenvolvedor, a Web não é sobre você : isso. É. Seu. Trabalho . 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.