antislop-human

Anti Slop: Regras para Agentes de Codificação de IA. Habilidade humana

Parte do sistema antislop. Leia em conjunto com antislop.md (o núcleo). Esta habilidade aprofunda a preocupação humana: a UI deve permanecer utilizável por pessoas com diferentes olhos, mãos e configurações. Contraste, teclado, foco, estados e os detalhes mobile que excluem pessoas.

Como usar esta habilidade

Carregue junto com antislop.md sempre que a tarefa construir ou editar UI. O núcleo contém o mecanismo (o teste de propósito, os três níveis, o Portão de Entrega); esta habilidade contém a profundidade do lado humano: as partes de uma UI que excluem pessoas com diferentes olhos, mãos e configurações.
Cada entrada tem a mesma forma: Diga (o padrão), Porquê (quem exclui e por que parece inacabado), Consertar (o que fazer em vez disso), com a regra central citada como R-XX.
Acessibilidade não é uma lista de verificação de extras colocados no final. É parte da promessa central de que "a UI se sustenta" (C-4). O Portão de Entrega do núcleo continua sendo o portão; a "Lista de Verificação da Habilidade Humana" no final deste arquivo é o suplemento para executar em paralelo.
O verificador de contraste (fórmula + tabela de referência + script) reside nesta habilidade. Use-o para cada par de cores que você não puder verificar a olho nu.
Esta habilidade mantém apenas os detalhes mobile que excluem pessoas: zoom e o teclado na tela.

Cor e Contraste

Texto com Baixo Contraste

Diga: texto cinza claro em fundo branco ou quase branco, texto corporal fino, rótulos suaves escolhidos porque parecem "elegantes", mas são difíceis de ler.
Porquê: exclui usuários com baixa visão e todos sob luz forte. É uma escolha visual feita sem verificar o padrão, exatamente o tipo de padrão que o filtro existe para capturar.
Consertar: atender aos mínimos WCAG AA (R-25): 4,5:1 para texto normal, 3:1 para texto grande (18px+). Calcule a proporção; não a julgue a olho.

Texto Sobre Foto ou Gradiente

Diga: texto branco colocado diretamente sobre uma imagem ou gradiente que é claro em algumas áreas, verificado apenas em um ponto claro.
Porquê: o contraste é local. Onde a imagem é clara, o texto cai abaixo de 4,5:1 mesmo que o herói ainda "pareça" bom. R-25 exige testar toda a área sobre a qual o texto passa, não um único ponto.
Consertar: adicione um véu ou um bloco de cor sólida atrás do texto, depois verifique o pior ponto, não o melhor. Se qualquer parte da área de texto falhar, o tratamento falha.

A Alucinação Cinza sobre Cinza

Diga: "cinza escuro sobre preto" ou "cinza claro sobre branco" alegados como aprovados sem um cálculo.
Porquê: esta é a alucinação de acessibilidade mais comum. O olho superestima o contraste em pares de cinza, e os agentes repetem a afirmação porque parece plausível. #555555 sobre preto é 2,8:1. Falha.
Consertar: nunca afirme que um par passa. Execute o verificador de contraste (abaixo) ou aplique a fórmula. Quando nenhum for possível, use a tabela de referência.

Contraste Não-Texto

Diga: componentes interativos (botões, ícones, bordas de entrada, indicadores de foco, segmentos de gráfico) distinguidos do fundo por menos de 3:1.
Porquê: a UI não textual carrega informações pela forma e borda. Quando a borda é um fio de matiz, usuários com baixa visão não conseguem encontrar o controle. A mesma barra se aplica a estados como hover e selecionado.
Consertar: dê a cada limite de componente e a cada indicador de status uma proporção de 3:1 contra cores adjacentes (WCAG 1.4.11). Emparelhe ícones com um rótulo de texto que atenda 4,5:1.

O Verificador de Contraste

A casa do verificador de contraste. Três camadas, da mais para a menos conveniente:

O script. Quando um runtime de script estiver disponível e o arquivo estiver presente, execute-o em vez de calcular manualmente. O script está na pasta desta habilidade (contrast-check.py, ao lado deste SKILL.md). Execute-o com python3 no macOS e Linux, python no Windows:

