Todas as coleções
Material Educativo
Requisitos de Relatório de Acessibilidade
Requisitos de Relatório de Acessibilidade

Como Documentar um Relatório em Testes de Acessibilidade.

Nikola Jonic avatar
Escrito por Nikola Jonic
Atualizado há mais de uma semana

Para esse tipo especial de teste, nosso formulário de bug padrão não oferece campos suficientes para todas as informações necessárias. Além disso, requisitos adicionais se aplicam aos relatórios de acessibilidade para além dos requisitos para relatórios de bugs regulares, conforme descrito nos artigos da academia sobre Requisitos de Relatório de Bug e Anexos de Relatório de Bug.

Obrigações adicionais que cada relatório de acessibilidade deve seguir são descritas nos capítulos seguintes. Dois exemplos são fornecidos no final do artigo para ilustrar relatórios de acessibilidade com regras aplicadas.

Título

O título do seu bug deve seguir o formato abaixo, dependendo do nível de acessibilidade (A ou AA) e do ponto de verificação de sucesso WCAG:

Questões de Nível A

Questões de Nível AA

[A] [Critério de sucesso WCAG]: <título do bug>

[AA] [Critério de sucesso WCAG]: <título do bug>

[A] [1.1.1]: A imagem significativa não tem atributo alt

[AA][4.1.2]: Link de saída anunciado sem função

O espaço reservado deve ser substituído por uma descrição do seu bug que você usaria para relatórios de bugs regulares. Por exemplo:

  • [A] [1.1.1] Links de redes sociais são anunciados incorretamente

Aqui estão exemplos de títulos de bugs para os problemas de acessibilidade mais comuns. Sinta-se à vontade para usá-los e ajustá-los conforme necessário:

  • [A] [4.1.2] Link de saída anunciado sem função

  • [A] [2.4.3] Botão de alternância de filtro anunciado com estado incorreto

  • [A] [2.4.2] Título da página não é único e descritivo

  • [AA] [2.4.7] Contorno de foco não é visível para o link do tester abaixo do botão de login

Passos para Reproduzir

Em geral

Primeiro passo: Além de chamar a URL de teste, inclua o nome da ferramenta que você usou no seu primeiro passo. Substitua o espaço reservado <tool> por, por exemplo, NVDA, JAWS, WAVE, etc., no seguinte modelo:

  1. Usando <tool>, abra <URL do teste>, por exemplo, Usando NVDA, abra https://www.test.io

Múltiplos elementos: Se um ponto de verificação falhar para vários elementos do mesmo tipo (por exemplo, botão ou link), agrupe essas repetições em um relatório.

Múltiplas ocorrências: Para documentar múltiplas ocorrências idênticas de um problema na mesma página ou em páginas diferentes, liste-as em seu resultado atual em uma seção chamada ❝Outras ocorrências:❞.

Ações Descritas: Como pessoas com deficiência visual ou cegas não usam um mouse de computador, evite descrever ações do mouse. Em vez disso, foque em descrever ações de teclado e touchpad, tais como:

  • Use a tecla TAB para navegar até Conta do Usuário.

  • Pressione a tecla ENTER para ativar o link de saída.

  • Deslize para a esquerda para focar no menu hamburguer.

Ferramentas Automatizadas: Embora você possa utilizar ferramentas como o WAVE para identificar problemas, seu relatório, incluindo os passos, deve ser descrito do ponto de vista do usuário. Evite descrever como você utiliza uma ferramenta automatizada e o que ela relata. Em vez disso, descreva tudo como se não tivesse usado nenhuma ferramenta, apenas com base nos pontos de verificação WCAG.

Problemas de Contraste de Cor

Seus passos devem ser os seguintes (substitua os espaços reservados):

  1. Abra <URL do teste>

  2. ...

  3. ...

  4. Meça a taxa de contraste de cor de <nome do elemento>

Problemas com o mesmo conjunto de cores só podem ser relatados uma vez. Por exemplo, um problema com texto azul em fundo branco e texto branco em fundo azul é o mesmo conjunto de cores e não pode ser enviado duas vezes.

Resultado Atual

No campo de resultado atual, além do resultado atual típico que você deve inserir em testes exploratórios regulares, forneça qual ponto de verificação falhou. Por exemplo:

Pontos de verificação falhados do WCAG 2.1: 1.3.2 (Nível A).

Anexos

