Glossário do Axe Developer Hub

a11y

Abreviação baseada em número (ou numerônimo) para a palavra "acessibilidade", com "11" (onze) representando o número de caracteres entre o "a" inicial e o "y" final em acessibilidade. Pronunciado como ally.

Chave API

Para autorização, você gerará um chave de API nas Configurações de Conta Axe. Você pode usar a mesma Chave de API para múltiplos projetos, embora deva usar uma Chave de API do Axe Developer Hub apenas para projetos web e uma Chave de API do Axe DevTools Mobile apenas para projetos móveis.

Axe Developer Hub

Axe Developer Hub permite que você crie novos projetos de teste e mostra os resultados de suas execuções de teste de acessibilidade. Você pode criar quantos projetos precisar para visualizar e gerenciar a acessibilidade em seus sites e aplicativos móveis.

Linha de Base

Uma linha de base é a varredura inicial que o Developer Hub mantém constante para que uma comparação possa medir o que mudou. Qual varredura serve como linha de base depende do tipo de comparação: uma comparação entre branches usa a última execução de pipeline no branch padrão, e uma comparação dentro do branch, junto com a Ação do GitHub, usa a varredura do commit anterior que tem resultados no mesmo branch.

Melhores Práticas

As melhores práticas da Deque são técnicas comprovadas que produzem resultados de acessibilidade desejados quando métodos formais específicos estão em falta ou são insuficientes. Embora não estejam oficialmente incluídas em nenhum conjunto de regras de acessibilidade estabelecido, seguir as melhores práticas da Deque pode melhorar a acessibilidade e a qualidade geral da página web testada. Vale ressaltar que o não cumprimento das diretrizes de melhores práticas da Deque não indica automaticamente uma falha. Além disso, é necessário julgamento especializado para considerar a adequação no contexto dos objetivos da aplicação, site ou página. Às vezes, a melhor prática de acessibilidade não é aplicável ou prática para resolver um problema específico. Veja Melhores Práticas para as regras que compõem o conjunto de regras de melhores práticas.

ID de Construção

O ID de construção é gerado automaticamente como um UUID quando não fornecido pelo usuário, e é usado para vincular escaneamentos como uma única sessão de teste. Ao executar uma suíte de testes em várias máquinas ou ambientes, fornecer um ID de build ligará todas essas execuções e será exibido como uma única sessão no Developer Hub.

Comparação entre Branches

Uma comparação entre branches compara a última varredura de um branch com a última execução de pipeline no branch padrão do projeto. Ela aparece na visualização de Branches e mostra o que mudaria se o branch fosse mesclado agora.

Duplicado

Um duplicado é o mesmo problema de acessibilidade visto no mesmo nó do modelo de objeto de documento (DOM) em múltiplos estados de página. Se você corrigir um problema com duplicatas, todas as suas duplicatas desaparecerão porque são todas o mesmo problema.

Dois resultados são tratados como o mesmo problema quando todos os três critérios a seguir coincidem:

• A regra que foi violada.
• O elemento. O Axe Developer Hub identifica o elemento pelo seu seletor CSS e seu XPath, e também pelo seletor de ancestralidade quando ancestry está habilitado; uma correspondência em qualquer um desses já é suficiente.
• A URL da página, comparada na íntegra, incluindo qualquer string de consulta.

Mais nada é comparado. Em particular, o título da página e o HTML do elemento não têm impacto sobre se um resultado é tratado como duplicado.

A desduplicação aplica-se atualmente apenas a projetos web. Os resultados móveis não têm seletor CSS, portanto, essa comparação nunca coincide, e cada resultado móvel é tratado como novo em todas as comparações, sem opção para alterar isso.

A mesma comparação determina se um resultado web é novo: um resultado que não corresponde a nada no linha de base aplicável é contado como novo. Veja Por que os mesmos problemas continuam sendo reportados como novos? para saber como corrigir isso.

Teste e2e

Teste de ponta a ponta, ou e2e, refere-se a testar toda a funcionalidade do aplicativo web testando sua implementação no mundo real. Com o Axe Developer Hub, você pode testar cenários e2e para problemas de acessibilidade.

Regras Experimentais

As regras experimentais ainda estão sendo desenvolvidas e testadas para abordar novas tecnologias ou aumentar a compreensão e conscientização sobre questões de acessibilidade. Essas regras não devem ser usadas em ambientes de produção porque ainda estão em desenvolvimento e estão sujeitas a falsos positivos. Eventualmente, regras desse conjunto poderão fazer parte dos padrões de acessibilidade. As regras experimentais estão desativadas por padrão. Consulte Regras Experimentais para as regras que compõem esse conjunto na última versão do axe-core.