python3 "${CLAUDE_SKILL_DIR}/contrast-check.py" "#FFFFFF" "#777777"
# texto normal: FALHA (4.48 < 4.5)
# texto grande:  PASSA (4.48 >= 3.0)

Se a variável ${CLAUDE_SKILL_DIR} não estiver disponível neste agente, aponte o caminho do script diretamente para a pasta desta habilidade. O script existe para que os agentes parem de alucinar AA. Ele recebe duas cores hexadecimais e imprime a proporção e o veredito para ambos os tamanhos de texto. Se o arquivo estiver faltando, a fórmula e a tabela abaixo são completas por si só. Nunca bloqueie por causa do script.

A fórmula (WCAG 2.x).

Proporção de contraste = (L1 + 0,05) / (L2 + 0,05), onde L1 é a luminância relativa mais clara e L2 a mais escura.
Luminância relativa L de uma cor: converta cada canal para 0-1 (c = hex / 255), depois linearize: se c <= 0,03928, c_lin = c / 12,92; caso contrário c_lin = ((c + 0,055) / 1,055)^2,4.
L = 0,2126*R + 0,7152*G + 0,0722*B.
Compare a proporção não arredondada: 4,5:1 para texto normal, 3:1 para texto grande (18px+, de acordo com R-25). Arredonde apenas para exibição, de modo que um par em 4,498:1 seja impresso como 4,50 e ainda falhe 4,5:1. A proporção máxima é 21.0 (preto sobre branco).

A tabela de referência (pares comuns, calculados com a fórmula):

| Par (texto sobre fundo) | Proporção | Texto normal (4.5) | Texto grande (3.0) | |-------------------------|-----------|--------------------||--------------------| | Preto sobre branco | 21.00 | Passa | Passa | | Branco sobre preto | 21.00 | Passa | Passa | | Branco sobre #333333 | 12.63 | Passa | Passa | | Branco sobre #666666 | 5.74 | Passa | Passa | | #777777 sobre branco | 4.48 | Falha | Passa | | #777777 sobre #070707 | 4.50 | Falha | Passa | | Branco sobre #888888 | 3.54 | Falha | Passa | | Branco sobre #999999 | 2.85 | Falha | Falha | | #555555 sobre preto | 2.82 | Falha | Falha |

A linha #777777 sobre #070707 é o caso próximo do limite: 4,4983:1 arredonda para 4,50 para exibição e ainda falha 4,5:1.

Leia a tabela como uma verificação de sanidade, não como um substituto. Qualquer par não listado, ou qualquer coisa perto de um limite, passa pela fórmula ou pelo script.

Teclado

Contorno de Foco Removido

Diga: outline: none ou outline: 0 sem um estilo de foco substituto.
Porquê: usuários de teclado não conseguem ver onde estão. É a maneira mais rápida de tornar uma UI inutilizável sem um mouse, e R-32 proíbe isso explicitamente.
Consertar: mantenha ou substitua o contorno por um estilo visível :focus-visible que atenda à mesma barra de contraste (3:1 contra seus vizinhos). Nunca defina outline: none sem um substituto.

Padrões Apenas para Mouse

Diga: menus que abrem apenas ao passar o mouse, dropdowns que abrem com clique mas não abrem com teclado, arrastar e soltar sem fallback de teclado.
Porquê: cada um exclui usuários de teclado e tecnologia assistiva (R-32). Se um controle não pode ser alcançado e operado por Tab, Enter ou Espaço, ele não existe para um grupo inteiro de pessoas.
Consertar: todo elemento interativo é alcançável e operável por teclado (R-32): ordem de tabulação lógica seguindo a ordem visual, ativação com Enter ou Espaço e diálogos fecháveis com Escape (R-26).

Ordem de Tabulação Quebrada

Diga: o foco pula pela página, pula conteúdo ou cai em elementos ocultos porque a ordem do DOM não corresponde à ordem visual.
Porquê: a ordem de tabulação que lê a ordem do código em vez da ordem visual torna a navegação imprevisível (R-32). Os usuários perdem seu lugar e a página parece quebrada.
Consertar: mantenha a ordem do código correspondendo à ordem visual, adicione links de pular para páginas longas e nunca dê a conteúdo real tabindex="-1" a menos que faça parte de uma armadilha de foco controlada, como um diálogo.

Foco e Estados

