Acessibilidade para além do contraste

A primeira coisa que muitas equipas associam a acessibilidade é cor. “Verifica o contraste no Stark.” E é importante. Mas se o trabalho de acessibilidade acaba aí, é o equivalente a dizer que a saúde se resume a tomar vitaminas.

A acessibilidade tem várias camadas. Visual é só uma. As outras (auditiva, motora, cognitiva, neurodivergente) são igualmente reais e, em muitos casos, mais ignoradas. Este post percorre o que costumo verificar para além do contraste.

A camada visual (rapidamente)

Para fechar primeiro a parte mais conhecida:

• Contraste: rácio mínimo 4.5:1 para texto normal, 3:1 para texto grande (WCAG AA). Para AAA, 7:1 e 4.5:1. Verificável com Stark, Contrast Checker, WebAIM.
• Tamanho de fonte: 16px é o piso confortável para texto corrido. Em mobile, mais.
• Não usar cor como único indicador: erros não podem ser apenas vermelhos; sucesso não pode ser apenas verde. Texto, ícone, ou padrão.
• Foco visível: sempre. O foco do teclado tem de ser óbvio para quem navega sem rato.

Isto cobre a parte visual mais imediata. O resto é onde menos equipas chegam.

A camada auditiva

Áudio em produto está a crescer (notificações, voice UI, vídeos integrados). Cada som pede legendas, transcrição ou alternativa textual.

• Legendas em vídeos: sempre. Mesmo nos GIFs explicativos sem narração, considera adicionar texto descritivo abaixo.
• Transcrição: para podcasts, calls gravadas, qualquer áudio principal.
• Não dependeres apenas de som para feedback: um beep de sucesso tem de ter um equivalente visual.
• Voice UI: oferecer alternativa textual sempre que possível. Nem todos podem ou querem falar em público.

A camada motora

Pessoas com tremor, paralisia, lesões de pulso, ou que usam só uma mão precisam de interfaces que não exijam gestos finos.

• Áreas de toque mínimas: 44×44px (Apple HIG) ou 48×48dp (Material). Não menos.
• Espaço entre alvos: 8px no mínimo. Botões colados são cliques errados garantidos.
• Hover não é confiável em mobile. Nem em tablets. Tudo o que aparece em hover tem de ter alternativa de toque.
• Tempo limite generoso ou ajustável. Se tens session timeouts ou animações que avançam sozinhas, dá controlo ou aviso.
• Drag and drop tem de ter alternativa. Reorder list com setas, por exemplo.

A camada cognitiva

Aqui é onde me concentro mais ultimamente, porque é onde menos equipas pensam. Cognitivo abrange: dificuldades de atenção, memória de trabalho, processamento de linguagem, ansiedade, neurodivergências.

Práticas que funcionam:

• Linguagem simples. Palavras curtas, frases curtas. Sem jargão. Vale Flesch Reading Ease alto.
• Estrutura previsível. Mesma localização de elementos entre páginas. O cérebro que tem dificuldade em prever cansa-se com layouts inconsistentes.
• Reduzir carga cognitiva: mostrar uma coisa de cada vez quando possível. Steps em wizards, não 30 campos numa página.
• Progress indicators: a pessoa com ansiedade beneficia de saber onde está e quanto falta.
• Save state automaticamente. Quem se distrai e fecha o separador não pode perder tudo.
• Confirmação de ações destrutivas, mas não confirmação de tudo (ruído).

Acessibilidade para dislexia (o caso contra-intuitivo)

Algo que aprendi na minha equipa, partilhado pela Rita, que tem dislexia: as práticas para dislexia, em alguns pontos, contradizem as práticas gerais de acessibilidade visual.

Acessibilidade geral pede contraste alto. Para dislexia, contraste mais baixo ajuda. Texto preto em fundo branco puro pode causar fadiga e dificultar leitura para quem tem dislexia. Um cinzento escuro em fundo creme ou off-white é, frequentemente, mais legível.

Outras práticas:

• Fonte sans-serif, não serif.
• Tamanho maior: 18px+ em vez de 16px.
• Espaçamento entre letras ligeiramente maior (letter-spacing: 0.02em-0.05em).
• Espaçamento entre linhas generoso (line-height: 1.5+).
• Evitar itálicos e sublinhados que distorcem a forma das letras.
• Linhas curtas: máximo 60-80 caracteres por linha.

A solução em produto: oferecer um modo de leitura ou theme alternativo. Não substituir o default.

Leitores de ecrã: o que mais faz a diferença

Se o produto não funciona com VoiceOver, JAWS ou NVDA, está exclusivo. As práticas mais impactantes:

• HTML semântico. <button> para botões, <nav> para navegação, <main> para conteúdo principal. Não dependas só de classes.
• Alt text em imagens. Descritivo, não “imagem de uma pessoa”.
• Labels em todos os inputs. Não placeholders como labels.
• Ordem do DOM coerente com a ordem visual. Ler em ordem, não saltar.
• ARIA quando o HTML não chega, mas só quando não chega. Mau ARIA é pior do que nenhum.

Testar é mais simples do que parece: Mac vem com VoiceOver embutido (Cmd+F5). Dez minutos a navegar o teu próprio produto com VoiceOver mostra mais do que uma audit do que qualquer checklist.

O que adicionar ao teu fluxo

Três acções concretas:

1. Adiciona uma rubrica de acessibilidade ao design review, com pelo menos 5 linhas: contraste, tamanho de toque, alternativa não-visual, leitor de ecrã, simplicidade de linguagem.
2. Faz um teste de VoiceOver mensal num flow do teu produto. Apenas tu, 10 minutos, sem audit formal. Vais encontrar coisas.
3. Conversa com alguém que use tecnologia assistida. Mesmo que seja uma chamada curta. Vale mais do que ler 5 artigos.

Mais sobre o pano de fundo no guia Inclusão e Diversidade. Sobre o overlap entre acessibilidade e envelhecimento, ver The crucial need for designing for ageing. Para acessibilidade em workshops e research, ver Workshops acessíveis.