Questão 1: Navegação de Título Quebrada / Manipulação de DOM

[adress (Angela Dresselhaus)]

Problema: Os elementos de postagem de resposta não são exibidos inicialmente no Modelo de Objeto de Documento (DOM) no carregamento inicial da página e são removidos do DOM após o leitor de tela passá-los, fazendo com que os leitores de tela do Windows percam o acesso ao conteúdo e o VoiceOver tenha acesso limitado às ferramentas que podem ser usadas para acessar a página.

Comportamento Específico:

● Ao tentar navegar da postagem principal para as postagens de resposta, os elementos usados nas postagens de resposta ainda não foram renderizados no DOM, portanto, os usuários não podem usar a navegação rápida para navegar até qualquer elemento em qualquer postagem de resposta.

● Postagens de resposta individuais são marcadas como nível de título 2 no DOM apenas quando o leitor de tela está focado nelas, exigindo que os usuários naveguem por todos os elementos da página para chegar às postagens de resposta.

● A ferramenta de acessibilidade ANDI mostra uma estrutura de título em constante mudança após interações com elementos.

● Os elementos mostram erros de “removido do DOM” ao tentar acessá-los.

● O leitor de tela perde a visão consistente da estrutura da página.

Detalhes da Plataforma:

● JAWS/NVDA: Falha completa - não é possível acessar os títulos de resposta.

● VoiceOver: Acesso via navegação rápida, mas sem acesso ao rotor - como o VoiceOver funciona lendo a página diretamente, os usuários podem navegar pelos títulos de resposta usando as teclas de navegação rápida, no entanto, apenas os elementos em que o leitor de tela está focado são acessíveis dentro do rotor.

Por que é Crítico: Usuários de leitores de tela não conseguem completar a tarefa principal de ler as respostas das discussões. Esta é uma barreira total para participar de discussões.

[adress (Angela Dresselhaus)]

Estes problemas foram relatados pela primeira vez em Screen Reader Accessibility issues . Por favor, ajude na resolução, temos toda uma comunidade de usuários cegos e com baixa visão incapazes de completar funções básicas no fórum de discussão.

[awesomerobot (Kris)]

Obrigado por relatar isso!

Você sabe em qual(is) tópico(s) isso foi testado especificamente? Seria útil ter uma referência compartilhada para garantir que estamos vendo os mesmos problemas, pois existem muitas variações no conteúdo das postagens, então gostaria de ter certeza de que estamos focando nossos esforços no lugar certo.

Poderíamos usar o try.discourse.org, ou podemos usar uma postagem aqui no Meta como referência, se isso ajudar.

@adress

portanto, os usuários não conseguem usar a navegação rápida para navegar para nenhum elemento em nenhuma postagem de resposta.

Por “navegação rápida”, parece que você está se referindo especificamente a listas de elementos? Posso confirmar que tanto no NVDA quanto no VoiceOver, apenas o conteúdo atualmente disponível no DOM pode ser acessado nas listas de elementos, isso também é verdade para usuários videntes e é uma parte fundamental de como o Discourse funciona. Em vez de paginação manual, carregamos/descarregamos conteúdo à medida que alguém rola para cima/para baixo na página.

@adress

exigindo que os usuários naveguem por todos os elementos da página para chegar às postagens de resposta.

É isso que geralmente espero quando alguém menciona “navegação rápida”, embora eu perceba que nem sempre há terminologia consistente entre os aplicativos.

Confirmei que a navegação de elemento para elemento funciona no NVDA e no VoiceOver, mas identifiquei um problema com nossas “postagens pequenas” dentro dos tópicos que pode impedir a continuação da navegação e aplicarei uma correção para isso.

Uma “postagem pequena” é uma atualização de status do tópico, como fixada, fechada/aberta, ativada, etc. O problema com essas é que elas não têm um cabeçalho interno como as postagens regulares, então quando elas caem no limite antes que mais postagens sejam carregadas durante a navegação… um usuário pode ser interrompido e ouvir apenas “nenhum próximo cabeçalho”.

@adress

