Concrete Logo
Hamburger button

Acessibilidade para aplicações Android

  • Blog
  • 4 de Maio de 2018

O Android possui um conjunto de recursos/ferramentas para que pessoas que possuam algum tipo de desabilidade possam executar as mesmas ações que um usuário sem estas desabilidades.

Cada usuário, em algum momento da vida, pode vir a possuir alguma desabilidade, mesmo que seja momentânea.

Um senso realizado no Brasil, no ano de 2010, mostra que pelo menos 23.9% da população brasileira possui algum tipo de deficiência, sendo que a mais presente é a visual (18.5%), seguida da deficiência motora (7%). Não é a toa que o termo acessibilidade tem sido muito utilizado ultimamente, mas não é algo tão novo assim. Já existia essa preocupação na WEB e agora está se intensificando no mundo mobile. Mas,a final, o que é acessibilidade quando falamos de mobile?

Acessibilidade é oferecer uma experiência similar a todos os usuários, considerando as possíveis desabilidades que um usuário possua.

Observação: A WEB possui uma cartilha com diversas disposições de acessibilidade, criadas pelo W3C (World Wide Web Consortium), um consórcio internacional que possui organizações filiadas e uma equipe em tempo integral que, junto ao público, trabalha para desenvolver padrões para a web.

Em outras palavras, a acessibilidade está muito ligada à experiência do usuário (User Experience). Ou seja, proporcionar acessibilidade em um aplicativo implica em também melhorar a experiência, independente do usuário.

Ao contrário do que algumas pessoas acreditam, implementar acessibilidade em uma aplicação mobile não é tão complicado assim, apenas algumas poucas linhas de código ou atributos no seu xml de layout e pronto.

Recursos de acessibilidade no Android

Recursos são ferramentas ou funcionalidades do framework de acessibilidade que possuem o intuito de facilitar o uso de uma aplicação ou até mesmo do sistema. Estes recursos ficam disponíveis nas configurações de sistema, e alguns deles já vêm instalados no aparelho. Outros, por sua vez, podem ser baixados no Google Play. Cada recurso se aplica a uma desabilidade ou um conjunto delas. Vamos ver quais são eles?

Magnification

Este recurso permite ampliar o conteúdo da tela do device. Por meio de um toque triplo, o zoom é aplicado à área, permitindo que seja ampliado mais ainda com movimento de arrastar com dois dedos e pinch. Na imagem abaixo é possível ver a ampliação aplicada à tela:

Na imagem, funcionalidade de gesto de ampliação sendo mostrada, com capturas de tela.

O zoom só é ativado depois de um triplo clique na tela e usar o gesto de segurar (manter o dedo pressionado). O efeito de pinch é aplicado depois que do zoom.

Para ativar esta funcionalidade: Configurações > Acessibilidade > Gestos de ampliação.

Voice Access

Permite interagir com o device por meio de comandos de voz. O uso deste recurso foi intensificado com o surgimento dos wearables, e hoje pode ajudar bastante em features com suporte à acessibilidade.

No Google IO de 2016 foi lançado o VoiceAccess, que permite não somente comandos de voz no app, mas também comandos de voz para atuar no sistema operacional como um todo, permitindo, por exemplo, que você abra um aplicativo e interaja com ele. Este recurso é do tipo built-in, ou seja, as aplicações que já atendem a ele sem que precise implementar algo. A única sugestão do Google é que o aplicativo siga as guidelines.

Ao acionar o recurso, são plotados em cada componente um índice numérico, e o usuário pode tanto acionar ao falar o número quanto ao falar a ação desejada. A imagem abaixo mostra o voice access em funcionamento:

Na imagem, índices numéricos da representação dos componentes quando o voice access está ligado

Neste vídeo você também pode ver como esse recuros funciona. O Voice Access está em fase beta, e você pode ser um usuário beta e fazer parte do programa só fazendo o download do app. Para participar, o usuário deve se inscrever aqui.

