[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/

[marcossanhudo]

Ah, perdão, li errado. Mesmo assim, é melhor que comecemos a partir do h1 pelo mesmo motivo: o usuário teria que adivinhar que começamos com o h2 (ou qualquer outro posterior).

[marcossanhudo]

Realizei mais testes e identifiquei os seguintes pontos:

Nas páginas em geral

Era interessante que os <title>'s das páginas refletissem cada página, já que estas tags são usadas para narrar a aba exibida, quando o usuário troca abas ou aplicações. De preferência, com a página, sufixada pelo site.

Exemplos:

• "Home - SOS Rio grande do Sul"
• "${nome do abrigo} - SOS Rio Grande do Sul"
• "Sobre nós - SOS Rio Grande do Sul"
• "Política de Privacidade - SOS Rio Grande do Sul"
• "Apoiadores - SOS Rio Grande do Sul"

Na home

• Os textos de quando a busca não encontra resultados usam h1, mas era melhor que o primeiro usasse p (talvez <p><strong>), e que o segundo usasse small.

• Os chevrons (as flechinhas no canto superior direito) dos cards dos abrigos não têm uma label; enquanto isso não interfere na leitura corrida da página, interfere se o usuário estiver pulando de botão em botão; talvez colocamos uma aria-label "Mais informações sobre ${nomeDoAbrigo}"?

Nas páginas de abrigos

• O botão "copiar" das chaves Pix precisa ser definido como um botão, preferivelmente com a tag button.
• Os textos "Sobre o abrigo" e "Itens do abrigo", enquanto nomes de seção, podem usar a h2; os status dos abrigos ("Abrigo disponível" e afins) podem usar a tag small.

Na página "Sobre nós"

• O "Frentes atendidas" era para ser um h2 mas está como um h3.

Acredito que seja interessante estruturar a lista de frentes como uma ul com seus li's. O nome de cada item pode ser um h4, e os parágrafos podem continuar p's.

Tanto o Windows Narrator quanto o NVDA narram os emoji na lista das frentes atendidas. Como os emoji são apenas decorativos, fica chato ouvir cada um deles, principalmente porque a descrição auditiva deles nem sempre faz sentido com o texto acompanhante. Estou procurando um jeito de fazer com que os narradores os ignorem.

Na página "Apoiadores do projeto"

Precisamos de alguma coisa que narre os nomes de cada apoiador. Atualmente, são apenas links com imagens, sem qualquer narração. Uma aria-label já serve, mas a minha dúvida é como colocá-las. Se os apoiadores vêm de um banco de dados, talvez precisemos de uma coluna nova para os nomes deles. Também era interessante que a lista de apoiadores fosse uma ul, com cada link sendo um li; ou então uma região com a role "list".

[marcossanhudo]

@risaddex Gostaria de uma ajuda na programação? A tarefa acabou ficando bem grande. Eu posso ajudar com as coisas que apontei.

[risaddex]

@risaddex Gostaria de uma ajuda na programação? A tarefa acabou ficando bem grande. Eu posso ajudar com as coisas que apontei.

Irmão, aceito sim. acabei dando preferência no tempo hábil que tinha para uma task do backend (que acabei de enviar pra revisão).

Fique à vontade para criar outro PR a partir desse ou sugerir edições. Devo conseguir ver ao fim da noite.

[marcossanhudo]

Show, vou dar uma atenção assim que conseguir também. Devo começar hoje ou amanhã.