Semana passada, vi uma apresentação sobre shift left com acessibilidade que me chamou minha atenção.
Para quem não conhece o termo, shift left é uma abordagem para garantir a qualidade desde o início. Isso traz diversos benefícios, dentre eles:
- Prevenir bugs;
- Antecipar melhorias;
- Gerar previsibilidade e agilidade;
- Aumentar a confiança do time.
De forma prática, vou te mostrar:
- Ferramentas;
- Abordagens;
- Algumas dicas.
Observação: nossa jornada irá seguir uma pirâmide que faz uma analogia com a famosa pirâmide de testes. Vale lembrar, que ela não é uma representação real da pirâmide de testes.
Vamos lá.
A informação n°1: O teste de acessibilidade automatizado substitui o teste manual?
Não, precisamos deixar isso bem claro. Os testes automatizados são apenas um complemento para uma cobertura maior.
A Deque, fez algumas pesquisas e concluiu que: 57% dos problemas de acessibilidade podem ser detectados em testes automatizados.
Etapa 0: Testes estáticos
Investir tempo em testes estáticos é muito importante. Nessa etapa, podemos encontrar possíveis problemas que seriam identificados lá na frente.
Recomendo usar o axe-linter, ele pode ser integrado com o VSCode e detecta problemas em tempo real.
Imagine o cenário, você esta escrevendo um componente de imagem e esquece o atributo ALT.
O axe-linter emite um alerta informando onde ocorreu o erro e como corrigi-lo.
Além disso, ele permite customizar as regras. Basta definir nas suas configurações.
Etapa 1: Testes unitários
Devemos investir em vários cenários de testes unitários pensando em acessibilidade. Isso irá contribuir para uma abordagem mais robusta.
São testes extremamente objetivos e rápidos de executar.
Uma ferramenta que pode ser utilizada é o jest-axe. Ele é um custom matcher para Jest que inclui validações de acessibilidade.
Um exemplo de um componente <img> sem o atributo ALT inserido.
/**
* @jest-environment jsdom
*/
const { axe, toHaveNoViolations } = require('jest-axe')
expect.extend(toHaveNoViolations)
it('deve demonstrar o uso do matcher', async () => {
const render = () => '<img src="#"/>'
// pass anything that outputs html to axe
const html = render()
expect(await axe(html)).toHaveNoViolations()
})O resultado da asserção seria:
O jest-axe não é a única solução existem diversas, como:
Etapa 2: Testes de componentes
Para ilustrar, vamos pensar em um componente de modal. Ele tem diversos comportamentos específicos como:
- Leitura do conteúdo em telas pequenas, deve ser de 100% da tela;
- Foco inicial deve ser no primeiro elemento focalizável da tela;
- Definir o foco inicial quando a modal abrir.
Deu pra pegar a ideia? Existem diversos cenários, além disso, devemos validar o suporte ao teclado.
Utilizo para esse tipo de teste o Cypress focado nos componentes.
Nesse componente devemos ter o suporte de teclado:
- Tab: deve mover o foco para o próximo elemento focalizável dentro da modal;
- Shift + Tab: deve mover o foco para o elemento focalizável anterior dentro da modal;
- Esc: deve permitir fechar a modal.
Etapa 3: Testes E2E
Os testes E2E auxiliam para identificar possíveis problemas na jornada do usuário. Quando pensamos nessa abordagem de shift left, o E2E cumpre somente o papel de validar os passos do usuário.
Para esse teste utilizo o Cypress outro interessante é o Playwright.
É muito importante não sobrecarregar o E2E com outras responsabilidades. É bem comum sobrecarregar ele com testes de componentes.
Devemos usar o teste E2E com sabedoria, geralmente eles são interessantes em:
- fluxos principais;
- jornadas críticas;
- fluxo de alto valor.
Etapa 4: Testes manuais
No início comentei sobre o valor dos testes manuais. Ele é importante pois valida a experiência real de pessoas com necessidades especificas.
Esses testes são realizados por usuários de leitores de tela, avaliamos coisas como:
- Leitor de telas;
- Zoom;
- Compreensão textual;
- Palavras incomuns;
- Contraste textual e não textual;
- Identificação consistente.
Não adianta ter uma abordagem bonitinha, mas a experiência final ser uma bela de uma porcaria.
Resumindo:
- Use testes estáticos com o axe-linter;
- Crie testes unitários, com o jest-axe ou alguma Testing Library;
- Teste isoladamente os componentes com seus comportamentos específicos;
- Sabedoria ao usar os testes E2E, pequeno gafanhoto;
- Abuse dos testes manuais.
Gostou dessa edição? Adoraria saber sua opinião.
SDG,
Bruno Pulis.