[BUG] Acessibilidade com falhas de audição

[HbLuca]

Descrição

Realizar o teste de acessibilidade para verificação do que está sendo apresentado na tela de modo falado. Está correlacionado ao #181

Problema encontrado

Ao realizar o teste de acessibilidade para verificação do que está sendo apresentado na tela, existem algumas coisas que não estão corretas. Ex: Logo no Inicio escutasse "Notifications F8", não aparece a parte do botão atualizar, não aparece os "três traços" para que seja realizada a leitura, o Buscar por abrigo ou endereço não é identificado, Rua que escuta como "ÉRRE" ou seja fonética da letra ao invés de ser identificado como RUA, os nros de CEP, podem ter a parte escrita com CEP a frente.

Após conversa com Marcos Sanhudo pelo Discord, temos um pouco mais de detalhamento sobre...
A primeira preocupação é que parece que a semântica dos componentes não é narrada (Não é mesmo)
Por exemplo, o leitor não diz que o "SOS Rio Grande do Sul" é um título, ou que o "Filtros" é um botão, com isso a pessoa pode ficar bem desorientada, era ideal que a lista dos abrigos fosse narrada como uma lista, e cada abrigo como um elemento também outra preocupação é testar com múltiplos leitores de tela. (Farei logo menos).

Prioridade

• Grave

Solução proposta

Verificar a parte de front referente a acessibilidade para que da mesma forma que os abrigos e a quantidade de abrigos seja também audível

Ambiente

Mobile - Xiaomi Redmi Note 9S Google Chrome https://stg.sos-rs.com/ com opções do desenvolvedor - selecionar para ouvir e atalho ativo.

Evidência

https://www.loom.com/share/ed7fe03d6d224e5b9070fcbb2a079629?sid=37308bec-3cab-4abf-9ffc-979019888901

[marcossanhudo]

Como @HbLuca já citou, temos alguns problemas semânticos com a página.

Estranhamente, nos meus testes com o narrador nativo do Windows, os headings são corretamente narrados. Porém, temos algumas falhas críticas, detalhadas a seguir. Em caso de qualquer dúvida ou contestação, entre em contato!

Tags incorretas

Na página de um abrigo, algumas informações chave usam a tag h1 para que tenham um texto em negrito. É ideal que use-se, ao invés, uma tag puramente formatativa, como b, strong, span, ou div. A tag h1 não é a melhor, porque ela tem uso semântico: identifica títulos de alto nível, como o da página ou de grandes seções da página. O uso indevido de tags prejudica a navegação com narradores de tela.

Itens afetados: cidade, pessoas abrigadas, capacidade do abrigo, contato, chave Pix.

Tags faltantes

É ideal que usemos a tags de landmarks para identificar as partes das páginas. Especificamente, podemos usar:

• a tag nav, para identificar a barra de navegação do site;
• a tag main, para identificar a parte principal de cada página (como a lista de abrigos, na home; e as informações dos abrigos, nas páginas de abrigos).

Um exemplo visual do uso das tags pode ser encontrado aqui: exemplo do W3C.

O uso destas tags também facilita a navegação com narradores de tela, permitindo que os usuários dos narradores pulem entre diferentes partes da página.

Botões ícone sem descrição textual

Existem botões que contêm apenas ícones, sem texto acompanhando. Isso impossibilita que narradores de tela narrem o sentido desses botões, e tem duas soluções, que podem ser discutidas com a equipe de design:

• incluir um texto no próprio botão;
• manter o botão sem texto, e atribuir a ele algum aria-label.

Itens afetados:

• Na home, os botões do menu hambúrguer, e o de atualizar a página;
• Nas páginas de abrigo, o botão de voltar à home.

Observação: é otimo que estejamos usando SVG's como ícones, ao invés de fontes de ícone; muitas pessoas com dislexia usam extensões de navegadores para alterar a tipografia dos sites que visitam, e nem sempre as fontes mais acessíveis incluem ícones.

[risaddex]

Comecei a fazer alguns ajustes relacionados a Issue.

Alguns pontos:

Esse "Notifications (F8)" é relacionado a lib de toasters (notificaçoesq que aparecem no canto) - F8 é a tecla que o navegador utiliza para focar essa parte onde estão "empilhadas" as notificações. Então o que da pra fazer é só traduzir essa prop mesmo.