A ferramenta de acessibilidade ANDI mostra uma estrutura de cabeçalho em constante mudança após interações com elementos.

Ferramentas automatizadas como o ANDI muitas vezes falham em reconhecer as mudanças no DOM em aplicativos web como o Discourse, elas geralmente são construídas para cenários mais simples, como páginas estáticas. Portanto, embora às vezes usemos essas ferramentas para identificar problemas, em cenários mais complexos, como navegação, precisamos nos concentrar no que podemos reproduzir com testes manuais.

@adress

Elementos mostram erros de “removido do DOM” ao tentar acessá-los

O leitor de tela perde a visão consistente da estrutura da página

Presumo que isso também se refira a listas de elementos? Isso é esperado, mas talvez haja uma melhoria que possamos considerar para fazer as listas de elementos funcionarem no Discourse, posso discutir isso com nossos engenheiros para obter sugestões.

@adress

JAWS/NVDA: Falha completa - não é possível acessar os cabeçalhos de resposta

Isso também é especificamente em uma lista de elementos? Como mencionado acima, testei a navegação NVDA e VoiceOver para navegação de elemento para elemento e posso confirmar que isso funciona… mas se houver um contexto específico em que não funciona, podemos investigar mais a fundo.

[adress (Angela Dresselhaus)]

@awesomerobot

Você sabe em qual(is) tópico(s) isso foi testado especificamente?

Latest Expanded Core Curriculum/Mastering the Monarch topics - APH Hive Discussion Board

As atividades expressas foram testadas.

[awesomerobot (Kris)]

Atualização rápida sobre isso, tenho trabalhado para melhorar nossos marcos de uma forma que deve fornecer uma maneira melhor de navegar em uma lista de elementos.

A navegação por títulos em listas de elementos permanecerá inalterada, mas esperamos que isso forneça uma alternativa razoável. As alterações estão descritas aqui: A11Y: improve landmark navigation and add aria-labels to post controls by awesomerobot · Pull Request #34421 · discourse/discourse · GitHub

Em resumo, o que isso faz é:

• Fornecer regiões de marcos para todas as postagens no DOM
• Adiciona uma região de marco que deixa mais claro que há mais postagens acima/abaixo — carregamos/descarregamos postagens para não precisarmos usar paginação manual, se um tópico tivesse centenas de postagens carregadas no DOM de uma vez, isso poderia causar problemas de desempenho.

Tornar todo o conteúdo de títulos acessível no DOM sem degradar o desempenho para todos seria uma mudança muito complicada, então este é um meio-termo. Embora não seja perfeito, navegar para as áreas de “carregar mais conteúdo” carregará corretamente mais postagens, momento em que a lista de elementos pode ser reaberta.

• Fiz uma atualização para mudar os controles de postagem de uma região de navegação para uma região de barra de ferramentas, isso é semanticamente mais preciso e permite que a lista de regiões de marcos se concentre nas postagens.

• Também melhorei a rotulagem nos controles de postagem enquanto estava nisso.

Então, estamos passando de uma lista de elementos de marcos bastante esparsa dentro dos tópicos

Para algo que representa mais claramente a estrutura do tópico

Esta atualização deve ser lançada em algum momento esta semana. Ficarei curioso para ouvir alguns comentários sobre essas mudanças assim que estiverem disponíveis @adress!

[Cody_Laplante]

Olá @awesomerobot, fomos contratados pela APH para consultoria de acessibilidade nesta questão. Forneci alguns links de vídeo abaixo mostrando nosso principal problema relacionado a este tópico. Você verá o problema na primeira gravação começando no carimbo de data/hora 08:36 na primeira gravação.
Auditoria de Acessibilidade do Discourse JAWS
Isso não está relacionado à lista de elementos, mas ao que chamaríamos de Teclas de Atalho ou Navegação Rápida, na qual navegaremos para o próximo tipo de elemento HTML (neste caso, títulos).

O problema em corrigir essa questão criando novos marcos é que os marcos são tipicamente reservados para seções de alto nível, então, para um usuário de leitor de tela, navegar entre pequenas seções da página com marcos tiraria o acesso rápido às grandes regiões da página, como o banner de navegação. Isso também viola os padrões WCAG nível A, criando um Bypass Block.

