Como automatizar testes de acessibilidade com Cypress

No meu postagem anterior, Abordei como adicionar teste de captura de tela no Cypress para garantir que os componentes não mudem acidentalmente com o tempo.

Agora, vou compartilhar como automatizar testes de acessibilidade com o Cypress.

Por que devemos nos preocupar com a acessibilidade?

Resposta curta: porque é a coisa certa a fazer.

Resposta longa: uma web acessível pode ajudar as pessoas com deficiência a melhorar suas vidas.

Existem diferentes tipos de deficiência, incluindo auditivas, cognitivas, neurológicas, físicas, de fala e visuais. E nosso objetivo como criadores de produtos, engenheiros e designers é criar experiências que incluam todas as pessoas.

Também é importante mencionar que a acessibilidade na web também beneficia as pessoas sem deficiências.

Por exemplo, sites acessíveis ajudam as pessoas com habilidades de mudança devido ao envelhecimento ou pessoas com conexões de Internet lentas ou que usam dispositivos com telas pequenas.

E uma deficiência também pode ser temporária. Por exemplo, alguém com um braço quebrado não pode digitar e usar um mouse ao mesmo tempo.

Se você quiser se informar sobre o assunto, posso recomendar o W3C Web Accessibility Initiative (W3C WAI) e Projeto A11Y.

Técnicas de teste de acessibilidade

Existem diferentes maneiras de testar se seu site / aplicativo está acessível. O W3C WAI tem um lista de mais de 140 ferramentas para ajudá-lo a determinar se seu site / aplicativo atende às diretrizes de acessibilidade.

Você também pode adicionar em sua estratégia:

• Teste de usuário real: empresas como Fábula conecte você e as pessoas com deficiência para que sua pesquisa e testes de usuário possam ajudá-lo a cumprir suas metas de conformidade.
• Extensões de navegador: Machado é uma extensão recomendada para Chrome, Firefox e Edge que ajuda a identificar e resolver problemas comuns de acessibilidade.

o motor de acessibilidade do machado é de código aberto e pode ser usado de diferentes maneiras, como mostrará este post.

Antes de começarmos

Eu criei um site de amostra para imitar uma biblioteca de componentes. É um site muito simples criado com Tailwind CSS e hospedado no Vercel e documenta 2 componentes: distintivo e botão.

Você pode verificar o Código fonte no GitHub. O site é estático e está dentro do public pasta. Você pode ver o site localmente executando npm run serve e verificando no navegador http: // localhost: 8000.

Adicionando cipreste e cipreste-machado

Comece clonando o repositório de exemplo. Em seguida, crie um novo branch e instale cipreste, o pacote responsável por amarrar o motor do machado ao Cypress.

git checkout -b add-cypress
npm install -D cypress cypress-axe

Em seguida, crie um cypress/support/index.js arquivo contendo:

import 'cypress-axe'

Essa importação injetará todas as funções de que precisamos para nossos testes.

Criação do teste de acessibilidade

É hora de criar o teste de acessibilidade. Aqui está o plano:

1. Cypress irá visitar cada página (crachá e botão) do projeto.
2. Cypress testará cada exemplo da página. o Página de crachá tem 2 exemplos (padrão e pílula), enquanto o Página de botão tem 3 exemplos (padrão, pílula e esboço).

Todos esses exemplos estão dentro de um <div> elemento com um cypress-wrapper. Essa classe foi adicionada com a única intenção de identificar o que precisa ser testado.

O primeiro passo é criar o arquivo de configuração Cypress (cypress.json):

{
  "baseUrl": "http://localhost:8000/",
  "video": false
}

o baseUrl é o site em execução localmente. Como eu mencionei antes, npm run serve servirá o conteúdo do public pasta. A segunda opção, video desabilita a gravação de vídeo Cypress, que não será usada no projeto.

É hora de criar o teste. No cypress/integration/accessibility.spec.js, adicionar:

const routes = ['badge.html', 'button.html'];

