Acessibilidade: construindo aplicações acessíveis para Android

Itaú Tech
ItauTech
Published in
7 min readFeb 27, 2024

Por Luiz Felipe Russi Lobato Guerrero, Team Member na Comunidade de Cash Management no Itaú

A imagem traz a frase “Acessibilidade em Android: boas práticas para o desenvolvimento de aplicaões acessíveis para todas as pessoas” em seu lado esquerdo. Ao lado direito, há a foto de um homem preto, de costas, encarando uma tela de computador.

Falarmos sobre acessibilidade em um mundo digital ainda pode parecer um tema complexo para algumas pessoas. No entanto, é importante nos lembrarmos que esse é um assunto de grande importância, não apenas para o Itaú, mas sim para todos nós: no levantamento mais recente realizado pelo IBGE, a população com deficiência no Brasil foi estimada em 18,6 milhões de pessoas –aproximadamente 9% de toda a população do país.

Quando combinamos diferentes levantamentos, considerando a população global, esse número salta para aproximadamente 15%. Ou seja, estamos falando de um grande número de pessoas que precisam ser levadas em consideração no desenvolvimento de apps, sites e serviços que moldam a forma com que nos comunicamos, estudamos, trabalhamos etc.

No Itaú, o assunto é levado muito a sério, e um compromisso declarado por meio do nosso Estatuto de Acessibilidade e Relatório Anual ESG.

Atualmente, pessoas desenvolvedoras podem usar diversas ferramentas para criar apps mais acessíveis e garantir uma boa experiencia para todos os públicos. Nesse artigo, vamos explorar alguns guidelines, ferramentas e dicas de como podemos tornar nossos apps mais acessíveis.

The Web Content Accessibility Guidelines (WCAG)

Quando falamos sobre acessibilidade digital, precisamos sempre começar pela WCAG (The Web Content Accessibility Guidelines — ou Guia de Acessibilidade para Conteúdo Web).

Ela abrange diversas recomendações com a finalidade de tornar o conteúdo da Web mais acessível, e possui 3 níveis de conformidade: A, AA, AAA. Quanto mais se eleva o nível, mais se remove barreiras de acesso para as diversas deficiências e limitações. Trata-se de um documento que não foca apenas em tecnologia — ou seja, mesmo sendo considerado técnico, ele é agnóstico e filosófico, provocando reflexões sobre as diferentes necessidades.

Seu foco é em conteúdo, informações e semântica. Por isso, suas normas são flexíveis, com conceitos que podem ser aplicados em diversas plataformas.

Ferramentas e Componentes

Quando falamos especificamente de desenvolvimento em Android, a própria IDE do Android Studio já possui diversas ferramentas e componentes que podemos utilizar para tornar nossos apps mais acessíveis. Vamos abordar aqui alguns itens básicos que aparecem em várias das documentações e incluir mais alguns outros pontos que achamos importantes:

Tamanho da área de toque: precisamos sempre garantir que nossos botões, ou áreas de toque, sejam grandes o suficiente para que usuários consigam interagir com a interface. Não existe nada mais frustrante do que elementos mal posicionados ou deslocados. É recomendado que seja utilizado um tamanho mínimo de 48dp x 48dp para elementos interativos.

Tamanho do texto: mesmo que smartphones hoje possuam a funcionalidade de aumentar o tamanho de todos os textos, nada nos impede de já construir uma aplicação que atenda a alguns pré-requisitos. Ainda que essa não seja uma recomendação oficial da WCAG, para o Android, recomendamos a utilização de um tamanho mínimo de 14sp.

Contraste: além do tamanho das fontes, também é importante garantirmos um bom contraste nesse cenário. O contraste é basicamente a relação perceptível entre duas cores: quanto maior seu contraste, mais intensa é a diferença entre elas. Aqui, devemos medir o contraste entre nosso elemento visual e seu background para garantirmos um valor mínimo de 4.5:1. Esse elemento pode ser uma imagem, um ícone e até mesmo a cor do texto.

Caso tenha dúvidas sobre esse critério em específico, nesse link você pode testar e validar o contraste, informando o hexa decimal das cores que seu app utiliza.

Marcação de conteúdo: a marcação de conteúdo, também conhecida como contentDescription, é um atributo padrão dos elementos visuais do Android. É nele em que devemos colocar qual informação deve ser lida quando o elemento receber o foco do leitor de tela.

Nem todos os elementos precisam desse atributo, já que elementos como Button e TextView utilizam seu próprio conteúdo de texto como contentDescription. Já em imagens e ícones, caso necessário, é preciso adicionar o atributo. Aqui, é importante lembrarmos que devemos informar o tipo do elemento dentro de seu contentDescription apenas em casos em que não é possível usar a marcação semântica. Caso você tenha um botão com o texto ‘continuar’ seu contentDescription deve ser apenas “continuar” e não “botão continuar” ou “continuar, botão”.

