ShortArrow/interface-design

Design de interface

Uma pergunta sobre uma tela não é uma pergunta sobre gosto. Contraste tem uma proporção, um alvo tem um tamanho, um reflow tem uma largura na qual ainda deve funcionar, e um layout tem uma ordem de informação que decorre do que o leitor faz primeiro. Isso é decidido por medição e por padrões publicados, portanto entregá-los ao usuário como "qual você prefere" gasta a atenção deles em trabalho que era do agente.

O que resta após medir é uma pergunta real, e esta skill existe para tornar esse resto pequeno e anexar a evidência a ele. own-the-call rege como ela é então feita.

Os momentos que isso substitui

Prestes a…	Em vez disso
perguntar qual cor, tamanho, espaçamento ou posicionamento o usuário prefere	medir contra o padrão abaixo; perguntar apenas o que nenhum limite resolve
chamar uma escolha visual de subjetiva	nomear o critério que ela falha ou passa — contraste, tamanho do alvo, largura de reflow, visibilidade do foco, ordem de informação
dizer "parece bom"	abrir, capturar a tela e dizer o que foi medido em qual viewport
dimensionar um controle a olho	24×24 CSS px é o piso WCAG AA; um design system pode definir um mais restritivo (Material: 48dp)
escolher cores de uma paleta pela aparência	calcular a proporção: 4,5:1 texto do corpo, 3:1 texto grande e não texto
enviar um layout verificado em um tamanho de janela	verificar com 320 CSS px de largura e 256 CSS px de altura, onde o reflow ainda deve funcionar
ler uma execução verde do axe como acessível	axe encontra cerca de 57%; o resto é teclado, ordem de foco e significado
projetar um componente que um design system já define	pegar o deles e dizer qual
perguntar como desenhar um diagrama	decidir a partir do que o leitor traça primeiro, depois mostrar uma renderização

Decidir a partir do padrão antes de perguntar

Quatro corpos respondem a maior parte disso, e eles não concordam totalmente — onde diferem, o número mais restritivo é o que deve ser cumprido, porque cumpri-lo satisfaz ambos.

WCAG 2.2 é o piso, e é normativo: uma Recomendação W3C, e ISO/IEC 40500. Alvo Nível AA; AAA não é alcançável para todo conteúdo e o W3C diz isso.

Critério	Nível	Limite
1.4.3 Contraste (Mínimo)	AA	4,5:1 texto; 3:1 para texto grande (≥18 pt, ou 14 pt negrito)
1.4.11 Contraste Não Texto	AA	3:1 contra cores adjacentes
1.4.4 Redimensionar Texto	AA	utilizável em 200%
1.4.10 Reflow	AA	sem rolagem em dois eixos a 320 px de largura ou 256 px de altura
1.4.12 Espaçamento de Texto	AA	altura da linha ≥1,5×, parágrafo ≥2×, letra ≥0,12×, palavra ≥0,16× tamanho da fonte
2.4.7 Foco Visível	AA	um modo onde o indicador de foco é visível
2.4.11 Foco Não Obstruído	AA	o controle focado não está totalmente oculto
2.5.8 Tamanho do Alvo (Mínimo)	AA	24×24 CSS px, ou espaçamento de 24 px
2.4.13 Aparência do Foco	AAA	≥2 px de perímetro, 3:1 entre focado e não focado
2.5.5 Tamanho do Alvo (Aprimorado)	AAA	44×44 CSS px

Um design system resolve o que o WCAG deixa em aberto: escala de espaçamento, escala tipográfica, anatomia de componentes, papéis de cor. Pegar seu componente não é um atalho, é a decisão — e carrega o trabalho de acessibilidade já feito. Material Design 3 define alvos de toque de 48×48 dp, mais restritivo que os 24 px do WCAG, e pede que a cor seja escolhida como papéis (primary, on-primary, surface) em vez de hex fixo, para que temas e modo escuro sigam sem uma segunda decisão. Para trabalho público japonês, o design system da Agência Digital (design.digital.go.jp, β版 como padrão vivo) carrega componentes, orientação e tokens, com os tokens e componentes de exemplo no GitHub sob MIT.

