Il n'existe pas de délai fixe applicable à toutes les applications. Une petite application avec un nombre limité d'écrans et une base de code bien structurée peut atteindre le niveau souhaité en quelques semaines ; une application avec de nombreux composants personnalisés, plusieurs plateformes et un long historique de dette technique prend plutôt plusieurs mois. La plus grande variable n'est pas le nombre d'écrans, mais le volume d'interactions construites en dehors des composants standards d'iOS ou d'Android.
À titre indicatif : une application composée principalement d'éléments d'interface utilisateur standard et dont l'équipe a déjà une expérience en matière d'accessibilité peut généralement être adaptée en six à dix semaines. Une application avec beaucoup d'interactions personnalisées, d'animations, de gestes personnalisés ou de SDK de tiers intégrés dépasse rapidement trois à six mois, tout simplement parce que chaque élément doit être examiné séparément et parfois reconstruit. Ce ne sont pas des limites strictes, mais une indication de la façon dont la plupart des projets se terminent dans la pratique.
Ce qui détermine réellement la durée
Le temps qu'un projet prend dépend moins de la loi elle-même et davantage de trois facteurs pratiques. Premièrement : l'interaction est-elle basée sur les composants standards du système d'exploitation, ou largement construite sur mesure ? Les composants standards offrent souvent une grande partie de l'accessibilité d'emblée ; les composants personnalisés doivent être équipés individuellement des bonnes étiquettes, de l'ordre de navigation et des annonces pour les lecteurs d'écran. Deuxièmement : combien de composants externes contient l'application, tels que des modules de paiement, des cartes ou des fenêtres de chat de tiers ? Ceux-ci échappent souvent au contrôle direct de l'équipe interne, et la consultation d'un fournisseur prend généralement plus de temps que le test lui-même. Troisièmement : existe-t-il déjà une routine de test avec un lecteur d'écran sur le vrai appareil, ou faut-il la mettre en place ? Cette dernière option prend le plus de temps lors du premier cycle, mais se rentabilise lors des mises à jour ultérieures.
Où les planifications rencontrent des obstacles dans la pratique
Le retard se produit généralement non pas lors de l'ajustement du texte ou du contraste des couleurs, mais lorsque l'interaction s'avère non opérable au clavier ou avec un lecteur d'écran : un geste de glissement sans alternative, une fenêtre modale qui ne maintient pas le focus, ou un formulaire dont les messages d'erreur ne sont pas annoncés. Ce type de problème n'apparaît souvent qu'lors des tests manuels avec un lecteur d'écran, ce qu'une analyse automatisée ne peut pas entièrement remplacer. Celui qui ne compte que sur une vérification automatique découvre généralement ces goulots d'étranglement trop tard dans le projet, ce qui prolonge encore la durée. Un bon point de départ est donc obtenir en quelques questions une première indication du stade actuel de l'application, afin que les éléments chronophages apparaissent tôt dans le processus plutôt que juste avant la livraison.
Les cycles d'examen de l'app store jouent également un rôle : une modification qui améliore l'accessibilité doit tout de même passer par le délai d'examen habituel du store concerné avant que les utilisateurs n'en remarquent les effets. Cela échappe à l'influence de l'équipe de développement et doit figurer dans chaque planification comme un tampon de temps fixe.
Rester accessible après la livraison
Une application conforme aujourd'hui peut ne pas l'être après la prochaine mise à jour. Chaque nouvelle fonctionnalité, chaque nouvel écran et chaque flux modifié méritent la même attention que le premier cycle, sans quoi le problème réapparaît. C'est aussi pourquoi l'obligation ne s'arrête pas à un seul test : l'évaluation interne doit rester à jour, et cela nécessite un cycle régulier plutôt qu'un projet ponctuel. Pour les détails relatifs à ce qui vous est précisément demandé dans cette situation, la documentation adaptée à chaque situation est un point de départ approprié.
Ce qu'axessia.eu fait et ne fait pas dans ce processus
Axessia procède à l'évaluation, la priorisation, la documentation et la surveillance : le diagnostic montre l'état actuel de l'application, le rapport présente les constatations en langage clair selon un ordre de priorité, et la déclaration ainsi que le plan d'amélioration documentent ce qui a été fait et ce qui reste à faire. Les audits manuels et les travaux de correction de l'application elle-même n'en font pas partie ; ces tâches restent confiées à l'équipe de développement ou à l'entité qui a développé l'application. Le déroulement exact du diagnostic et les sources utilisées sont expliqués sur la page sur la manière dont l'information est élaborée. Le tarif d'un parcours complet incluant rapport et déclaration est indiqué sur l'aperçu des abonnements.
Pour savoir où se situe une application concrète à l'heure actuelle, il est préférable de commencer par le diagnostic rapide gratuit d'axessia.eu. Celui-ci fournit une première évaluation en quelques minutes, sans qu'un compte soit nécessaire.