O que significa acessibilidade aplicada em um Design System
Acessibilidade aplicada em um Design System é a prática de transformar requisitos de inclusão em decisões repetíveis, verificáveis e fáceis de usar no dia a dia do produto. Em vez de tratar acessibilidade como “ajustes finais”, o Design System define padrões para que componentes, conteúdos e layouts já nasçam com contraste adequado, foco visível, leitura confortável e semântica coerente. Isso reduz retrabalho, evita inconsistências entre squads e melhora a experiência para pessoas com baixa visão, daltonismo, limitações motoras, uso de teclado, leitores de tela e também para usuários em contextos difíceis (sol forte, tela ruim, distrações, uso com uma mão).
Quatro pilares práticos ajudam a operacionalizar acessibilidade no sistema: contraste (percepção), foco (navegação), leitura (compreensão) e semântica (significado). Eles se conectam: um botão pode ter bom contraste, mas se o foco for invisível, o uso por teclado falha; um texto pode ser legível, mas se a hierarquia e a semântica estiverem erradas, leitores de tela e navegação por headings ficam confusos.
Contraste: garantindo percepção e distinção entre elementos
O que é contraste e por que ele falha em Design Systems
Contraste é a diferença perceptível entre primeiro plano e fundo (texto, ícones, bordas, estados). Em Design Systems, falhas comuns acontecem quando: cores são escolhidas apenas por estética, estados (hover/disabled) reduzem contraste demais, textos pequenos usam cores “suaves”, e componentes são reutilizados em fundos variados sem regras claras.
Para operacionalizar contraste no sistema, você precisa de regras que funcionem em escala: quais combinações de cor são permitidas, como tratar estados, e como garantir que “texto sobre cor” e “ícone sobre cor” mantenham legibilidade.
Regras práticas de contraste (referência WCAG)
- Texto normal: contraste mínimo 4.5:1 com o fundo.
- Texto grande (aprox. 18pt regular ou 14pt bold): contraste mínimo 3:1.
- Elementos não textuais essenciais (ícones informativos, bordas de campos, indicadores): contraste mínimo 3:1 contra o fundo adjacente.
- Não use apenas cor para comunicar estado (ex.: erro só em vermelho). Combine com texto, ícone, padrão, ou mensagem.
Mesmo que seu produto não tenha exigência formal, adotar esses limites como padrão do Design System reduz risco e melhora a consistência.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Passo a passo: como validar contraste de cores e estados no Figma
O objetivo é criar um ritual simples para designers: toda nova combinação de cor usada em texto/ícone/contorno deve ser checada, e os estados do componente devem ser checados também.
- 1) Identifique o par relevante: texto vs fundo, ícone vs fundo, borda vs fundo. Em componentes, verifique também o fundo do componente vs fundo da página quando isso afeta percepção (ex.: card com borda sutil).
- 2) Teste o estado padrão e todos os estados: default, hover, pressed, focus, disabled, selected, error/success/warning/info. Estados “disabled” são campeões de contraste insuficiente.
- 3) Verifique tamanhos: o mesmo token de cor pode passar em título grande e falhar em texto pequeno. Se o componente permite tamanhos diferentes, valide o pior caso (menor tamanho).
- 4) Documente a combinação aprovada: registre no guideline do componente quais pares são permitidos (ex.: texto inverso só em superfícies X e Y).
- 5) Se falhar, ajuste por regra, não por exceção: em vez de “aqui pode”, defina um token/estilo alternativo (ex.: texto em cor mais escura para fundos claros, ou superfície mais escura para texto branco).
Exemplo prático: botão primário em fundo colorido e em fundo neutro
Imagine um botão primário com fundo azul e texto branco. Ele pode passar em uma tela com fundo branco, mas falhar quando colocado sobre um banner azul claro (o contorno some, o foco some, e a distinção do botão diminui). Para evitar isso, defina regras no Design System:
- Botão primário: permitido sobre fundos neutros e superfícies com contraste mínimo X.
- Em fundos coloridos: usar variante “on-color” (ex.: botão com contorno e fundo diferente) ou inserir uma superfície intermediária (ex.: container com fundo neutro).
- Estados: hover/pressed não podem reduzir contraste abaixo do mínimo; prefira alterar luminosidade com cuidado e manter texto constante.
O ganho aqui é sistêmico: você evita que cada tela “reinvente” uma solução.
Foco: navegação por teclado e feedback claro de interação
O que é foco e por que ele é parte do Design System
Foco é o indicador visual de qual elemento está ativo durante navegação por teclado (Tab/Shift+Tab, setas, Enter/Espaço). Ele também é útil para usuários que alternam entre mouse e teclado, e para quem usa tecnologias assistivas. Em Design Systems, o foco precisa ser padronizado: mesma linguagem visual, mesma espessura, mesmo comportamento em componentes compostos (ex.: input com ícone, select, date picker).
Um erro recorrente é tratar foco como “um outline qualquer” que some em determinados fundos, ou que é removido por estética. Outro erro é confundir foco com hover: hover é ponteiro; foco é navegação e ativação.
Regras práticas para foco visível e consistente
- Foco deve ser sempre visível e não depender apenas de cor sutil. Use contorno com espessura suficiente e offset (se necessário) para não “grudar” no componente.
- O indicador de foco deve ter contraste mínimo 3:1 contra o fundo ao redor.
- Não use apenas sombra leve como foco; sombras podem desaparecer em fundos complexos.
- Em componentes com borda (inputs), o foco pode ser uma borda reforçada + anel externo (focus ring) para garantir visibilidade.
- Em componentes dentro de grupos (ex.: tabela, lista), defina se o foco é no item inteiro ou em subelementos, e mantenha previsível.
Passo a passo: especificando foco em componentes (sem depender de “bom senso”)
- 1) Defina um padrão de focus ring: cor, espessura, raio, offset e quando aparece (apenas teclado vs sempre). Mesmo que a implementação use
:focus-visible, o Design System precisa mostrar o visual. - 2) Aplique o padrão em componentes básicos: botão, link, input, checkbox, radio, switch, select, textarea. Esses são a base do restante.
- 3) Trate componentes compostos: por exemplo, um campo com ícone e botão de limpar. Decida se o foco vai para o campo inteiro e se ações internas são focáveis separadamente.
- 4) Defina foco em estados críticos: erro + foco, disabled (normalmente não recebe foco), read-only, loading. “Erro + foco” precisa continuar legível e não virar um conflito de bordas.
- 5) Documente a ordem de foco esperada em padrões: formulários, modais, menus, tabelas. Mesmo que o Design System não implemente, ele orienta.
Exemplo prático: foco em modal e armadilhas comuns
Em um modal, o foco deve ir para um elemento útil ao abrir (título não interativo não é ideal), e deve ficar “preso” dentro do modal até fechar (focus trap). No Design System, você pode especificar:
- Ao abrir: foco no primeiro campo ou no botão principal, dependendo do contexto.
- Tecla Esc fecha (quando permitido) e devolve foco ao elemento que abriu o modal.
- Ordem de Tab percorre apenas elementos do modal.
Mesmo sem entrar em detalhes de implementação, essa especificação evita que cada time decida diferente e que usuários de teclado se percam.
Leitura: tipografia, espaçamento e estrutura para compreensão
Leitura não é só fonte: é previsibilidade e carga cognitiva
Leitura envolve legibilidade (enxergar as letras), leiturabilidade (conseguir percorrer frases e parágrafos) e compreensão (entender o que é mais importante). Em Design Systems, isso se traduz em padrões de hierarquia, densidade, alinhamento, comprimento de linha, espaçamento e uso de estilos de texto por função.
Problemas comuns: textos longos em colunas muito largas, line-height apertado, contraste insuficiente em textos secundários, uso excessivo de caixa alta, e hierarquia inconsistente (um “subtítulo” que parece “título” em outra tela).
Regras práticas para leitura em interfaces
- Comprimento de linha: evite linhas longas demais em textos corridos; prefira limitar a largura de blocos de conteúdo.
- Espaçamento entre linhas: use line-height confortável para textos de parágrafo; textos pequenos precisam de mais respiro.
- Hierarquia clara: títulos, subtítulos, corpo e legenda devem ser distinguíveis por tamanho/peso/espaçamento, não apenas por cor.
- Evite depender de cor para hierarquia: “texto secundário” deve continuar legível e com contraste adequado.
- Use alinhamento consistente: textos longos geralmente funcionam melhor alinhados à esquerda; centralização em parágrafos longos dificulta leitura.
- Evite caixa alta em textos longos; reserve para rótulos curtos, se necessário.
Passo a passo: checklist de leitura para componentes com texto
Use este checklist ao desenhar ou revisar componentes como cards, listas, tabelas, banners e páginas de conteúdo.
- 1) Identifique a função de cada texto: título, descrição, metadado, ação, ajuda, erro. Cada função deve mapear para um estilo consistente.
- 2) Verifique contraste por função: descrição e metadados não podem cair em contraste “decorativo”. Se for informação necessária, trate como essencial.
- 3) Garanta espaçamento vertical: entre título e descrição, entre itens de lista, entre rótulo e valor. Espaçamento é parte da leitura.
- 4) Teste o pior caso de conteúdo: textos longos, idiomas com palavras grandes, números extensos, nomes próprios. Defina truncamento com reticências apenas quando houver alternativa (tooltip, expansão, quebra de linha).
- 5) Verifique estados de leitura: erro em formulário (mensagem clara), vazio (empty state), carregando (skeleton não deve parecer conteúdo real).
Exemplo prático: mensagens de erro e texto de ajuda em formulários
Um padrão acessível de leitura para formulários evita que o usuário “adivinhe” o que fazer. Defina no Design System:
- Texto de ajuda: aparece abaixo do campo, antes do erro, com linguagem instrutiva (o que é esperado).
- Texto de erro: mensagem específica (o que está errado e como corrigir), com contraste adequado e não apenas cor vermelha.
- Associação visual: erro próximo ao campo, com espaçamento consistente e, se possível, um ícone com significado (sem depender só do ícone).
Esse padrão melhora leitura para todos e reduz suporte e abandono.
Semântica: significado consistente para UI e para tecnologias assistivas
O que é semântica no contexto de Design System
Semântica é a correspondência entre a intenção do elemento e sua representação: um link navega, um botão executa ação, um título estrutura a página, um campo recebe entrada. Quando a semântica é respeitada, a interface fica previsível para usuários e interpretável por leitores de tela. Quando é quebrada, surgem problemas como: “texto que parece link mas não é”, “div clicável que não recebe foco”, “ícone sem rótulo”, “componentes que anunciam errado”.
No Design System, semântica não é só um detalhe de código: ela começa no design, ao escolher padrões corretos, rótulos claros e estruturas coerentes. O sistema deve orientar decisões para que o handoff seja direto: o desenvolvedor sabe qual elemento HTML/role faz sentido, e o designer sabe quando um padrão é inadequado.
Regras práticas de semântica para componentes
- Links vs botões: link para navegação; botão para ação. Se “parece botão” mas navega, alinhe visual e semântica (ou ajuste o padrão).
- Rótulos visíveis: campos devem ter label visível sempre que possível; placeholder não substitui label.
- Nome acessível: ícones clicáveis precisam de rótulo (texto visível ou nome acessível). “Somente ícone” exige cuidado extra.
- Estrutura por headings: páginas e modais devem ter hierarquia de títulos coerente para navegação rápida.
- Estados anunciáveis: componentes com estados (toggle, checkbox, tabs) devem ter semântica que comunique selecionado/não selecionado, expandido/recolhido.
Passo a passo: como documentar semântica no Design System (para reduzir ruído no handoff)
- 1) Para cada componente, declare a intenção: “navegar”, “submeter”, “filtrar”, “selecionar”, “expandir”. Isso guia a escolha de elemento semântico.
- 2) Liste comportamentos obrigatórios: foco por teclado, ativação por Enter/Espaço, leitura por leitor de tela (nome, estado, descrição).
- 3) Defina conteúdo obrigatório: label, texto de ajuda, mensagens de erro, contagem, título do grupo. Indique quando pode ser opcional e qual alternativa é aceitável.
- 4) Especifique atributos/roles esperados (em linguagem de guideline): por exemplo, tabs devem expor qual aba está selecionada e qual painel está ativo; acordeão deve indicar expandido/recolhido.
- 5) Inclua exemplos de uso correto e incorreto: isso evita que o componente seja usado como “atalho” para outra finalidade.
Exemplo prático: ícone de ação sem texto (botão de lixeira)
Um botão apenas com ícone pode ser acessível, mas precisa de regras. No Design System, defina:
- Quando é permitido: ações frequentes e reconhecíveis, em contextos com pouco espaço (ex.: linha de tabela).
- Nome acessível obrigatório: rótulo como “Excluir item” (não apenas “Excluir”).
- Tooltip não substitui nome acessível, mas pode complementar para usuários de mouse.
- Tamanho mínimo de área clicável e foco visível ao redor do ícone, não só no SVG.
Assim, o padrão não vira um “ícone misterioso” para leitores de tela ou para quem não reconhece o símbolo.
Integração dos 4 pilares em componentes do Design System
Como revisar um componente com uma matriz simples
Para tornar a revisão objetiva, use uma matriz de verificação por componente. Para cada estado do componente (default, hover, focus, pressed, disabled, error etc.), responda:
- Contraste: texto/ícone/borda passam nos mínimos?
- Foco: existe indicador visível e consistente? Não conflita com erro/seleção?
- Leitura: rótulos e mensagens são claros? Hierarquia e espaçamento ajudam?
- Semântica: a intenção do componente está clara? Há rótulos e estados comunicáveis?
Essa matriz funciona bem para botões, inputs, selects, tabs, acordeões, toasts, banners, tabelas e cards.
Passo a passo: criando “regras de uso” para evitar combinações inacessíveis
Um Design System acessível não depende apenas de “componentes bons”; ele depende de regras de uso que evitem combinações ruins.
- 1) Mapeie contextos de fundo: superfícies neutras, superfícies elevadas, fundos coloridos, imagens. Defina quais componentes podem aparecer em cada contexto.
- 2) Defina variações para contexto: por exemplo, “on-color” para texto e ícones em fundos fortes, e “subtle” apenas para conteúdo não essencial.
- 3) Estabeleça limites para estados: disabled não pode ser tão claro que vire ilegível; hover não pode reduzir contraste; focus não pode desaparecer em fundos coloridos.
- 4) Padronize mensagens: erro, alerta, sucesso e informação devem ter texto claro e não depender só de cor. Inclua estrutura: título curto + descrição opcional + ação.
- 5) Crie exemplos de composição: formulário completo, lista com ações, tabela com seleção, card com badge e botão. Em cada exemplo, mostre o foco e os estados.
Testes rápidos e rotinas de qualidade (para designers e times)
Checklist de revisão antes de liberar um componente/padrão
- Verifique contraste em todos os estados e tamanhos previstos.
- Navegue mentalmente por teclado: onde o foco aparece? a ordem faz sentido? existe algum elemento “clicável” que não deveria ser?
- Leia o conteúdo como se fosse a primeira vez: rótulos são específicos? mensagens dizem o que fazer?
- Confirme semântica: link é link, botão é botão, título parece título, agrupamentos são claros.
- Teste com conteúdo extremo: textos longos, números grandes, traduções, nomes extensos.
Exemplo de especificação em formato copiável (para documentação do componente)
Componente: Campo de texto (Text Field) Requisitos de acessibilidade: - Contraste: texto e placeholder devem manter contraste adequado; borda do campo deve ser perceptível (mín. 3:1). - Foco: focus ring visível (espessura X, offset Y), não pode ser removido; deve funcionar em erro + foco. - Leitura: label sempre visível; texto de ajuda opcional; erro sempre abaixo do campo com mensagem acionável. - Semântica: label associado ao campo; erro associado ao campo; estado disabled não recebe foco; read-only deve ser anunciado como somente leitura. Estados: default, hover, focus, filled, error, disabled, read-only
