Módulo 2 · 7 de 9
Acessibilidade: não é bônus, é requisito
Leitura: ~10 min
Agora vamos falar de algo que eu considero um dos temas mais importantes de todo este curso. E eu quero que você entenda acessibilidade não como uma checklist que você preenche no final do projeto, mas como um ato de empatia. Projetar com acessibilidade é dizer: "eu reconheço que as pessoas usam tecnologia de formas diferentes, e todas elas merecem uma experiência digna."
E acredite: acessibilidade não é algo que afeta "poucas pessoas". Pense em um grupo de uns 12 homens que você conhece: é provável que pelo menos um deles tenha algum grau de daltonismo (a prevalência é de cerca de 8% entre homens e de 1 em 200 entre mulheres). Ou em uma pessoa que quebrou o braço e está usando o celular com uma mão só. Ou em uma mãe segurando o bebê enquanto tenta ler uma notificação. Acessibilidade não é exclusiva para pessoas com deficiências permanentes, ela alcança qualquer pessoa em qualquer momento da vida.
Três histórias que mudaram minha perspectiva
O dashboard que ninguém via
Em um projeto de dashboard financeiro, um dos stakeholders mencionou que tinha dificuldade em distinguir as cores dos gráficos. Fomos investigar e descobrimos que ele era daltônico. A paleta que tínhamos escolhido, cheia de verdes e vermelhos para indicar lucro e prejuízo, tornava boa parte das informações invisíveis para ele. E o mais revelador: muitos sites de visualização de dados que encontramos como referência na internet eram igualmente falhos em acessibilidade, inclusive os que ensinavam boas práticas de apresentação de dados. Redesenhamos usando formas e padrões além de cor, e o resultado funcionou melhor para todos, não só para ele.
Esse caso me ensinou algo concreto: daltonismo acomete uma parte significativa da população masculina mundial. Existem diferentes tipos, alguns mais raros que outros, mas a prevalência é alta o suficiente para que você sempre tenha usuários daltônicos no seu produto. Se a sua interface depende exclusivamente de cor para comunicar informação, você está excluindo essas pessoas sem perceber.
A colega surda e os avatares de Libras
Uma colega surda fez uma apresentação que mudou a forma como eu penso sobre soluções de acessibilidade. Ela explicou que muitos surdos não são alfabetizados na escrita da mesma forma que pessoas ouvintes, o que impacta diretamente a forma como consomem conteúdo textual. Uma solução que parecia inclusiva, o uso de assistentes virtuais e avatares 3D para interpretação de Libras, se mostrava ineficaz na prática.
O motivo: Libras é um idioma visual, rico em expressões faciais e corporais. O rosto transmite emoção, ênfase, pergunta, negação. Os avatares digitais, apesar de bem-intencionados, não conseguem reproduzir essa riqueza expressiva. A comunicação fica mecanizada, incompleta. Ela me ensinou que acessibilidade não é só implementar uma solução técnica, é entender profundamente como as pessoas se comunicam. Com o avanço da inteligência artificial, podem surgir melhorias, mas até lá, o desafio persiste.
Seis meses com o braço imobilizado
Eu mesmo passei quase seis meses com o braço direito imobilizado após uma lesão, usando apenas o braço esquerdo. De repente, usar o celular com uma mão só virou um desafio diário. Botões que exigiam duas mãos, gestos de swipe que não funcionavam, formulários impossíveis de preencher. Acessibilidade deixou de ser "um tema importante que eu defendo" e virou minha realidade.
Pense também em uma mãe ou pai segurando um bebê com um braço, tentando ler uma notificação com o outro. Ou alguém com tendinite temporária. Essas situações mostram que acessibilidade não é algo exclusivo para pessoas com deficiências permanentes. É para qualquer pessoa, em qualquer momento da vida. Qualquer um de nós pode estar nessa situação amanhã.
O UX Honeycomb de Morville
Peter Morville, um dos pioneiros da arquitetura de informação, criou o UX Honeycomb, um modelo que organiza as facetas da experiência do usuário em sete qualidades: útil, usável, desejável, acessível, encontrável, credível e valioso. Repare que "acessível" está ali no mesmo nível de "usável" e "desejável". Não é um bônus, não é um detalhe. É uma das facetas fundamentais de qualquer experiência bem projetada.
Esse modelo é importante porque coloca acessibilidade no lugar certo: não como uma camada que você adiciona depois, mas como uma dimensão intrínseca da qualidade da experiência. Um produto pode ser útil e usável, mas se não for acessível, ele falha como experiência para uma parte significativa dos seus usuários.
WCAG 2.2: a referência que você precisa conhecer
As WCAG (Web Content Accessibility Guidelines) são as diretrizes internacionais de acessibilidade para conteúdo digital. A versão mais recente é a WCAG 2.2, lançada em 2023, que trouxe critérios novos especialmente relevantes para designers.
Os quatro princípios: POUR
As WCAG se organizam em quatro princípios fundamentais, conhecidos pela sigla POUR:
- Perceptível: o usuário consegue perceber o conteúdo? Textos alternativos em imagens, legendas em vídeos, contraste suficiente entre texto e fundo. Se a informação depende exclusivamente de um sentido (como visão), alguém que não tem esse sentido fica excluído.
- Operável: o usuário consegue interagir? Navegação por teclado, tempo suficiente para completar ações, sem conteúdo que pisca de forma perigosa. Se um fluxo só funciona com mouse, ele exclui quem navega por teclado ou por voz.
- Compreensível: o usuário entende o que está acontecendo? Linguagem clara, comportamento previsível, ajuda contextual em formulários. Um erro de formulário que diz "erro 422" sem explicação viola esse princípio.
- Robusto: funciona em diferentes tecnologias assistivas? HTML válido, tags semânticas, atributos ARIA quando necessário (ARIA são etiquetas extras que o dev adiciona ao HTML para dar contexto aos leitores de tela quando as tags comuns não bastam). O código precisa ser interpretável por leitores de tela, displays braille e outras ferramentas.
O nível de conformidade vai de A (o mínimo absoluto) a AA (o recomendado para a maioria dos produtos digitais) a AAA (o mais rigoroso, ideal mas nem sempre viável para toda a interface).
O que mudou na WCAG 2.2
A versão 2.2 trouxe critérios que impactam diretamente o trabalho de design:
- Tamanho mínimo de alvo (Target Size): elementos interativos devem ter pelo menos 24x24px (nível AA). A recomendação ideal continua sendo 44x44px. Aquele ícone minúsculo no canto da tela? Provavelmente viola esse critério.
- Aparência de foco (Focus Appearance): quando um usuário navega por teclado, o indicador de foco precisa ser claramente visível, com contraste mínimo e área suficiente. Muitos designers desabilitam o outline de foco por "estética". Isso é um problema real de acessibilidade.
- Movimentos de arrastar (Dragging Movements): toda funcionalidade que depende de arrastar deve ter uma alternativa que funcione com clique simples. Drag-and-drop é conveniente, mas exclui quem não consegue fazer esse gesto.
Contraste: os números que importam
Contraste é uma das questões mais práticas de acessibilidade no dia a dia do designer. As WCAG definem ratios mínimos:
- Texto normal: ratio mínimo de 4.5:1 (nível AA)
- Texto grande (acima de 18pt ou 14pt bold): ratio mínimo de 3:1
- Elementos de interface (ícones, bordas de input, indicadores de foco): ratio mínimo de 3:1
Aquele cinza claro sobre branco que parece elegante no seu monitor calibrado? Pode ser ilegível no celular do seu usuário, com a tela no brilho mínimo, dentro do ônibus sob luz solar direta. Ferramentas como o plugin Stark do Figma verificam contraste em tempo real enquanto você projeta.
Acessibilidade e HTML semântico: a conexão
Lembra do HTML semântico que vimos nas páginas anteriores deste módulo? Aquela distinção entre usar <div> genéricos e tags com significado como <nav>, <main>, <header> e <h1>? Ela é a base técnica da acessibilidade na web.
Quando a página usa tags semânticas, os leitores de tela conseguem navegar pela estrutura: "pular para a navegação", "ir para o conteúdo principal", "listar todos os títulos da página". Quando é tudo <div>, o leitor de tela vê um mar de caixas sem significado, e o usuário precisa percorrer elemento por elemento, linearmente, sem atalho.
É por isso que o HTML semântico não é "frescura de dev". É infraestrutura de acessibilidade. E o designer tem um papel direto nisso: quando você cria uma hierarquia de camadas bem organizada no Figma e se preocupa com a nomenclatura dos componentes, você está ajudando o desenvolvedor a construir um HTML mais semântico. Quando você define no handoff qual é o <h1>, qual é o <nav>, qual é o <main>, você está facilitando a construção de uma experiência acessível.
Pense comigo: acessibilidade não é uma camada que se adiciona no final. Ela começa na estrutura. E a estrutura começa no HTML. E o HTML começa nas decisões de design.
Teste de usabilidade vs. teste de acessibilidade
Uma confusão comum: achar que teste de usabilidade cobre acessibilidade. Não cobre. São testes complementares:
- Teste de usabilidade: avalia se a interface é eficaz, eficiente e satisfatória para o uso geral. Você observa usuários completando tarefas e identifica onde travam. Responde à pergunta: "as pessoas conseguem usar?"
- Teste de acessibilidade: verifica se a interface atende padrões técnicos como as WCAG: contraste de cores, navegação por teclado, textos alternativos em imagens, compatibilidade com leitores de tela. Pode ser automatizado (com ferramentas como Lighthouse, axe ou Wave) e também manual. Responde à pergunta: "todas as pessoas conseguem usar?"
Um produto pode ser usável e inacessível ao mesmo tempo. Funciona perfeitamente para quem vê, ouve e usa as duas mãos, mas trava completamente para quem não está nessa situação. Nosso papel como designers é garantir que ambos os testes façam parte do processo, desde o início, não como uma etapa final antes do lançamento.
Checagem rápida
Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.
Um formulário mostra o erro "422" em cinza clarinho sobre branco e só sinaliza o campo com problema pela cor vermelha da borda. Quais princípios do POUR isso fere?
Pelo menos dois. Compreensível: "erro 422" não diz à pessoa o que fazer, falta linguagem clara. E Perceptível: o cinza claro sobre branco pode não ter contraste suficiente, e depender só da cor vermelha exclui quem tem daltonismo. O ideal é mensagem em texto explicando o problema, mais um indicador que não seja apenas cor.
No handoff o time discute um texto de corpo em cinza claro sobre fundo branco porque "fica elegante". Que número você leva para a conversa, e por quê?
4.5:1, o ratio mínimo de contraste para texto normal no nível AA das WCAG. Abaixo disso, o texto que parece elegante no seu monitor calibrado vira ilegível no celular do usuário, no brilho mínimo, dentro do ônibus sob sol. Um verificador de contraste, como o plugin Stark no Figma, mostra na hora se o par de cores passa.