por A11yGuard (LX AI)

Contraste e ARIA em aplicações codificadas por vibração

As 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, por isso a correção pertence a uma lista de verificação, não a uma edição única.

Como a matemática do contraste realmente falha em temas gerados

Quando um modelo inventa uma paleta, 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 em 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 o 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ê irá 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 não textual é o gêmeo silencioso

O critério de sucesso 1.4.11 (Contraste não textual) pede 3: 1 nas fronteiras dos componentes da interface do usuário, 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 em 4,5: 1. Controles apenas de ícones 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 do WCAG 2.2 é o lugar mais rápido para re-verificar quais critérios se aplicam em AA.

Os tokens batem em patches hexadecimais 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 a cor: #94a3b8 em um rótulo de botão, o seu "conserto" nunca foi um conserto. Pareie os 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 ecrã anunciam o nome acessível de um controlo, 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 um rótulo associado torna-se "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 utilizadores de teclado se estagnam.

A ordem de computação do nome é definida pela árvore de acessibilidade: texto de conteúdo, referências labelled-by, em seguida, rótulos fornecidos pelo autor, como aria-label. Os geradores muitas vezes emitem o glifo e uma classe Tailwind e param. Eles também inventam nomes duplicados ("Fechar" em cada controlo de dismissal em uma pilha de modais) ou nomes que descrevem a metáfora do ícone em vez da ação ("caixa de lixo" em vez de "Eliminar fatura"). Prefira a linguagem de ação que corresponde à affordance visível.

Onde os nomes desaparecem após regeneração

A regeneração apaga os valores de aria-label em linha 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 + cadeia de nome - Usando texto visível ao lado dos ícones quando o espaço permite (o 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 papel e pacote de nome

A visão geral dos fundamentos da WAI ainda é o melhor guia curto sobre por que os nomes, papéis e estados devem viajar juntos (Fundamentos de Acessibilidade da WAI).

Quando o ARIA ajuda — e quando esconde o bug

O HTML nativo já expõe funções, comportamento de teclado e muitos estados. Um verdadeiro <button> é 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 desativado 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; não é uma licença para restilar um div em cada controle.

Erros comuns do ARIA em marcação codificada 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 estagnado: aria-expanded="true" deixado para trás após um render de cliente alternar um painel fechado - Spam de pontos de referência: cinco regiões role="navigation" sem nomes, para que as listas de saltos se tornem ruído - Regiões ao vivo para vaidade: aria-live="polite" em cada toast para que a página fale

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).

Caminhos do teclado que o gerador esquece

A ordem de foco, o foco visível e os links de saltar são omitidos nos layouts de um único disparo. 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 controlo focado. Navegue pela página gerada de cima para baixo com a tecla Tab. Confirme que a ordem corresponde à ordem de leitura. Confirme que nenhum controlo fica 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 rato. Abra a página em um perfil limpo. - Navegue com a tecla Tab do chrome do navegador para o documento. Há um link de saltar que funciona? - Alcance todas as ações principais sem a necessidade de usar setas do teclado, pois o componente nunca implementou essa funcionalidade. - Abra e feche todas as modais com a tecla Escape. O foco retorna ao invocador? - Acione o cabeçalho fixo e o banner de cookies. Você ainda pode ver o controlo focado? - Acione todos os botões de ícones com um leitor de ecrã (NVDA ou VoiceOver). O nome corresponde à ação?

Esse passe captura o que o Lighthouse não captura. As ferramentas automatizadas são um primeiro filtro; elas não são um certificado de conformidade. Para contratação e ferramentas de decisão automatizadas, as orientações dos EUA também lembram aos construtores 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 de IA do ADA.gov). A UI do produto não está isenta desse pensamento apenas porque um modelo escreveu o JSX.

A A11yGuard, WCAG, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo e ADA devem ser preservados.

Faça a verificação sobreviver à regeneração

Porque a regeneração apaga patches manuais, o controlo 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 de CI (axe ou equivalente) em pedidos de pull, falhando em nomes vazios e contraste - Restrições de prompt que proíbem hex brutos e proíbem div-como-botão sem uma bandeira de exceção explícita - Passagem de teclado humano em cada vertical antes da libertação, registada como um item de lista de verificação, não como uma vibração

Trate a marcação gerada como saída de rascunho não confiável. Revise-a da mesma forma que revisa um PR júnior que chegou a um hackathon de fim de semana: assuma nomes em falta, assuma ARIA teatral, assuma 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 erro chegar:

- Se muitas páginas partilham a cor de texto muteada incorrecta, corrija o token e re-measure as razões. - Se um tipo de controlo carece de nomes (todos os botões de ícone), corrija o primitivo e elimine patches locais. - Se um único herói de marketing falhar sobre uma foto, corrija a sobreposição ou tratamento de texto dessa página. - Se o ARIA foi colado no elemento incorrecto, substitua por um controlo nativo antes de escrever mais atributos.

Os patches ARIA ao nível da página são os menos duradouros. São também os que as sessões de vibe-coding adoram emitir. Empurre as correções para cima.

O que isto não é

Este artigo não é um certificado de conformidade com o WCAG para o seu produto. Não é um aconselhamento jurídico e não afirma que executar o A11yGuard (ou qualquer scanner) torna um site "conforme à ADA" ou "100% acessível." As verificações automatizadas de contraste e ARIA detectam falhas mensuráveis; elas perdem chamadas de julgamento sobre ordem de leitura, alternativas de arrasto e se um nome é compreensível. Nós não inventamos logotipos de clientes, aumentos de conversão ou garantias de "nunca perder uma falha de contraste." O papel honesto do produto é uma primeira passagem rápida mais uma lista de verificação que você ainda possui.

Encerramento

A matemática do contraste e os nomes acessíveis falham independentemente e regeneram-se juntos. Bloqueie tokens, prefira controles nativos, verifique ARIA contra APG quando precisar personalizar e mantenha uma senha de teclado no ritual de lançamento. Utilize as referências abaixo quando uma afirmação sobre uma razão ou um critério estiver em disputa — o texto da especificação tem prioridade sobre a memória de um modelo de chat. A11yGuard, WCAG, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo e ADA devem ser considerados.

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