Qu’est-ce que les tests d’accessibilité ? (Exemples)

Qu’est-ce que les tests d’accessibilité ?

Test d'accessibilité Il s'agit d'un type de test logiciel réalisé pour confirmer qu'une application est utilisable par les personnes handicapées, notamment celles souffrant de déficiences visuelles, auditives, motrices, cognitives ou liées à l'âge. C'est un sous-ensemble de tests d'utilisation et vérifie que le produit est compatible avec les technologies d'assistance dont ces utilisateurs s'appuient au quotidien.

Les technologies d'assistance permettent aux personnes handicapées d'utiliser un logiciel. Voici quelques exemples courants :

• Logiciel de reconnaissance vocale – Convertit les mots prononcés en texte servant d'entrée à l'ordinateur.
• Logiciel de lecture d'écran – Lit à voix haute le texte et les éléments d'interface affichés à l'écran.
• logiciel de grossissement d'écran – Agrandit certaines parties de l'écran pour faciliter la lecture aux utilisateurs malvoyants.
• Claviers spécialisés – Conçu pour les utilisateurs ayant des difficultés de motricité afin de faciliter la tâcheping Plus facile.
• Interrupteur et œil-tracappareils royaux – Permettre aux utilisateurs souffrant de graves handicaps moteurs de naviguer et de sélectionner les éléments de l'interface.

Pourquoi des tests d'accessibilité ?

Raison 1: Cibler le marché des utilisateurs handicapés.

Selon l'Organisation mondiale de la santé, environ 1.3 milliard de personnes, soit environ une personne sur six dans le monde, vivent avec un handicap important.

• Une personne sur dix souffre d'un handicap grave.
• Une personne sur deux âgée de plus de 65 ans présente des capacités réduites.

Les handicaps comprennent la cécité, la surdité, les troubles moteurs, les troubles cognitifs et d'autres problèmes de santé de longue durée. Un produit conçu pour être accessible peut atteindre ce vaste marché, et la plupart des défauts d'accessibilité peuvent être évités en intégrant les tests d'accessibilité au cycle de vie normal des tests logiciels.

Raison 2Respectez la législation en matière d'accessibilité.

Partout dans le monde, les gouvernements ont adopté des lois exigeant que les produits informatiques soient accessibles aux personnes handicapées. Voici quelques exemples importants :

• États-Unis : Americans with Disabilities Act (ADA, 1990) et Section 508 du Rehabilitation Act.
• Royaume-Uni : Loi sur l'égalité de 2010 (qui a remplacé la loi de 1995 sur la discrimination des personnes handicapées).
• Union européenne : Règlement européen sur l’accessibilité, applicable à de nombreux produits et services depuis juin 2025, et norme EN 301 549.
• Australie : Loi de 1992 sur la discrimination des personnes handicapées.
• Irlande : Loi sur le handicap de 2005.
• Canada : Loi de 2019 sur l’accessibilité au Canada.

Les tests d'accessibilité sont essentiels pour garantir la conformité légale sur tous les marchés où votre produit est vendu.

Raison 3: Éviter les poursuites judiciaires potentielles.

De grandes entreprises ont été poursuivies en justice à plusieurs reprises parce que leurs produits numériques n'étaient pas accessibles. Voici quelques affaires marquantes :

• Fédération nationale des aveugles (NFB) c. Target (2006, réglé en 2008).
• Règlement NFB c. AOL (1999).
• Robles c. Domino's Pizza (2019), où les États-Unis SupremLa Cour a confirmé une décision selon laquelle l'ADA s'applique aux sites web et aux applications mobiles.
• Gil c. Winn-Dixie (2017), le premier verdict de procès américain exigeant la réparation d'un site Web inaccessible.

Aux États-Unis, les poursuites judiciaires relatives à l'accessibilité web augmentent chaque année, avec plus de 4 000 affaires numériques relevant du titre III de l'ADA déposées annuellement depuis 2022. Concevoir des produits accessibles dès le départ permet d'éviter ces coûts et de protéger l'image de marque.

