Frontends com Vibecoding · Capítulo 22 de 35 · 32 min
Auditar acessibilidade e contraste nos dois temas
Você roda a auditoria nos dois temas, percorre a tela pelo teclado e mede a razão de contraste degrau a degrau da sua escala de cor.
Este capítulo faz parte do curso gratuito Frontends com Vibecoding.
Um tribunal francês condenou o Carrefour a corrigir site e aplicativo em seis meses, sob multa de 500 euros por dia de atraso. A defesa alegou 71% de conformidade com a norma de acessibilidade, e o tribunal respondeu que conformidade parcial não conta como conformidade.
Ao fim, você mede sozinho o contraste das cores da marca e percorre uma página só pelo teclado, sem esperar o relatório de ninguém. Tempo de leitura: cerca de 32 minutos, e a medição das cores da sua empresa, mais 15.
Acessibilidade é a tela funcionando por teclado, com contraste suficiente entre tinta e fundo. Vale também para o leitor de tela, ou seja, o programa que lê a página em voz alta para quem não enxerga. Quem não enxerga bem desiste da compra quando o texto some no fundo, e o prejuízo chega antes do processo.
A WCAG é a norma internacional que descreve essas exigências, e o alvo técnico recomendado é a versão 2.2 no nível AA. A obrigação legal depende do país, do setor, do serviço e dos contratos; não existe uma exigência universal de WCAG 2.2 AA.
Ver como texto
Três cartões mostram as três formas de usar a mesma tela: pelo teclado, com Tab, Enter e Esc; pelo contraste entre tinta e fundo, com piso de 4,5 para 1; e pelo leitor de tela, que lê a página em voz alta. Setas levam os três à WCAG 2.2 no nível AA, o alvo técnico recomendado. No rodapé, a lembrança de que a revisão exige testes manuais e automáticos.
No Brasil, a ABNT NBR 17225 é a norma técnica de acessibilidade digital. Ela se apoia na WCAG, a mesma régua usada em auditoria e em ação judicial.
Na União Europeia, as regras de acessibilidade abrangem produtos e serviços específicos, como comércio eletrônico e serviços bancários ao consumidor, desde 28 de junho de 2025. Existem transições e exceções, inclusive para microempresas prestadoras de serviços que atendam aos critérios previstos. A data de criação do site, sozinha, não decide se a exceção se aplica. Confira o serviço, o porte da empresa e a legislação do país em que atua.
Em notícia de 7 de julho de 2026, o MPF cita levantamento do TCU com 366 organizações públicas federais: 88,5% tinham sites classificados como ruins em acessibilidade. A notícia relata uma liminar que deu à União 180 dias para apresentar um plano de transição, sob possibilidade de multa diária de R$ 10 mil. O prazo é para o plano; a notícia não comprova que todos os sites tenham sido corrigidos.
Nos Estados Unidos, a regra do Departamento de Justiça usa a WCAG 2.1 no nível AA para governos estaduais e locais. As agências federais seguem a Section 508, alinhada à versão 2.0 AA.
A WCAG 3.0 segue em rascunho, sem valor normativo e sem jurisdição que a exija. Ela vai coexistir com a 2.2 por anos, e pedir ao agente conformidade com a versão 3 cobra uma promessa que nenhum auditor consegue conferir.
O que já venceu e o que está correndo
- 11/03/2025Concluído
ABNT NBR 17225 publicada no Brasil
Norma técnica de acessibilidade digital, apoiada na WCAG.
- 28/06/2025Concluído
Diretiva europeia de acessibilidade entra em vigor
Alcança comércio eletrônico, banco ao consumidor e livro digital.
- 24/04/2024Concluído
DOJ publica regra com WCAG 2.1 AA
O escopo são governos estaduais e locais dos Estados Unidos.
- 04/06/2026Concluído
Tribunal de Caen condena o Carrefour France
Seis meses para corrigir, multa de 500 euros por dia de atraso.
- 07/07/2026Agora
Liminar dá 180 dias à União, no Brasil
Multa diária de dez mil reais, decisão provisória e recorrível.
Contraste e teclado são as duas falhas que mais reprovam uma tela. Contraste é a razão entre a tinta e o fundo, com piso de 4,5:1 no texto normal e 3:1 no texto grande. Corrija pelo token, ou seja, a cor guardada com nome, porque o ajuste se propaga a todos os componentes irmãos.
O axe é o verificador que roda no navegador e aponta o elemento e a regra quebrada, como um fiscal que já entrega a multa com o endereço. Instale a extensão axe DevTools, aperte F12 e rode a análise nos dois temas, com menu e diálogo abertos. Ele só enxerga o que está no ar naquele instante.
Teclado falha pelo mesmo motivo: o componente foi construído olhando só para o mouse. Percorra a tela inteira com Tab, Shift+Tab, Enter e Esc, e quando numa parada você não sabe onde está, então o foco sumiu. Menu que ignora o Enter e diálogo que não fecha no Esc estão quebrados.
Ver como texto
Esboço de uma página de imobiliária com o percurso do foco pelo teclado. As paradas numeradas seguem a ordem da tela: 1 o link Início, 2 o menu Imóveis, 3 o botão do filtro de bairro, 4 o anúncio e 5 o botão Agendar visita. Entre o filtro e o anúncio há uma parada sem contorno de foco, marcada com interrogação: ali quem navega por teclado não sabe onde está, sinal de que o foco sumiu. A legenda lembra que Tab avança, Shift+Tab volta, Enter abre o filtro e Esc fecha.
Numa imobiliária com filtro de bairro que só abre no clique do mouse, metade dos anúncios some para quem navega por teclado. A lista chega vazia, e a visita se perde sem que ninguém descubra o motivo. Abrir o filtro só com Enter e fechá-lo só com Esc expõe a falha em menos de um minuto.
Ver como texto
Pirâmide WCAG 2.2: níveis A, AA e AAA de conformidade de acessibilidade
Pirâmide de três níveis do WCAG 2.2: A com os critérios essenciais na base, AA com os ampliados no meio e AAA com os adicionais no topo. A recomendação é mirar AA por padrão.
Uma varredura com nota máxima não autoriza declarar a tela pronta. O axe-core dentro do Playwright, a ferramenta que abre o navegador sozinha e clica como um visitante, vira portão da esteira de publicação. Ele barra a entrega que reprova.
A cobertura tem dois números que se confundem. O teste automatizado alcança de 30% a 40% dos critérios da norma, e os 57% da Deque medem outra coisa: o volume de problemas encontrados.
O resto é revisão humana, porque ordem de foco quebrada e rótulo errado passam batido na máquina. O Pa11y faz varredura parecida por linha de comando, útil quando são dezenas de páginas.
Também é o axe-core o motor do Lighthouse e do painel do Chrome DevTools. Ferramentas que parecem independentes convergem porque leem a mesma régua, e três notas iguais não valem como três confirmações.
Ver como texto
Três ferramentas que parecem independentes, o painel do Chrome DevTools, o Playwright na esteira e o relatório do Lighthouse, apontam setas para um único motor, o axe-core. Abaixo, uma barra representa os critérios da norma: a parte que a máquina alcança vai de 30% a 40%, e o restante fica para a revisão humana, como ordem de foco e rótulo errado. O rodapé conclui que três notas iguais valem uma confirmação só.
Três regras de norma dispensam ferramenta. Alvo de toque é a área que o dedo acerta. O piso é 24 px no nível AA, 44 px no AAA e nas diretrizes da Apple, e 48 dp no Android. Todo modal fecha por um botão visível e tocável, porque quem não consegue fechar a janela abandona o site.
Gráfico que sustenta uma decisão ganha tabela alternativa, e a checagem Chartability serve de auditoria, com a sonificação como canal complementar.
Canvas e WebGL entregam ao leitor de tela uma imagem muda, e o cliente cego escuta silêncio no lugar do preço. Eles precisam de uma camada paralela em HTML com atributos ARIA, ou seja, rótulos que dizem o que cada elemento é. O agente só escreve essa camada se você pedir.
A skill frontend-design inclui orientações de responsividade, foco visível, movimento reduzido, contraste e coerência da paleta. Carregar essas instruções não demonstra que a tela as cumpriu.
Transforme cada orientação em uma verificação: abra a tela no celular, percorra os controles com o teclado, ative movimento reduzido e meça contraste nos dois temas. Registre o resultado e os problemas encontrados na versão avaliada.
Ver como texto
Cinco itens de revisão propostos pela skill frontend-design; os ícones representam o checklist, não resultados de testes: tela que funciona no celular, foco de teclado visível, menos movimento respeitado, contraste correto e paleta harmoniosa. A faixa embaixo pede testar cada item na tela renderizada.
Antes de aprovar qualquer fluxo que fatura, comprar, agendar ou cadastrar, rode o axe nos dois temas, com menu e diálogo abertos. Depois percorra a tela só com Tab, Shift+Tab, Enter e Esc, e conserte o que travar. Deu certo quando o axe não aponta falha e o axe-core no Playwright segura sozinho a publicação que reprova.
Conferir se cada cor da sua escala tem contraste suficiente
A auditoria automática aponta onde o contraste falha, e a escala de cor ainda precisa ser medida degrau a degrau, nos dois temas, antes de virar token.
No degrau 500 de uma escala de cor, nem o texto branco nem o quase-preto passam no piso de contraste. O branco fica em 3,96:1 e o quase-preto em 4,49:1, contra o piso de 4,5:1, por isso esse degrau serve só de fundo decorativo ou de traço.
Razão de contraste é o número que compara a tinta com o fundo, como a diferença entre giz branco no quadro-negro e o mesmo giz na parede clara. Texto que se aproxima do fundo cansa o olho do cliente, e quem não enxerga bem desiste da compra antes de achar o botão.
A escala inteira, de 50 a 950, precisa da razão medida degrau a degrau, nos dois temas, com uma regra de corte escrita para o agente obedecer.
Essa escala nasce em OKLCH (o jeito de escrever cor por claridade, intensidade e matiz, como afinar um instrumento por altura, volume e timbre). Nela a claridade cresce em linha reta: cada degrau de 50 a 950 escurece o mesmo tanto para o olho, o que o código hexadecimal não garante.
Com color-mix(in oklch, ...) o agente deriva o tema inteiro de uma cor só, no lugar de dezenas de valores fixos. Medir cada degrau contra branco e contra o texto quase-preto revela onde nenhuma das duas tintas passa. No meio da escala, no 500, os dois reprovam.
Laboratório ao vivo: a régua de contraste da escala
1. A escala 50 a 950 medida
500: zona morta para texto, nenhum dos dois passa
Suporte: contrast-color escolhe a tinta de cada faixa no Chrome e no Edge 147, no Firefox 146 e no Safari 26. Sem suporte, a faixa usa a tinta fixa que já passa, e os onze números continuam visíveis.
2. Um valor para cada tema
Este cartão troca de cor com o tema do site (use o botão de tema no topo da página).
Suporte: light-dark só funciona com color-scheme declarado no bloco. Sem suporte, o cartão volta para os tokens do site e continua legível nos dois temas.
3. Alvo de toque por norma
Modal sempre com fechamento visível e tocável. Suporte: alvo de toque é regra de norma, não recurso de navegador, e vale em qualquer versão.
A função contrast-color() escolhe sozinha entre preto e branco contra a cor que você passa, e poupa a decisão manual em cada botão. Ela chegou ao estágio Baseline Newly Available em 10 de abril de 2026.
Newly Available quer dizer que os navegadores atuais já trazem o recurso e os antigos ainda não. Por isso ela vai atrás de uma consulta de suporte, com a tinta fixa como reserva, e o fallback entra junto, nunca depois.
A função compara preto puro e branco puro, e não escolhe entre as tintas quase pretas e quase brancas da marca. Mesmo aprovada na razão, ela pode deixar texto pequeno difícil de ler. Confira tamanho, peso e fundo além da medida, e ajuste o token quando a leitura continuar ruim.
Outra função, light-dark(), guarda dois valores numa declaração só, um para cada tema, e exige color-scheme declarado no bloco. Sem essa declaração ela é ignorada em silêncio, e o cartão fica com a cor do tema errado.
Ver como texto
Fluxograma de decisão da função contrast-color. No topo, a pergunta: o navegador tem contrast-color? Se sim, a função escolhe sozinha entre preto puro e branco puro. Se não, vale a tinta fixa de reserva, escrita junto do recurso. Os dois caminhos chegam à mesma conferência: tamanho, peso e fundo, com ajuste do token se a leitura continuar ruim. Uma nota lembra que light-dark sem color-scheme declarado é ignorada em silêncio.
O tema escuro troca o papel dos tokens (o valor de cor guardado com nome, como a etiqueta na lata de tinta). O que era fundo vira tinta, a razão muda junto, e a medição se repete nos dois temas.
Sobre fundo escuro, texto claro parece mais fino que o mesmo texto escuro sobre claro, e o peso da fonte sobe um degrau para compensar.
Três linhas resumem a regra da casa para qualquer figura que o agente desenhe. Tinta e fundo ficam fortemente contrastantes nos dois temas, e a fonte tem 14 px ou mais no viewBox do SVG. Todo texto leva fill próprio, porque ele não herda a cor do site, e o auditor de contraste do navegador é conferido antes de concluir.
Ver como texto
Dois quadros lado a lado com a mesma amostra de texto. No tema claro, o token de fundo usa um degrau claro da escala e o token de tinta, um degrau escuro. No tema escuro, os papéis trocam: o fundo passa a um degrau escuro, a tinta a um degrau claro, e o peso da fonte sobe um degrau para compensar a aparência mais fina do texto claro. Uma faixa abaixo conclui que, com os papéis trocados, a razão de contraste muda e precisa ser medida de novo nos dois temas.
A régua de corte cabe numa linha. Texto sobre cor vai no degrau 600 ou mais escuro, com tinta branca, ou no 300 ou mais claro, com tinta quase-preta. O 400 passa com quase-preto em 6,67:1 e o 600 passa com branco em 5,51:1; entre eles fica o 500, reservado a fundo decorativo e traço.
Esse piso de 4,5:1 vale para texto. Componente de interface e elemento gráfico essencial exigem 3:1, pelo critério 1.4.11 da WCAG. A borda do campo e a linha do gráfico entram nessa conta. Esse é o item mais esquecido no design system, ou seja, o conjunto de peças e cores reaproveitadas no site inteiro.
Numa clínica com portal do paciente, a cor da marca no degrau 500 vira fundo do botão de agendar, com texto branco. Esse par fica em 3,96:1 e reprova o piso, então o paciente idoso não acha o botão e liga para a recepção.
Baixar o fundo para o degrau 600, que passa em 5,51:1 com texto branco, devolve legibilidade sem mudar a identidade. O mesmo botão é medido de novo no tema escuro, porque o fundo da página mudou de papel.
Ver como texto
Antes e depois do botão de agendar do portal de uma clínica. Em cima, o fundo no degrau 500 da escala com texto branco mede 3,96 para 1 e reprova o piso, e o paciente idoso não acha o botão e liga para a recepção. Embaixo, o mesmo botão com fundo no degrau 600 mede 5,51 para 1 e passa o piso de 4,5 para 1, sem mudar a identidade da marca.
Peça ao agente a escala de 50 a 950 em OKLCH, com a razão de contraste de cada degrau medida nos dois temas. A medida vale contra branco e contra o texto escuro, e o degrau do meio fica proibido para texto, mesmo com contrast-color().
Só aprove a tela quando o auditor de contraste do navegador não apontar par abaixo de 4,5:1 em nenhum dos dois temas.
Guia prático: auditoria técnica com nota antes de corrigir
Corrigir contraste tela por tela, conforme alguém reclama, nunca termina. O comando audit da skill Impeccable inverte a ordem: primeiro um relatório do que é mensurável no código, com nota, e só depois a correção pela gravidade. Ele não altera nenhum arquivo.
A nota soma cinco dimensões, cada uma de 0 a 4: acessibilidade, desempenho, tema, responsividade e integridade da implementação. A última roda o detector de antipadrões e confere cada achado em contexto. O total vai até 20. De 18 a 20 a tela pede só acabamento; de 14 a 17 há dimensões fracas a tratar; de 10 a 13 o trabalho é significativo; de 6 a 9 a tela pede reforma ampla; de 0 a 5 o estado é crítico.
Cada problema recebe uma gravidade de P0 a P3. P0 impede a pessoa de concluir a tarefa e é corrigido na hora. P1 causa dificuldade séria ou descumpre o nível AA das diretrizes de acessibilidade da web (WCAG), e é corrigido antes de publicar. P2 incomoda e tem contorno, e fica para a próxima rodada. P3 é acabamento sem impacto real, e entra se sobrar tempo. O roteiro avisa contra o excesso de P3: uma lista longa de detalhes esconde os dois problemas que importam.
/impeccable audit pagina de matricula
Nota da auditoria (exemplo ilustrativo)
1 Acessibilidade 2 botão com contraste de 3,2:1
2 Desempenho 3 imagens abaixo da dobra sem carregamento adiado
3 Responsividade 2 alvos de toque de 32 px no menu
4 Tema 3 seis cores escritas à mão, fora dos tokens
5 Integridade da implementação 3 cartão dentro de cartão em duas seções
Total 13 de 20 aceitável, com trabalho significativo
[P1] Contraste do botão principal
Onde: componente BotaoMatricula
Impacto: quem lê no sol ou tem baixa visão não distingue o texto
Norma: WCAG 2.2, critério 1.4.3
Comando sugerido: /impeccable colorize
[P1] Alvos de toque abaixo de 44 px
Onde: menu do topo, largura de celular
Comando sugerido: /impeccable adaptAuditar, corrigir por gravidade e medir de novo
Cinco passos. A nota serve para comparar a mesma tela com ela mesma, antes e depois.
Passo 1: Nomeie o alvo pelo percurso
Audite um percurso que a pessoa faz inteiro, como a matrícula ou o blog com a página de artigo, e não o site todo. O relatório fica curto e cada achado tem endereço.
Deu certo quando: O relatório cita componentes e arquivos do percurso pedido.
Erro comum: Pedir a auditoria do projeto inteiro e receber 80 itens que ninguém prioriza.
Passo 2: Leia primeiro o veredito de integridade
O relatório abre dizendo se a implementação expressa um sistema coerente ou uma colagem de atalhos. Cor escrita à mão em 15 componentes é um problema de sistema, não 15 problemas.
Deu certo quando: Você sabe quais achados somem juntos ao corrigir uma causa compartilhada.
Erro comum: Corrigir cada cor no lugar e manter o hábito que as criou.
Passo 3: Comece pelos P0 e P1
Peça um comando por vez, na ordem sugerida pelo relatório, e confira a tela depois de cada um nos dois temas e na largura de celular.
Deu certo quando: Cada correção tem um antes e um depois que você consegue mostrar.
Erro comum: Rodar cinco comandos seguidos e não saber qual deles quebrou o tema escuro.
Passo 4: Confira com a sua própria medição
Meça o contraste dos pares corrigidos com a ferramenta do navegador e percorra o percurso só com o teclado. A auditoria aponta; a prova é a tela.
Deu certo quando: Os pares de texto e fundo passam de 4,5 para 1 e o foco aparece em todo controle.
Erro comum: Dar a tela por acessível porque a nota subiu.
Passo 5: Rode a auditoria de novo e guarde as duas notas
Anote a nota de antes, a de depois e a data no registro do projeto. Termine com /impeccable polish se houve correção.
Deu certo quando: A segunda nota é maior nas dimensões tratadas e nenhum P1 continua aberto.
Erro comum: Comparar a nota da sua tela com a de outro site; a escala só faz sentido contra a mesma tela.
No fim você tem: Duas notas datadas da mesma tela, nenhum problema P0 ou P1 aberto e a lista de P2 e P3 guardada para a próxima rodada.
Guia prático: testar a página com o movimento reduzido ligado
Pedir acessibilidade ao agente não garante acessibilidade. Na biblioteca de 1.451 componentes de interface estudada em 07/10/2026, o pedido de cada componente exige respeitar a preferência por menos movimento. Nos 815 exemplos de uso que vêm preenchidos, essa preferência aparece em zero. Foco visível aparece em 8 e texto para leitor de tela em 4.
Os templates de site repetem o quadro. Só 14 dos 51 tratam a preferência por menos movimento, e nenhum dos 12 que usam WebGL ou cena 3D faz isso. Outros sinais medidos: 25 tiram o contorno de foco sem pôr outro no lugar, 26 usam rótulos de 9 a 11 px e 29 têm algum atributo aria.
A preferência existe no sistema de todo aparelho: no Windows 11 é desligar os efeitos de animação em Acessibilidade, no iPhone é ligar Reduzir Movimento, no Android é remover animações. Quem sente tontura com movimento liga essa opção e espera que o site respeite. A lição: confie no teste, não na promessa do pedido. Ligue a opção no seu aparelho uma vez por entrega e deixe um teste automático repetir a checagem.
// Teste do Playwright: a página fica parada para quem pediu menos movimento.
import { test, expect } from "@playwright/test";
test("respeita movimento reduzido", async ({ page }) => {
await page.emulateMedia({ reducedMotion: "reduce" });
await page.goto("/");
await page.waitForTimeout(1500);
// Animações de CSS e da Web Animations API que rodam sem parar.
const emLoop = await page.evaluate(() =>
document.getAnimations().filter(
(a) => a.playState === "running" && a.effect?.getTiming().iterations === Infinity,
).length,
);
expect(emLoop).toBe(0);
// Vídeo de fundo não toca sozinho.
const tocando = await page.locator("video").evaluateAll((vs) =>
vs.filter((v) => !(v as HTMLVideoElement).paused).length,
);
expect(tocando).toBe(0);
// O conteúdo aparece sem depender da animação.
await expect(page.getByRole("heading", { level: 1 })).toBeVisible();
});Da promessa de acessibilidade à prova
Cinco passos, um manual e quatro automáticos. Cabem numa tarde.
Passo 1: Ligue a opção no seu aparelho e percorra a página
No celular ou no computador, ative a redução de movimento e abra a página do começo ao fim. Anote tudo que ainda se mexe: fundo, carrossel, número que conta, vídeo.
Deu certo quando: Você tem uma lista do que se move com a opção ligada.
Erro comum: Testar só no navegador de desenvolvimento e esquecer o celular, onde a opção é mais usada.
Passo 2: Defina o estado parado de cada efeito
Para cada item da lista, decida o que aparece no lugar: imagem fixa no fundo, carrossel com setas, número final já escrito, vídeo com pôster. Parado não é vazio.
Deu certo quando: Cada efeito tem um estado final visível e legível.
Erro comum: Esconder o conteúdo com opacidade zero e depender da animação para mostrá-lo.
Passo 3: Peça a correção com a lista na mão
Passe ao agente a lista e o estado parado de cada item. Peça que o canvas e o WebGL também parem fora da tela, o que poupa bateria de todo mundo.
Deu certo quando: O agente devolve a lista item por item com o arquivo alterado.
Erro comum: Pedir "respeite movimento reduzido" sem lista e receber só uma regra de CSS que não alcança o canvas.
Passo 4: Deixe o teste rodar a cada entrega
Ponha o teste do bloco acima na pasta de testes do Playwright. Ele finge a preferência ligada, procura animação em repetição infinita e vídeo tocando, e confere o título visível.
Deu certo quando: O teste passa e entra no comando que roda antes de publicar.
Erro comum: Achar que o teste cobre tudo: animação feita por JavaScript quadro a quadro, como a do GSAP, e canvas não entram em getAnimations. Esses você confere no passo manual.
Passo 5: Confira o foco junto
Com a mesma página aberta, percorra só com Tab. Todo contorno de foco removido precisa ter um substituto visível.
Deu certo quando: Você sempre sabe onde o foco está, em todos os botões e links.
Erro comum: Aceitar o contorno removido porque "ficou mais bonito".
No fim você tem: Uma página que fica parada e legível para quem pediu menos movimento, com um teste que repete a checagem sozinho.
O que mudou de agosto a outubro de 2026
A régua não mudou. O piso para texto comum continua em 4,5:1, e o nível mais exigente pede 7:1, como resume o guia de contraste do web.dev. O que muda é a facilidade de medir: o verificador da WebAIM e o painel do Chrome dão a razão em segundos, então não há motivo para aprovar uma paleta sem o número ao lado.