Indicador de Foco Fraco ou Invisível

Diga: um anel de foco da mesma cor do fundo, um anel que só aparece ao passar o mouse ou um indicador mais fino que uma borda de 1px.
Porquê: o indicador de foco é como os usuários de teclado sabem onde estão. Se ele falhar na barra de contraste ou só aparecer ao passar o mouse, o uso apenas por teclado quebra (R-32, R-34).
Consertar: um indicador de foco visível em todo elemento interativo, 3:1 contra cores adjacentes, em cada tema que você enviar. Verifique nos modos escuro e claro.

Feedback Apenas por Cor

Diga: sucesso, erro e status comunicados apenas por cor: texto de erro vermelho, borda de sucesso verde, um chip colorido, sem ícone, rótulo ou texto.
Porquê: exclui usuários daltônicos e com baixa visão e desaparece completamente no modo de cores forçadas. Um status que depende de ver matiz não é um status (C-4).
Consertar: emparelhe cada sinal de cor com texto, um ícone ou um padrão. Estados de erro são texto primeiro: "A senha deve ter pelo menos 8 caracteres", não apenas uma borda vermelha.

Estados de UI Faltando

Diga: uma visualização de dados sem estado vazio, de carregamento ou de erro, ou estados que existem, mas são invisíveis: um spinner sem texto, uma tela vazia sem explicação.
Porquê: R-27 exige os três estados; o ângulo de acessibilidade é que cada um deve ser perceptível e informativo, não decorativo. Um spinner de carregamento sem contexto lê como uma página congelada para usuários de leitores de tela.
Consertar: toda visualização de dados tem todos os três estados (R-27), cada um anunciado ou visível: uma mensagem explícita de vazio, um estado de carregamento com texto e um estado de erro que diz o que aconteceu e como proceder.

Zoom e Uso Mobile

A mecânica de layout por trás do mobile (pontos de quebra, escala, grades, overflow, alvos de toque) é preocupação de antislop-layoutmobile. Esta seção mantém apenas os detalhes mobile que excluem pessoas: zoom e o teclado na tela.

Texto que Não Pode Aumentar Zoom

Diga: tamanhos de fonte fixos em pixels, ou contêineres com overflow: hidden que cortam o texto em 200% de zoom.
Porquê: os usuários devem poder redimensionar o texto (WCAG 1.4.4). Se aumentar o zoom para 200% cortar o conteúdo ou forçar rolagem horizontal, o texto não é redimensionável na prática.
Consertar: tipo fluido que reflui com o zoom, sem contêineres que cortam o texto, e verifique se o layout se mantém em 200% de zoom em uma viewport estreita (R-35).

Teclado Mobile Cobre o Formulário

Diga: entradas na parte inferior da viewport escondidas atrás do teclado na tela, sem rolagem para visualização e sem espaço para a entrada.
Porquê: um formulário que o usuário não pode ver ou alcançar é um formulário que ele não pode completar. É uma exclusão apenas mobile (R-03).
Consertar: quando uma entrada recebe foco, ela rola para a visualização acima do teclado, com preenchimento inferior suficiente para que o campo focado nunca seja coberto. Teste com um dispositivo real ou um teclado emulado.

Lista de Verificação da Habilidade Humana

Execute estas junto com o Portão de Entrega do núcleo quando a tarefa envolver UI. Todas as respostas devem ser sim:

Cada par de texto e fundo foi verificado contra o verificador de contraste (fórmula, tabela ou script), incluindo texto sobre imagens e gradientes? (R-25)
Cada limite de componente interativo e indicador de status atende 3:1 contra seu fundo? (contraste não textual)
O indicador de foco está visível, com alto contraste e presente em cada elemento interativo em cada tema? (R-32, R-34)
Cada elemento interativo é alcançável e operável por teclado, com diálogos fecháveis via Escape e nenhum outline: none sem substituto? (R-32, R-26)
Os estados vazio, de carregamento e de erro de cada visualização de dados estão presentes e perceptíveis, e não apenas por cor? (R-27, C-4)
O texto pode ser redimensionado para 200% sem ser cortado, e o teclado mobile nunca cobre uma entrada focada? (R-35)

yonathan-boop/Claude

O que é Claude?

Perguntar na sua IA favorita

Documentação