por A11yGuard (LX AI)

Lista de verificação WCAG 2.2 para UI gerada por IA

As UIs geradas por LLM falham na 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 alterou para a interface do utilizador gerada

A WCAG 2.2 baseia-se na 2.1 e acrescenta nove critérios de sucesso destinados a necessidades móveis, de baixa visão e de mobilidade. Tornou-se uma Recomendação W3C em outubro de 2023; mantenha o texto normativo aberto enquanto audita (w3.org/TR/WCAG22). Para equipas que enviam componentes gerados por IA, as adições que mais importam são Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) e Accessible Authentication (3.3.8). A maioria das organizações de produtos visa o Nível AA. As páginas fundamentais da WAI ainda enquadram por que estas regras existem para além de "passar no scanner" (WAI Accessibility Fundamentals).

Os geradores falham aqui porque otimizam a densidade visual e o polimento da demonstração de cliques. Eles reduzem as áreas de ícones, inventam quadros kanban apenas arrastáveis, empilham cromo aderente que cobre campos focados e espalham papéis ARIA que não correspondem ao comportamento. A lista de verificação abaixo está 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 a branch gerada. Não continue a regenerar enquanto mede. - Execute uma varredura de acessibilidade automatizada (axe, Lighthouse ou seu portão CI) e arquive cada contraste / nome em falta / hit de 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 apenas 2.2 como linhas explícitas no seu bilhete. - Passe apenas pelo teclado em todas as jornadas de utilizador primárias (inscrição, pagamento, tarefa principal). - Verifique o leitor de ecrã (NVDA no Windows ou VoiceOver no macOS) em botões de ícones e diálogos. - Registe 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 pode ser calculado, contraste que não pode

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

O contraste não textual (1.4.11) é a regra gêmea: as fronteiras dos componentes da interface do usuário, ícones necessários para entender o controlo e indicadores de foco devem atingir 3:1 em relação às cores adjacentes. Um botão desenhado apenas com uma borda tênue 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 de instrumentos atingem o mesmo obstáculo; a Smashing Magazine documenta como os limiares de acessibilidade redefinem 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 em relação à superfície atrás dele - Afirmações de ícone apenas ≥ 3:1 quando o glifo carrega significado - Nenhuma dependência apenas da cor para estado de erro ou sucesso (emparelhado com texto ou ícone)

Tamanho do alvo e arrastar após WCAG 2.2

Tamanho Mínimo do Alvo (2.5.8) exige alvos 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 comuns produzem botões de ícone de 16 pixels sem preenchimento. Isso agora é uma questão de conformidade, não um debate de gosto. Preenchimento, min-width/min-height ou maior hit-slop em torno do glifo visível contam se o alvo do ponteiro atender ao tamanho.

Movimentos de Arrastar (2.5.7) significa que qualquer interação de arrastar — polegar de slider, cartão kanban, controle de scrub — 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 ao ponteiro

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

Ordem de foco, chrome fixo e 2.4.11

O Focus Not Obscured (Mínimo) exige que, quando um controlo recebe foco de teclado, não esteja completamente escondido por conteúdo criado pelo autor. Os cabeçalhos fixos, barras de navegação inferiores, banners de cookies e widgets de "Ajuda de IA" flutuantes são os principais ofensores em aplicações codificadas por vibração. Navegue pela página com essas camadas abertas. Se o campo focado estiver sob uma barra fixa de 72px, corrija o preenchimento de rolagem ou a empilhamento, não a visão do utilizador.

Confirme também o 2.4.7 (Focus Visível): todos os elementos interativos mostram um indicador de foco visível. Os geradores muitas vezes removem contornos "por estética." Restaure um anel de alto contraste que atenda ao 1.4.11.

Lista de verificação — foco

- Foco visível em links, botões, entradas, widgets personalizados - A ordem de foco corresponde à ordem de leitura para os principais fluxos - Modais armazenam foco e devolvem-no ao invocador ao fechar - UI fixa/fixa nunca cobre completamente o controlo focado (2.4.11) - Link de saltar presente e funcionando em páginas com muito conteúdo

ARIA: HTML semântico primeiro, ARIA segundo

Os geradores inventam funções 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>, controlos de formulário. O ARIA preenche lacunas; não substitui a semântica. Funções mal combinadas confundem leitores de ecrã e podem esconder a ação real. Trate cada atributo aria-* gerado como uma afirmação a verificar.

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

Porque os testes automatizados 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 totalmente 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 é o motivo pelo qual 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, para que o contraste e os nomes desapareçam - Confiar na gravação da demo (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 ou mais tarde

Enviar 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 através do checkout ou da tarefa principal - Foco totalmente ocultado por UI stick 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 isto não é

Esta lista de verificação não é uma auditoria completa do WCAG, não é um VPAT e não é um conselho jurídico. 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ã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 a branch, execute o scanner e, em seguida, faça a passagem do teclado e da nomenclatura. Mantenha o texto normativo da WCAG e a Referência Rápida abertos enquanto discute casos de bordo. Quando o modelo regenerar uma tela, execute a mesma lista — a dívida de acessibilidade em aplicativos com vibe codificado é um loop, não um projeto de uma vez.

Referências

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