Componentes e estados: especifique além da tela padrão

O desenho de um componente em repouso mostra uma parte pequena do seu comportamento. Um campo pode estar preenchido e inválido; um botão pode receber foco durante uma operação; uma opção pode continuar selecionada mesmo quando o cursor está em outro lugar. Essas combinações precisam de decisões explícitas para que a interface comunique o que está acontecendo.

Separe interação, valor e condição operacional

Comece listando dimensões diferentes. Interação inclui repouso, passagem do ponteiro e foco. Valor inclui marcado, desmarcado ou parcialmente selecionado, quando aplicável. Condição operacional abrange disponível, indisponível e processando. Misturar essas dimensões em uma única lista costuma esconder combinações que aparecem no uso real.

Uma caixa de seleção marcada também pode estar em foco. Se ambos os estados usam exatamente o mesmo preenchimento sem outros sinais, a pessoa pode confundir localização com escolha. Projete indicadores que coexistam. A marca identifica o valor; um contorno reconhecível pode indicar onde a próxima ação de teclado acontecerá.

Monte uma matriz apenas com combinações possíveis

Organize uma tabela com estado, evento de entrada, aparência, comportamento e saída. Descarte combinações impossíveis por regra de negócio e justifique as restantes. Um botão de envio que fica processando precisa informar se aceita novo acionamento, se pode ser cancelado e o que acontece quando a requisição falha.

Especifique transições e persistência

Não basta desenhar sucesso e erro em quadros separados. Registre quando a mensagem aparece, quando desaparece e quais dados permanecem. Uma opção selecionada não deveria perder seu valor só porque o ponteiro saiu; uma falha de rede não deveria apagar silenciosamente a configuração anterior.

Dê significado consistente aos controles

Considere um painel hipotético que permite fixar relatórios favoritos. O botão com ícone de alfinete alterna entre fixado e não fixado. Nesse caso, aparência e informação para tecnologia assistiva precisam refletir a mesma condição. A documentação da MDN sobre aria-pressed explica o estado de botões de alternância e a relação com seus rótulos.

Já abrir uma janela é outro comportamento: não representa necessariamente uma preferência ativada. Antes de escolher uma propriedade técnica, descreva a ação em linguagem comum. Esse passo reduz o risco de reutilizar o mesmo componente visual para interações com significados incompatíveis.

Explique indisponibilidade sem criar um beco sem saída

Um controle desativado pode mostrar que uma função existe, mas sozinho não explica o que falta. Se a liberação depende de uma condição, apresente essa condição perto da área relevante. Em um cadastro, a frase selecione um depósito para continuar pode ser mais útil que um botão acinzentado sem contexto.

Decida também como a pessoa descobre a explicação usando teclado e leitor de tela. Um texto mostrado somente ao passar o mouse deixa parte do público sem resposta. Quando a restrição deriva de permissão, diferencie-a de um carregamento temporário: esperar não resolverá uma autorização ausente.

Verifique o componente na composição real

Estados costumam falhar quando saem da página de exemplos. Um foco com boa visibilidade no fundo branco pode desaparecer sobre um aviso. Mensagens longas podem empurrar ações importantes para fora de um painel. A composição deve preservar leitura, relação entre mensagens e controle e ordem de interação.

Escolha um fluxo que combine entrada inválida, processamento e recuperação. Compare o navegador com a matriz e registre divergências de comportamento, além de cor ou tamanho. Atualize a documentação quando surgir uma combinação legítima ainda não prevista. Esse ciclo mantém os estados próximos do produto e evita que cada entrega reinvente regras essenciais.