Cole HTML ou abra um arquivo local para consultar os problemas encontrados. A navegação por teclado e o layout renderizado exigem uma revisão da interface.
Funciona localmente no seu navegadorEsta auditoria de código-fonte não pode inspecionar layout calculado, teclado, estados dinâmicos ou a árvore de acessibilidade real de uma aplicação em execução.
Use os achados como lista de revisão e teste a interface renderizada com teclado, árvore de acessibilidade do navegador e pessoas que usam tecnologias assistivas.
Cole um documento HTML ou um trecho no editor, ou escolha um arquivo local, e pressione Auditar localmente. O relatório é montado apenas a partir da marcação: ids duplicados, atributo lang ausente ou vazio, ausência de landmark main, títulos H1 ausentes ou repetidos, níveis de título que pulam uma etapa, imagens sem atributo alt, controles sem label ou nome acessível, botões e links sem nome, textos de link genéricos, tabelas de dados sem células de cabeçalho, cabeçalhos vazios e iframes sem título.
O painel à direita responde a outra pergunta: a razão de contraste entre duas cores, calculada como o WCAG define. Os dois painéis rodam dentro desta aba, então a página funciona offline e nenhuma marcação, arquivo ou cor é enviada.
Os itens de revisão são falhas demonstráveis a partir do texto: um id que aparece duas vezes, uma imagem sem alt, um controle sem label, aria-label, aria-labelledby ou title utilizável, um botão ou link sem nome acessível, um cabeçalho vazio, um iframe sem título e um elemento com role=button que não recebe foco do teclado. Um label que envolve o controle, o nome padrão que o navegador dá a um input submit ou reset e o alt de um input do tipo image contam como nome, então a marcação válida não é reportada.
Os itens de informação dependem do contexto: um documento sem landmark main, uma ordem de títulos que pula um nível, um link cujo texto é todo uma frase como "click here" e uma tabela sem células th. Merecem revisão, mas nem sempre são erro. Quando não sobra nenhum item de revisão, o relatório diz isso; é uma afirmação sobre esta lista, não uma prova de conformidade com o WCAG.
Cada cor é convertida em luminância relativa com a fórmula sRGB que o WCAG usa (canal dividido por 255 e depois / 12,92 ou ((c + 0,055) / 1,055) ^ 2,4) e a razão é (L1 + 0,05) / (L2 + 0,05); preto sobre branco dá 21:1 e uma cor sobre si mesma, 1:1. A ordem dos dois valores não importa.
Os níveis mostrados são os limites do WCAG: 4,5:1 para texto normal (AA), 3:1 para texto grande e para componentes de interface e gráficos (AA) e 7:1 para texto normal em AAA. Tamanho da fonte, peso e resultado renderizado não entram no cálculo, por isso a página informa o nível alcançado em vez de um veredito. Só valores hexadecimais de 3 ou 6 dígitos são aceitos; rgb(), HSL e nomes de cor recebem uma dica em vez de uma razão.
A auditoria lê a marcação e nunca renderiza o documento. Contraste renderizado, ordem de foco, armadilhas de teclado, estados hover e focus, regiões live, mudanças de estado ARIA, legendas e tudo o que só existe em uma aplicação em execução ficam fora do alcance. Regras automáticas também cobrem apenas parte do WCAG: testes com teclado e leitor de tela, zoom e espaçamento de texto continuam sendo manuais.
O painel de cor verifica um par por vez e não conhece o tamanho da fonte, então trate o nível como um aviso para inspecionar o elemento real. Se uma cor não puder ser interpretada, a linha de contraste do resumo volta a um travessão e a mensagem abaixo dos campos indica o formato esperado.