Este artigo não será uma linha de código, nem um único termo complexo. Vou tentar afirmar de tal maneira que mesmo uma pessoa longe do desenvolvimento entenda.
Será sobre a implementação da acessibilidade (acessibilidade) em um aplicativo móvel.
Breve histórico
Recentemente, em nome do projeto Vida Acessível, comecei a ajudar a Yandex na implementação da acessibilidade de seus aplicativos de navegação.
Fui confrontado com o fato de que muitas coisas que são óbvias do meu ponto de vista não me vêm à mente: elementos invisíveis na tela, saída direta de mensagens de voz usando a API do programa de acesso à tela e assim por diante.
Portanto, decidi declarar tudo isso em um artigo separado.
Em geral, vamos lá.
Itens invisíveis
O problema
No processo de trabalhar em mapas, encontramos um problema:
Quando você clica em uma área da tela com um mapa, o aplicativo deve alternar entre os modos (não me lembro dos detalhes com certeza).
Para um usuário cego com um programa de acesso à tela, essa ação aparentemente simples se torna impossível.
O fato é que os programas de acesso à tela “veem” apenas objetos específicos na tela: botões, blocos de texto, campos de entrada, controles e listas. E no aplicativo Yandex.Maps, clicar no mapa não era processado como uma seleção de um objeto, mas como um toque em uma área específica da tela.
Solução
A solução é bastante simples: criar um botão na tela sem moldura, com fundo transparente e sem texto visível (fonte zero, que não é tão esteticamente agradável do ponto de vista do programador, ou atributos especiais que exibem texto apenas para programas de acesso à tela sem exibi-lo na tela).
Essa abordagem chocou e surpreendeu os programadores, mas, na prática, tudo deu certo, a ideia funcionou e está sendo ativamente introduzida sempre que você precisar processar cliques diretos na área da tela.
Saída direta de mensagens de voz usando o próprio programa de acesso à tela
O problema
Outro problema era que, às vezes, é necessário exibir informações adicionais apenas para o usuário cego. Nesse caso, as mensagens pop-up estragam o design e interferem com os outros, e implementar um modo de aplicativo separado no qual essas mensagens serão exibidas é complicado e ilógico.
Solução
A solução não é tão óbvia como no caso de botões invisíveis, mas também está na superfície.
Você precisa usar a API do próprio programa de acesso à tela para exibir mensagens. Parece menos volumoso no código do programa, não força o desenvolvedor a fazer esforços adicionais para criar modos separados, configurações adicionais etc.
A propósito, se você usa a API do leitor de tela, não precisa nem verificar se está ativada. Se o programa estiver em execução, ele exibirá uma mensagem usando o sintetizador de fala selecionado pelo usuário. E se o programa estiver desligado, nada acontecerá e o usuário médio não perceberá nada.
Compartilhe!
O problema
Esta é uma recomendação e não um truque de vida, mas sou obrigado a mencionar isso.
Lembre-se de que existem apenas objetos na tela para o programa de acesso à tela?
Portanto, o tipo de objeto também é importante. O texto não pode ser clicado, na opinião dela, mas o botão não pode ser copiado. Ou seja, se a tabela de configurações for implementada como um grande bloco de texto que "captura" cliques em diferentes partes de si mesmo, essa tabela não estará disponível para o programa de acesso à tela. Será lido, mas não permitirá interação.
Solução
A solução é bastante simples: use os elementos como pretendido.
Se for uma lista, você precisará usar o elemento que descreve a lista no código;
se é um botão, deve ser o botão; se for um controle deslizante, um regulador de alguma coisa, deve ser um elemento do controle deslizante, e não um texto com animação ao arrastar.
Conclusão
Concluindo, quero dizer que o desenvolvimento para Windows, embora não seja essencial, é diferente do desenvolvimento para plataformas móveis, portanto, os recursos de acessibilidade para Windows diferem dos recursos para Android / Ios.