Não existe um prazo fixo que se aplique a todas as aplicações. Uma aplicação pequena com um número limitado de ecrãs e uma base de código bem organizada pode ser colocada no nível pretendido em algumas semanas; uma aplicação com muitos componentes personalizados, múltiplas plataformas e um longo histórico de débito técnico leva mais facilmente alguns meses. A variável mais importante não é o número de ecrãs, mas quanto da interação foi construída fora dos componentes padrão do iOS ou Android.
Como indicação aproximada: uma aplicação que consiste principalmente em elementos de UI padrão e cuya equipa já está familiarizada com acessibilidade pode, na prática, ser adaptada em seis a dez semanas. Uma aplicação com muita interação personalizada, animações, gestos personalizados ou SDKs incorporados de terceiros rapidamente chega a três a seis meses, simplesmente porque cada componente deve ser examinado separadamente e às vezes reconstruído. Estes não são limites rígidos mas uma indicação de onde a maioria dos projetos acaba na prática.
O que realmente determina o tempo de execução
O tempo que um projeto leva depende menos da lei em si e mais de três factores práticos. Em primeiro lugar: a interação é construída a partir de componentes padrão do sistema operativo, ou principalmente personalizada? Os componentes padrão muitas vezes já fornecem acessibilidade em grande medida; os componentes próprios precisam ser equipados um a um com os rótulos corretos, ordem de foco e anúncios para leitores de ecrã. Em segundo lugar: quantos componentes externos estão na aplicação, como módulos de pagamento, visualizações de mapa ou janelas de chat de terceiros? Estes frequentemente estão fora do controlo direto da equipa interna, e contactar um fornecedor normalmente leva mais tempo do que testar. Em terceiro lugar: existe já um procedimento de teste com um leitor de ecrã no dispositivo real, ou é preciso configurá-lo? Este último consome a maior parte do tempo na primeira rodada, mas compensa-se nas atualizações subsequentes.
Onde os cronogramas enfrentam obstáculos na prática
A maioria dos atrasos não ocorre ao ajustar texto ou contraste de cores, mas quando a interação não pode ser operada com teclado ou leitor de ecrã: um gesto de arrastamento sem alternativa, uma janela modal que não mantém o foco, ou um formulário cujas mensagens de erro não são anunciadas. Este tipo de problemas geralmente só se torna visível durante testes manuais com um leitor de ecrã, algo que uma verificação automatizada não consegue substituir completamente. Quem confia apenas numa verificação automática normalmente descobre estes problemas demasiado tarde no projeto, o que prolonga ainda assim o tempo de execução. Um bom ponto de partida é portanto obter uma primeira indicação em algumas perguntas de onde a aplicação se encontra neste momento, para que as partes que consomem mais tempo fiquem visíveis no início em vez de perto da entrega.
Os ciclos de revisão da app store também têm influência: uma adaptação que melhora a acessibilidade ainda precisa passar pelo período de revisão normal da loja relevante antes que os utilizadores notem algo. Isto está fora da influência da equipa de desenvolvimento e deve constar em cada plano como um buffer de tempo fixo.
Manter a acessibilidade após a entrega
Uma aplicação que cumpre hoje pode não cumprir após a próxima atualização. Cada nova funcionalidade, cada novo ecrã e cada fluxo alterado merece a mesma atenção que a primeira rodada, caso contrário o problema volta a aparecer sorrateiramente. É também por isso que a obrigação não termina num único teste: a sua avaliação própria tem de estar sempre atualizada, e isso requer um ciclo recorrente em vez de um projeto único. Para a fundamentação do que é precisamente esperado de si nesta situação, o contexto selecionado para cada situação é um ponto de partida adequado.
O que axessia.eu faz e não faz neste trajeto
A Axessia avalia, ordena por prioridade, documenta e monitora: a análise mostra a situação atual da aplicação, o relatório apresenta as conclusões em linguagem clara numa lista ordenada por prioridade, e a declaração e o plano de melhoria documentam o que foi feito e o que ainda precisa ser realizado. Auditorias manuais e trabalho de reparação na própria aplicação não fazem parte disso; essa responsabilidade permanece com a equipa de desenvolvimento ou a entidade que desenvolveu a aplicação. Como a análise é realizada exatamente e quais são as fontes utilizadas está explicado em página sobre como a informação é produzida. O custo de um percurso completo, incluindo relatório e declaração, encontra-se em a visão geral das subscrições.
Quem quiser saber em que situação se encontra uma aplicação concreta neste momento deve começar pela análise rápida gratuita da axessia.eu. Oferece uma primeira visão em poucos minutos, sem necessidade de conta.