axe-core mede o que pode ser medido e afirma seu próprio limite: cerca de 57% dos problemas WCAG em média. Uma execução verde é, portanto, evidência sobre 57% da pergunta, e dizer "axe passou" sem esse número o exagera — measured-claims aplica-se a este número como qualquer outro.

npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet

A pontuação de acessibilidade do Lighthouse é o mesmo mecanismo usando um número. Suas auditorias são regras do axe-core — cada uma linka para a página de regra da Deque — então os 57% são herdados, e a pontuação adiciona duas maneiras de ser mal interpretada. É uma média ponderada, pesos de 3 a 10 pela avaliação de impacto do usuário do axe, e auditorias manuais e de melhores práticas são completamente excluídas dela, então a aritmética não pode alcançar a parte que uma pessoa precisa verificar. Cada auditoria também é binária: um botão não rotulado falha "Botões têm um nome acessível" diretamente, sem crédito parcial. Portanto, 100 significa "o subconjunto automático ponderado passou", e o relatório honesto de uma pontuação perfeita diz isso, não "acessível". Use-o para a lista classificada do que corrigir; use o JSON do axe quando a descoberta importar mais que a classificação. As categorias de desempenho do Lighthouse são do web-perf, não desta skill.

O que nenhum dos dois pode ver: se a ordem do foco segue a ordem de leitura, se um rótulo nomeia a coisa que rotula, se o significado de um ícone sobrevive sem cor, se a ordem de informação do layout corresponde à tarefa. Isso é lido por uma pessoa, e a pessoa pode ser o agente.

Olhe para isso, então diga o que foi visto

Uma alegação de interface sem observação por trás é o boato do measured-claims em outro meio. O host tem um navegador, então a observação está disponível:

mcp__claude-in-chrome__navigate      → a página
mcp__claude-in-chrome__read_page     → estrutura, cabeçalhos, rótulos
mcp__claude-in-chrome__computer      → captura de tela em um viewport declarado
mcp__claude-in-chrome__resize_window → 320 px, para testar reflow

Relate o viewport com a descoberta. "Parece certo" não nomeia largura nem medição; "a 320 px a segunda coluna quebra sob a primeira e nada rola para os lados" é uma leitura que alguém pode verificar. A ordem do teclado é percorrida com Tab e relatada como a sequência observada, porque essa é a metade que o axe não cobre.

A ordem de informação é derivada, não escolhida

Onde algo vai decorre do que o leitor faz com isso, que é a pergunta do reader-map aplicada a uma tela: quem chega, o que veio fazer, do que precisa primeiro. Um controle usado uma vez na configuração e um controle usado a cada minuto não competem pelo mesmo lugar.

Portanto, "onde isso deve ir" é respondido nomeando a tarefa, não listando três posições. Quando duas tarefas genuinamente competem e nenhuma domina, esse é o resto que vale a pena perguntar — e é perguntado com as tarefas concorrentes nomeadas, não como uma escolha de cantos.

O mesmo vale para um diagrama. O que o leitor traça primeiro decide a direção do fluxo; a forma segue o traço, e uma renderização é mostrada em vez de três descritas.

O que é genuinamente do usuário

Três coisas sobrevivem à medição:

• Qual público ou mercado a interface atende, quando isso ainda não está fixo — decide qual padrão se aplica (regulated-claims para um mercado regulado).
• Uma restrição de marca — uma cor, tipografia ou marca obrigatória. A restrição é deles; se atende a 4,5:1 ainda é medido, e uma cor de marca que falha é relatada com a proporção e a variante aprovada mais próxima.
• Um trade-off já medido de ambos os lados, onde a evidência não decide: densidade contra escaneabilidade, uma tela contra duas. Perguntado com ambas as medições anexadas, é uma pergunta que own-the-call admite.

Todo o resto — contraste, espaçamento, tamanho do alvo, foco, reflow, escolha de componente, forma do diagrama, posicionamento que segue uma tarefa — é decidido e relatado.

