Cet article a été rédigé en collaboration avec les personnes suivantes, qui ont accepté de se prêter à une interview d’expert: Diane Illi et Patrick Mukherjee (SwissSign), Marcel Belz (MeteoSwiss), Guido Riedweg et Christian Rudolf von Rohr (Well), Sandro Lüthi (École de la pomme).

De nos jours, les sites Internet sont universellement composés de HTML, JavaScript et CSS (enrichi avec ARIA si nécessaire). Ces langages sont standardisés et il incombe aux éditeurs de navigateurs de les mettre en œuvre conformément aux spécifications. On constate à cet égard une nette amélioration par rapport au passé. Les standards Web sont développés et enrichis en permanence. Les professionnels du développement Web se sont familiarisés avec les fonctionnalités et les éléments supportés par tous les navigateurs. Les progrès significatifs en matière de standardisation ainsi que la réduction à deux plateformes de base pour les navigateurs Web – WebKit d’Apple et Chromium de Google – ont simplifié le développement Web. Au fond, dans le domaine du développement Web, nous sommes proches de l’idéal de développer pour un écosystème unique et homogène: le «Web». Les technologies d’assistance telles que les lecteurs d’écran, qui dépendent d’un code valide et sémantiquement correct dans le navigateur, profitent également de cette uniformisation.

Dans le monde des applications mobiles, la situation d’un écosystème homogène est toute autre: il existe ici deux plateformes complètement différentes, à savoir iOS d’Apple et Android de Google. Bien qu’en apparence, les deux plateformes semblent similaires à bien des égards, elles sont pourtant fondamentalement différentes en coulisses: différents langages de programmation sont utilisés, et bien que les palettes de fonctionnalités standard et d’éléments de l’interface utilisateur aient des points communs évidents, elles ont toutefois des caractéristiques spécifiques qui leur permettent de créer l’apparence typique de chaque plateforme. Pour proposer une seule et même application sur Android et iOS, il faut intérioriser deux écosystèmes complètement différents lors du développement de l’application. La même application doit donc être produite quasiment deux fois.

Divers frameworks de programmation promettent de minimiser cette double charge de travail en générant les versions de l’application pour iOS et Android à partir d’une seule source de code. Certains frameworks traduisent leur code dans les langages de programmation natifs de la plateforme concernée, tandis que d’autres génèrent du code HTML qui peut être chargé depuis les deux plateformes (applications dites hybrides). Les représentants les plus connus de tels frameworks (p. ex. Flutter et React Native) semblent être conscients de l’importance de l’accessibilité: les applications générées sont présentées comme étant accessibles! Soit parce qu’elles sont traduites en applications natives dont l’accessibilité est garantie par le système d’exploitation, soit parce qu’une application hybride est créée qui respecte les spécifications traditionnelles de HTML (et ARIA). Flutter opte pour une approche intermédiaire: les applications sont implémentées en code natif du système d’exploitation, mais le framework n’utilise pas la palette du système d’exploitation, mais «peint» ses propres éléments développés qui, selon l’éditeur, doivent également être accessibles. Malgré ces simplifications, il incombe toujours à l’équipe de développement de connaître les fonctionnalités correspondantes et de les mettre en œuvre de manière cohérente. Même si l’algorithme de traduction des frameworks évoqués devrait être très clair et offrir en théorie tout ce que les experts adorent en matière d’accessibilité, cela n’a pas grand intérêt si le plan de construction à partir duquel les applications sont générées est défectueux. L’adage bien connu prend ici tout son sens: «Garbage in, garbage out».

Et même si la conception et la programmation relèvent d’un niveau extrêmement élevé, une assurance qualité régulière est indispensable. Ce n’est que lorsque le lecteur d’écran est démarré, que le zoom à l’échelle du système est activé et qu’un clavier physique est connecté que l’on peut voir si l’ensemble des fonctionnalités et des éléments d’une application interagissent de manière judicieuse. À cet égard, il convient d’ancrer fermement l’accessibilité dans le processus de développement. Afin d’obtenir des responsabilités bien définies, il convient de définir des postes au sein de l’équipe et d’y attribuer des missions claires. Cela permet de garantir que le thème de l’accessibilité ne passe pas au second plan tout au long du cycle de développement.

À 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.