Comment nous concevons Formulaires GC: nos quatre approches accessibles

1. Configurez des tests automatisés pour détecter tout problème d’accessibilité afin de diminuer la charge de travail manuel et d’augmenter la capacité de l’équipe à se développer sur le plan professionnel et à appuyer la croissance de son produit.

Pour nos tests automatisés, nous dépendons fortement du moteur de test d’accessibilité Axe (texte en anglais) source libre. Axe s’intègre parfaitement à notre suite de test Cypress, ce qui nous permet d’effectuer des tests sur des pages Web de la même façon qu’un·e utilisateur·rice interagirait avec ces pages. Si nous n’avions pas de configuration automatique capable de détecter ces problèmes, nos développeur·euse·s auraient une charge de travail manuel supplémentaire et se verraient limité·e·s dans leur capacité à développer le produit.

2. Utilisez un linter d’accessibilité pour identifier les problèmes lorsque vous écrivez le code. C’est un peu comme un vérificateur d’orthographe. Le linter vous permettra d’économiser du temps de révision du code.

Nous ne comptons pas seulement sur le moteur d’Axe pour effectuer nos tests automatisés. Nous misons aussi sur des outils qui tentent de repérer les problèmes pendant que nous écrivons le code de notre application, ce qui nous permet d’économiser du temps de réécriture après le test (parce que nous aurons déjà détecté les problèmes à l’avance).

Par exemple, nous utilisons le plug-in jsx-a11y ESLint pour nous aider à repérer les problèmes pendant la conception de notre application Web. Certain·e·s de nos développeur·euse·s vont même plus loin en utilisant le linter d’accessibilité d’Axe (texte en anglais), qui agit comme un vérificateur d’orthographe, mais pour repérer les problèmes d’accessibilité, comme une extension dans VS Code, ce qui permet d’effectuer une analyse statique d’accessibilité pour le texte HTML, Angular, React, Markdown et Vue.

3. Préparez votre fichier pour le test d’accessibilité et ajoutez quelques lignes de code (vous trouverez ci-dessous les instructions détaillées correspondantes).

Pour configurer le fichier utilisé afin de réaliser des tests automatisés, vous devez ajouter les logiciels à vos dépendances de développement existantes (les autres logiciels utilisés pour les tâches de développement, pas seulement ceux utilisés pour les tests). Ajoutez-les à l’aide d’un gestionnaire de paquets : cet outil assure le suivi de tous les logiciels présents sur votre ordinateur, vous permettant d’utiliser les nouveaux paquets logiciels destinés aux tests dans le cadre de votre automatisation.

Voici comment (pas à pas) :

1. À l’aide des gestionnaires de paquets yarn ou npm recherchez et ajoutez les paquets logiciels suivants à vos dépendances de développement : cypress, axe-core et cypress-axe.

2. Ajoutez une ligne de configuration simple dans Cypress : importez « cypress-axe »;

Texte de remplacement : Capture d’écran de la configuration de ligne dans Cypress. Ajout de “import “cypress-axe”;” sous “// Import Axe-Core library”.

3. Configurez vos options Axe dans le fichier de test (lisez la documentation API d’Axe pour obtenir des instructions).

Texte de remplacement : Capture d’écran de la façon dont l’équipe Formulaires GC a configuré ses options Axe en testant pour : “wcag21aa”, “wcag2aa”, “best-practice” et “section508”.

Comme vous pouvez le voir dans notre fichier de test Cypress sur GitHub, la configuration d’Axe avec Cypress en vue de tests d’accessibilité automatisés se fait en ajoutant à peine trois lignes de code :

1. cy.visit(path);
2. cy.injectAxe();
3. cy.checkA11y(null, A11Y_OPTIONS);

Texte de remplacement : Capture d’écran des trois lignes de code dans le fichier de test Cypress de Formulaires : “cy.visit(path); cy.injectAxe(); cy.checkA11y(null, A11Y_OPTIONS);”.

1. Former les développeur·euse·s sur au moins une technologie d’assistance pour combler les lacunes existantes entre l’apparence et la fonctionnalité d’une application Web.

Les développeur·euse·s mettent souvent l’accent sur l’aspect visuel d’une application Web ou sur la version de cette application destinée aux personnes voyantes. Il se peut que davantage d’efforts soient déployés pour soigner l’apparence d’un composant HTML et d’une interaction que pour veiller à ce que le composant en question respecte les meilleures pratiques en matière de présentation HTML et de balisage.