repositório Git

Muitos projetos do Developer Hub têm suítes de teste que usam um repositório repositório Git. Usar Git permite que você associe defeitos de acessibilidade ao código em diferentes branches e commits específicos, auxiliando na sua resolução.

Gitless

Gitless refere-se a um projeto do Developer Hub com uma suíte de teste que não usa um repositório Git. Embora não seja necessário, um repositório Git permite associar defeitos de acessibilidade a alterações específicas no código, ajudando na sua resolução.

Impacto

Um nível de impacto é atribuído a cada violação de acessibilidade, categorizado em quatro níveis do menos ao mais impactante: leves, moderadas, graves e críticos. Essa métrica ajuda a priorizar os esforços de remediação, e os especialistas em acessibilidade da Deque atribuem um nível de impacto a cada tipo de violação por padrão.

Defeitos com níveis de impacto graves ou críticos apresentam barreiras significativas ou intransponíveis para usuários com deficiência, com a maior responsabilidade legal. Embora questões nos níveis leves e moderadas não sejam tão graves, ainda são cruciais para conformidade e para atender às necessidades daqueles com deficiência.

Os quatro níveis usados para categorizar o impacto das questões de acessibilidade são:

1. Leve: Questões que afetam usuários com deficiência menos que questões moderadas, mas ainda requerem resolução para conformidade total.

2. Moderado: Existem algumas barreiras para usuários com deficiência, mas não impediriam que eles acessassem conteúdos ou fluxos básicos. Essas questões podem deixar sua organização vulnerável a ações legais e devem ser corrigidas antes de alcançar a conformidade total.

3. Grave: Usuários com deficiência enfrentarão barreiras significativas ao interagir com o site, causando frustração e dificuldade em acessar conteúdo relacionado. A remediação deve ser uma alta prioridade para evitar ações legais.

4. Crítico: Usuários com deficiência são completamente impedidos de acessar ou interagir com um recurso na página web, tornando o conteúdo inacessível e deixando sua organização altamente vulnerável a processos judiciais. A remediação de questões críticas deve ser uma prioridade máxima.

Suíte de Teste Modificada

Um suíte de teste modificada é uma suíte de testes que você modificou de acordo com as instruções fornecidas pelo Axe Developer Hub ao criar um novo projeto. Modificar sua suíte de testes permite adicionar testes de acessibilidade à sua suíte de testes existente com mudanças mínimas na própria suíte.

Administrador Organizacional

Um administrador organizacional (admin org) é um usuário com privilégios administrativos para toda a sua empresa na Conta Axe. Admins org podem visualizar todos os projetos em sua empresa e gerenciar membros e configurações de projetos, independentemente de serem membros de um determinado projeto. O status de admin org tem precedência sobre os papéis a nível de projeto. Admins org devem ter uma licença ativa do Axe Developer Hub ou Axe DevTools for Mobile para criar novos projetos ou enviar resultados ao Axe Developer Hub, mas podem gerenciar projetos existentes sem uma licença.

Estado da Página

O estado da página refere-se ao estado do modelo de objeto de documento (DOM) de uma página web em um momento específico. Visualizar diferentes estados de página é útil para sites complexos com telas de login ou interfaces dinâmicas, como aplicações de página única (SPAs). Exemplos de estado do DOM incluem:

• A visibilidade dos elementos
• O conteúdo dos elementos
• O estado marcado dos botões de rádio e das caixas de seleção

Ao usar o Watcher, o pacote verifica novamente as páginas da web sempre que detecta alterações no DOM e salva um novo estado da página a cada vez.

Execução de Pipeline

Uma execução de pipeline é uma varredura acionada por um pipeline CI/CD, ao invés de uma execução local de um desenvolvedor. O Developer Hub marca execuções de pipeline separadamente para sempre saber qual varredura de um branch é autorizada. Uma execução de pipeline configurada no branch padrão do projeto é necessária para que comparações entre branches tenham uma linha de base; sem uma, cada problema é reportado como novo. Veja Informações do Pipeline e Observador Axe em Ambientes de Integração Contínua (CI).

Projeto

Um projeto no Axe Developer Hub contém resultados de acessibilidade, informações de execução de testes e dados do Git (branches e commits). Você cria e nomeia um novo projeto no Developer Hub, que cria um ID de Projeto a ser usado com seus testes para identificar o projeto e associar dados de resultados a ele.

Administrador do Projeto

