Les applications natives deviendront plus populaires

mercredi 13 novembre 2024

Quand et pourquoi vous êtes-vous intéressé à l’accessibilité numérique ?

Pour moi, ça a commencé en troisième année à l'université, dans un cours qui s'appelait Advanced Mobile Development. Dès la sortie d'Android et d'iOS, je me suis intéressé à la création d'applications. Il y a une dizaine d'années, la Fondation pour l'accessibilité aux Pays-Bas a eu l'idée de développer une application accessible aux personnes aveugles. C'était le premier public cible, avant de lancer l'application à tout le monde. L'idée était de proposer un city trip et, à certains endroits dédiés, grâce au GPS, on avait une description audio du lieu. À cette époque, je ne savais pas qu'il était possible pour les personnes aveugles d'utiliser un smartphone. C'était mon premier projet pour les personnes handicapées.

Vous êtes membre de la Mobile Accessibility Task Force du W3C : quel est son objectif actuel ?

Il est difficile de s'en tenir à la norme européenne EN 301 549 lorsqu'on audite des applications mobiles. C'est la raison pour laquelle nous [à la Fondation Appt] avons rédigé notre propre méthodologie, en essayant d'expliquer étape par étape comment appliquer les critères de réussite aux applications mobiles. Beaucoup de gens utilisent cette méthodologie, mais certains pensent que c'est la vérité alors que, sur certains points, nous donnons simplement notre avis.

Il est difficile de rédiger des directives, surtout si vous souhaitez qu'elles soient utilisées non seulement dans votre entreprise ou dans votre pays, mais aussi ailleurs. Il faut donc, à un moment donné, collaborer. Cela m'a finalement conduit à participer, il y a deux ans et demi, à la Mobile Accessibility Task Force (MATF), qui fait partie du W3C. J'ai été nommé en janvier à la tête de cette MATF. Dix à vingt experts en accessibilité mobile y contribuent activement et nous prévoyons de publier de nouvelles directives en décembre. Ce sera une première ébauche, mais ce sera tout de même un événement, car peu de choses ont été publiées au cours des dix dernières années. L'objectif serait de créer des directives qui pourraient être utilisées dans le monde entier, afin d'appliquer pleinement les WCAG aux applications.

Quel est votre point de vue sur l’accessibilité des applications ? A-t-elle tendance à s’améliorer au fil du temps ?

Je pense que oui. C'est ce que nous voyons lorsque nous examinons le tableau de bord national où le gouvernement néerlandais suit les déclarations d'accessibilité. Vous pouvez avoir cinq statuts, de A à E. De toute façon, il est assez difficile d'obtenir le statut A, beaucoup restent bloqués dans le statut B. C'est particulièrement vrai pour les applications : vous pouvez avoir des restrictions en fonction de votre framework, surtout si vous développez des applications multiplateformes. Je pense que les applications natives deviendront plus populaires car vous aurez alors un contrôle total et il n'y aura aucune limitation due à des frameworks tiers.

Quels sont les problèmes les plus courants que vous rencontrez ?

Problèmes liés au critère WCAG intitulé « 4.1.2 Nom, rôle, valeur ». De nombreuses applications n'ont pas de noms accessibles pour les composants interactifs. Vous pouvez avoir un écran de code PIN où les dix boutons (1, 2, 3…) sont simplement rendus par les lecteurs d'écran sous la forme « bouton », « bouton », « bouton », etc. Vous devez deviner quel bouton correspond à quel numéro. C'est le retour que nous recevons des audits et de notre hotline.

Développer des applications pour les modes portrait et paysage est-il vraiment si compliqué ?

Le mode paysage est clairement l'un des problèmes les plus courants. Mais les utilisateurs ne s'en plaignent jamais. Le mode paysage est beaucoup plus difficile à prendre en charge pour un développeur, surtout si vous le concevez après avoir déjà publié l'application. Par exemple, sur Android, lorsque vous passez en mode paysage, l'application se « recrée », vous devez donc ajouter une certaine logique. Par exemple, l'utilisateur saisit des données, puis il les fait pivoter. Si le développeur n'a pas ajouté la prise en charge de la mise en cache des données saisies, alors elles disparaîssent. Ce n'est pas si difficile si vous le prenez en compte dès le début.

Vous proposez une solution logicielle permettant d'analyser l'accessibilité d'une application Android ou iOS depuis macOS : combien de critères de la norme européenne peuvent être analysés automatiquement ?

Vous pouvez tester environ 20 % des critères, mais ces critères couvrent peut-être environ 50 % des problèmes. Dans un avenir proche, avec l'IA, vous pourrez peut-être aller un peu plus loin. L'IA pourrait déterminer visuellement si l'écran contient un titre, où il se trouve précisément, puis vérifier si ce titre est correctement codé. Il serait autrement difficile de le faire par programmation.

Remarquez-vous une différence entre les applications du secteur public et les applications des entreprises privées ?

Cela dépend vraiment : si l'application du secteur public est créée par une société commerciale tierce, elle est généralement pire que s'il s'agit d'une application interne créée par le gouvernement : celles-ci sont généralement bien meilleures que les applications commerciales.

Prévoyez-vous de continuer à investir votre temps dans l’accessibilité des applications ?

J'aime beaucoup cela. Au début, je ne trouvais pas de personnes partageant les mêmes idées. Très peu de personnes se consacrent exclusivement à la création d'applications mobiles accessibles. Et c'est ce que j'aime avec la MATF : le travail quotidien de ces personnes consiste à travailler sur l'accessibilité des applications mobiles. Nous partageons également nos connaissances dans un groupe Slack, c'est quelque chose qui manquait.