Problemas de spoiler com VoiceOver

Bug
, ,
1

Continuando a discussão de Spoiler blur not compatible with screen readers:

Recebi um relato de um usuário do VoiceOver de que o novo código de spoiler não funciona:

Algum dos meus colegas usuários de leitores de tela tem tido dificuldades com o recurso de spoilers atualizado no fórum? Pelo menos ASSUMO que houve uma atualização — costumava ser que o texto do spoiler era lido normalmente, sem qualquer indicação de que algo deveria estar oculto, o que, é claro, não era ideal. A atualização parece ter corrigido esse problema colocando o conteúdo atrás de uma área recolhível rotulada como “mostrar conteúdo oculto”, mas por algum motivo o texto não está sendo captado quando pressiono o botão para expandir/revelar. Para referência, estou usando o VoiceOver, o leitor de tela nativo da Apple, e notei isso tanto no iOS quanto no Mac OS.

3 curtidas
3

Alguém mais disse

Eu tenho os mesmos problemas ao usar o NVDA no Windows.

E uma terceira pessoa concordou.

Desculpe, mas não parece que o código atual funcione adequadamente! Provavelmente seria melhor até reverter para o código antigo.

1 curtida
6

Olá @Dannii, obrigado por identificar este problema. Acabei de publicar uma correção, que agora deve melhorar o comportamento para que os leitores de tela leiam o conteúdo do spoiler assim que ele for ativado.

4 curtidas
7

Fiz um upgrade no meu fórum, mas os usuários de leitores de tela estão relatando que nada mudou para eles.

1 curtida
8

Tem certeza de que o plugin foi atualizado para a versão mais recente? (commit 0ee68da)

Parece estar funcionando aqui no Meta para mim com o VoiceOver. Também estamos usando aria-live como polite para isso, o que significa que o leitor de tela não será tão assertivo e disruptivo. Em vez disso, ele esperará que o usuário esteja ocioso para falar o conteúdo.

Testar isso será lido

1 curtida
9

Sim, o plugin de spoiler está em 0ee68da1.

1 curtida
11

Keegan, você pode falar um pouco mais sobre como está testando isso? Sua captura de tela parece ser de um navegador de desktop. Você está usando o VoiceOver do macOS? (Em qual navegador?)

O VoiceOver do macOS é um produto muito diferente do VoiceOver do iOS. É comum haver bugs no VoiceOver do macOS que não aparecem no VoiceOver do iOS, e vice-versa. (Por várias razões, o VoiceOver do iOS é vastamente mais popular entre usuários com deficiência visual do que o VoiceOver do macOS.)

Quando tentei testar sua postagem https://meta.discourse.org/t/spoiler-issues-with-voiceover/257450/8?u=dfabulich no Safari 16.3.1 do iOS, foi isso que vi:

Aqui está uma transcrição:

  • O vídeo começa com o foco no vídeo. Em seguida, deslizo para a direita para focar o texto borrado do spoiler.
  • O VoiceOver anuncia: “Mostrar conteúdo oculto. Botão. Recolhido. Toque duas vezes para expandir.”
  • Eu toco duas vezes. O texto do spoiler é visualmente desborrado.
  • O VoiceOver anuncia: “Ocultar conteúdo. Expandido. Ocultar conteúdo.” Eu afirmo que este é um bug no Discourse. Ele deveria ter lido o conteúdo do texto em voz alta, como fez no vídeo de Keegan.
  • Eu deslizo para a direita, navegando para o próximo controle da interface do usuário.
  • O VoiceOver anuncia: “Uma pessoa curtiu esta postagem. Clique para ver. Botão de alternância.”
  • Eu deslizo para a esquerda, navegando de volta para o texto do spoiler desborrado.
  • O VoiceOver anuncia: “Ocultar conteúdo. Botão. Expandido. Toque duas vezes para recolher.”
  • Em seguida, deslizo para a direita e para a esquerda novamente apenas para verificar se o mesmo comportamento ocorre, e ocorre.

Temos relatos de usuários no fórum intfiction.org de que o desfoque do spoiler também está quebrado no NVDA, o que pode valer a pena testar do seu lado.

2 curtidas
12

Olá @dfabulich, obrigado por compartilhar esses detalhes. Sim, eu estava testando principalmente no Chrome (macOS VoiceOver e Windows 11 Narrator).

Vou investigar/testar mais um pouco e ver se consigo lançar uma correção em breve que resolva o problema para iOS, NVDA e outros dispositivos importantes.

Obrigado!

3 curtidas
13

Sim, nenhum desses são leitores de tela remotamente populares e não devem ser suas plataformas principais para testes.

Aqui está a principal pesquisa da indústria de usuários de leitores de tela, da WebAIM.

