Design X Acessibilidade – O desafio do One Time Code

Pode parecer um pouco estranho quando colocamos dessa forma (Design VERSUS Acessibilidade) mas infelizmente é o que mais encontramos no mercado de aplicativos. Designs incríveis com efeitos deslumbrantes, mas a acessibilidade é jogada de escanteio e torna a vida do usuário um inferno.

Acessibilidade em primeiro lugar

Os aplicativos são para todos. Isso não significa simplesmente que eles estão disponíveis nas Stores para serem baixados. Significa que todos devem poder utilizá-los sem restrições.

Um usuário com deficiência visual deve ter acesso a todos os recursos que um usuário sem deficiência visual. 

A acessibilidade deve partir desde a concepção. Negligenciar a acessibilidade por conta de prazos, ou por não valorizar a sua importância é um erro gigantesco. Principalmente se levarmos em conta que acessibilidade é lei no Brasil.

Art. 63. É obrigatória a acessibilidade nos sítios da internet mantidos por empresas com sede ou representação comercial no País ou por órgãos de governo, para uso da pessoa com deficiência, garantindo-lhe acesso às informações disponíveis, conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente. – LEI Nº 13.146, DE 6 DE JULHO DE 2015.

Além de retrabalho e um aumento significativo de custos, negligenciar a acessibilidade pode não se limitar no cenário econômico. Ignorar a acessibilidade é simplesmente como ignorar um grupo de pessoas; é como lhes dizer que eles não podem usar seu aplicativo. Isso faz sua marca ganhar uma imagem horrível em um cenário mundial conectado. Uma publicidade negativa dessas pode fazer com que centenas ou milhares de usuários deixem de usar seu aplicativo: seja por serem incapazes de usar, ou pela empatia por aqueles que não o podem usar.  

O OneTime Code

Vamos pegar um exemplo muito comum nos apps atuais. Quase todos (QUASE, mas não todos) os apps que usam um segundo fator de autenticação baseado em SMS apresentam telas de digitação de código semelhante à da imagem abaixo:

Lindo, não é? Cada caixa sendo um caractere, ficando ativo, mudando de cor, conforme o código é digitado. Mas isso é o inferno da acessibilidade.

O caso do OneTime Code é um desses exemplos que fogem à regra de que a leitura deve ser igual ao que é exibido: “ler” os campos, da forma como são exibidos, causam mais confusão do que ajudam.

Um usuário deficiente visual, que utiliza o VoiceOver (no caso do iOS), não acessa os campos clicando em cima deles. A ação utilizada para navegar entre os campos é um “swipe” horizontal, que informa ao VoiceOver que o usuário deseja navegar para o próximo campo, ou para o anterior, dependendo o sentido do swipe.

Agora imagine se você fosse um usuário do VoiceOver e está digitando seu código nesses campos. Para passar do último caractere para o primeiro, você precisaria executar N swipes, onde N é a quantidade de dígitos que o seu código tem.

E o pior é como fica a leitura disso. A cada campo, a leitura é feita de modo individual, forçando o usuário a fazer um quebra cabeça mental para tentar montar sua senha parte a parte, isso se formos levar em conta que ele está navegando do primeiro para o último dígito. Em sentido inverso, isso se torna ainda mais desafiador.

Aproxime o uso ao conceito

No caso do OneTime Code, apesar de composto por N dígitos (geralmente de 4 a 8), ele é um código único. É essa a imagem mental que o usuário deve ter desse código: algo único.

Ao pensar no Design, um campo composto por dígitos independentes que se colorem ao serem digitados pode parecer algo muito agradável aos olhos; mas, ao pensar na usabilidade, a coisa muda um pouco de figura.

Precisamos aproximar o uso ao conceito. Visualmente, podemos ter o campo exibido de forma individual, mas no seu funcionamento, ele deve ser tratado como um campo único.

No meu próximo post, vou tratar essa situação e esse conceito, mostrando como solucioná-lo no iOS.