Checklist

• Contraste calculado, não estimado a olho: 4,5:1 texto, 3:1 grande e não texto
• Alvos interativos ≥24×24 CSS px, ou o valor mais restritivo do design system
• Verificado a 320 px de largura e 256 px de altura sem rolagem em dois eixos
• Foco visível em cada elemento interativo, e não obstruído
• Ordem de tabulação percorrida e relatada como observada
• Componentes retirados do design system onde ele define um, e nomeados
• axe ou Lighthouse executado, e o limite de 57% declarado em vez de implícito
• Uma pontuação de acessibilidade do Lighthouse relatada como o subconjunto automático ponderado, nunca como "acessível"
• Toda alegação de aparência carrega o viewport em que foi observada
• Perguntas deixadas para o usuário são os três tipos acima, com evidência anexada

Como isso se conecta

own-the-call molda a pergunta que sobrevive a esta skill; a maioria das perguntas sobre uma tela não deve alcançá-la. reader-map fornece a ordem de tarefas à qual esta skill aplica o posicionamento. measured-claims rege toda proporção e porcentagem aqui, os 57% incluídos. document-structure e cognitive-rhythm são donos da prosa em uma página; esta skill é dona do quadro ao redor dela. any-screenshot é como uma tela é capturada fora de um navegador. Velocidade de carregamento e interação, Core Web Vitals e pontuação de desempenho do Lighthouse pertencem ao web-perf no plugin cloudflare; esta skill pega apenas a categoria de acessibilidade do Lighthouse.

Fontes

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", Recomendação W3C datada de 12 de dezembro de 2024 (www.w3.org/TR/WCAG22/): os quatro princípios, os níveis A/AA/AAA, e a remoção de 4.1.1 Analisando como obsoleto.
• W3C, "How to Meet WCAG 2.2 (Quick Reference)" (www.w3.org/WAI/WCAG22/quickref/): todo limite na tabela acima, lido no Nível AAA para incluir 2.4.13 e 2.5.5.
• Deque Labs, README do axe-core (github.com/dequelabs/axe-core): MPL-2.0; regras mapeadas para WCAG 2.0, 2.1 e 2.2 em A, AA e AAA; "você pode encontrar em média 57% dos problemas WCAG automaticamente".
• Chrome para Desenvolvedores, "Pontuação de acessibilidade no Lighthouse" (developer.chrome.com/docs/lighthouse/accessibility/scoring): a pontuação é uma média ponderada, pesos de 3 a 10, "com base nas avaliações de impacto do usuário do axe", com cada auditoria linkando para uma página de regra do axe-core 4.11 da Deque University; cada auditoria é binária; auditorias manuais e de baixo impacto são excluídas da pontuação. A página não diz que uma pontuação perfeita significa que a página é acessível — nem diz o contrário, então o aviso acima é desta skill.
• デジタル庁デザインシステム (design.digital.go.jp): v2.18.2, rotulado β版 no sentido de um padrão vivo. O site não declara nenhum nível WCAG nem alvo JIS X 8341-3. digital-go-jp/design-tokens, design-system-example-components-react e -html no GitHub são MIT.
• O alvo de toque de 48×48 dp do Material Design 3 e sua orientação de papéis de cor são retirados de fontes secundárias que citam m3.material.io, não desse site: suas páginas renderizam por script e não puderam ser lidas aqui. O valor de 48 dp é uma recomendação de design, não um mínimo imposto pela plataforma.

A alegação de que essas fontes discordam, e que o valor mais restritivo é o que deve ser cumprido, é a leitura deste proprietário do catálogo, não qualquer uma de suas posições publicadas.

Nenhum dos comandos acima foi executado enquanto esta skill era escrita: ambos buscam um pacote no primeiro uso, e o sandbox aqui se recusa a executar código baixado recentemente. As flags vêm da documentação de cada ferramenta, não de uma execução, portanto o primeiro uso em um projeto é também o primeiro teste da invocação.