por A11yGuard (LX AI)
Contraste e ARIA em aplicativos codificados por vibração
Interfaces de usuário codificadas por vibração falham na acessibilidade em dois pontos que os scanners raramente capturam juntos: matemática de contraste e nomes acessíveis. Um componente pode passar em uma auditoria de cor e ainda ser inutilizável quando seu papel está errado ou seu nome está vazio. Ambos se quebram novamente na regeneração, então a correção pertence a uma lista de verificação, não a uma edição única.
Como a matemática de contraste realmente quebra em temas gerados
Quando um modelo inventa uma paleta, ele geralmente copia um mood board: texto slate suave, chips pastel, cartões translúcidos. Isso parece bom no monitor do designer e falha nas razões da WCAG 2.2 no momento em que o conteúdo real é carregado. O texto do corpo em Nível AA precisa de uma razão de contraste de 4,5: 1 contra seu fundo (critério de sucesso 1.4.3). O texto grande pode usar 3: 1. Os geradores não executam essa matemática; eles escolhem valores hex que "sentem secundários."
Um segundo modo de falha é o fundo que você não pode ver na exportação do Figma. O texto sobre uma imagem de herói, uma lavagem de gradiente ou um painel de glassmorphism precisa do fundo renderizado, não do token nomeado bg-surface. Amostra o pixel sob o glifo ou você limpará uma auditoria de token e ainda assim enviará cópia ilegível. Gráficos e tinta de dados têm a mesma armadilha; a escrita da Smashing Magazine sobre contraste de gráficos mostra como os limiares padrão mudam as escolhas de design visual sem transformar todos os gráficos em uma rainbow (padrões de acessibilidade para design de gráficos).
O contraste de não-texto é o gêmeo silencioso
O critério de sucesso 1.4.11 (Contraste de não-texto) pede 3: 1 nas fronteiras de componentes de UI, objetos gráficos necessários para entender o conteúdo e estados como indicadores de foco. Uma borda fina de 1px que parece "premium" geralmente falha. Um anel de foco definido como outline: 2px solid rgba (15,118,110,.35) falha mesmo quando o texto do rótulo passa 4,5: 1. Controles de ícone apenas que dependem de um glifo cinza claro contra branco são a mesma classe de bug. Trate as cores da borda, do ícone e do foco como tokens de primeira classe com razões publicadas, não como afterthoughts decorativos. A referência rápida da WCAG 2.2 é o lugar mais rápido para re-verificar quais critérios se aplicam em AA.
Tokens batem patches hex de uma vez
O conserto duradouro é chato: defina tokens de cor semânticos (text-primary, text-muted, border-strong, focus-ring) com razões medidas contra cada fundo permitido, então proíba o modelo de inventar strings hex em arquivos de componentes. Coloque a regra de proibição no prompt e no CI. Se a regeneração pode reescrever cor: #94a3b8 em um rótulo de botão, sua "correção" nunca foi uma correção. Pareie tokens com uma camada de variável CSS para que o modo escuro e os temas de marketing herdem as mesmas restrições.
Nomes acessíveis não são rótulos visíveis
Os leitores de tela anunciam o nome acessível de um controle, não os dados do caminho SVG. Um botão de ícone que mostra um glifo de lixo sem conteúdo de texto, sem aria-label e sem rótulo associado <label> se torna "botão" sem propósito. Isso é uma falha de nomeação, não uma falha de contraste, é por isso que as auditorias de cor permanecem verdes enquanto os usuários do teclado param.
A ordem de computação do nome é definida pela árvore de acessibilidade: texto de conteúdo, referências rotuladas, então rótulos fornecidos pelo autor, como aria-label. Os geradores geralmente emitem o glifo e uma classe Tailwind e param. Eles também inventam nomes duplicados ("Fechar" em cada controle de descarte em uma pilha de modais) ou nomes que descrevem a metáfora do ícone em vez da ação ("lixeira" em vez de "Excluir fatura"). Prefira a linguagem de ação que corresponde à affordance visível.
Onde os nomes desaparecem após a regeneração
A regeneração apaga os valores de aria-label inline que foram adicionados à mão porque o modelo os trata como ruído opcional. Sobreviva a isso:
- Mantendo mapas de ícones em um módulo que sempre emparelha glifo + string de nome - Usando texto visível ao lado dos ícones quando o espaço permitir (nome vem de graça) - Falhando no CI quando um elemento interativo tem um nome acessível vazio - Rejeitando PRs que introduzem <div onClick> sem um pacote de nome e papel
A visão geral dos fundamentos da WAI ainda é o melhor curto primer sobre por que os nomes, papéis e estados devem viajar juntos (WAI Fundamentos de Acessibilidade).
Quando o ARIA ajuda — e quando esconde o bug
O HTML nativo já expõe funções, comportamento de teclado e muitos estados. Um botão real é focável, ativa com Enter e Space, e participa de formulários. Um <div role="button" tabindex="0"> que um modelo colou ainda precisa desses manipuladores de teclas, um estado pressionado ou desabilitado quando relevante, e um nome acessível. Pule qualquer uma dessas coisas e a tecnologia assistiva anuncia um botão que não faz nada no Space. O Guia de Práticas de Autoria do ARIA (APG) existe para os casos em que você realmente precisa de um widget personalizado; ele não é uma licença para restilar um div em cada controle.
Erros comuns do ARIA em marcações codificadas por vibração
- Função no elemento errado: role="button" em um <a href>, ou role="link" em um botão que envia um formulário - ARIA decorativo: aria-label que duplica texto visível e confunde algumas combinações de AT - Estado obsoleto: aria-expanded="true" deixado após um render de cliente alterar um painel - Spam de pontos de referência: cinco regiões role="navigation" sem nomes, então as listas de saltos se tornam ruído - Regiões ao vivo para vaidade: aria-live="polite" em cada toast, então a página tagarela
A recomendação WAI-ARIA 1.2 descreve a ontologia de funções e propriedades; use-a quando você deve estender além do HTML, não como uma camada padrão em cada nó (WAI-ARIA 1.2).
Situação | Preferir | Evitar Ação primária | <button type="button"> | <div role="button"> sem teclas Navegação para uma URL | <a href> | Botão que apenas chama router.push sem URL Controle de ícone apenas | Texto visível ou aria-label estável de um mapa | SVG nu com título faltando Caixa de combinação personalizada | Padrão APG + mapa de teclado | Funções inventadas copiadas de uma resposta de chat
Caminhos de teclado que o gerador esquece
A ordem de foco, foco visível e links de saltos caem fora de layouts de um único tiro. O Critério 2.4.7 exige um indicador de foco visível. O Critério 2.4.11 (Foco Não Obscurecido — Mínimo), novo na WCAG 2.2, exige que cabeçalhos fixos, banners de cookies e widgets de chat flutuantes não escondam completamente o controle focado. Tabule a página gerada de cima para baixo. Confirme que a ordem corresponde à ordem de leitura. Confirme que nenhum controle está preso atrás de uma sobreposição. Confirme que o anel de foco atende ao 1.4.11 contra qualquer coisa que esteja atrás dele.
Um curto passe manual de teclado (15 minutos)
- Desconecte o mouse. Abra a página em um perfil limpo. - Tabule do chrome do navegador para o documento. Há um link de saltos que funciona? - Alcance cada ação primária sem folclore de tecla de seta que o componente nunca implementou. - Abra e feche cada modal com Escape. O foco retorna ao invocador? - Acione o cabeçalho fixo e o banner de cookies. Você ainda pode ver o controle focado? - Acione cada botão de ícone com um leitor de tela (NVDA ou VoiceOver). O nome corresponde à ação?
Esse passe pega o que o Lighthouse não pega. As ferramentas automatizadas são um primeiro filtro; elas não são um certificado de conformidade. Para ferramentas de contratação e decisão automatizada, as orientações dos EUA também lembram os construtores de que os recursos de IA podem criar riscos de discriminação por deficiência se as interfaces excluírem pessoas que usam tecnologia assistiva (orientações do ADA.gov sobre IA). A UI do produto não está isenta desse pensamento apenas porque um modelo escreveu o JSX.
Faça a verificação sobreviver à regeneração
Porque a regeneração apaga patches manuais, o controle duradouro parece infraestrutura:
- Tokens de design com contraste medido, verificados em um teste unitário ou plugin stylelint - Primitivos de componentes (IconButton, TextField) que sempre emitem nome + estilos de foco - Porta de acessibilidade CI (axe ou equivalente) em pull requests, falhando em nomes vazios e contraste - Restrições de prompt que proíbem hex raw e proíbem div-as-button sem uma flag de exceção explícita - Passagem de teclado humano em cada vertical antes do lançamento, registrada como um item de lista de verificação, não um vibe
Trate a marcação gerada como saída de rascunho não confiável. Revise-a da mesma forma que você revisa um PR junior que chegou de um hackathon de fim de semana: suponha nomes ausentes, suponha ARIA teatral, suponha texto pastel.
Critérios de decisão: corrigir em tokens, primitivos ou código de página?
Use esta ordem quando um relatório de bug chega:
- Se muitas páginas compartilham a cor de texto desbotada incorreta, corrija o token e re-measure as razões. - Se um tipo de controle falta nomes (todos os botões de ícone), corrija o primitivo e exclua patches locais. - Se um único herói de marketing falha sobre uma foto, corrija a sobreposição ou tratamento de texto da página. - Se o ARIA foi colado no elemento errado, substitua por um controle nativo antes de escrever mais atributos.
Patches de ARIA de nível de página são os menos duráveis. Eles também são os que as sessões de vibe-coding amam emitir. Empurre as correções para cima.
O que isso não é
Este artigo não é um certificado de conformidade com o WCAG para o seu produto. Não é um conselho jurídico e não afirma que executar o A11yGuard (ou qualquer scanner) torna um site "conforme a ADA" ou "100% acessível." Verificações automatizadas de contraste e ARIA capturam falhas mensuráveis; elas perdem julgamentos sobre ordem de leitura, alternativas de arrastar e se um nome é compreensível. Nós não inventamos logotipos de clientes, aumentos de conversão ou garantias de "nunca perder um bug de contraste." O papel honesto do produto é uma primeira passagem rápida mais uma lista de verificação que você ainda possui.
Conclusão
A matemática do contraste e os nomes acessíveis falham de forma independente e se regeneram juntos. Bloqueie tokens, prefira controles nativos, verifique ARIA contra APG quando você precisar personalizar e mantenha uma passagem de teclado no ritual de lançamento. Use as referências abaixo quando uma afirmação sobre uma razão ou um critério estiver em disputa — o texto da especificação vence a memória de um modelo de chat.
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
Artigos relacionados
- Lista de verificação da WCAG 2.2 para UI gerada por IA (2026) - Explore a matriz completa de tópicos de micro-SaaS de IA →
Por que meu componente passa em uma auditoria de cor, mas ainda parece quebrado?
A auditoria de cor verifica a razão do texto. Ela não verifica se o controle tem um nome acessível, um estado de foco visível ou um manipulador de teclado. Essas lacunas são comuns em marcação gerada e não são problemas de contraste.
O ARIA é suficiente para fazer um div se comportar como um botão?
Não. Um div com role="button" ainda precisa de tabindex, manipuladores de teclas Enter/Space e um nome acessível. Um botão nativo <button> fornece os três. Use o elemento nativo, a menos que tenha um motivo específico para não usá-lo.
Como posso evitar que as correções desapareçam na regeneração?
Trave os tokens de cor e espaçamento no sistema de design para que o modelo não possa inventar valores e execute um portão de acessibilidade automatizado no CI. Trate a interface de usuário gerada como um rascunho e revise-a da mesma forma que você revisa a saída não confiável.
O que é a regra de contraste não de texto 3:1?
O critério 1.4.11 exige que as fronteiras de componentes de interface de usuário, ícones e indicadores de foco atinjam 3:1 em relação às cores adjacentes. É separado da regra de texto 4.5:1 e é frequentemente perdido por temas gerados.
Apoio à decisão apenas. Não é um conselho jurídico ou um certificado de conformidade de acessibilidade.