Leitores de tela não são ferramentas de teste · Eric Eggert
Testar com tecnologias assistivas é uma parte importante de qualquer revisão de acessibilidade. No entanto, especialmente ao auditar as Diretrizes de Acessibilidade de Conteúdo da Web (WCAG), elas não devem ser as principais ferramentas a serem usadas para testes. Aqui está o porquê:
Apoie o trabalho independente de Eric
Sou um profissional de acessibilidade web que se preocupa profundamente com a inclusão e uma web aberta para todos. Trabalho com o Axess Lab como especialista em acessibilidade. Anteriormente, trabalhei com a Knowbility, o World Wide Web Consortium e a Aktion Mensch. Neste blog publico minhas próprias idéias e pesquisas sobre a indústria da web.
Os leitores de tela são softwares especializados feitos para pessoas que precisam deles. Isso significa que eles possuem recursos incríveis para facilitar o uso do computador, principalmente quando o usuário não consegue ver a tela. Eles também não servem apenas para usar a web, mas também para o resto do sistema operacional.
Essa complexidade significa que eles não são tão simples de usar como as pessoas imaginam. “Basta testar com um leitor de tela” pode ter consequências indesejadas. Muitos testadores não sabem que os usuários de leitores de tela raramente usam a tecla Tab em sites para navegar, mas o que chamo de “navegação com tecla de seta”. Neste modo, um cursor virtual percorre a página, incluindo elementos não interativos, e lê o que está selecionado por aquele cursor.
Deque tem uma boa visão geral dos atalhos do leitor de tela (e gestos para leitores de tela sensível ao toque). O JAWS usa as teclas de seta e modificadores para ler a próxima seção, caractere, linha ou frase. O narrador usa Caps Lock mais teclas de seta. NVDA Insert mais teclas de seta. VozOver VO (por padrão, a combinação de Control e Option) mais teclas de seta. Mas isso é apenas para deslocamento linear. Os leitores de tela possuem teclas dedicadas para acessar títulos e pontos de referência, obter uma lista de links e interagir com elementos de interface do usuário mais complexos.
Armadilhas do teste do leitor de tela
Muitas vezes vejo testadores criticando botões feitos de
keyupdefinido como inacessível para usuários de leitores de tela. Mas esse não é o caso. É inacessível para pessoas que usam o teclado sem leitor de tela, por exemplo, ao usar dispositivos switch ou sip-and-puff. Mas os leitores de tela podem simular cliques do mouse, e alguns o fazem por padrão. Selecione um
with a tabindex=0 atributo e pressione VO+Space e será clicado.
Mesmo elementos sem funções, tabindex ou manipuladores de eventos de teclado podem ser encontrados e ativados por leitores de tela. A experiência seria ruim porque é impossível saber que você poderia interagir com algo ou o que acontece quando você o faz. Os leitores de tela são desenvolvidos para funcionar com interfaces mal codificadas, se necessário.
Isso significa que algumas falhas podem não ser facilmente detectadas quando o leitor de tela está ativado. Outro exemplo disso é o indicador de foco. A maioria dos sites tem indicadores de foco ruins, portanto, para indivíduos com baixa visão, os leitores de tela têm um indicador de foco sempre ativo que também indica as seções não interativas da página que são lidas.
Outra coisa que vejo com frequência é que os testadores de leitores de tela que não usam leitores de tela o tempo todo tendem a querer mais explicações do leitor de tela do que normalmente fazem. Alguns exemplos recentes que encontrei são dois
Embora ambos não sejam falhas das WCAG (eles ainda descrevem o que o botão ou seleção faz), informações redundantes podem ser uma barreira e retardar significativamente os usuários. Meu conselho geral é não adicionar detalhes sobre o que pode ser visto na tela aos nomes acessíveis, a menos que o controle seja difícil de entender de outra forma. Normalmente, se houver contexto visual para um botão, esse contexto também estará presente para usuários de leitores de tela (ou pelo menos deveria estar ao seguir as WCAG 1.3.1 Informações e relacionamentos). As conversas podem estar em uma seção rotulada ou seguindo um título “conversas recentes”, portanto a repetição não é necessária.
O que procurar antes de testar com um leitor de tela
Muitas falhas que você encontraria ao usar um leitor de tela podem ser encontradas de forma mais conveniente com ferramentas de teste dedicadas. A11y-tools.com tem bookmarklets realmente excelentes que, por exemplo, podem mostrar elementos focáveis em uma página. Você pode encontrar todos os links e botões e mostrar seu nome acessível, inclusive comparando-o com o rótulo visual. É muito mais conveniente do que navegar com um leitor de tela tentando localizar problemas.
O Polypane possui ferramentas semelhantes e é o que uso para testar. Usar o Polypane Peek para verificar rapidamente o nome acessível de um botão ou link é extremamente conveniente. Se o nome acessível estiver errado, posso verificar instantaneamente na árvore de elementos ou na árvore de acessibilidade de onde vem o nome acessível e formular uma solução para os clientes com essas informações.
Porque saber que algo está quebrado é uma pequena parte do teste. Auditorias acionáveis identificam a causa raiz ou o mal-entendido do erro e também informações sobre como resolver o problema e aprender como nunca mais repeti-lo. Sem olhar o código, é impossível saber por que o resultado não é o esperado: é um erro na página, uma configuração do leitor de tela ou uma peculiaridade estranha da combinação leitor de tela/navegador? E se você precisa olhar o código para determinar isso de qualquer maneira, por que não olhar diretamente para o código?
Os leitores de tela mostram os sintomas de código incorreto, mas não os problemas reais. Eles são uma forma indireta de testar.
Quando usar leitores de tela
Existem algumas interações que são melhor testadas com leitores de tela no momento. Ferramentas em torno de regiões ativas ARIA, por exemplo, são péssimas. Usar um leitor de tela para verificá-los é a opção mais fácil. O mesmo vale para padrões interativos complexos. Mesmo que os papéis e nomes acessíveis estejam todos presentes e funcionando na teoria, é importante verificar se a interação faz sentido quando não se tem a referência visual.
Este também é o momento de testes de usabilidade com usuários de leitores de tela. Encontre todos os problemas de acessibilidade de baixo nível, como nomes acessíveis incorretos e funções ausentes e enganosas, antes de realizar testes de usabilidade. Não há nada mais embaraçoso do que encontrar simples rótulos incorretos quando um usuário testa o site, porque isso desperdiça um tempo valioso que poderia ser gasto em interações mais detalhadas.
Conclusão
Testar com leitores de tela requer uma quantidade significativa de insights para entender como eles funcionam e como as pessoas os usam na prática. Para testadores que não são usuários de leitores de tela, é difícil obter essas informações e é necessária muita experiência para identificar a origem de um problema percebido.
Ferramentas de teste dedicadas levarão você ao resultado com mais rapidez e mais insights. Verificar com um leitor de tela é uma boa prática.