Ver como texto
Página Contrast Checker da WebAIM com dois campos de cor: primeiro plano com o código 0000FF e fundo com o código FFFFFF, cada um com seletor de cor e régua de luminosidade. Abaixo, a caixa Contrast Ratio mostra 8.59:1 e, sob ela, as seções Normal Text e Large Text marcam Pass nos níveis WCAG AA e AAA. À direita, uma lista de recursos relacionados, como o verificador de contraste de links.

Ver como texto
Trecho do artigo Color and contrast accessibility do web.dev com quatro amostras do mesmo parágrafo em cinza sobre branco e a razão de cada uma: 15.9:1 com #222222, 5.7:1 com #666666, 3.5:1 com #888888 e 1.6:1 com #CCCCCC. Abaixo, o texto diz que 4,5:1 é o mínimo exigido pela WCAG e que o nível AAA pede 7:1, e mostra o alerta do Lighthouse para cores sem contraste suficiente.

Ver como texto
Página Make your website more readable da documentação do Chrome DevTools, de Sofia Emelianova, com um destaque que diz que texto de baixo contraste é o problema de acessibilidade mais comum da web e que, em fevereiro de 2022, 83,9% das um milhão de páginas iniciais mais visitadas tinham esse problema, segundo o relatório WebAIM Million 2022, seguido de um vídeo sobre como achar e corrigir texto de baixo contraste.
| Razão medida | Texto comum (piso 4,5:1) | Texto grande (piso 3:1) | Nível mais exigente (7:1) |
|---|---|---|---|
| 15,9:1 | Passa | Passa | Passa |
| 5,7:1 | Passa | Passa | Não passa |
| 3,5:1 | Não passa | Passa | Não passa |
| 1,6:1 | Não passa | Não passa | Não passa |
Texto grande é a partir de 24 px, ou 18,66 px em negrito.
Fonte: Valores das amostras do web.dev; pisos da WCAG, consultados em 24/10/2026.
Faça agora: meça as cores da marca e ande pela página com o teclado
Passo 1: Peça ao time o código das cores de texto, fundo e botão principal, nos temas claro e escuro.
Deu certo quando: Uma lista com seis códigos no formato #RRGGBB.
Passo 2: No verificador da WebAIM, digite cada par de texto e fundo e anote a razão.
Deu certo quando: Cada par com um número e o veredito ao lado.
Erro comum: Medir só o tema claro e descobrir o problema no escuro depois de publicar.
Passo 3: Abra a página principal do site, clique na barra de endereço e aperte Tab várias vezes.
Deu certo quando: Um contorno visível mostra onde você está a cada Tab, na ordem da leitura.
Erro comum: O foco some ou pula para o rodapé antes do menu.
Passo 4: Leve ao time os pares que não passaram e os pontos onde o foco sumiu.
Deu certo quando: Uma lista curta com números, que dispensa discussão de gosto.
No fim você tem: Uma tabela das cores da marca com a razão de cada par e a lista de correções de foco.
Antes de aprovar uma paleta ou uma tela nova
Contraste
0/3Teclado
0/2Aplicar os recursos ao projeto
| Aspecto | Automação ajuda | Pessoa confere |
|---|---|---|
| Nome do controle | Identificar ausência | Significado da ação |
| Contraste | Medir combinação | Fundo e estados reais |
| Teclado | Executar percurso | Ordem e retorno de foco |
| Conteúdo | Inspecionar estrutura | Compreensão da tarefa |
Uma ferramenta aprovada não certifica toda a interface; a tarefa precisa continuar compreensível e executável com os recursos usados pelo público.