Quels handicaps accompagner ?

Une application doit prendre en charge les personnes handicapées, notamment :

Type d'invalidité	Invalidité Description CMS
Déficience visuelle	Cécité totale, daltonisme ou basse vision. Sensibilité aux effets stroboscopiques et clignotants.
Handicap physique	Incapacité à utiliser une souris ou un clavier d'une seule main. Motricité réduite, notamment mouvements de la main limités ou lenteur musculaire.
Handicap cognitif	Difficultés d'apprentissage, mauvaise mémoire ou difficulté à suivre des scénarios complexes.
Handicap en matière d'alphabétisation	Difficultés de lecture telles que la dyslexie.
Handicap auditif	Problèmes auditifs, notamment la surdité et la déficience auditive. Incapacité à entendre un son ou à l'entendre clairement.

Normes et lignes directrices en matière d'accessibilité

Les programmes de tests d'accessibilité s'appuient sur un nombre restreint de normes largement adoptées. Avant toute élaboration d'un plan de test, il est primordial de déterminer la norme applicable à votre marché.

• WCAG 2.2 Publiées par le W3C en octobre 2023, les Règles pour l’accessibilité des contenus Web 2.2 constituent la norme mondiale actuelle. Elles définissent trois niveaux de conformité : A (basique), AA (le minimum légal dans la plupart des pays) et AAA (le plus élevé).
• WCAG 3.0 – Un projet de norme du W3C qui introduit un modèle de notation basé sur les résultats. Il est encore en cours d'élaboration et n'a pas remplacé les WCAG 2.2.
• Section 508 – Règlement fédéral américain sur les marchés publics exigeant que les technologies électroniques et de l'information achetées par les agences fédérales répondent aux critères de niveau AA des WCAG 2.0.
• FR 301 549 – Norme européenne harmonisée pour l'accessibilité des TIC, utilisée pour démontrer la conformité à la loi européenne sur l'accessibilité.
• Titre III de l'ADA – La loi américaine sur les droits civiques s'applique aux sites web et aux applications mobiles des établissements recevant du public ; les tribunaux utilisent généralement les WCAG 2.1 ou 2.2 AA comme référence.

La plupart des équipes traitent niveau AA des WCAG 2.2 comme objectif de travail car il constitue à la fois le socle juridique commun et un objectif d'ingénierie pratique.

Comment faire des tests d’accessibilité ?

Les tests d’accessibilité peuvent être réalisés de deux manières :

1. Manuel
2. Chaînes de vente

Les tests d'accessibilité peuvent s'avérer complexes pour les testeurs qui ne sont pas familiarisés avec les handicaps. Il est recommandé de faire appel à des utilisateurs en situation de handicap ou à des spécialistes de l'accessibilité capables de décrire les difficultés rencontrées au quotidien. Les techniques décrites ci-dessous couvrent les principales catégories de handicaps.

1) Handicap visuel

Imaginez que vous soyez totalement aveugle et que vous ayez besoin d'utiliser le site web XYZ. Votre seule option pratique est un lecteur d'écran. Un lecteur d'écran est un logiciel qui décrit le contenu d'une page web, y compris le texte, les liens, les boutons radio, les images et les vidéos, afin qu'un utilisateur aveugle puisse percevoir l'interface. Parmi les lecteurs d'écran populaires, on trouve : MÂCHOIRES, NVDA, Apple VoiceOver et Android Répondre.

Lorsque vous lancez JAWS puis ouvrez un navigateur, JAWS annonce le titre de la page. Si vous déplacez le curseur vers la barre d'adresse, JAWS dit « Barre d'adresse » et lit ensuite chaque caractère que vous tapez. Par exemple, tapez «  ».ping google.com publie une annonce comme celle-ci :

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

