L'accessibilité numérique vue par une testeuse

La conception et le développement d'une application doivent-ils respecter les directives et les normes d'accessibilité? Pour Apps with love, cela va de soi. Garantir que l'application puisse être utilisée par des personnes aux capacités différentes est une caractéristique essentielle de tout produit numérique. Rendre une application accessible n'est pas seulement une obligation éthique, mais également, dans de nombreux cas, une obligation légale. Cela peut également avoir un impact sur les dimensions sociales et économiques.

Dans cet article, tu apprendras quelles sont les règles d'accessibilité les plus courantes et quelles sont les étapes que l'équipe d'assurance qualité d'Apps with love a élaborées avec ses partenaires pour évaluer un produit numérique en fonction de critères d'accessibilité. Tu découvriras également les avantages de la conformité et les défis que tu pourrais rencontrer dans le processus d'assurance qualité. Pour mieux illustrer le sujet, nous avons également donné des conseils utiles à l'aide d'un exemple de projet concret.

Prescriptions, normes et règles

La conception et le développement d'applications accessibles doivent aller au-delà de la simple conformité - il s'agit d'offrir une expérience utilisateur exceptionnelle. L'objectif est de créer et de fournir un produit inclusif qui offre à tous les utilisateurs un niveau élevé d'intuitivité, une navigation frappante mais logique et une interface cohérente et attrayante.

Néanmoins, lors de la conception, du développement et du test d'une application, nous devons bien entendu tenir compte des bases, à savoir les lois et les normes. Lorsqu'il s'agit d'accessibilité, les normes et lois les plus courantes sont:

• Les Directives pour l'accessibilité aux contenus Web WCAG (version actuelle: 2.2.), publiées par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C). Les WCAG sont les normes les plus reconnues dans la plupart des régions du monde.

• The Americans with Disabilities Act (ADA): loi fédérale sur les droits civils introduite en 1990 aux États-Unis d'Amérique pour interdire la discrimination des personnes handicapées dans les activités quotidiennes.

• L'article 508 de la loi sur la réadaptation aux États-Unis: une loi fédérale qui exige des autorités publiques qu'elles fournissent aux personnes handicapées un accès aux informations et données électroniques comparable à celui dont bénéficient les personnes non handicapées, à moins que cela n'impose une charge déraisonnable aux autorités publiques.

• En Suisse, le respect de la norme d'accessibilité eCH-0059 (plus précisément eCH-0059 version 3.0), basée sur les WCAG 2.1, est obligatoire pour toutes les informations et tous les services des pouvoirs publics disponibles sous forme numérique. Cela s'appuie sur l'article 8, paragraphe 2, de la Constitution fédérale, qui prescrit la non-discrimination des personnes souffrant d'un handicap physique, mental ou psychique.

Pour en savoir plus sur les bases de l'accessibilité, les lois, les règlements et les normes, consulte un précédent article de blog sur l'accessibilité. Cet article se concentre davantage sur les aspects pratiques des tests par rapport aux WCAG et aux réglementations américaines, d'autant plus que nous avons récemment fait l'expérience de tester l'application FELFEL par rapport à ces réglementations, puisqu'elle arrive sur le marché américain.

Vérification selon les WCAG, ADA et la section 508

En fonction du marché cible, du public visé et de la localisation ou du siège de l'entreprise propriétaire de l'application, il peut être nécessaire d'assurer le respect d'une ou de plusieurs règles d'accessibilité. Les principales caractéristiques de ces règles sont présentées dans le tableau ci-dessous.

En résumé, les WCAG s'appliquent à tous les produits numériques dans le monde entier, tandis que l'ADA et la section 508 ne s'appliquent qu'aux États-Unis. En outre, les WCAG s'appliquent aux applications dans tous les secteurs et pour tous les groupes cibles, tandis que l'ADA s'applique au secteur privé et à certains domaines du secteur public, tandis que la section 508 ne s'applique qu'aux agences fédérales et à leurs contractants. Ces réglementations se distinguent par leur centre d'intérêt. Les WCAG s'appliquent à tous les contenus numériques, y compris les sites web, les applications et les documents. L'ADA se concentre sur la définition de règles anti-discrimination pour les organismes publics, les employeurs et les entreprises. La section 508 oblige les autorités fédérales à fournir aux utilisateurs handicapés le même accès aux informations et données électroniques qu'aux personnes non handicapées. Il convient de noter que la section 508 est actuellement basée sur les normes WCAG de niveau A et AA. Après sa mise à jour en avril 2024, le titre II de l'ADA stipulera également que les sites web, les applications, les kiosques, les applications mobiles et le contenu numérique doivent être conformes aux WCAG 2.1, niveau AA.