Nous encourageons vivement nos développeur·euse·s à se familiariser suffisamment bien avec au moins une technologie d’assistance (NVDA, JAWS, VoiceOver, etc.) pour utiliser une application Web et interagir avec cette dernière. Lorsque nous avons demandé à nos développeur·euse·s d’utiliser Formulaires GC à l’aide d’une technologie d’assistance, il s’est produit quelque chose d’intéressant : la frustration les a envahi·e·s. Cet exercice a changé leur état d’esprit et les a amené·e·s à mettre l’accent sur l’expérience utilisateur au lieu de donner la priorité à un critère de réussite spécifique relatif aux normes WCAG. Il a permis de déterminer les points à améliorer, comme le contexte qu’il fallait étoffer.

2. Mettre à jour les processus de développement de l’équipe pour attribuer des responsabilités liées aux vérifications d’utilisabilité.

Nous avons incorporé une nouvelle règle à notre processus de développement : désormais, chaque développeur·euse est responsable de l’utilisabilité des composants qu’il ou elle crée ou modifie. Il lui faut veiller à ce que les composants soient accessibles à la fois pour les personnes voyantes et pour celles utilisant des technologies d’assistance.

Cette mise à jour de nos processus a rapidement mené à un changement dans l’ordre des priorités. Au lieu de veiller à réaliser des ombres parfaites au niveau visuel, par exemple, les développeur·se·s réfléchissent aux manières d’améliorer les interactions possibles avec les composants créés. Tout cela a beaucoup amélioré l’utilisabilité des interactions complexes de nos applications Web, comme le téléversement d’un fichier dans un formulaire Web ou encore la soumission d’un formulaire Web après une période déterminée (prévention des pourriels).

Conseils concernant la recherche en conception au sein du GC

Nous avons créé des ressources pour vous aider à planifier vos méthodes de test et à mener des entrevues de recherche. Nous offrons également un service pour vous aider à générer des formulaires de confidentialité et de consentement pour les séances de recherche.

Comment la recherche en conception a amélioré l’expérience offerte par Formulaires GC

Lors du développement de Formulaires GC, nous avons mené une recherche en conception pour mettre à l’épreuve nos hypothèses en matière d’accessibilité. Nous avons notamment réalisé deux activités de recherche auprès de 12 personnes employant des technologies d’assistance pour leur utilisation des services gouvernementaux. 10 personnes ont rempli un formulaire factice et ont fourni une rétroaction écrite sur cette expérience. Nous avons également demandé à 2 personnes de décrire leur expérience alors même qu’elles parcouraient l’outil et remplissaient le formulaire, ce qui nous a fourni des renseignements plus détaillés sur leur parcours.

Chaque personne participante a utilisé la technologie d’assistance et le navigateur de son choix :

• Dragon NaturallySpeaking avec Chrome ;
• JAWS avec Edge ;
• le lecteur d’écran intégré de Mac avec Safari ;
• NVDA avec Chrome ;
• NVDA avec Internet Explorer 11 ;
• Grossissement à l’écran avec Firefox ;
• Clavier à l’écran avec Chrome ;
• Clavier à l’écran avec Internet Explorer 11 ;
• Contrôle vocal avec Firefox ;
• VoiceOver avec Safari ; et
• ZoomText avec Edge.

L’une des conclusions de ces activités est que les gens ne connaissent pas la signification du terme « Alpha ». La présence de ce terme dans notre bannière portait donc à confusion: « Alpha: Ce site changera au fur et à mesure que nous testerons des idées. »

« Je trouve que le terme alpha n’a pas vraiment sa place ici, car je ne vois pas à quoi il pourrait se rapporter ni à quel endroit du formulaire il serait pertinent » — une personne participant à la recherche en conception

Il était évident que si les termes « Découverte », « Alpha », « Bêta » et « Production » avaient du sens pour nous (il s’agit d’étapes de développement agile pour le lancement de produits), ils n’étaient pas nécessairement aussi clairs pour les personnes utilisant Formulaires GC. Nous avons donc supprimé ces termes pour éliminer toute distraction inutile et pour réduire la confusion parmi les utilisateur·rice·s.

Conseil basé sur notre expérience : la liste de contrôle liée aux normes WCAG est trop volumineuse pour l’avoir en tête à tout moment. Essayez de diviser les exigences en tâches plus restreintes et d’intégrer ces dernières à différentes parties des processus liés à vos produits.

Pour pousser les gens à réfléchir aux expériences accessibles, nous avons des espaces réservés dans chaque récit utilisateur, que nous adaptons à chaque tâche.

Prenons un exemple : lorsque nous développons un nouveau composant (comme un bouton permettant de téléverser des fichiers), nous veillons à ce qu’il soit possible de réaliser la navigation à l’air du clavier et à ce qu’un lecteur d’écran puisse fournir les renseignements nécessaires pour le téléversement du document. Nous avons intégré la vérification de navigation à la définition de produit fini et aux critères d’acceptation.