Switch Access

Também conhecido como troca de acesso, este recurso permite que o usuário navegue pelos elementos da tela e possa interagir com os elementos que a compõem por meio de um dispositivo como este:

É basicamente um módulo com 2 botões, um para navegar pelos elementos e outro para selecionar (o equivalente ao toque na tela). Pode estar associado ao talkback, e permite que usuários com desabilidades motoras possam interagir com as aplicações com maior facilidade.

BrailleBack

O brailleback é um recurso bem interessante, pois são muitos os casos de pessoas com desabilidades visuais que não aprenderam o nosso alfabeto, ou seja, que lêem somente em braille. Este recurso foi criado pensando nestes casos.

É um teclado que se “monta” conforme o texto desejado. Ele possui furos na parte superior e alguns pintos na parte inferior, que, conforme o conteúdo desejado, sobem passando pelos furos, formando textos em braille.

Talkback

Este é um dos recursos de acessibilidade mais famosos, e um dos mais utilizados também. Ele permite que pessoas com desabilidades visuais parcial ou total possam interagir com o aparelho somente ouvindo o feedback de áudio emitido ao interagir com qualquer componente da tela. A maioria das modificações necessárias podem ser feitas por meio dos layouts (arquivos .xml), salvo alguns casos que vamos falar mais para a frente.

Toda vez que um componente é focado pelo talkback, um som é emitido descrevendo o componente. O componente é falado assim:

Para interagir com o Talkback o usuário usa comandos específicos, como abaixo:

Atalhos e gestos para serem usados com o Talkback

O usuário navega por cada tela basicamente de duas formas: ou explorando por meio do toque (e escutando cada componente) ou pelo movimento de swipe para os lados (que troca o foco para o próximo componente).

Dica: tome cuidado quando desativar o foco de layouts/componentes, pois você pode prejudicar a acessibilidade. Sempre teste o app para ver se a mudança no atributo foco não prejudicou o talkback.
Em termos práticos, o talkback hoje é o recurso que precisa de mais trabalho da equipe de desenvolvimento, e por isso precisamos entender como oferecer acessibilidade ao usá-lo.

Dar significado aos componentes (nomeação)

O significado dos componentes é um dos itens mais importantes para acessibilidade. Quando não há significado em uma imagem, o talkback pode emitir um áudio similar a um click, que denota ao usuário com desabilidade visual que há algo ali, porém sem descrição. Isto pode prejudicar bastante a experiência, já que este usuário será forçado a “descobrir” o que aquela imagem significa.

Outro exemplo: alguns botões que ficam sem descrição podem estar com áudio: “botão sem descrição” ou “botão21”, ou seja, a descrição dos componentes é algo primordial para acessibilidade.

O atributo “android:content_description” , presente em praticamente todos os componentes, é responsável por emitir este áudio. Quando o talkback passar por um componente que tenha este atributo, ele lê o seu conteúdo e oferece o usuário a descrição do componente. Veja a imagem abaixo, por exemplo:

Tela de login, com uma imagem representando um alarme, campos de texto representando usuário e senha, e 3 botões para acessar o app por meio do Facebook , Twitter ou Google Plus.

Podemos dividir a nomeação de componentes em dois tipos básicos: imagens decorativas e imagens que executam ações.

Imagens decorativas

Para o usuário que utiliza o Talkback esta imagem não é importante, pois não executa ação. A recomendação no Android é que não coloquemos esta descrição. Para Web, porém, é recomendado descrever mesmo que seja decorativa. O que sugiro é: coloque descrição se realmente for necessário. Neste tipo de imagem colocamos a descrição como “@null”, o que fará com que o talkback não leia este item.

A partir da API 16 é possível usar outro atributo android:importantForAccessibility=”no” .

Imagens que executam ações

A imagem que mostra login com redes sociais na verdade não se comporta como uma imagem, já que leva o usuário a conectar sua rede social. Portanto, ela se comporta como um botão. As imagens que executam ações jamais podem estar sem descrição, pois podem trazer uma experiência confusa para o usuário.

