Ainda no brainstorm, parte conceitual de qualquer produto digital, somos guiados a focar no público médio, aquele formado pela maioria dos usuários para a qual é destinada a principal função de um produto. Pelo menos é assim que aprendemos na faculdade da vida. E é assim em tudo na vida. Desde a tampa do pote de geleia, feita sob medida por alguém pesquisou o tamanho médio das mãos das pessoas para que pudéssemos segurar e abrir a tampa confortavelmente, até a altura da bancada da sua pia de cozinha, onde os mais altos enfrentam dificuldades diárias para lavar uma simples louça.

A vida é mais fácil se você está na média, mas se você é muito maior que a média vai ter dores constantes nas costas na hora de lavar louças. Seguindo por esse pensamento, um público que é constantemente esquecido (ou até ignorado) e não está na média, são as pessoas com necessidades especiais desabilitadas. Enxergar esse público é uma dificuldade para mim e para muitos outros que fazem parte “da média”. Tenho tentado seguir alguns processos ao começar ou entrar em um projeto, o que tem me ajudado a pensar em públicos que não são contemplados pela maioria. Mais especificamente, os com necessidades especiais.

1) Contraste e cores

O design gráfico possui uma incrível relação entre as cores e as mensagens que elas passam. Mas além de escolher uma paleta incrível para o seu projeto, você precisa pensar que as pessoas que não vão enxergar a plenitude delas também usarão sua interface.

Nada como o preto no branco (literalmente): tente testar sua interface ao menos uma vez somente com tons de cinza. Esse artigo da UX Mag fala sobre isso.

Se você usa Sketch App pra trabalhar, o plugin Color Contrast Analyser vai quebrar um galho para você.

Ah, dê uma pesquisada rápida sobre os tipos de daltonismo existentes: Deuteranopia, Protanopia e Tritanopia.

2) Tamanhos de fontes

Para pessoas idosas ou com problemas de visão, tamanho de fonte é algo que se deve prestar a atenção. A hierarquia de fonte tem muita importância, mas para acessibilidade você precisa pensar com mais carinho a respeito disso. Segundo o WCAG (Web Content Accessibility Guidelines) 2.0, as fontes grandes são 18pt e 14pt e em negrito já garantem uma pontuação de contraste em 3:1 (o ideal é 4.5:1).

(você pode fazer o teste nesse link https://www.w3.org/TR/WCAG/).

3) Guias de acessibilidade dos sistemas

O guia do Material Design tem um material rico e didático sobre acessibilidade, que aborda alguns temas de forma bem direta. Como por exemplo colocar “rótulos” nos seus botões de uma maneira correta e sucinta, tamanho de botões para que fiquem mais acessíveis e tamanhos de fontes. E mesmo que você não o use no Android ou em algo que de fato siga ele, o guia do Material Design serve como uma boa fonte para você se basear na hora de pensar em acessibilidade.

https://material.io/guidelines/usability/accessibility.html#accessibility-style

A Apple também possui uma área em seu site falando sobre acessibilidade no iOS:

https://developer.apple.com/ios/human-interface-guidelines/interaction/accessibility/

4) Não esqueça de alt tags e rótulos (label) de botões

Algo simples e que ajuda muito os que têm uma visão muito comprometida ou nenhuma.

O item dois dessa lista fala sobre o guia do Material Design e de como dar rótulos aos seus botões.

Meu coração ficou tocado após assistir um vídeo do Android no qual pessoas cegas passam pela frustração de usar um aplicativo no modo acessibilidade. E o aplicativo só retorna pra ele “botão sem rótulo”.

Se você tiver oportunidade de se comunicar com a equipe técnica, dê um jeito de tocar o coração dessa equipe e mostre a importância de prestar a atenção nos alt tags e labels. Eles que vão fazer um leitor de acessibilidade dizer o que cada botão ou formulário faz ali.

5) Tente sempre lembrar a sua equipe

A conscientização é a tarefa mais fácil e mais esquecida. Sempre que tiver uma reunião de planejamento, levante a pauta da acessibilidade. Ela pode ser demorada e cara de implementar quando o projeto já estiver instalado, por isso o quanto antes você trouxer a questão para a mesa melhor.

Claro que o universo não é perfeito e provavelmente uma startup não vai ter escolha e vai deixar a acessibilidade parada no backlog, até ter recursos para executar. Mas não deixe a acessibilidade morrer, traga ela à pauta sempre que possível.

6) Leia os princípios de acessibilidade da W3C

Enquanto o Web Content Accessibility Guidelines é difícil de ler e desempolgante, os princípios de acessibilidade do W3C é um pouquinho mais fácil. Vale a pena dar uma olhada pra guiar seus estudos (e para, pelo menos, saber que existe uma normativa pela W3C sobre acessibilidade, que é tipo o Inmetro da Internet).

https://www.w3.org/WAI/intro/people-use-web/principles

E vale o registro – como citado no item dois – para você se aventurar no guia WCAG (Web Content Accessibility Guidelines). Tá aqui: https://www.w3.org/TR/WCAG/

7) O checklist irado do A11yProject

O A11y Project é uma comunidade de web developers pela acessibilidade. E o checklist deles mostra de forma rápida e mastigada muito do que o guia da W3C possui, porém mais voltado para Front-End Devs, com vários itens que você deve lembrar quando for criar os códigos do site no qual está trabalhando.

http://a11yproject.com/checklist.html

Ainda que o checklist seja específico, o conteúdo básico deles sobre acessibilidade é bem bacana: http://a11yproject.com/#Basics

Eu não sou nenhum expert de acessibilidade, mas o tema tem entrado em debate constante aos meus arredores e tenho ficado sensível. Então resolvi fazer esse apanhado para auxiliar alguém que, assim como eu, esteja começando a aprender e a debater sobre acessibilidade.

Além disso, nesses tempos onde todo mundo tem um smartphone, não é nada difícil ver seu pai, sua mãe ou sua avó espremendo os olhos para poder interagir com os apps. Então está mais que na hora de pensarmos que a acessibilidade em produtos digitais também é qualidade de vida.

__

É designer e quer trabalhar em um time multidisciplinar fantástico? Clique aqui.