Un lecteur d'écran décrit mot à mot le contenu des champs de texte, annonce les liens comme « lien » et les boutons comme « bouton », permettant ainsi à un utilisateur aveugle d'identifier chaque élément. Si un site web est mal conçu, le lecteur d'écran peut mal identifier certains éléments ; par exemple, un lien affiché comme du texte brut peut être interprété comme du contenu, masquant ainsi une action essentielle à l'utilisateur. Le coût pour l'entreprise se traduit alors par un manque à gagner réel.

2) Daltonisme

Le daltonisme signifie qu'une personne ne perçoit pas correctement certaines couleurs. Le daltonisme rouge-vert est la forme la plus courante. Si un site web utilise beaucoup le rouge pour transmettre des informations, une personne daltonienne rouge-vert risque de ne pas comprendre le message.

Les équipes de conception ne devraient jamais utiliser la couleur seule pour communiquer des informations. Un bouton d'erreur rouge est plus visible lorsqu'il est encadré, accompagné d'une icône et d'un texte descriptif. Le noir et blanc restent la palette universelle la plus sûre, et des outils comme l'extension Stark ou les simulateurs de daltonisme pour navigateur permettent de détecter les problèmes rapidement.

3) Basse vision

Les utilisateurs malvoyants ou souffrant d'autres affections rétiniennes ont besoin d'une assistance supplémentaire pour utiliser le site :

1. Évitez les textes de très petite taille. Les WCAG recommandent une taille de corps par défaut qui s'adapte confortablement à la taille de l'écran sans zoom.
2. Assurez-vous que la mise en page s'adapte correctement lorsque le texte est agrandi jusqu'à 200 % (critère de succès WCAG 2.2). Les lignes ne doivent pas être coupées et le contenu ne doit pas se chevaucher.
3. Maintenez un rapport de contraste minimal de 4.5:1 pour un texte normal et de 3:1 pour un texte de grande taille.

4) Handicaps moteurs et autres handicaps

Une exigence d'accessibilité majeure est que l'intégralité du site soit utilisable sans souris. Chaque lien, bouton, option radio, case à cocher, fenêtre contextuelle, menu déroulant et commande doit être accessible et utilisable uniquement au clavier.

Par exempleUn utilisateur à mobilité réduite peut ne pas être en mesure d'utiliser une souris. Si les cases à cocher ou les liens ne sont pas accessibles via la touche Tabulation, l'utilisateur ne pourra pas utiliser ces fonctionnalités.

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

La sélection doit toujours être visible. Lorsque l'utilisateur appuie sur la touche Tabulation, le contrôle sélectionné doit ressortir clairement. Une sélection visible aide les personnes malvoyantes ou daltoniennes à suivre le parcours de la page et rend la navigation prévisible pour tous.

Utilisateurs ayant une déficience auditive On peut généralement visualiser le contenu visuel d'un site, mais l'audio et la vidéo posent problème. Chaque vidéo doit être sous-titrée et chaque fichier audio doit comporter une transcription ou un texte descriptif. Par exemple, un tutoriel vidéo sur la réservation d'un billet d'avion doit être accompagné de sous-titres précis afin qu'une personne sourde puisse le suivre.

Exemples de cas de test pour les tests d'accessibilité

La liste de contrôle ci-dessous sert à valider les tests d'accessibilité d'une application web standard. Utilisez-la comme point de départ et complétez-la avec les critères de succès WCAG 2.2 pertinents pour votre produit.