Por isso, precisamos descrever o significado da imagem que executa a ação. Fica muito mais fácil de entender, se o desenvolvedor escrever a ação exata, de forma objetiva:

Mas não são só as imagens que precisam ser nomeadas. Muitas vezes os textos, devido ao leitor de tela, podem induzir o usuário ao erro, como na imagem abaixo, que mostra um texto que representa parcelas de pagamentos e outro que representa a data de vencimento:

Na imagem, dois itens: Plano mensal, seguido de um valor de parcelas, e Vencimento, seguido de uma data.

Neste caso, o Talkback lê as parcelas como: vinte e quatro x de vinte e cinco reais e noventa centavos, ou seja, o “x” é lido como uma letra e não como a palavra “vezes”. Portanto, devemos colocar o atributo texto como “25 x R$ 25,90” e o atributo contentDescription como “25 vezes de R$ 25,90”.

No caso do vencimento, podemos facilitar a leitura colocando “vencimento em” ao invés de só “vencimento”.

Agrupamento de Views

Este recurso pode facilitar bastante a leitura do usuário, e é muito útil quando temos formulários nos quais faz mais sentido itens serem lidos em sequência.

Na imagem abaixo, que contém três artistas com três músicas alinhados, quando o Talkback lê o item Metallica logo em sequência lê o item Whiskey in the jar, que é o nome da música.

Imagem mostrando agrupamento de views. Na imagem, três artistas, cada um com uma música.

Se os elementos não são agrupados, pode ocorrer uma situação em que o usuário ouça um artista porém a música seja de outro. Ou seja, pode ser que o elemento que ele toque não corresponda ao elemento que deveria ter sido lido pelo talkback.

Para agrupar views, devemos ter um viewGroup como pai destas views. Ou seja, para cada pequeno grupo devemos ter um pai. E adicionamos nesta viewGroup 2 atributos, android:focusable=”true” e android:focusableInTouchMode=”true”.

Campos de Texto

Os campos de texto possuem um comportamento diferenciado ao serem tocados. Apesar de também possuírem o atributo contentDescription, a recomendação é não utilizá-lo.

Todo EditText, segundo acessibilidade, deve estar acompanhado de um texto acima dele, que funciona como um título do editText em questão, identificando do que aquele campo se trata. Com a chegada do material design, este texto passou a ser o TextInputLayout.

Imagem mostrando componente EditText com TextInputLayout.

E então basta colocar no TextInputLayout (ou no texto que deve ficar acima do EditText) o atributo android:labelFor=”@+id/editTextId”. Com isso, o texto já será lido da forma correta.

Componentes de duplo estado

Muitas aplicações usam componentes de duplo estado. Um exemplo bem comum em aplicações são os cards que expandem, como na imagem abaixo:

A imagem mostra dois estados de um card, um retraído escrito tarefas para lembrar hoje, e outro expandido escrito as tarefas: passar no supermercado, lavar a louça e estudar.

O usuário vai mapear a tela no estado inicial, porém precisamos avisar o usuário que um novo estado está sendo mostrado na tela, com o card expandido.

Outro exemplo no qual isso acontece é quando temos uma lista que é mostrada após buscarmos um dado em nuvem, em que no estado inicial mostramos um “loading” e depois carregamos a lista. Veja na imagem abaixo:

Duas imagens: uma mostra um estado de carregando (loading) e outra mostra uma lista de jogos com dois botões no topo: buscar e buscar com erro.

Para podermos informar ao Talkback que um novo estado surgiu podemos usar algumas técnicas como live region, accessibility event e announce for accessibility.

Live Region
Usado para situações em que um novo estado surge em tempo de execução.

As views possuem um método para setar o live region, permitindo que ela tenha este comportamento, basta, então, dentro de View ou ViewCompat chamar este método, passando a view e o modo, como mostra o código:

São três os possíveis modos para o live region: polite, assertive e none. O polite vai esperar o talkback terminar o áudio (caso algum esteja em processo) para depois falar o conteúdo. O assertive vai interromper o áudio do talkback, sua aplicação é bem útil em casos nos quais há erro e temos que dar este feedback logo ao usuário. O None vai fazer com que nenhum áudio seja dito.

Accessibility Event

Outra forma de fazer com que um áudio seja emitido em tempo de execução é enviar um evento para o talkback. É possível inclusive enviar diversos tipos de evento já existentes em componente ao talkback, como cliques, foco, seleção, etc. Neste caso de uma view ficar visível em tempo de execução ele é muito útil, view é quem receberá o foco, no código mostrado abaixo:

Announce Accessibility

O framework de acessibilidade também permite que um áudio qualquer seja emitido pelo talkback a qualquer momento da aplicação, sendo bem útil para dizer que um componente ficou visível em tempo de execução. Porém ele somente funciona a partir da API 16.

CustomViews

Os componentes customizados nos permitem criar elementos com comportamentos mais variados, mas para a acessibilidade eles podem apresentar um problema. No quesito acessibilidade, podemos classificá-los em dois tipos: componentes que herdam acessibilidade e componentes que não possuem acessibilidade.

Componentes que herdam acessibilidade são as chamadas Compound Views ou views compostas, views criadas a partir da junção de elementos dentro de um ViewGroup. Este tipo de CustomView não costuma apresentar problemas com acessibilidade, porém vale a pena conferir se ela atende mesmo.

Compound Views

Componentes que não possuem acessibilidade são aqueles que tiveram alterações nos métodos onDraw e onMeasure, ou que herdam diretamente de View. Geralmente, estes componentes apresentam problemas com acessibilidade, ou seja, a acessibilidade terá que ser feita para estes componentes.

Componentes que herdam de view

No exemplo abaixo, simulei a seguinte situação: quando este meu elemento, uma seta (como da figura acima) fica visível, eu então, dentro da minha customView envio um evento para o framework de acessibilidade, para que meu elemento seja “focado”:

Dentro ainda da customView preciso sobreescrever o método dispatchAndPopulateAccessibilityEvent, como abaixo:

Dicas finais

A acessibilidade não é difícil, e não requer tanto trabalho, já que muita coisa é possível via layout. Porém, devemos nos ater a alguns pontos:

  • Cuidados com transparência, principalmente aqueles tutoriais nos quais uma camada de tela está por cima de outra parte da tela, pois os componentes são lidos por trás da tela;
  • Explore vibração, claro, sem excesso;
  • Coloque acessibilidade como parte da concepção e desenvolvimento, pois assim será bem mais fácil de melhorar experiências que não estejam tão boas e detectar possíveis erros para acessibilidade com antecedência, evitando retrabalho nos layouts;
  • Trabalhe em conjunto com o UX e designer da sua empresa, se houver. Vale a pena mostrar pra ela/ele que uma experiência não está tão legal. Peça ajuda.

Não desista. Nem todas as pessoas enxergam o valor da acessibilidade, e por isso é um trabalho de formiguinha convencê-las de que é tão importante quanto qualquer outra coisa, mas tenho certeza que aos poucos todos vão repensando e considerando. Principalmente porque não é algo tão complexo. Ficou alguma dúvida ou tem alguma contribuição? Aproveite os campos abaixo! Até a próxima.

A Concrete, parte da Accenture Technology, é referência em consultoria ágil, facilitando a transformação digital dos clientes ao criar produtos digitais inovadores. Só no capítulo Android contamos com 60 pessoas, que compartilham informações o tempo todo, em talks semanais e treinamentos frequentes. Nossos times têm autonomia para trabalhar e acesso direto aos gerentes, o que facilita a troca de conhecimento e a constante evolução técnica. Quer trabalhar com os melhores? Acesse: concrete.com.br/vagas