[awesomerobot (Kris)]

Ótimo, obrigado pelos detalhes adicionais! Um vídeo ajudará imensamente - parece que o vídeo está protegido por senha, você pode desbloqueá-lo ou enviar o código para accessibility@discourse.org

[Cody_Laplante]

Sim, desculpe por isso. Aqui está o link com o código de acesso incorporado. Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
Código de acesso: .kBwdK3a

[dkapoor (Dylan Kapoor)]

Olá @awesomerobot, sou colega do Cody e engenheiro de acessibilidade. Dei uma olhada no repositório para diagnosticar o problema. Como você já deve saber, o problema principal parece ser que (1) o conteúdo em posts ocultos não é visualizável por leitores de tela e (2) os posts só são exibidos quando estão dentro da visualização de um usuário, de acordo com o PostStreamViewportTracker.

Pensando em uma correção potencial, quero otimizar duas coisas: (1) permitir a navegação de cada post por título com leitores de tela e (2) minimizar as alterações no repositório do Discourse e o impacto no desempenho.

A abordagem que recomendo é manter um wrapper leve para cada post carregado que inclua o H2 semântico usado para navegação por título, enquanto o corpo pesado do post permanece oculto. Isso mantém os títulos estáveis para tecnologias assistivas sem inflar o DOM em toda a página. Quando um usuário chega a qualquer H2 de um post por meio da navegação por título, o leitor de tela aciona uma rolagem de página que, por sua vez, revela o corpo do post no local.

A viabilidade dessa solução depende de quando o próximo bloco de posts é carregado. Uma melhoria opcional é um título sentinela apenas para leitores de tela “carregar mais posts” (semelhante à “região de carregamento” proposta em seu PR) localizado na parte inferior da lista de posts carregados. Quando este título entra em foco ou é selecionado no rotor de títulos, ele carrega o próximo bloco e anuncia a conclusão por meio de uma mensagem aria-live=polite.

[awesomerobot (Kris)]

Obrigado pelo feedback e sugestões, discutiremos isso internamente e voltaremos com uma atualização!

[awesomerobot (Kris)]

@dkapoor

A abordagem que recomendo é manter um wrapper leve para cada post carregado que inclua o H2 semântico usado para navegação por títulos, enquanto o corpo pesado do post permanece oculto. Isso mantém os títulos estáveis para tecnologias assistivas sem inflar o DOM em toda a página. Quando um usuário acessa o H2 de qualquer post por meio da navegação por títulos, o leitor de tela acionará uma rolagem da página que, por sua vez, revelará o corpo do post no local.

Esta é a abordagem em que estamos trabalhando atualmente em A11Y: improve heading-to-heading nav, fix infinite scrolling for screenreaders by awesomerobot · Pull Request #34589 · discourse/discourse · GitHub

Como você sugeriu, estamos adicionando alguns títulos leves apenas para leitores de tela em todos os posts (ocultos ou não), bem como um título que acionará o carregamento de mais posts, juntamente com o anúncio de que o carregamento foi concluído.

Ainda é um trabalho em andamento, então ainda precisará de algum refinamento, mas esperamos ter essa correção disponível para todos em breve.

[awesomerobot (Kris)]

Atualização rápida sobre as expectativas de cronograma: estamos em um congelamento pré-lançamento para a próxima semana ou mais e grande parte de nossa equipe estará em nosso encontro anual… então provavelmente levará algumas semanas antes que essa alteração possa ser implementada.

[awesomerobot (Kris)]

Olá! A partir de 5 de novembro, implementamos uma atualização que deve melhorar a navegação por tópicos usando cabeçalhos. Mais detalhes aqui:

@awesomerobot

Obrigado por relatar isso. A partir de ontem, implementamos uma atualização que tem como objetivo tornar a navegação de posts por meio de cabeçalhos mais confiável. Garantimos que cabeçalhos consistentes estejam disponíveis para cada post e adicionamos cabeçalhos com regiões ativas que anunciarão quando posts adicionais estiverem sendo carregados.