por A11yGuard (LX AI)

Checklist WCAG 2.2 para UI gerada por IA

UIs de LLM falham em acessibilidade de maneiras previsíveis: texto alternativo ausente, divs usados como botões, controles sem rótulo e estados de foco que desaparecem sob cabeçalhos fixos. A WCAG 2.2 adicionou critérios de sucesso que abordam esses problemas de interface gerada. Execute uma primeira passagem automatizada, então verifique a lista de verificação manualmente antes de lançar.

O que a WCAG 2.2 mudou para a interface do usuário gerada

A WCAG 2.2 é baseada na 2.1 e adiciona nove critérios de sucesso voltados para necessidades móveis, de baixa visão e de mobilidade. Ela se tornou uma Recomendação da W3C em outubro de 2023; mantenha o texto normativo aberto enquanto você audita (w3.org/TR/WCAG22). Para equipes que enviam componentes gerados por IA, as adições que mais importam são Foco Não Obscurecido (2.4.11), Movimentos de Arrastar (2.5.7), Tamanho Mínimo de Alvo (2.5.8), Ajuda Consistente (3.2.6), Entrada Redundante (3.3.7) e Autenticação Acessível (3.3.8). A maioria das organizações de produtos tem como alvo o Nível AA. As páginas fundamentais da WAI ainda explicam por que essas regras existem além de "passar no scanner" (WAI Fundamentos de Acessibilidade).

Os geradores falham aqui porque otimizam para densidade visual e polimento de demonstração de cliques. Eles diminuem as áreas de ícones, inventam quadros kanban de arrastar apenas, empilham cromo grudento que cobre campos focados e espalham papéis ARIA que não correspondem ao comportamento. A lista de verificação abaixo é ordenada para uma aprovação no dia do lançamento: itens mensuráveis primeiro, itens de julgamento segundo.

Fluxo de trabalho passo a passo antes de enviar

- Congele o branch gerado. Não continue regenerando enquanto mede. - Execute uma varredura de acessibilidade automatizada (axe, Lighthouse ou seu portão de CI) e arquive todos os hits de contraste / nome ausente / ARIA inválido. - Percorra os filtros de referência rápida da WCAG 2.2 para o Nível AA e marque os critérios exclusivos da 2.2 como linhas explícitas em seu ticket. - Passe apenas pelo teclado em todas as jornadas de usuário primárias (cadastro, pagamento, tarefa principal). - Verifique o leitor de tela (NVDA no Windows ou VoiceOver no macOS) em botões de ícones e diálogos. - Registre o risco residual: o que o scanner não pode ver, o que você adiou, quem é o proprietário do follow-up.

O A11yGuard é construído para a primeira passagem mensurável. A conformidade legal e as chamadas de julgamento ainda precisam de um proprietário de QA humano. Se o seu produto usa IA em fluxos de decisão de contratação ou similares, também leia as orientações dos EUA sobre algoritmos e discriminação de deficiência para que a exclusão da UI não seja tratada como um bug cosmético (ADA.gov Orientações de IA).

Contraste que você pode computar, contraste que você não pode

O contraste de texto é a falha mais fácil de detectar: o texto do corpo precisa de 4,5:1 contra o seu fundo; o texto grande precisa de 3:1 (critério1.4.3). Temas gerados frequentemente enviam cinza-em-cinza ou gradientes de placeholder que falham. Medir contra o fundo renderizado, incluindo imagens e sobreposições.

O contraste de não-texto (1.4.11) é a regra gêmea: as bordas dos componentes da interface do usuário, ícones necessários para entender o controle e indicadores de foco devem atingir 3:1 contra as cores adjacentes. Um botão desenhado com apenas uma borda fraca ou um anel de foco definido para uma linha de baixa opacidade falha, mesmo quando o texto do rótulo passa. As interfaces de usuário de gráficos e painéis atingem o mesmo muro; a Smashing Magazine documenta como os padrões de acessibilidade reformulam o design visual de gráficos sem exigir ruído decorativo (padrões de acessibilidade para design de gráficos).

Lista de verificação — contraste

- Cópia de corpo ≥ 4,5:1 em todos os temas (incluindo modo escuro) - Texto grande / numerais grandes ≥ 3:1 - Anel de foco ≥ 3:1 contra a superfície atrás dele - Afirmações de ícone apenas ≥ 3:1 quando o glifo carrega significado - Nenhuma dependência de cor apenas para estado de erro ou sucesso (parear com texto ou ícone)

Tamanho de destino e arrastar após WCAG 2.2

Tamanho Mínimo de Destino (2.5.8) exige destinos interativos de pelo menos 24×24 pixels CSS no nível AA, com exceções limitadas para links inline e certos casos de espaçamento. Layouts de IA comumente produzem botões de ícone de16pixels sem preenchimento. Isso agora é uma questão de conformidade, não um debate de gosto. Preenchimento, min-width/min-height ou maior hit-slop ao redor do glifo visível contam se o destino do ponteiro atende ao tamanho.

Movimentos de Arrastar (2.5.7) significa que qualquer interação de arrastar — polegar de slider, cartão kanban, scrubber de faixa — precisa de uma alternativa de um único ponteiro, como botões de seta, entrada numérica ou clique para definir. Se um usuário não puder concluir a tarefa sem arrastar, o padrão não está em conformidade. Geradores adoram demos de arrastar porque parecem interativos em um GIF; envie o controle alternativo no mesmo PR.

Lista de verificação — acesso de ponteiro