La norme WCAG est la plus répandue et présente de nombreux recoupements avec des réglementations spécifiques à certaines régions, comme l'ADA américaine ou l'eCH-0059 suisse. C'est pourquoi le reste de cet article se concentre sur la description de l'accessibilité dans le contexte de cette norme spécifique.

Test d'accessibilité des produits numériques.

Lorsqu'il s'agit de vérifier si un produit numérique répond aux critères d'accessibilité, la question se pose souvent de savoir par où commencer. Le processus peut être complexe et varie en fonction du produit, des attentes des parties prenantes, du temps et du budget. Chez Apps with Love, nous avons constaté qu'il vaut la peine de procéder selon les étapes suivantes:

1. Définir les exigences: détermine quelle loi/règlement s'applique à ton application et dans quelle mesure le produit doit satisfaire aux exigences correspondantes. Par exemple, quel niveau WCAG est le point de référence. Alors que dans certains cas, cela est défini par des réglementations, dans d'autres cas, ces exigences peuvent être définies par le propriétaire du produit ou dérivées de la consultation de toutes les parties concernées.

2. Testing: Vérifie que l'application répond aux exigences choisies. Cette étape nécessite souvent un échange intensif entre l'équipe de développement et le propriétaire du produit.

   • Consultation entre QA: la complexité des problèmes d'accessibilité peut nécessiter une analyse et un examen plus approfondis sous différentes perspectives, ce qui peut être réalisé en impliquant plus d'une paire d'yeux dans le processus de test.

   • Consultation avec les concepteurs et les développeurs: certaines exigences en matière d'accessibilité ne peuvent pas être testées uniquement du côté frontal d'une application. L'aperçu du point de vue du design et du code est essentiel pour évaluer si certains critères sont remplis ou non.

3. Conclusions et rapport: résumez les résultats des tests afin de les présenter clairement: quelles exigences ont été entièrement, partiellement ou pas du tout remplies. Cette étape peut se terminer par l'établissement d'une liste de recommandations pour l'application, afin que les incohérences puissent être corrigées ou abordées à l'avenir.
   

4. Conseil et prise de décision: analysez les conclusions et décidez d'un éventuel plan d'amélioration pour l'application - généralement sous la forme d'un échange entre les Product Owners et la gestion de projet.

Les lignes directrices pour les tests d'accessibilité

Comme nous avons testé l'accessibilité de certains produits numériques chez Apps with love, nous disposons d'une grande expérience qui nous permet de donner quelques conseils utiles:

Détermine les caractéristiques de base de ton application.

• Systèmes d'exploitation: les solutions d'accessibilité peuvent différer, par exemple, entre Android et iOS - les applications de soutien ainsi que les outils de test d'accessibilité peuvent n'être disponibles que pour une plate-forme spécifique ou des versions limitées (les plus récentes) du système.

• Desktop vs. application mobile: Cela influencera fortement les méthodes et techniques de test, car cela détermine l'utilisation des systèmes d'exploitation, la taille des écrans, les technologies de soutien possibles, les dispositifs d'aide, la navigation à l'écran, etc. Pour cette raison, certains critères d'accessibilité seront remplis sur l'ordinateur de bureau, mais pas sur l'application mobile, et vice versa.

• Web vs. application native: Détermine des sujets tels que les technologies d'assistance possibles ou la navigation à l'écran. Par exemple, certaines solutions de navigation pour une plateforme mobile pourraient être disponibles pour une application native, mais pas pour l'autre. Il peut également influencer la question de la cohérence de l'application entre différents systèmes d'exploitation.