Um administrador do projeto é um membro do projeto com permissões elevadas. Administradores de projeto podem fazer tudo o que um membro de projeto pode, além de gerenciar as configurações do projeto, adicionar ou remover membros e alterar papéis de membros. Ao usar o Axe Watcher, uma chave de API de um administrador de projeto é necessária para executar testes em um pipeline.

ID do Projeto

Um ID do Projeto é gerado automaticamente quando você adiciona um novo projeto, para associar seus dados de resultados a esse projeto. Tanto um ID de Projeto quanto uma chave de API são necessários para enviar resultados de acessibilidade ao Developer Hub. É uma boa prática mapear um ID de projeto para uma suíte de testes/repositório, para rastrear mais precisamente o status de acessibilidade de seu projeto.

Membro do Projeto

Um membro do projeto é um usuário que foi adicionado a um projeto no Axe Developer Hub. Membros do projeto podem executar testes e visualizar resultados dentro do projeto. Os membros devem ter uma licença ativa para acessar o projeto.

Varredura

Uma varredura é o resultado de acessibilidade que o Developer Hub recebe ao testar seu produto, e o que uma varredura cobre varia conforme o tipo de projeto.

Para projetos web, uma varredura é o conjunto completo de resultados que seu conjunto de testes produz em uma execução, independentemente de quantas páginas visita ao longo do caminho, enviado ao Developer Hub via Axe Watcher, Axe DevTools for Web CLI ou as APIs da Web, que fazem o upload através do CLI. Cada página que verifica pode produzir um ou mais estados de página, um para cada estado distinto do DOM detectado, como uma aplicação de página única mudando de estado sem um recarregamento da página; a varredura é a coleção completa dos estados das páginas dessa execução.

Para projetos móveis, uma varredura é o resultado do teste de uma tela única de aplicativo com o Axe DevTools Mobile Analyzer. Testar várias telas em uma única sessão produz várias varreduras, que são agrupadas em uma única sessão.

SHA

Quando você cria um commit com o Git, ele cria um ID para identificar exclusivamente o commit. Este ID único é chamado de SHA (em homenagem aos Algoritmos de Hash Seguro, um grupo de funções hash criptográficas).

Tag

Um tag agrupa regras que pertencem a uma diretriz específica de acessibilidade, como WCAG. Para mais informações sobre as regras e as tags a que essas regras pertencem, veja Descrições das Regras do axe-core

WCAG

WCAG, ou Diretrizes de Acessibilidade para Conteúdo da Web, são um conjunto de diretrizes desenvolvidas pelo World Wide Web Consortium (W3C) para ajudar a tornar o conteúdo web mais acessível a pessoas com deficiência. Essas diretrizes fornecem uma estrutura para criar sites e conteúdos digitais acessíveis que possam ser usados por pessoas com uma ampla gama de deficiências.

Os três níveis de conformidade da WCAG são definidos por um conjunto de critérios de sucesso que descrevem elementos específicos de conteúdo da web que devem ser atendidos para alcançar esse nível de conformidade. O nível de conformidade A é o nível mínimo de conformidade, enquanto o nível de conformidade AAA é o mais rigoroso. O nível de conformidade AA exige conformidade com os critérios de sucesso dos níveis A e AA. A conformidade com os três níveis de critérios de sucesso (A, AA e AAA) é necessária para a conformidade com o nível AAA.

A WCAG 1.0 foi a primeira versão dessas diretrizes e foi publicada em 1999. A WCAG 2.0 foi publicada em 2008 e forneceu diretrizes mais abrangentes para tornar o conteúdo da web acessível a pessoas com uma gama mais ampla de deficiências.

A WCAG 2.1 foi publicada em 2018. Ela se baseia nas versões anteriores e inclui novos critérios de sucesso para abordar questões de acessibilidade que surgiram desde o lançamento da WCAG 2.0. A WCAG 2.1 também fornece mais orientação sobre acessibilidade móvel, acessibilidade para baixa visão e deficiências cognitivas e de aprendizagem.

A WCAG 2.2, a versão mais recente dessas diretrizes, foi publicada em 2023 e oferece nove novos critérios de sucesso em relação à WCAG 2.1. Ela fornece orientação aprimorada para atender às necessidades de usuários com deficiências cognitivas ou de aprendizagem, usuários com baixa visão e usuários com deficiência em dispositivos móveis. Ela é compatível retroativamente com a WCAG 2.1.

Comparação Dentro do Branch

Uma comparação dentro do branch compara a varredura de um commit com a varredura do commit anterior que tem resultados no mesmo branch. Ela aparece na visualização de Commits e mostra o que um commit específico introduziu ou corrigiu.