https://webaim.org/projects/screenreadersurvey9/ (eles refazem esta pesquisa a cada poucos anos; esta é de 2021)

Agora, você precisa ler esta pesquisa com atenção, porque ela primeiro fala sobre navegadores de desktop e tem um gráfico “Leitor de Tela Principal” https://webaim.org/projects/screenreadersurvey9/#primary, mas está se referindo especificamente ao leitor de tela “desktop/laptop” principal.

Esse gráfico indica que o “VoiceOver” não é muito popular, mas está se referindo ao VoiceOver do macOS nessa seção. (Se você rolar para baixo até a seção “Sistemas Operacionais”, verá que o próprio macOS não é muito popular entre os usuários de leitores de tela.)

O JAWS para Windows é o principal leitor de tela, seguido pelo NVDA para Windows. O VoiceOver do macOS é um distante terceiro. O Narrator do Windows tem um uso de 0,5%!

Observe que o JAWS é pago (e seu esquema de licenciamento é oneroso), e o NVDA é gratuito. Mas também, o NVDA tende a ser mais propenso a erros do que o JAWS; na minha experiência, qualquer coisa que funcione no NVDA também funciona no JAWS.

Mais tarde, ele fala sobre “Leitores de Tela Móveis Usados” https://webaim.org/projects/screenreadersurvey9/#mobilescreenreaders

Esse gráfico mostra que os leitores de tela integrados ao sistema operacional dominam, com o VoiceOver do iOS (71,5%) e o TalkBack do Android (29,1%). (Esses somam mais de 100% porque algumas pessoas usam ambos.)

Ausente desta pesquisa está uma pesquisa de “tempo em dispositivos móveis vs. tempo em desktop”, mas, na minha experiência, a grande maioria dos relatórios de bugs que ouço de usuários de leitores de tela são de usuários de iOS e NVDA.

Portanto, recomendo testar nesta ordem de prioridade:

  1. VoiceOver do Safari no iOS. Recomendo mobile em vez de desktop (porque, afirmo sem dados, que mobile é significativamente mais popular entre usuários com deficiência visual) e iOS em vez de Android, porque o iOS é esmagadoramente mais popular que o Android entre usuários com deficiência visual.
  2. NVDA do Windows no Chrome. O NVDA não é tão popular quanto o JAWS, mas é mais propenso a erros. Qualquer coisa que funcione no NVDA também funcionará no JAWS, mas não necessariamente vice-versa.
  3. JAWS do Windows no Chrome.
  4. TalkBack do Android no Chrome.
  5. VoiceOver do macOS no Safari.

Mas acho que você descobrirá que apenas testar no VoiceOver do Safari no iOS oferece um excelente retorno sobre o investimento. Normalmente, eu testo apenas o Safari do iOS e, em seguida, o NVDA do Windows no Chrome quando quero ser muito minucioso, e então eu paro.

Faz pelo menos cinco anos que não vejo um usuário relatar um bug que ocorre no JAWS do Windows, mas não no NVDA do Windows. Acho que nunca vi um usuário relatar um bug no TalkBack do Android.

4 curtidas
14

Algum progresso nesta questão ainda?

15

aria-live não foi feito para ser alternado. Você deve defini-lo como polite no início e deixá-lo ativado. Com a implementação existente, ele nunca chega a reconhecer que uma alteração foi feita porque as alterações nunca acontecem enquanto ele está ativado.

1 curtida
16

O problema para mim (NVDA/Windows) parece ser que você tem uma div externa com um aria-label. Acredito que na maioria dos leitores de tela, isso não é uma anotação do conteúdo, é uma substituição de conteúdo inacessível. Pelo menos, o aria-label é a única coisa que está sendo lida para mim.

Aqui está uma gravação do spoiler neste tópico: lendo o controle deslizante de tempo na parte inferior do vídeo, depois um espaço em branco (não sei o que é isso), depois o spoiler visível (“botão expandido ocultar conteúdo”) e, em seguida, o menu suspenso “2 respostas”.

Observe que, se eu usar o recurso de depuração do NVDA e passar o mouse sobre o texto expandido para lê-lo, ele lê. Mas não encontrei nenhuma maneira de fazê-lo ler o texto sem usar o mouse. Portanto, isso não parece ser uma maneira válida de testar se ele é realmente acessível…

2 curtidas
17

Fiz um PR com algumas melhorias de acessibilidade:

3 curtidas
19

Obrigado @Dannii pela PR :slight_smile:

Acabei de revisá-la e adicionei alguns comentários, apenas coisas muito pequenas, mas, fora isso, parece bom!

1 curtida
21

Obrigado @Dannii, seu PR foi mesclado :slight_smile: este problema agora deve ser resolvido

2 curtidas