En tant que développeur web, j’ai trouvé passionnant de pouvoir appliquer aux plateformes mobiles mes nombreuses années d’expérience et mes connaissances sur l’accessibilité dans le cadre de l’«Étude suisse sur l’accessibilité 2023 – applications mobiles». Si je connaissais déjà beaucoup d’aspects, j’ai également dû apprendre d’autres éléments. Je vais partager ci-après quelques expériences et découvertes surprenantes.

Éléments natifs vs. éléments définis par l’utilisateur

Mon expérience de développeur m’en a apporté la confirmation au fil des années: les meilleurs résultats en matière d’accessibilité sont obtenus dans les projets où le choix des fonctionnalités se rapproche le plus de l’offre de la plateforme utilisée. Pour les sites Internet, il s’agit du navigateur pour lequel HTML définit la palette d’éléments et de fonctionnalités; pour les applications, iOS et Android proposent leurs propres palettes. Si l’on met ensuite en œuvre ces fonctionnalités conformément aux spécifications du langage de programmation correspondant, on peut se fier en toute tranquillité au système d’exploitation, car c’est lui qui est responsable de l’accessibilité.

Plus un projet doit être élaboré, plus on risque de se heurter aux limites des éléments disponibles, en particulier lorsque des éléments de contrôle complexes tels que des accordéons, la saisie semi-automatique ou des glisser-déposer sont nécessaires. Ceux-ci doivent être programmés manuellement, la responsabilité de l’accessibilité incombant désormais à l’équipe de programmation elle-même. Heureusement, il existe ici aussi de nombreuses possibilités d’étendre des éléments standard par exemple; il est également possible de définir des éléments de contrôle entièrement nouveaux, ce qui est naturellement bien plus fastidieux et complexe. La saisie semi-automatique de l’application «MS Teams» est un bon exemple de champ de recherche accessible avec des suggestions de recherche: lors de la recherche de contacts, les utilisateurs et utilisatrices de lecteurs d’écran sont également informés du nombre de résultats affichés sur la base du texte de recherche actuel. En revanche, pour l’application «Klapp – Communication scolaire», le lecteur d’écran reste muet.

La même expérience pour tous: pas de chemins d’accès alternatifs!

L’accessibilité de ces éléments un peu plus complexes n’est jamais le fruit du hasard: des connaissances approfondies sont nécessaires pour prendre en charge des fonctions à l’échelle du système telles que le zoom, les modes de contraste, l’utilisation du clavier, etc., et l’objectif doit être poursuivi de manière cohérente et pendant toute la durée du projet. Cela peut entraîner un surcroît de travail considérable, raison pour laquelle des équipes de développement ingénieuses sont parfois enclines à proposer des variantes «simplifiées» d’éléments ou de contenus complexes à des groupes d’utilisateurs ayant des besoins particuliers. Je le déconseille vivement: d’une part, parce que l’expérience utilisateur risque non seulement d’en être simplifiée, mais aussi d’en souffrir (par exemple parce que des fonctionnalités, voire des contenus, seront réduits). D’autre part, parce que l’entretien de ces chemins d’accès alternatifs entraîne souvent un surcroît de travail considérable et est vite oublié; le gain de temps initial ne vaut pas la peine. Ma recommandation est donc la suivante (et elle a fait ses preuves au fil des années): tous les utilisateurs et toutes les utilisatrices doivent toujours pouvoir utiliser les mêmes fonctionnalités et les mêmes chemins d’accès (user stories), même si cela nécessite parfois des compromis. Seuls des cas particuliers tels que le glisser-déposer, qui mise «by design» sur l’utilisation de la commande par pointeur, nécessitent parfois une implémentation alternative supplémentaire afin de ne pas exclure les utilisateurs et utilisatrices de claviers.

Fonctionnalités supplémentaires pour appareils de saisie alternatifs

Il est courant de trouver des éléments de contrôle différents des éléments habituels lors des tests. Toutefois, pour répondre aux attentes en matière d’accessibilité, un tel élément doit présenter certaines fonctionnalités supplémentaires pour pouvoir être utilisé par d’autres appareils de saisie. L’application «Fairtiq» en est un bon exemple: le bouton bien visible pour démarrer un trajet doit être tiré de gauche à droite (geste de balayage). Les lecteurs d’écran ne prennent pas en charge ce geste (ou le demandent pour déplacer leur curseur de lecture); c’est pourquoi, lorsque le lecteur d’écran est actif, le bouton peut être activé par un simple clic au lieu du balayage habituel. Il en va autrement avec l’application «Teletext», qui nécessite également un mouvement de balayage pour faire défiler les pages: pour les lecteurs d’écran, c’est malheureusement impossible (pour la raison mentionnée ci-dessus). Un bouton supplémentaire «Afficher la page suivante» constituerait une solution simple et efficace.

