Registrando com as APIs Node do axe-DevTools

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Usando o pacote @axe-devtools/logger para registrar resultados de acessibilidade

Not for use with personal data

Existem virtualmente maneiras ilimitadas de aproveitar os resultados de uma análise do Axe DevTools

Todas as análises de acessibilidade orientadas pelo axe-core podem ser configuradas para retornar seus resultados como um objeto JSON. Este formato significa que é fácil de consumir para iniciantes em acessibilidade web, contém a profundidade de informação que especialistas experientes precisam e permite a geração automatizada de relatórios e testes personalizados, mesmo fora de um formato de teste baseado em asserções padrão.

Axe DevTools Logger

Se você não deseja gerar relatórios em um dos formatos oferecidos, mas quer salvar seus resultados em arquivo, a Deque oferece um componente para lidar com isso chamado Axe DevTools Logger. Com este módulo, você pode gravar os resultados dos seus testes em arquivo, em linha com a execução dos seus testes.

Para instalar, ele requer a mesma configuração de informações de autenticação que qualquer outro componente baseado em nodeJS do Axe DevTools. Consulte o guia de instalação para o método que você usou para instalar inicialmente o Axe DevTools para mais informações.

Para instalar o logger, execute o comando npm install @axe-devtools/logger para npm ou yarn add @axe-devtools/logger para yarn.

Usando o Axe DevTools Logger

O logger é importado da seguinte forma:

const { AxeDevToolsLogger } = require('@axe-devtools/logger');

Além disso, você pode importar o pacote usando módulos ES6:

import { AxeDevToolsLogger } from '@axe-devtools/logger';

Uma vez importado, você pode instanciá-lo assim

const logger = new AxeDevToolsLogger('Report Name', '/path/to/a/directory');

Após executar uma análise e gerar um objeto de resultados, você pode registrar o resultado em arquivo com este comando

logger.logTestResult('\<test-name>', results-object);

O arquivo registrado aparecerá no diretório que você especificou ao instanciar o logger, com um nome de arquivo de Test-Reports-<test-name>.json.

Visão Geral dos Resultados

As seções a seguir descrevem os objetos contidos no arquivo JSON de resultados.

Meta

O objeto de resultados começa com algumas informações meta úteis. Isto inclui o nome do teste, o endereço web da página testada, a data e hora em que o teste foi executado, o conjunto de regras axe-core usado e mais.

Constatações

O início dos resultados é demarcado pelo cabeçalho "constatações". Existem quatro tipos de resultados, cada um com seu próprio array. Esses tipos de resultados são inaplicável, incompleto, aprovado e violação. Além disso, há alguns dados específicos do teste localizados imediatamente antes do array de violações.

Inaplicáveis

Inaplicável significa que não havia conteúdo de página relevante para esse teste específico, como testes relacionados a formulários em uma página sem formulários.

Incompletos

Incompletos são testes que foram executados, mas os resultados requerem revisão adicional para determinar em qual categoria os resultados devem ser finalmente classificados. Uma ocorrência comum de incompleto é a verificação de contraste de cores em elementos com fundos de cor variável, onde nem sempre é claro se o contraste suficiente é atendido. Questões nesta categoria não devem ser automaticamente tratadas como violações, pois podem ou não ser. Para usuários com mais conhecimento de acessibilidade, um exame mais profundo desses resultados pode ajudar a encontrar violações adicionais que não podem ser testadas automaticamente.

Aprovados

Este grupo de resultados enumera as regras verificadas que não encontraram quaisquer violações de acessibilidade relacionadas. Associado a cada regra aprovada, haverá um array de elementos da página que foram verificados contra a regra e aprovados.

Violações

O array de violações contém todas as violações de acessibilidade encontradas na análise. Graças à política de zero falsos positivos da Deque, qualquer resultado encontrado aqui é garantido como genuíno. Cada violação contém mais informações sobre o que é a violação, onde ela está na página, sugestões sobre como corrigi-la, e mais. Veja a referência de campo abaixo para mais informações.

Referência de Campo - Aprovados e Violações

Os campos contidos nos objetos aprovados e violações estão enumerados abaixo:

  • description — Cadeia de texto que descreve o que a regra faz
  • help — Texto de ajuda que descreve o teste realizado
  • helpUrl — URL que fornece mais informações sobre os detalhes da violação. Links para uma página no site da Deque University.
  • id — Identificador único para a regra; veja a lista de regras.
  • impact — Quão grave é a violação. Pode ser uma das categorias menor, moderada, séria ou crítica se o teste falhou, ou nula se o teste foi aprovado
  • tags — Array de tags atribuídas a esta regra. Essas tags podem ser usadas na estrutura de opções para selecionar quais regras são executadas (veja os parâmetros de attest.a11yCheck).
  • nodes — Array de todos os elementos testados pela regra
    • html — Trecho de HTML do Elemento
    • impact — Quão grave é a violação. Pode ser uma das categorias menor, moderada, séria ou crítica se o teste falhou, ou nula se o teste foi aprovado
    • target — Array de seletores, onde cada elemento corresponde a um nível de iframe ou frame. Se houver um iframe ou frame, deve haver duas entradas em target. Se houver três níveis de iframe, deve haver quatro entradas em target.
    • any — Array de verificações feitas onde pelo menos uma deve ter passado. Cada entrada no array contém:
    • id — Identificador único para esta verificação. IDs de verificação podem ser os mesmos que IDs de regra
    • impact — Quão grave é essa verificação específica. Pode ser uma das categorias menor, moderada, séria ou crítica. Cada verificação que faz parte de uma regra pode ter impactos diferentes. O impacto mais alto de todas as verificações que falharem é reportado para a regra
    • message — Descrição de por que essa verificação foi aprovada ou falhou
    • data — Informações adicionais específicas do tipo de verificação, que são opcionais. Por exemplo, uma verificação de contraste de cores incluiria a cor de primeiro plano, cor de fundo, razão de contraste, etc.
    • relatedNodes — Array opcional de informações sobre outros nós relacionados a esta verificação. Por exemplo, uma violação de verificação de ID duplicado listaria os outros seletores que têm esse mesmo ID duplicado. Cada entrada no array contém as seguintes informações:
      • target — Array de seletores para o nó relacionado
      • html — Fonte HTML do nó relacionado
    • all — Array de verificações feitas nas quais todas devem ter sido aprovadas. Cada entrada no array contém as mesmas informações que o array any
    • none — Array de verificações feitas nas quais todas não devem ter sido aprovadas. Cada entrada no array contém as mesmas informações que o array any

Além disso, o objeto de resultados JSON facilita a criação de seus próprios testes personalizados. Além das afirmações padrão das violações de acessibilidade, você pode dividir o objeto de resultados por violações, sua gravidade, seu impacto, seu conjunto de regras associado ou por qualquer um dos parâmetros no objeto de resultados. Assim, qualquer dado apresentado no objeto de resultados pode ser testado.

Próximos Passos

A Deque facilita o compartilhamento e a compreensão dos resultados de suas análises com nosso repórter. É configurável para produzir relatórios em HTML, JUnit XML ou CSV e, uma vez configurado, retorna relatórios automaticamente. Veja o guia do repórter para obter informações sobre como configurar e usar o repórter.

Você também pode fazer upload de seus resultados para Axe Developer Hub. Veja Usando a CLI para Enviar Resultados de Acessibilidade para o Axe Developer Hub.