Ver como texto
Senhora sorri ao concluir um agendamento no celular, com um botão grande e contrastado na tela, enquanto um rapaz navega pelo notebook só com o teclado, com um cartão destacado por contorno de foco.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- CursoClaude Code: do zero à prática
- Agent Skills e SKILL.md: instruções reutilizáveissugerido pelo grafoApresenta o conceito “Skill (Agent Skill)”, usado em “Auditar acessibilidade e contraste nos dois temas”.
- CursoSíntese e didática com IAsugerido pelo grafoDepois de escolher a informação essencial e desenhar hierarquia, gráficos e fluxos compreensíveis, o aluno pode aplicar esses critérios às interfaces do curso de frontend. A ponte conecta clareza da mensagem, acessibilidade e decisões de apresentação.
- CursoNode.js: JavaScript no Servidorsugerido pelo grafo9 capítulos de “Frontends com Vibecoding” usam conceitos apresentados em “Node.js: JavaScript no Servidor”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- CRO: Otimização de Conversão e ExperimentaçãoAcessibilidade: fator de conversão e obrigação legalExaminar conexões de Acessibilidade: fator de conversão e obrigação legal
- MCP e Chrome: agentes de IA no navegadorQuando ler a estrutura da página e quando usar imagemExaminar conexões de Quando ler a estrutura da página e quando usar imagem
- Vibecoding para SEOAuditar uma página antes de colocar verba nelaExaminar conexões de Auditar uma página antes de colocar verba nela
- Software e IA para executivosA velocidade que o cliente sente no celularExaminar conexões de A velocidade que o cliente sente no celular
Terminou a leitura?
Você está aqui: capítulo 22 de 35
0 de 35 concluídos
- Próximo · Capítulo 23 de 35 · 34 minValidar desempenho, autenticação e segurançaLer o capítulo 23 sem concluir
Marque como concluído para o capítulo contar no seu painel e no certificado.
- Anterior · Capítulo 21 de 35 · 29 minAvaliar busca, conversão e padrões de comércioVoltar para o capítulo 21
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.
Laboratórios ao vivo deste curso
Cada laboratório monta a biblioteca real dentro da aula, com controles para você mexer e o código do exemplo para copiar. O texto de reserva descreve a demonstração para quem lê sem JavaScript. O link abre o capítulo já no ponto do laboratório.
Base UI
Prenda o foco num diálogo sem escrever o comportamento
Abra a janela Agendar visita, percorra os campos com Tab, feche com Esc e acompanhe no painel onde o foco está e para onde ele volta.
Pacote
Abrir no capítuloConstruir componentes, usar o registro e publicar o catálogo@base-ui/reactLucide e Iconify
Mantenha uma família de ícones coerente e nomeie cada botão
Mude tamanho, traço e cor da barra, veja o símbolo do Iconify acompanhar o Lucide e rode a auditoria de nomes acessíveis.
Pacote
Abrir no capítuloProjetar uma linguagem de ícones e ilustraçãolucide-react, @iconify/reactMotion
Testar os três sinais que autorizam o terceiro degrau
Reproduza a entrada em sequência, aperte o botão com mola e arraste o cartão; ajuste rigidez e amortecimento e veja o que muda.
Pacote
Abrir no capítuloProjetar movimento, assinatura e narrativas por rolagemmotionVidstack
Ver o que separa um player de um vídeo cru
Dê o play, troque a velocidade e ligue a legenda; o painel ao lado mostra o estado que o player publica e que a etiqueta crua esconde.
Pacote
Abrir no capítuloProjetar movimento, assinatura e narrativas por rolagem@vidstack/reactcmdk
Achar um destino entre quarenta digitando três letras
Abra a paleta, digite fat e escolha um item só pelo teclado; o painel embaixo conta o que o filtro deixou passar e quanto tempo levou.
Pacote
Abrir no capítuloConstruir formulários e estados de interaçãocmdknumber-flow
Animar indicadores que mudam ao vivo com formato pt-BR
Veja três indicadores fictícios rolarem a cada troca e compare com o número em texto puro. Pause, reinicie e observe o separador de milhar.
Pacote
Abrir no capítuloProjetar gráficos e painéis pela decisão@number-flow/reactApache ECharts
Medir o custo de desenhar 200 mil pontos com o ECharts
Troque o tipo de gráfico e o volume de pontos, leia o tempo de desenho e alterne o eixo em zero. Mude o tema do site e veja as cores refazerem.
Pacote
Abrir no capítuloProjetar gráficos e painéis pela decisãoechartsApache ECharts
Painel grande com visões coordenadas
Clique num canal para filtrar todas as visões, troque a densidade entre 6, 9 e 12 visões, alterne tema e movimento e abra a tela cheia.
Pacote
Abrir no capítuloProjetar gráficos e painéis pela decisãoechartssharp e svgo
Escolher a variante certa da imagem e conferir o teto de 150 KB
Arraste a largura da tela simulada, troque a densidade entre 1x e 2x e veja qual arquivo o navegador escolhe, quanto ele pesa e se cabe no orçamento.
Pacote
Abrir no capítuloValidar desempenho, autenticação e segurançasharp, svgoReact Flow (xyflow)
Disparar um pedido e ver o orquestrador distribuir, conferir e responder
Alterne paralelo e sequencial, ligue e desligue a verificação e use a medição real; observe o tempo de parede em cada combinação.
Pacote
Abrir no capítuloConstruir as cenas do orquestrador, do paralelismo e do robô@xyflow/reactGSAP, Web Workers e number-flow
Dividir mil tarefas entre trabalhadores reais e correr três ritmos de geração
Execute com um trabalhador, depois com quatro e oito, e compare o tempo; em seguida percorra a corrida e separe a espera inicial do ritmo.
Pacote
Abrir no capítuloConstruir as cenas do orquestrador, do paralelismo e do robôgsap, @number-flow/reactThree.js com React Three Fiber, drei, Rapier e XR
Carregar o braço robótico, ver a física trabalhar e entrar na cena com o visor
Carregue a cena pelo botão, inicie o ciclo, mostre os ângulos das juntas, troque a câmera e a velocidade; com visor, entre em realidade virtual.
Pacote
Abrir no capítuloConstruir as cenas do orquestrador, do paralelismo e do robôthree, @react-three/fiber, @react-three/drei, @react-three/rapier, @react-three/xrMotion
Ver quatro agentes em raias trocando mensagens e a revisão devolvendo um trecho
Reproduza os 60 s de modelo, percorra o tempo pelo controle e esconda as mensagens para comparar a leitura; repare no tempo de parede contra a soma.
Pacote
Abrir no capítuloEspecificar, medir e produzir as cenas da máquinamotionMediaRecorder, Canvas 2D e Long Animation Frames (plataforma)
Medir o quadro da cena e gravar seis segundos dela em vídeo
Suba as partículas, force um bloqueio de 300 ms e leia o medidor; depois grave seis segundos, veja o codec escolhido e baixe o arquivo.
Pacote
Abrir no capítuloEspecificar, medir e produzir as cenas da máquinasem pacotesigma.js, graphology com ForceAtlas2 e cosmos.gl
Ver o grafo real do curso e um grafo de milhares de nós se organizarem em aglomerados
Rode o layout no grafo real, passe o mouse pelos nós e busque uma entidade; troque para 20 mil nós e leia o medidor; depois carregue o modo massivo na placa de vídeo.
Pacote
Abrir no capítuloAnimar um grafo de conhecimento amplo em movimentosigma, graphology, graphology-layout-forceatlas2, graphology-generators, @cosmos.gl/graph
Capítulos vizinhos em Frontends com Vibecoding
- 20Comparar direção visual em Stripe e Apple
- 21Avaliar busca, conversão e padrões de comércio
- 22Auditar acessibilidade e contraste nos dois temas
- 23Validar desempenho, autenticação e segurança
- 24Planejar a modernização e publicar com reversão