A parte da "R. X" ou "Av. Y" Até onde sei é a forma que os endereços são cadastrados no backend. Não há um campo do tipo "Tipo de logradouro" para tal, o que podemos fazer talvez seja atualziar os dados existentes que seguem Esse padrão via algum script no banco.

Ao inspecionar a barra de pesquisa, o navegador chrome diz que ela aparenta estar "acessível". Posso adicionar um "aria-placeholder" para reforçar talvez (?)

Em breve abro um PR ( caso não o façam antes)

[marcossanhudo]

Com relação ao "Notifications (F8)", acho esta uma boa solução; pelo menos não consigo pensar em uma melhor no momento.

Quanto aos tipos dos logradouros, discutimos sobre isso no Discord, e chegamos a essa mesma conclusão. Acredito que teríamos que discutir isso mais a fundo antes de tentar resolver.

Acho ótimo colocarmos o aria-placeholder. Também conversamos sobre isso no Discord, e, na verdade, o ideal era que o "Buscar por abrigo ou endereço" fosse um label, não um placeholder; porém, isso precisaria de uma alteração no design, o que ainda não conseguimos discutir. Então usar o aria-placeholder é uma boa solução, pelo menos por enquanto. Tanto o narrador nativo do Windows, quanto o NVDA, conseguem ler esse atributo.

Mas, na verdade, me referia à barra de navegação que existe como o cabeçalho da página, a barra vermelha onde tem o título do site. Porém, agora, fico na dúvida se a tag nav é a mais apropriada para ela. Vou investigar mais a fundo.

[marcossanhudo]

Seguindo o próprio exemplo que eu linkei no meu primeiro comentário, acredito que a tag header seja a mais apropriada para a barra vermelha, e a nav, na verdade, seja mais apropriada para o menu lateral.

[risaddex]

Abri o PR #261 - Sou um cara mais diurno então caso eu tenha cometido alguma gafe, por favor podem me @ no discord. Ou comentar na PR (deixei e-mails notificando)

[marcossanhudo]

Também precisamos revisar as tags da página "Sobre nós", da página da política de privacidade, e da página dos apoiadores. É ideal que os títulos das páginas usem a tag h1, os títulos das seções das páginas usem a tag h2, e assim sucessivamente.

Na página "Sobre nós", por exemplo, faz mais sentido que o título "Sobre nós" seja marcado com uma tag h1 (como já é), e que os subtítulos "Como tudo começou", "Nossos parceiros", et cetera, usem a h2, ao invés da h3. Texto auxiliar, como o "Conheça a história do projeto SOS RS", pode usar uma p, small, ou mesmo uma div. Era ideal que esta hierarquia fosse seguida em todas as páginas.

Estabelecer esta hierarquia numerada é importante, porque a navegação com um leitor de tela fica confusa se pularmos números. É uma experiência de uso pior se o usuário tiver que adivinhar que nós usamos o h3 sem termos usado o h2, o que ele terá que fazer quando quiser navegar entre as seções das páginas para escolher qual quiser ler.

[marcossanhudo]

Os selos de abrigo verificado também não estão sendo narrados. Acho que uma aria-label resolve isso também.

[risaddex]

Também precisamos revisar as tags da página "Sobre nós", da página da política de privacidade, e da página dos apoiadores. É ideal que os títulos das páginas usem a tag h1, os títulos das seções das páginas usem a tag h2, e assim sucessivamente.

Na página "Sobre nós", por exemplo, faz mais sentido que o título "Sobre nós" seja marcado com uma tag h1 (como já é), e que os subtítulos "Como tudo começou", "Nossos parceiros", et cetera, usem a h2, ao invés da h3. Texto auxiliar, como o "Conheça a história do projeto SOS RS", pode usar uma p, small, ou mesmo uma div. Era ideal que esta hierarquia fosse seguida em todas as páginas.

Estabelecer esta hierarquia numerada é importante, porque a navegação com um leitor de tela fica confusa se pularmos números. É uma experiência de uso pior se o usuário tiver que adivinhar que nós usamos o h3 sem termos usado o h2, o que ele terá que fazer quando quiser navegar entre as seções das páginas para escolher qual quiser ler.

Então, aparentemente o "Sobre nós" hoje é um h2, e os demais títulos são h3. Se o screen reader não tiver um comportamento específico para cada hiearquia de header, enquanto não quebrarmos a semântica (ie: um h2 após um h3) talvez não ocorra este problema. Caso contrário, seria estranho mesmo um "h4" no nada

Em breve subirei as alterações conforme sugerido. o/