1. Existe-t-il des équivalents clavier pour chaque opération de la souris et chaque boîte de dialogue ?
2. La documentation utilisateur explique-t-elle comment utiliser l'application avec des technologies d'assistance ?
3. L'ordre de tabulation est-il logique pour que la navigation soit fluide et naturelle ?
4. Des raccourcis clavier sont-ils prévus pour les menus principaux ?
5. L'application est-elle compatible avec tous les systèmes d'exploitation et lecteurs d'écran ciblés ?
6. Le temps de réponse de chaque écran ou page est-il clairement indiqué afin que les utilisateurs sachent combien de temps attendre ?
7. Toutes les étiquettes sont-elles correctement rédigées et liées par programmation à leurs commandes ?
8. Les choix de couleurs sont-ils flexibles et ont-ils été testés à l'aide de simulateurs de daltonisme ?
9. Les images, icônes et émojis sont-ils utilisés de manière à être compréhensibles par les utilisateurs finaux ?
10. L'application émet-elle des alertes audio là où elles sont utiles ?
11. L'utilisateur peut-il régler ou désactiver les commandes audio et vidéo ?
12. L'utilisateur peut-il modifier les polices par défaut pour l'impression et l'affichage à l'écran ?
13. L'utilisateur peut-il régler ou désactiver les affichages clignotants, rotatifs ou mobiles ?
14. Assurez-vous que la couleur n'est jamais utilisée comme seul moyen de transmettre des informations.
15. La mise en surbrillance reste-t-elle visible lorsque les couleurs système sont inversées ? Testez en modifiant les rapports de contraste.
16. Des transcriptions ou des sous-titres audio et vidéo sont-ils disponibles pour les utilisateurs sourds ou malentendants ?
17. Une formation est-elle proposée aux utilisateurs handicapés pour les aider à se familiariser avec l'application ?
18. Toutes les commandes interactives sont-elles accessibles, utilisables et désactivables à l'aide du seul clavier ?

Comment l'IA transforme les tests d'accessibilité

L'IA est reshaping Les tests d'accessibilité sont désormais réalisés de trois manières concrètes. Premièrement, les scanners d'apprentissage automatique analysent le DOM rendu conjointement avec des modèles de vision par ordinateur afin de détecter les problèmes que les outils basés sur des règles ne repèrent pas, comme des textes alternatifs inappropriés ou des combinaisons de couleurs qui ne fonctionnent pas correctement dans les mises en page réelles. Deuxièmement, l'IA générative suggère des solutions compréhensibles par l'humain, notamment des textes alternatifs plus pertinents, des messages d'erreur plus clairs et des attributs ARIA pour les composants personnalisés. Troisièmement, l'IA priorise les résultats en fonction de leur impact sur l'utilisateur, permettant ainsi aux équipes de concentrer leur budget sur les problèmes les plus importants. Des outils tels que Deque axe AI, Evinced, UserWay et Siteimprove intègrent désormais des fonctionnalités d'IA. L'IA ne remplace pas les tests manuels avec des lecteurs d'écran ni les études auprès d'utilisateurs en situation de handicap, mais elle réduit considérablement la charge de travail liée au tri manuel et contribue à intégrer l'accessibilité dès les premières étapes du cycle de développement.

Mythes sur les tests d'accessibilité

Voici quelques idées reçues courantes sur les tests d'accessibilité, ainsi que les faits qui y sont associés :

Mythe: Créer un site web accessible coûte cher.

Fait: Non. Prendre en compte l'accessibilité dès la conception, et effectuer des tests de base, permet de réaliser des économies par rapport à une mise aux normes a posteriori et de réduire les coûteux travaux de reprise.

Mythe: Transformer un site web inaccessible en un site accessible est une opération trop longue et coûteuse.

Fait: Il n'est pas nécessaire d'appliquer tous les correctifs en même temps. Commencez par les modifications qui ont le plus d'impact sur les utilisateurs handicapés et déployez les autres dans des versions ultérieures.

Mythe: L'accessibilité, c'est simple et ennuyeux.

Fait: Les pages peuvent encore être visuellement riches et àtractout en respectant les directives WCAG 2.2. Le W3C déconseille explicitement les versions uniquement textuelles et privilégie une expérience accessible unique pour tous.

Mythe: L'accessibilité est réservée aux utilisateurs aveugles et handicapés.

Fait: Le respect des consignes d'accessibilité améliore l'ergonomie globale et profite à tous les utilisateurs, y compris ceux qui utilisent des appareils mobiles, qui travaillent en plein soleil ou qui se trouvent dans des environnements bruyants.

FAQ