describe('Component accessibility test', () => {
  routes.forEach((route) => {
    const componentName = route.replace('.html', '');
    const testName = `${componentName} has no detectable accessibility violations on load`;

    it(testName, () => {
      cy.visit(route);
      cy.injectAxe();
      
      cy.get('.cypress-wrapper').each((element, index) => {
        cy.checkA11y(
          '.cypress-wrapper',
          {
            runOnly: {
              type: 'tag',
              values: ['wcag2a'],
            },
          }
        );
      });
    });
  });
});

No código acima, estou criando testes dinâmicos com base no routes array. O teste irá verificar cada .cypress-wrapper elemento em relação às regras WCAG 2.0 Nível A.

Existem diferentes padrões / propósitos, como mostra a tabela abaixo:

Você pode encontrar mais informações sobre isso no ax-core docs.

Por último, vamos criar dentro do package.json comando para acionar os testes:

{
  "test": "cypress"
}  

A partir daqui, existem 2 opções: execute o Cypress no modo headless com npm run cypress run ou use o Cypress Test Runner com npm run cypress open.

Opção sem cabeça

Usando npm run test run, a saída deve ser semelhante à próxima imagem:

Os testes serão aprovados, pois os componentes não apresentam problemas de acessibilidade.

Opção de executor de teste

Usando npm run test open, Cypress Test Runner será aberto e você poderá acompanhar passo a passo os testes.

Nosso primeiro marco está concluído. Vamos mesclar este branch para master. Se você quiser ver o trabalho feito até agora, pule no meu Solicitação de pull.

Testando na vida real

Imagine que estamos atualizando o site e queremos identificar os botões com ids. o id a propriedade deve ser única no documento, pois não podemos ter 2 elementos com o mesmo. Mas esquecemos disso e 3 botões têm o mesmo id.

O Cypress falhará e a saída será parecida com esta:

Vamos melhorar a saída de nossos testes, mostrando uma tabela de problemas encontrados. Primeiro, vamos criar um novo branch:

git checkout -b improve-cypress-tests

Em seguida, crie o cypress/plugins/index.js arquivo com o seguinte conteúdo:

module.exports = (on, config) => {
  on('task', {
    log(message) {
      console.log(message)
 
      return null
    },
    table(message) {
      console.table(message)
 
      return null
    }
  })
}

Isso executará o código no Node através do task evento de plugin do Cypress. A seguir, vamos voltar ao accessibility.spec.js arquivo e adicione a seguinte função na parte superior do arquivo:

const terminalLog = (violations) => {
  cy.task(
    'log',
    `${violations.length} accessibility violation${
      violations.length === 1 ? '' : 's'
    } ${violations.length === 1 ? 'was' : 'were'} detected`
  )
  // pluck specific keys to keep the table readable
  const violationData = violations.map(
    ({ id, impact, description, nodes }) => ({
      id,
      impact,
      description,
      nodes: nodes.length
    })
  )
 
  cy.task('table', violationData)
}

o violations array contém todas as informações sobre os elementos com falha. Você pode ajustar esse código para incluir, por exemplo, o código-fonte do elemento na saída do teste.

Por último, vamos chamar a função dentro dos testes. Modifique o checkA11y função para:

cy.checkA11y(
  '.cypress-wrapper',
  {
    runOnly: {
      type: 'tag',
      values: ['wcag2a'],
    },
  },
  terminalLog,
);

Ao executar o teste novamente, você obterá uma tabela contendo os problemas relatados por ax:

Se você tiver alguma dúvida, verifique o Solicitação de pull no Github.

Próximos passos

A partir daqui, você pode continuar sua jornada para tornar os produtos mais acessíveis. Como algumas próximas etapas, eu recomendaria:

• Adicionando esses testes em sua solução de CI – escrevi sobre integrando Cypress dentro do Semaphore
• Encontrar a melhor maneira de personalizar a saída dos testes para melhorar a solução de problemas
• Aprendendo mais sobre como funciona o machado.

Espero que você tenha aprendido que o teste de acessibilidade não é difícil e não exige muito para começar. A automação movida a machado pode definitivamente nos ajudar a criar melhores experiências de usuário para todas as pessoas.

–

Questões? Comentários? Esta postagem também está em meu blog. Se você gostou deste conteúdo, siga-me no Twitter e GitHub.