Textos como títulos: é possível definir um elemento de texto como um elemento de título, facilitando a navegação do usuário caso ele opte por navegar entre títulos ao invés de parágrafos ou palavras. Para isso, basta adicionar o atributo android:accessibilityHeading=”true” no seu elemento de texto. Lembre-se de que esse atributo só é compatível com a API 28+ do Android.

Elementos importantes para acessibilidade: um outro atributo muito utilizado quando estamos montando a acessibilidade de uma tela é o importantForAccessibility. É ele quem diz para o sistema se esse elemento visual deve ou não disparar algum evento de acessibilidade. Aqui, podemos informar o valor “yes” caso o evento de acessibilidade deva sempre ser chamado ou “no” para ignorar totalmente os eventos.

Custom Views: às vezes precisamos utilizar alguns componentes que não são elementos padrão da plataforma. Nesses momentos, precisamos criar uma custom view. Ao criar um novo elemento, é recomendado que você use ou estenda widgets/classes fornecidos pelo sistema como base do seu novo componente. Quando esse for o caso, tente utilizar um elemento de mais baixo nível na hierarquia de classes do Android. Ou seja, em vez de estender uma classe genérica como View ou ViewCompat, busque sempre estender da classe Button ou Switch, de acordo com a sua necessidade.

Dessa forma, nosso novo componente já herda todos os eventos e características de acessibilidade do elemento padrão do sistema, o que facilita a configuração dos atributos de acessibilidade dele.

À esquerda um exemplo de um Dialog de alerta padrão do sistema, e à direita um exemplo de um Dialog que não segue os padrões da plataforma.

Usar outras indicações além da cor: cores não devem ser utilizadas como único meio visual de transmitir informações. É preciso adicionar algum outro tipo de indicador para distinguir os elementos da interface. No lugar de deixar um texto com a cor vermelha para sinalizar algum cenário de erro, pense em adicionar algum ícone ou imagem que ilustre o problema de uma forma mais intuitiva. Um ajuste pequeno como esse pode melhorar muito a experiencia do nosso usuário.

Ordem de navegação: assim como na língua portuguesa, os softwares leitores de tela, incluindo o TalkBack que é nativo no Android, devem navegar na tela da esquerda para a direita. Então, sempre que você for construir uma nova tela, tenha em mente esse fluxo de leitura — dessa forma, conseguimos ser mais assertivos quanto a leitura dos nossos elementos.

Caso seja necessário aplicar uma ordem de leitura customizada, podemos utilizar o atributo accessibilityTraversalAfter, com a seguinte implementação: android:accessibilityTraversalAfter=”@id/imageView2". Dessa maneira, estamos informando ao sistema que nosso elemento de interface deve ser lido após o elemento de id “imageView2”.

Lembrando que o atributo accessibilityTraversalAfter só está disponível para API 22+ do Android.

Testando sua aplicação

Tão importante quanto construirmos telas acessíveis é fazermos os testes necessários para validarmos e entendermos o comportamento de cada componente do sistema.

Uma ferramenta que gosto muito de usar é o app Scanner, disponível na Google Play Store do Android. O app foi desenvolvido pela própria Google e seu objetivo é justamente encontrar falhas e melhorias de acessibilidade para o seu layout. O app até possui um color picker para testes de contraste, por exemplo. Ele é perfeito para quem está começando a desenvolver aplicativos acessíveis, pois oferece um feedback rápido e pontual sobre problemas.

No entanto, a maneira mais completa para realizarmos testes é a utilização de leitores de tela em nossos aparelhos. A maioria dos smartphones Android hoje já possuem o TalkBack instalado, mas é possível fazermos o download do Android Accessibilty Suite e realizarmos as configurações necessárias.

Para quem nunca usou leitores de tela, o Talkback é a ferramenta de leitura de telas da Google. Toda a navegação por ela é feita por meio de gestos/swipes com um ou mais dedos. Ainda é possível configurar métodos de navegações diferentes: como por exemplo, você pode navegar apenas em elementos que são configurados como títulos, ou apenas entre elementos de botões ou links presentes na sua tela. Você consegue navegar, inclusive, letra por letra, caso seja necessário.

Este artigo foi pensado como uma introdução ao tema de acessibilidade. Os smartphones de hoje possuem tantas outras funcionalidades e ferramentas de acessibilidade que muita gente nem imagina, e com certeza precisaríamos de diversos artigos para descrevermos todas as funcionalidades.

Com esse conteúdo introdutório, esperamos que você tenha entendido um pouco sobre a importância da criação de aplicativos acessíveis e conseguido conhecer conceitos básicos para contemplar boas práticas durante sua construção. Independentemente de qual seja o seu segmento de atuação, a acessibilidade é um atributo importante para que todas as pessoas interajam com ferramentas e serviços de forma autônoma e independente.

Gostaria de deixar um agradecimento especial à Daniela Capassi Moreira e à Larissa Gabriela Silva Souza do time de Testes e Acessibilidade por revisar os dados desse arquivo e garantir sua qualidade — e deixar o espaço de comentários aberto para dúvidas e questionamentos!

--

--