O tipo de anexo necessário depende do tipo de problema de acessibilidade:

  • Contraste de cor: captura de tela.

  • Todos os outros problemas: gravação de tela.

Capturas de tela: Assim como nos testes regulares, o problema deve ser destacado nas capturas de tela.

Gravações de tela: Ao gravar sua tela, reduza a velocidade de suas ações antes de atingir o elemento que apresenta o problema. Se você realizar ações muito rapidamente durante a gravação, o visualizador pode perder o problema. Se isso ocorrer, o TL (Team Leader) pode solicitar uma gravação aprimorada.

Problemas de Navegação por Teclado

Sua gravação de tela deve incluir as teclas que você pressionou no teclado. Caso contrário, os espectadores não poderão entender o problema. Ative o teclado na tela em seu computador, disponível tanto para Windows quanto para macOS. Um teclado virtual será sobreposto em parte da tela, e você pode clicar em um botão para simular a tecla correspondente.

Modelo de Formulário

Atualmente, não temos um formulário específico para relatórios de acessibilidade; enquanto isso, utilizamos o formulário para relatórios de usabilidade. Para garantir uniformidade, é essencial que todos os relatórios sigam um formato padrão. Abaixo, fornecemos um modelo formatado que solicitamos que você utilize.

Basta copiar e colar o modelo no campo de texto único do formulário de usabilidade, substituir os espaços reservados (por exemplo, <tool>, <URL>, etc.) e inserir suas informações.

Notas:

  • Se você não utilizou uma ferramenta para identificar o problema, por exemplo, em casos de Problemas de Navegação por Teclado, siga os passos usuais: Abra <URL>.

  • Caso precise de mais ou menos etapas, ajuste a numeração conforme necessário.

#####Passos
1. Usando <tool>, abra <URL>
2.
3.
4.
5.

#####Resultado Atual
<resultado atual>
**Pontos de verificação falhados do WCAG 2.1**: X.X.X Nível <A/AA>

#####Resultado Esperado
<resultado esperado>


Exemplos

Exemplo de Leitor de Tela

Título:

[AA] [2.4.3]: Foco não retido no modal de menu hamburguer

Passos:

  1. Usando o VoiceOver, abra https://test.io/

  2. Deslize para a direita para focar no menu hamburguer

  3. Toque duplo para ativá-lo

  4. Deslize pelo modal de menu hamburguer expandido e observe

Resultado atual:

O foco continua a se mover pelo conteúdo de fundo atrás do modal, que não faz parte do menu hamburguer sobreposto.

Pontos de verificação falhados do WCAG 2.1: 2.4.3 Nível AA

Resultado esperado:

O foco deve ser retido no modal de menu hamburguer. Elementos ocultos da página subjacente não devem ser focados e anunciados..

Exemplo de Navegação por Teclado

Título:

[AA] [2.4.7] ❝Obter Demonstração❞ não tem contorno de foco visível

Passos:

  1. Usando o NVDA, abra https://test.io/

  2. 2. Pressione TAB para focar no botão ❝Obter Demonstração❞ na seção ❝Você leva a Qualidade Pessoalmente❞ e observe

Resultado atual:

O link "Obter uma Demonstração" na seção "Você leva a Qualidade Pessoalmente" não tem um contorno de foco.

Outras ocorrências: ícones de mídia social

Pontos de verificação falhados do WCAG 2.1: 2.4.7 Nível AA

Resultado esperado:

Elementos acionáveis devem ter contornos de foco visíveis quando estão focados.

Exemplo de Contraste de Cor

Título:

[AA] [1.4.3] Texto branco em fundo azul para o link "Obter uma demonstração" não atende aos requisitos de contraste de cor

Passos:

  1. Role até o link "Obter uma Demonstração"

  2. Meça a taxa de contraste de cor do link "Obter uma Demonstração"

Resultado atual:

O link "Obter uma Demonstração" não atende aos requisitos de contraste de cor. O texto em primeiro plano azul (#21BEF4) no fundo branco (#FFFFF) tem uma taxa de contraste de apenas 2.15:1.

Pontos de verificação falhados do WCAG 2.1: 1.4.3 Nível AA

Resultado esperado:

Textos pequenos devem ter uma taxa de contraste de pelo menos 4.5:1. Textos grandes (negrito com 14 pt ou 18 pt e maiores) devem ter uma taxa de contraste de pelo menos 3:1.

Isto respondeu à sua pergunta?