• Les appareils sur lesquels l'application sera utilisée: cela détermine entre autres les tailles d'écran et les technologies de soutien (par exemple: l'appareil peut-il être connecté par Bluetooth ou par un clavier basé sur USB)

• Le groupe cible de votre application: Le produit, sa compatibilité avec les technologies de soutien, la navigation, etc. doivent être adaptés aux besoins des utilisateurs cibles, en tenant compte des différents types de handicaps.

• L'objectif de votre application: Les principales fonctionnalités du produit influencent la manière dont les utilisateurs interagissent avec l'application. L'analyse des scénarios d'utilisation peut fournir des informations sur les points faibles éventuels et le besoin d'un soutien supplémentaire pour l'utilisateur.

Le contrôle de l'accessibilité nécessite de répondre à ces questions fondamentales, car elles déterminent l'ensemble du processus de contrôle. Certaines exigences sont conçues pour ne s'appliquer qu'à certains types d'applications et ne sont pas pertinentes pour d'autres.

Connaître tes exigences

C'est toujours une bonne idée de se tourner vers la source d'information officielle pour les exigences choisies. Mais ce n'est peut-être que le début. La lecture de critères spécifiques peut ne pas te donner suffisamment de visibilité pour les appliquer directement dans le processus de test. Selon la complexité des exigences, un AQ peut avoir besoin d'un soutien supplémentaire pour les interpréter correctement et les appliquer dans le processus de test. Il existe plusieurs sources de connaissances pratiques, telles que les interprétations des exigences en matière d'accessibilité et les exemples, qui peuvent être très utiles pour comprendre en profondeur les critères d'accessibilité. 

Tu trouveras de tels exemples et des explications détaillées sur le site du W3C: https://www.w3.org/TR/WCAG22/. Par exemple, pour le critère 1.3.4 "Orientation", les informations suivantes sont données: 

Définition: Les contenus ne limitent pas leur affichage et leur utilisation à une seule orientation d'affichage, telle que portrait ou paysage, à moins qu'une orientation d'affichage particulière ne soit indispensable.

Explication plus détaillée du critère, y compris l'objectif (les appareils peuvent être utilisés dans n'importe quelle orientation), ce qu'il faut faire (le contenu ne doit pas être fixé sur l'affichage en mode portrait ou paysage) et ce qui est important (les utilisateurs de fauteuils roulants et d'autres personnes peuvent avoir des appareils dans une orientation fixe).

Il contient en outre la définition de l'intention du critère, des avantages (les utilisateurs ayant une déficience visuelle peuvent consulter le contenu dans l'orientation qui leur convient le mieux, par exemple pour augmenter la taille du texte en consultant le contenu en mode paysage), des exemples de mise en œuvre (une application web eReader peut afficher le contenu d'un livre en mode portrait et paysage) et des règles de test.
Un lien séparé t'amène à une page d'exemples de mise en œuvre réussie et ratée de ce critère (https://www.w3.org/WAI/WCAG22/quickref/).

A la fin de cet article, tu trouveras d'autres sites web qui te donneront un aperçu des critères d'accessibilité.

Demande un deuxième avis 

Il y a un proverbe (il peut être de Confucius ou non) : "L'homme qui pose une question est un fou pour une minute, l'homme qui ne pose pas de question est un fou pour la vie". Cela est particulièrement vrai lorsqu'il s'agit du processus d'assurance qualité d'un produit numérique et est essentiel lorsqu'il s'agit de vérifier le respect des critères d'accessibilité. En raison de la complexité et du caractère universel des règles, un évaluateur peut souvent ne pas être certain qu'une application remplit le critère spécifique ou même que l'exigence est pertinente ou applicable au produit en question.

Certains aspects de l'accessibilité seront mieux connus d'un concepteur ou d'un développeur, car ils ont été intégrés à l'application très tôt dans le processus de développement et sont parfois difficiles à percevoir dans une perspective de boîte noire (lorsqu'on ne regarde que l'interface de l'application et non le code). Bien sûr, on ne peut jamais se tromper en échangeant avec d'autres QA. Chaque individu comprend peut-être les exigences un peu différemment. Cela peut conduire à une évaluation différente de la conformité de l'app au critère. L'établissement d'une compréhension commune des exigences spécifiques par différents testeurs peut améliorer considérablement la qualité des résultats des tests.

La meilleure façon de tester l'accessibilité d'un produit numérique est bien sûr de consulter les utilisateurs qui ont réellement besoin que les exigences en matière d'accessibilité soient correctement appliquées.

Essaye différents réglages de contrôle

Il ne s'agit certainement pas d'une nouvelle révolutionnaire, mais il convient de noter qu'il est important de modifier les paramètres de test lors de l'évaluation des aspects d'accessibilité d'un produit. L'utilisation de différents appareils, systèmes d'exploitation, technologies d'assistance ou résolutions donne définitivement une vision plus large de l'application et de son comportement dans différents environnements. Vous pouvez éviter de vous retrouver dans une situation où l'on vous dit "ça marche sur mon appareil" (mais pas sur les autres). Sans parler du fait que les couleurs, les résolutions, les contrastes, les graphiques et tous les autres éléments visuels peuvent être totalement différents sur différents appareils.

Défis et avantages des tests d'accessibilité

Il est bon que l'équipe d'AQ soit consciente des différents défis et risques liés aux tests d'accessibilité afin qu'ils puissent être pris en compte dans le processus de planification. Cela peut inclure:

Caractère universel des exigences 

Les exigences WCAG s'appliquent à tous les types de produits et secteurs numériques, desktop, mobile, web et natif, ainsi qu'à différents groupes cibles: le grand public, mais aussi des groupes spécifiques/étroits.
Lors de l'examen de critères concernant, par exemple, la mise en évidence de sections d'écran, l'utilisation de combinaisons de touches/boutons spéciaux tels que "Tab", le balayage ou la succession de gestes, l'AQ doit donc décider si l'exigence est valable et applicable au produit en question.

Différences entre les plateformes et les appareils

Les appareils Android et iOS diffèrent en termes de solutions d'accessibilité, de technologies d'assistance et de possibilités de débogage. Cela peut poser des problèmes lors de la mise en œuvre de solutions d'accessibilité adaptées et également lors du maintien de la cohérence de l'expérience utilisateur entre les différents appareils et systèmes. 

Des exigences difficiles à vérifier sur le front-end

Certaines exigences ne sont pas ou difficilement testables d'un point de vue purement frontal. Il s'agit par exemple des critères WCAG tels que:

• Déterminer la finalité de la saisie: L'objectif de chaque champ de saisie qui collecte des informations sur l'utilisateur peut être déterminé par programme sous certaines conditions (WCAG 2.2, §1.3.5)

• Nom, rôle, valeur: pour tous les composants de l'interface utilisateur (y compris, mais pas seulement: Les éléments de formulaire, les liens et les composants générés par des scripts), le nom et le rôle peuvent être déterminés par programme. Les états, propriétés et valeurs qui peuvent être définis par l'utilisateur peuvent être déterminés par programme, et la notification des modifications apportées à ces éléments est disponible pour les agents utilisateurs, y compris les technologies d'assistance (WCAG 2.2. §4.1.2.).

Exigences commerciales vs. exigences en matière d'accessibilité

Le design, l'objectif ou certains aspects commerciaux d'une application ne vont pas toujours de pair avec les exigences en matière d'accessibilité. Souvent, les couleurs, les polices de caractères, les tailles, l'orientation de l'écran et de nombreux autres éléments visuels font partie de la stratégie de communication et de marketing de la marque. Devraient-ils être modifiés pour que l'application réponde aux critères d'accessibilité? C'est un autre casse-tête difficile à résoudre.

Ainsi, une question importante se pose: la mise en œuvre d'une bonne accessibilité en vaut-elle la peine? Eh bien, il ne fait aucun doute que l'adaptation de l'application aux exigences de l'accessibilité est importante à de nombreux niveaux différents et peut profiter au produit, à la marque et à l'entreprise de multiples façons - même s'il n'existe pas toujours de réglementation contraignante à ce sujet.

• Acquérir un public plus large - une application plus conviviale et inclusive attire un public plus large, ce qui peut se traduire par une couverture de marché potentiellement plus large et des bénéfices plus élevés.

• Augmenter la fidélité à la marque - l'accessibilité permet aux personnes handicapées d'interagir et de participer au paysage numérique, ce qui rend le produit plus sympathique. Elle démontre l'engagement en faveur de la diversité, de l'égalité et de l'inclusion (DEI).

• Améliorer l'expérience générale des utilisateurs - l'amélioration de la convivialité, de la navigation, de la compréhension et de l'interaction peut rendre l'expérience utilisateur satisfaisante pour tous les utilisateurs, et pas seulement pour les personnes handicapées

• Optimisation des moteurs de recherche - la mise en conformité avec les exigences d'accessibilité peut améliorer la visibilité d'un produit numérique dans les moteurs de recherche et, par conséquent, augmenter la portée de son public.

  Optimisation de l'IA - les plateformes pilotées par l'IA, telles que Bing et ChatGPT, gagnent actuellement en popularité par rapport aux moteurs de recherche traditionnels. La mise en œuvre d'exigences d'accessibilité dans le produit numérique peut servir à optimiser l'intelligence artificielle (la limitation des barrières d'accès contribue au fonctionnement de ces plates-formes).

Ces aspects entraînent directement des bénéfices commerciaux supplémentaires, tels qu'une plus grande portée du marché, un public plus large, une meilleure satisfaction et fidélité des utilisateurs, une valeur et une reconnaissance accrues de la marque, et donc potentiellement des bénéfices plus élevés.

Accessibilité dans l'application FELFEL - un exemple pratique

Les avantages de l'accessibilité sont appréciés par un certain nombre d'entreprises, dont notre client FELFEL, dont nous développons et maintenons l'application depuis quelques années.

FELFEL est la solution appréciée pour la restauration des collaborateurs et le café de bureau en Suisse.

L'application permet aux utilisateurs de parcourir le menu disponible, d'ouvrir le réfrigérateur FELFEL, de sélectionner un plat de leur choix et de le payer. 

Afin de rendre l'application plus inclusive et conviviale, les responsables de produits de FELFEL ont décidé de s'assurer que l'application répondait aux normes d'accessibilité de WCAG 2.1 niveau AA.

Mais ce n'était pas tout: comme l'entreprise est en pleine expansion et qu'elle s'est récemment lancée sur le marché américain, elle devait également s'assurer de la conformité avec l'ADA.
L'objectif de notre équipe était de tester la version mobile de l'application sur deux plateformes: Android et iOS par rapport aux critères d'accessibilité des WCAG ainsi que de l'ADA.
En testant l'application FELFEL par rapport aux critères correspondants, certains doutes et questions concernant des exigences spécifiques sont apparus. 

En outre, les solutions d'accessibilité semblaient fonctionner différemment sur les différents systèmes d'exploitation. Cela concernait des critères tels que le contraste, le redimensionnement, l'effacement des pointeurs et la couverture du texte Alt.

L'évaluation de l'application FELFEL nous a donné un meilleur aperçu de la manière dont l'accessibilité peut être intégrée dans un produit numérique et nous a ouvert les yeux sur certaines constatations, comme par exemple

• Prendre en compte le fait que chaque système d'exploitation/plateforme nécessite un temps et des ressources différents pour être testé correctement

• Planifier le processus de test en supposant que du temps supplémentaire pourrait être nécessaire

• L'utilisation d'interprétations des exigences et de notre base de connaissances interne sur l'accessibilité aide énormément, de garantir la conformité de l'application et d'améliorer la qualité du produit

• Les mises à jour régulières de l'équipe sur l'accessibilité aident à concevoir et à créer des applications de meilleure qualité, qui passent plus facilement et plus rapidement par le processus d'évaluation.

L'accessibilité comme point fort?

Vérifier la compatibilité d'une application avec les exigences en matière d'accessibilité peut être un processus long et difficile. La quantité de règles, leur complexité et leur diversité peuvent être écrasantes au début. Et le véritable combat commence avec la vérification effective des éléments de l'application par rapport aux critères de réussite spécifiques. Mais au fur et à mesure que l'on acquiert de l'expérience en parcourant le processus, l'expertise.

L'équipe d'Apps with love s'engage non seulement à être à la pointe des réglementations en matière d'accessibilité, mais aussi à les mettre en pratique, de la conception à l'assurance qualité en passant par l'ensemble du processus de développement. Il est dans notre intérêt et dans celui de nos clients de développer des applications inclusives, conviviales et intuitives, basées sur des technologies innovantes. Il pourrait donc être avantageux de considérer les solutions d'accessibilité non pas comme des caractéristiques imposées, mais comme les points forts d'un produit numérique. Tout bien considéré, leur utilisation peut apporter un certain nombre d'avantages et augmenter considérablement la valeur d'une application.

Aide pour la conception, le développement et les tests d'accessibilité

Tu trouveras ici quelques outils et liens utiles parmi lesquels tu pourras facilement trouver des conseils, des interprétations et des informations utiles sur les questions d'accessibilité:

• Aperçu de l'accessibilité du Web

• Les lignes directrices du WCAG avec des interprétations

• WCAG 2.2. - comment comprendre

• Aide au test pour Android: Accessibility Scanner

• Indications pour le test sur le mobile

• Tester sur le mobile: Lecteur d'écran pour tester les entrées de texte et de non-texte, outils de conception tels que Zeplin ou Figma pour évaluer les couleurs et le contraste

Sources :

• https://www.accessibility.works/blog/2024-wcag-ada-website-compliance-standards-requirements/

• https://userway.org/blog/wcag-vs-ada-vs-section-508/

• https://www.consagous.co/blog/accessible-mobile-app-design-bridging-the-gap-for-all-usershttps://fastercapital.com/topics/understanding-the-importance-of-mobile-accessibility.html

A propos de Magdalena
Magdalena, plus connue sous le nom de Magda, est testeuse de logiciels chez Sagiton, notre partenaire de longue date. Elle teste nos développements sous toutes les coutures et sait renvoyer les éventuels bugs de manière claire mais diplomatique - il est possible que cette compétence soit due à son master en relations internationales.
Magda rêve d'une fusion Seigneur des Anneaux x Harry Potter (Gandalf et Dumbledore pourraient tout à fait passer pour des frères) et pense que le Nutella est surfait, contrairement aux idées reçues.