Open HbLuca opened 5 months ago
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!
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.
É ideal que usemos a tags de landmarks para identificar as partes das páginas. Especificamente, podemos usar:
nav
, para identificar a barra de navegação do site;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.
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:
aria-label
.Itens afetados:
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.
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)
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.
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.
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)
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.
Os selos de abrigo verificado também não estão sendo narrados. Acho que uma aria-label resolve isso também.
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 tagh2
, 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 ah2
, ao invés dah3
. Texto auxiliar, como o "Conheça a história do projeto SOS RS", pode usar umap
,small
, ou mesmo umadiv
. 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 oh2
, 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/
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).
Realizei mais testes e identifiquei os seguintes pontos:
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:
h1
, mas era melhor que o primeiro usasse p
(talvez <p><strong>
), e que o segundo usasse small
."Mais informações sobre ${nomeDoAbrigo}"
?button
.h2
; os status dos abrigos ("Abrigo disponível" e afins) podem usar a tag small
.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.
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".
@risaddex Gostaria de uma ajuda na programação? A tarefa acabou ficando bem grande. Eu posso ajudar com as coisas que apontei.
@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.
Show, vou dar uma atenção assim que conseguir também. Devo começar hoje ou amanhã.
Descrição
Realizar o teste de acessibilidade para verificação do que está sendo apresentado na tela de modo falado. Está correlacionado ao https://github.com/SOS-RS/frontend/issues/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
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