Autre avantage: comme le lecteur d’écran est intégré au système d’exploitation, l’application peut détecter s’il est actif et adapter ses fonctionnalités en conséquence. Une possibilité puissante, mais qui doit être utilisée avec précaution, dans l’esprit du principe directeur ci-dessus: «La même expérience pour tous!»

Sens et non-sens des «modes accessibilité»

Certaines applications proposent des options qui promettent d’améliorer l’accessibilité de certains éléments pour certains groupes d’utilisateurs. Cela peut s’avérer utile lorsque l’accessibilité d’un groupe restreint la facilité d’utilisation pour un autre groupe. De nombreux utilisateurs et utilisatrices d’applications d’actualités souhaitent par exemple que le contenu audio et vidéo soit lu immédiatement lors de l’ouverture, mais cela complique l’utilisation de l’application pour les aveugles, car les instructions audio de leur lecteur d’écran peuvent être masquées par des contenus audio bruyants. L’application «SRF News» résout ce problème en proposant une option permettant de lire ou d’arrêter automatiquement de tels contenus dans la zone des paramètres.

Toutefois, si une application fait la promotion d’un «mode accessibilité» général dès le lancement, l’expérience montre qu’il faut être prudent. Je me pose alors la question suivante: quel genre de fonctionnalités (ou de contenus) exceptionnels cette application contient-elle pour qu’ils ne puissent apparemment pas être proposés de la manière habituelle, c’est-à-dire de manière à ce qu’ils fonctionnent de la même manière pour tout le monde? Cela peut tout à fait être le cas pour les applications au graphisme sophistiqué ou ultra interactives, généralement pour les jeux vidéo. Mais cela arrive rarement avec les applications «classiques». J’étais donc sceptique vis-à-vis de l’application «beook», qui m’a proposé dès le premier lancement d’améliorer l’expérience utilisateur pour les personnes aveugles, notamment en supprimant des fonctions «rarement utilisées» (non définies). En fait, il s’est avéré que cela supprime complètement la fonction de recherche globale ainsi que la lecture de contenus audio et vidéo. Des fonctions, me semble-t-il, tout à fait pertinentes dans un lecteur de livres électroniques! Ici, la définition de l’accessibilité a été totalement mal comprise. Il s’agit en effet de rendre des fonctionnalités accessibles à tous et non de dissimuler des mises en œuvre potentiellement inaccessibles à certains groupes d’utilisateurs.

Une application pour personnes en situation de handicap – une bonne idée?

Après avoir testé plus de 40 applications, mon impression se confirme: plus les applications ont intégré le principe d’utilisation des fonctionnalités et éléments standard du système d’exploitation, plus le résultat est fluide, même pour les groupes d’utilisateurs qui ne se déplacent pas avec les périphériques d’entrée et de sortie classiques. L’application «Mobile CFF» prouve que de telles applications peuvent être très attrayantes tant sur le plan fonctionnel que visuel. Sa mise en page claire facilite la tâche des utilisateurs et des utilisatrices et les guide à travers une multitude de contenus et de fonctionnalités sans les surcharger d’informations. Néanmoins, les CFF ont décidé d’externaliser d’autres fonctionnalités (particulièrement utiles pour les personnes en situation de handicap) vers l’application «Inclusive CFF». Est-ce une violation de ma devise selon laquelle tous les utilisateurs et utilisatrices doivent toujours pouvoir utiliser les mêmes fonctionnalités et chemins d’accès? Si les éditeurs d’applications ont de bonnes raisons d’utiliser des applications spécifiques séparément et de les mettre en œuvre de manière cohérente (et durable), rien ne s’y oppose. Les deux applications des CFF ont reçu d’excellentes notes lors de nos tests, ce qui indique clairement que ces équipes de développement connaissent leur métier. On peut donc être sûr que les exigences élevées en matière d’accessibilité continueront d’être respectées à l’avenir.

En règle générale, je conseille aux agences de ne développer des éditions d’applications spécifiques aux besoins que dans des cas exceptionnels. Afin d’obtenir une accessibilité optimale avec un minimum d’efforts supplémentaires, il convient de miser en priorité sur les fonctionnalités de base du système d’exploitation. En respectant ce principe, il est ensuite possible de définir des chemins d’accès de base (user stories) qui fonctionnent de la même manière pour tous les utilisateurs et utilisatrices de l’application.

À propos de l’auteur

Josua Muheim est Accessibility Consultant auprès de la fondation «Accès pour tous». Josua Muheim est développeur d’applications qualifié. Il a rejoint la fondation en 2014 et y a tout appris sur l’accessibilité jusqu’en 2018. Après quelques années de voyages et de travail en freelance, il est revenu au sein de l’équipe en 2023 et est désormais responsable, entre autres, de la formation des stagiaires.