Consegue remarcar um serviço na sua app sem ver o ecrã? E com o texto aumentado ao máximo?
Antes de aprovar uma renovação visual, peça à equipa que demonstre essas tarefas. Para decidir onde investir em acessibilidade numa app para iPhone e Android, comece pelo que impede o cliente de concluir uma ação, não pelo número de problemas encontrados numa ferramenta.
A Apple organiza a avaliação de VoiceOver em torno das tarefas comuns da aplicação. A documentação Android recomenda combinar testes manuais, ferramentas de análise e participação de utilizadores. Em ambos os casos, avaliar a utilização real faz parte do trabalho. (developer.apple.com)
A proposta abaixo é um método de triagem para o responsável de uma empresa: escolher percursos, observar barreiras e encomendar correções verificáveis. Não substitui uma auditoria completa nem uma avaliação de conformidade legal.
Comece por uma tarefa que o cliente precisa de terminar
Imagine uma empresa de assistência doméstica cuja app permite consultar intervenções e alterar a data de uma visita. É um exemplo hipotético, mas serve para definir um teste concreto.
Em vez de pedir «uma análise aos ecrãs», proponha esta tarefa: encontrar a próxima visita, escolher outra data, confirmar a alteração e consultar o novo agendamento.
Inclua uma tentativa que não possa ser concluída, como escolher um horário entretanto indisponível. Quer observar se a pessoa percebe o impedimento e encontra uma saída, sem receber instruções de quem está a conduzir o teste.
Para delimitar a primeira avaliação, escolha:
- Uma tarefa frequente, como consultar uma intervenção marcada.
- Uma tarefa com consequência para o cliente, como alterar a data.
- Um percurso de recuperação, como corrigir uma escolha inválida.
Esta seleção é uma recomendação de trabalho, não uma amostra que permita declarar toda a app acessível. Escreva no pedido o que fica por avaliar. Se o histórico, a ajuda e os documentos anexos estiverem fora desta primeira ronda, devem aparecer como exclusões, não como áreas implicitamente aprovadas.
Peça também resultados separados para iPhone e Android. Para aceitar uma correção, exija demonstração na plataforma onde o problema foi identificado; não aceite que o teste num equipamento dê automaticamente o outro por resolvido.
Ouça a app, em vez de olhar apenas para ela
VoiceOver, no ecossistema Apple, e TalkBack, no Android, permitem explorar a interface através de informação falada. Não basta que o texto seja lido: os controlos precisam de transmitir a sua função e o estado em que se encontram. A avaliação da Apple inclui identificação dos elementos, navegação e execução das tarefas; a Google explica como testar a app com TalkBack ativo. (developer.apple.com)
Na demonstração da app de assistência, peça para observar estes pontos:
- O cliente distingue «Alterar visita» de «Cancelar visita»?
- Ao percorrer os horários, percebe qual está selecionado?
- Depois de abrir a escolha de data, consegue regressar sem confirmar?
- Quando um horário deixa de estar disponível, recebe informação suficiente para escolher outro?
- No final, consegue verificar a nova data sem procurar ajuda?
Não dê indicações como «o botão está no canto superior direito». O objetivo do exercício é precisamente perceber se a interface fornece a informação necessária.
Registe o ponto exato em que a tarefa ficou bloqueada. «O leitor de ecrã funciona mal» não orienta uma correção. Prefira uma descrição observável: «Ao chegar à lista de horários, são anunciadas as horas, mas não se percebe qual foi selecionada».
Reserve a avaliação aprofundada para quem conhece estas tecnologias. Uma demonstração feita pelo responsável de produto serve para descobrir perguntas e acompanhar resultados; não deve ser apresentada como equivalente à experiência de utilizadores habituais.
Aumente o texto e tente chegar ao fim
A Apple recomenda testar diferentes tamanhos de texto, incluindo os tamanhos de acessibilidade, e verificar cortes e sobreposições. Distingue ainda o suporte a texto maior do simples recurso ao zoom do sistema: ampliar o ecrã não prova que a disposição da app se adapta ao texto. (developer.apple.com)
Peça à equipa que repita a alteração da visita com texto ampliado. Na versão Android, inclua também as configurações de tamanho de letra e de apresentação previstas no plano de testes, seguindo as orientações da plataforma para conteúdo escalável. (developer.android.com)
O critério de aceitação deve ser funcional. No nosso exemplo, proponha que o cliente consiga ler a morada completa, distinguir a data anterior da nova e alcançar a confirmação sem reduzir o tamanho do texto.
Não rejeite automaticamente um ecrã por passar a exigir deslocação vertical. Pergunte antes se a informação continua organizada e se a tarefa permanece executável. Uma apresentação mais comprida pode ser uma solução aceitável; esconder parte da morada para conservar o desenho original não deve ser aceite neste percurso.
Teste com conteúdo realista em português: nomes compostos, moradas extensas e mensagens de indisponibilidade. Para esta avaliação, evite preencher tudo com palavras curtas que tornam a demonstração artificialmente simples.
Verifique o toque, a cor e as alternativas aos gestos
As orientações Android recomendam áreas de toque com pelo menos 48 por 48 dp, unidades próprias da plataforma. Também indicam que a cor não deve ser a única forma de comunicar informação e que os gestos devem ter alternativas acessíveis. Estas recomendações não devem ser convertidas diretamente em píxeis nem copiadas como medidas universais para iOS. (developer.android.com)
Use-as para formular perguntas à equipa. Na lista de visitas, há um pequeno ícone para abrir detalhes? Qual é a área efetivamente acionável? Se cancelar exige deslizar um cartão, existe outra forma de executar a ação?
No calendário, proponha um teste simples: cada estado deve continuar compreensível sem depender exclusivamente da cor. «Disponível», «Selecionado» e «Indisponível» precisam de uma distinção que a equipa consiga explicar e demonstrar.
Não transforme, porém, esta primeira ronda num inventário interminável de detalhes visuais. Registe os problemas e relacione-os com uma tarefa. Essa ligação será necessária para decidir a ordem das correções.
Use uma grelha de prioridade, não uma contagem de erros
Propomos a seguinte grelha para discutir o trabalho com a equipa de desenvolvimento. É um instrumento de gestão do projeto, não uma classificação oficial das plataformas.
| Situação observada | Prioridade proposta | Decisão a tomar | Prova a pedir |
| --- | --- | --- | --- |
| O cliente não consegue concluir uma tarefa essencial | Bloqueio | Corrigir antes de aceitar esse percurso | Repetição integral da tarefa na configuração afetada |
| A interface pode levar à escolha da ação errada | Elevada | Rever identificação, estado e confirmação | Demonstração das alternativas sem ambiguidade |
| A tarefa só termina com ajuda de outra pessoa | Elevada | Identificar a barreira e eliminar a dependência | Execução autónoma por participante no teste |
| A tarefa termina, mas exige passos evitáveis | Melhoria | Planear depois dos bloqueios, considerando a frequência | Comparação do percurso antes e depois |
| O comportamento ainda não foi testado | Por avaliar | Não classificar como aprovado | Teste com resultado documentado |
Para cada ocorrência, registe a tarefa, versão da app, equipamento, sistema operativo, configuração de acessibilidade, comportamento observado e resultado esperado.
Acrescente um responsável pela correção e outro pela validação. Se o mesmo problema aparecer em vários ecrãs, peça à equipa que verifique se existe um componente comum a corrigir, em vez de encomendar alterações isoladas sem investigar a origem.
Não use a soma de ocorrências como único argumento para aprovar orçamento. Nesta grelha, um impedimento na alteração de uma visita deve ter precedência sobre vários desalinhamentos que não impedem a leitura ou a ação. A prioridade resulta da consequência observada, não da aparência do relatório.
O relatório automático é uma entrada, não a aprovação
A Apple esclarece que eliminar os problemas assinalados pelo Accessibility Inspector não garante uma app totalmente acessível e recomenda testes com tecnologias de apoio. A documentação Android também apresenta a análise automática como parte de uma abordagem mais ampla. (developer.apple.com)
Por isso, se receber uma proposta de auditoria, pergunte o que acontece depois de correr a ferramenta. Haverá observação dos percursos? Quem interpreta os resultados? Estão previstos testes com pessoas que utilizam tecnologias de apoio?
Peça que o relatório distinga claramente os problemas encontrados automaticamente dos observados em utilização. Exija ainda uma lista das configurações e áreas não avaliadas.
Para sessões com participantes, prepare contas e dados de teste. Defina tarefas sem ensinar antecipadamente o caminho e peça autorização antes de gravar. O objetivo proposto é recolher evidência da dificuldade, não avaliar a capacidade da pessoa.
Encomende uma correção que possa ser aceite
Evite pedir apenas um preço para «tornar a app acessível». Envie os percursos escolhidos e peça uma proposta que separe avaliação inicial, alterações e validação posterior.
Na avaliação, identifique as plataformas, versões, tarefas e tecnologias de apoio abrangidas. Nas alterações, peça a relação entre cada problema e a intervenção proposta. Na validação, exija a repetição dos testes que revelaram a barreira, incluindo as partes do percurso que já funcionavam.
Se existir um componente de outro fornecedor, como um calendário incorporado, pergunte quem consegue alterá-lo. Peça alternativas caso a correção dependa desse fornecedor: atualização, substituição ou outra apresentação da tarefa. Não aceite encerrar o problema apenas por estar fora do código da equipa contratada.
Para a app de assistência, uma entrega aceitável seria demonstrar que o cliente encontra a visita, escolhe uma data, compreende uma indisponibilidade e confirma a alteração com as configurações acordadas. «Melhorámos a acessibilidade» não é uma prova suficiente.
Na próxima reunião de produto, leve um percurso, a grelha de prioridade e um pedido de demonstração em cada plataforma. Depois decida o orçamento com base nos bloqueios observados. O primeiro investimento deve permitir que mais clientes terminem a tarefa que os levou à app.