Tentarei isso mais tarde, no entanto, esta não é a solução, pois você não está executando os passos que um leitor de tela real faria. Como me movo para uma postagem específica, pode-se presumir que quero ler essa postagem. Tab não é um comando de leitura, mas uma maneira de mover o foco para o próximo elemento que pode ganhar foco. Um comando de leitura seria usar as teclas de seta para baixo ou o comando SayAll específico para o leitor de tela. Pelo menos a seta para baixo, que é meu comando de leitura preferido, falha, o foco não está onde está visualmente, mas geralmente antes da lista de postagens.
Claro, tab poderia ser a maneira suja de resolver este bug, mas não a solução do bug em si.
Obrigado @thoeg@nolan, muito apreciado. Acho que entendi qual é o problema. Atualmente, estamos usando um elemento span vazio para definir o foco na postagem. Este elemento tem aria-hidden=true e tabindex=-1, e acho que isso torna o elemento invisível para leitores de tela.
Acho que seria melhor mudar o foco para o primeiro elemento focável na postagem. Na maioria dos casos, será o link do nome de usuário, ou seja, o autor da postagem.
Isso faz sentido. Ariahidden deve ocultar o elemento e -1 impede que ele receba foco. Se este elemento recebesse foco para o título do assunto, estaria tudo bem. Seria interessante ver o que aconteceria se você apenas definisse tabindex=0 em vez disso.
Sim, ouvi você @anni_anni, vamos consertar isso. Tentei uma primeira tentativa na semana passada, mas tive que reverter porque teve alguns efeitos colaterais indesejados. Tentarei uma abordagem diferente em breve.
Ok, finalmente, outra tentativa de correção para isso foi mesclada. A implementação atual é definir o foco no primeiro elemento focável em uma postagem, que, na maioria dos casos, será o nome de usuário do autor da postagem. Ao navegar para uma postagem e pressionar Tab, deve parecer assim no Chrome:
Ainda vejo o comportamento antigo e quebrado no Meta e community.fly.io com o Chrome, mas posso confirmar que a correção funciona em nosso site discourse.team. Eles estão executando versões diferentes do Discourse? Estou usando a mesma versão do Chrome com o mesmo perfil.
Hmm, todos os três sites podem estar em versões ligeiramente diferentes do Discourse, mas acredito que todos eles tenham a alteração vinculada acima. O Meta, especificamente, está sempre atualizado com as últimas alterações em nosso branch tests-passed, então estou um pouco preocupado que isso não esteja funcionando aqui…
OK, tenho mais algumas informações para você sobre isso, observado em nosso site discourse.team, onde relatei que isso funcionava.
Se eu clicar em uma postagem totalmente nova que nunca li, não recebo nenhum feedback falado e o foco parece pousar aleatoriamente no que eu presumiria ser a primeira página de postagens.
Se eu clicar em um tópico visitado anteriormente, o foco pousa corretamente e recebo feedback falado.
Esse comportamento parece consistente entre Firefox e Chrome agora. Acho que antes o Firefox colocava o foco corretamente na primeira postagem ao visualizar um novo tópico. Seria bom ter esse comportamento de volta, se possível, para que as experiências de primeira leitura e retorno se comportem da mesma forma. Fico feliz que pelo menos restaure minha última posição de leitura no Chrome agora, já que isso é necessário para o trabalho.
É impressionante que esses comportamentos fossem tão diferentes entre Firefox e Chrome.
Que ótimo saber! De fato, limitei as alterações aqui à navegação para postagens que não são a primeira postagem de um tópico. Para usuários recorrentes, isso geralmente será a navegação para tópicos que você já leu, mas que agora têm novas respostas.
É bom saber disso, acho que temos um caminho para iterar e corrigir isso. Se você puder compartilhar a ordem exata dos comandos que usa, isso também ajudaria.
No meu navegador Chrome normal, se vou para um novo tópico que não li e pressiono Tab, o foco pousa no título do tópico, o que me parece razoável, mas provavelmente não é suficiente para o seu caso de uso.
Obrigado novamente pelo seu feedback contínuo, muito apreciado!
Isso é estranho com Jaws e Chrome e, ao testar um novo tópico no meta, vi um novo comportamento do Jaws. Após pressionar Enter no título do tópico, recebo as informações usuais sobre a página que acabou de carregar, comportamento padrão do Jaws. O mesmo acontecerá quando eu voltar para a lista de tópicos e pressionar Enter no mesmo tópico, o foco é apenas colocado na última postagem lida. Isso parece ter resolvido pelo menos 2 problemas aqui. Não testei o ir para a última postagem na lista de tópicos, mas minha suposição é que isso funcionará.
No entanto, é claro, nem tudo está bom, mas isso pode não estar relacionado. Quando uso o botão Voltar para retornar à lista de tópicos, o foco é perdido, não sou colocado de volta no tópico que abri e estava lendo. Isso pode ser um bug do Jaws/Chrome, já vimos algo semelhante antes, mas também pode ser do seu lado. Terei que verificar com o NVDA.
Acabei de tentar com nvda e chrome e aqui nada funciona, ou seja, não consigo mais simplesmente pressionar enter em nenhum dos títulos de tópicos na tabela. Tenho certeza que isso funcionava antes. Claro que, como sou um usuário do jaws, isso não me incomodará, mas para usuários do nvda é outra história.
Como o nvdadid não funcionou realmente, não consigo testar o problema com o foco ao retornar de um tópico para a lista de tópicos.
O JAWS, no entanto, é confiável aqui, o foco é colocado no topo da página.
No Chrome mais recente em nosso site discourse.team, clicar em um tópico visitado anteriormente me leva de volta para onde parei de ler, e o NVDA anuncia corretamente o título da postagem com foco.
Infelizmente, clicar em um novo tópico não coloca o foco na primeira postagem do tópico. Da mesma forma, usar “h” para tentar colocar o foco na primeira postagem falha. Tenho que encontrá-la manualmente para começar a ler.
Note que a posição parece estar corretamente definida em novas postagens no Firefox. Parece que é apenas o Chrome por algum motivo.
Com tudo igual, fico feliz que a posição seja restaurada em threads anteriores, pois esse é o meu maior ponto de dor. Espero que tenhamos um comportamento consistente e correto em ambos os casos de uso.
Isso também está correto. A implementação atual especificamente ignora a definição de foco se a postagem de destino for a primeira postagem. Tentei adicionar a mesma coisa à primeira postagem, mas isso muitas vezes resultava em rolagem desnecessária ao carregar um URL de tópico e isso era muito perturbador para todos os usuários.
Isso deve funcionar. Farei alguns testes e verei se podemos corrigir isso.
Gostaria de sinalizar outro “papercut” que me incomoda há algum tempo.
Ao postar um novo tópico, o menu suspenso para adicionar tags/categorias é um pouco estranho. Primeiro, o rótulo para mim é “Filtrar por”. Não sei se isso é exibido visualmente ou não, mas levou literalmente anos postando no Discourse antes que eu percebesse que era assim que as tags eram adicionadas. O uso de “Filtrar” para mim implica algo como “filtrar algo da água”, não adicionar uma nova coisa. Se isso for exibido visualmente, faça o que achar melhor com esse feedback, mas se for apenas para ARIA, pode se beneficiar de algum ajuste.
Em seguida, clicar na lista de tags me dá o que parecem ser botões de rádio. Se eu pressionar Espaço neles (ou seja, de acordo com o padrão de grupo de rádio ARIA), isso parece acionar uma pesquisa. Sim, eu posso pressionar Enter aqui em vez disso, mas estou acostumado a pressionar Espaço para acionar interações de botões porque meus polegares estão bem ali.
Certamente não é um bloqueador, mas é definitivamente mais difícil de descobrir, e tenho que pensar extra para lembrar/reaprender como funciona cada vez que faço uma postagem. Historicamente, eu clicava em categorias individuais, mas isso limitou minha capacidade de usar várias tags.
Acho que um ajuste melhor para essa interação pode ser o padrão combobox ARIA. Especificamente, o combobox editável se comporta de uma maneira muito menos confusa. Se eu digitar “A”, posso descer com as setas até “Alabama”. Não é apresentado como um botão de rádio, então minha resposta automática não é pressionar Espaço ali, mas se eu o fizer, ele insere o espaço como esperado. Talvez tudo o que seja necessário seja remover a apresentação do botão de rádio, mas provavelmente também poderia ser menos detalhado sobre as contagens de resultados.
Se eu digitar um emoji na caixa de edição de posts (por exemplo, :)) e o foco for para esse emoji enquanto edito, não consigo usar as setas para cima/baixo para ir para a linha anterior ou seguinte. Tenho que usar as setas para a esquerda/direita para sair do emoji primeiro.
Adivinho que isso se deve ao comportamento de autocompletar? Eu me pergunto se esse comportamento poderia ser desativado em casos onde há apenas uma correspondência, ou a menos que Enter ou outra tecla seja pressionada? Eu entenderia o comportamento de autocompletar para entrada inicial e edições, mas definitivamente tem sido complicado depurar por que não consigo mover o foco em algumas instâncias, e isso parece ser o motivo. Uma espécie de menu suspenso acionado manualmente para edições parece ser a escolha certa aqui.