- Área de destino de cada botão de ícone ≥ 24×24 CSS px - Destinos adjacentes têm espaçamento suficiente ou compartilham uma exceção em conformidade - Cada gesto de arrastar tem um caminho não-arrastar documentado na interface do usuário - Destinos de toque ainda funcionam quando o tamanho de texto do sistema operacional aumenta

Ordem de foco, chrome fixo e 2.4.11

Foco não obscurecido (Mínimo) exige que, quando um controle recebe foco de teclado, não esteja completamente oculto por conteúdo criado pelo autor. Cabeçalhos fixos, barras de navegação inferiores, banners de cookies e widgets de "Ajuda de IA" flutuantes são os principais ofensores em aplicativos codificados por vibração. Navegue pela página com essas camadas abertas. Se o campo focado estiver sob uma barra fixa de 72px, ajuste o preenchimento de rolagem ou a empilhamento, não a visão do usuário.

Também confirme 2.4.7 (Foco Visível): todos os elementos interativos mostram um indicador de foco visível. Geradores muitas vezes removem contornos "por estética." Restaure um anel de alto contraste que atenda à 1.4.11.

Lista de verificação — foco

- Foco visível em links, botões, entradas, widgets personalizados - Ordem de foco coincide com a ordem de leitura para os principais fluxos - Modais capturam foco e o retornam ao invocador ao fechar - UI fixa/nunca cobre completamente o controle focado (2.4.11) - Link de pulo presente e funcionando em páginas com muito conteúdo

ARIA: HTML semântico primeiro, ARIA em segundo lugar

Geradores inventam papéis ARIA que não correspondem ao comportamento ou adicionam role="button" a elementos que já são links. Prefira elementos nativos: <button>, <a>, <nav>, <main>, controles de formulário. ARIA preenche lacunas; não substitui a semântica. Papéis não coincidentes confundem leitores de tela e podem ocultar a ação real. Trate cada atributo aria-* gerado como uma afirmação a ser verificada.

Quando você realmente precisa de um widget personalizado, siga um padrão publicado do Guia de Práticas de Autoria ARIA e verifique papéis/estados contra WAI-ARIA 1.2. Copiar e colar uma string de papel de um resposta de chat sem suporte de teclado é como o "marcação acessível" se torna comportamento inacessível.

Por que as verificações automatizadas capturam apenas parte do quadro

A prática da indústria e a documentação dos fornecedores comumente colocam a cobertura automatizada na faixa de aproximadamente 30–40% dos problemas de acessibilidade do mundo real. As ferramentas encontram texto alternativo ausente, muitas falhas de contraste e ARIA inválido. Elas não podem julgar completamente se a ordem de foco corresponde à ordem de leitura, se existem alternativas de arrastar ou se o nome de um botão de ícone é compreensível. Essa lacuna é por que um score limpo do Lighthouse não é prova de conformidade com o WCAG 2.2. Combine uma primeira passagem automatizada com testes de teclado e uma revisão manual da marcação gerada.

Não cite um único percentual como lei; trate-o como uma suposição de planejamento: os scanners são necessários e insuficientes. Orçamento tempo humano para a camada de julgamento a cada lançamento.

Erros comuns que as equipes cometem com a AI UI

- Regenerar após correções manuais sem bloquear tokens ou primitivos, então o contraste e os nomes desaparecem - Confiar na gravação da demonstração (somente mouse) como evidência de que o caminho do teclado funciona - Empilhar ARIA para silenciar um linter em vez de corrigir o tipo de elemento - Enviar gradientes de marketing que nunca foram medidos no DOM ao vivo - Chamar um build verde de CI de "conforme" em decks de vendas — essa linguagem superestima

Critérios de decisão: AA agora vs depois

Lançar bloqueadores para a maioria dos aplicativos B2B em AA:

- Nomes acessíveis vazios em ações primárias - Texto do corpo abaixo de 4,5:1 no tema padrão - Nenhum caminho de teclado por meio do checkout ou da tarefa central - Foco totalmente oculto por UI grudenta em campos obrigatórios - Ações críticas apenas arrastáveis sem alternativa

Deferir apenas com um proprietário e uma data: animações decorativas secundárias, gráficos não críticos com uma tabela de dados alternativa já presente, polimento do widget de ajuda que não bloqueia tarefas. Deferido não é esquecido.

O que isso NÃO é

Esta lista de verificação não é uma auditoria completa da WCAG, não é um VPAT e não é um conselho jurídico. Ela não afirma que o A11yGuard (ou qualquer ferramenta) garante a conformidade, a conformidade com a ADA ou que as varreduras automatizadas "nunca perdem" problemas. Nós não publicamos métricas de clientes inventadas ou melhorias de conversão antes/depois. O produto automatiza a primeira passagem mensurável; você ainda precisa de QA humano para critérios de julgamento e para linguagem de assinatura usada com clientes ou reguladores.

Encerramento

Imprima as tabelas, congele o branch, execute o scanner e, em seguida, faça a passagem do teclado e da nomenclatura. Mantenha o texto normativo do WCAG e a Referência Rápida abertos enquanto discute casos de borda. Quando o modelo regenerar uma tela, execute a mesma lista — a dívida de acessibilidade em aplicativos com código de vibe é um loop, não um projeto de uma vez.

Referências

- WCAG 2.2 - Referência Rápida do WCAG 2.2 - Fundamentos de Acessibilidade da WAI - Guia de Práticas de Autoria ARIA (APG) - WAI-ARIA 1.2 - Smashing Magazine — padrões de acessibilidade e design de gráficos - ADA.gov — orientação sobre IA e discriminação de deficiência