Pour en revenir à l’accessibilité par défaut et à la conception même du bâtiment, au début, nous avons mené des recherches auprès de fonctionnaires qui utilisent des technologies d’assistance afin de comprendre les formats de sortie qu’ils utilisent. Le gouvernement utilise Excel et PDF, mais cela n’a rien de surprenant. L’utilisation de ces programmes pose certaines difficultés. Nous avions un fonctionnaire qui, en raison de son ordinateur, mettait 5 minutes pour ouvrir un fichier PDF volumineux. Il avait également des difficultés à naviguer dans les fichiers Excel. 

Les premières données que nous avons fournies étaient donc au format HTML. Ainsi, quel que soit le format dans lequel vous obtenez vos données, il existera toujours un format HTML plus facile à naviguer et compatible avec la technologie d’assistance que vous utilisez. 

Quelques fonctionnaires souhaitaient disposer immédiatement du format CSV. Nous avons commencé par le format HTML en raison des premières recherches que nous avons menées en tant que fonctionnaires. Le format CSV existe également dans Excel, mais le format HTML s’est révélé à maintes reprises être le plus accessible pour consulter différents formulaires et différentes façons de naviguer dans les données.

1. Proposition d’une nouvelle fonctionnalité : Cela commence par des wireframes ou fichier de structure. Nous utilisons un outil appelé Figma, qui est un outil collaboratif. Un designer propose une nouvelle idée de fonctionnalité en fonction des décisions prises concernant le produit, etc.
   
2. Réflexion de l’équipe sur la conception accessible : Dès le début, les autres développeurs et moi-même pouvons commencer à discuter de la conception. Par exemple, lorsque les utilisateurs rencontrent des difficultés, nous essayons de réfléchir à la facilité d’utilisation, à l’accessibilité, de manière globale, afin de pouvoir ajouter des commentaires à la conception et commencer à nous poser des questions telles que : Que se passe-t-il si l’utilisateur clique ici ou s’il est dérouté par cela ? Avez-vous pensé à ce contraste, etc. Cela aide vraiment, car cela nous permet d’engager la conversation avec les concepteurs et les développeurs.
   
3. Réalisation de tests d’accessibilité manuels à l’échelle de l’équipe afin de prendre en compte un maximum de perspectives : Ensuite, lorsque les développeurs commencent à construire, nous savons déjà ce que nous construisons. Et une fois que nous sommes prêts à tester, nous avons des tests automatisés qui vérifient la conformité aux WCAG 2.1 et d’autres choses. Ces tests s’exécutent automatiquement par défaut avec notre processus de compilation une fois que tout est prêt pour les tests.
   
4. Création et tests d’accessibilité automatiques : Ensuite, des tests manuels sont effectués par moi-même et surtout par d’autres membres de l’équipe qui ne sont pas aussi proches de la fonctionnalité. En tant que développeur, si je crée quelque chose et que je le regarde fixement, je vais toujours avoir une vision tunnel. À ce stade, je vais passer à côté de beaucoup d’autres choses, donc d’autres personnes viennent m’aider à tester, ce qui est très utile. Mais oui, pendant ce temps, j’ai ma propre petite liste mentale, fruit de mes années d’expérience, des choses à vérifier, comme par exemple : est-ce que tout est navigable au clavier ? Est-ce que cela va au-delà de l’accessibilité, par exemple, comme un dispositif de pointage tactile pour les téléphones mobiles, est-ce que la cible à cliquer est suffisamment grande pour être atteinte. Juste des choses basiques comme ça. Et puis, une fois que c’est fait, on peut peut-être itérer un peu plus sur la fonctionnalité si on a de nouvelles idées, revenir au processus de conception, regarder le Figma, et avancer. 
   
5. Tests utilisateurs et amélioration de l’accessibilité : Ensuite, si nous le pouvons, nous demandons à de vrais utilisateurs de tester notre produit, Fable pour ce service, je crois, à Toronto. Vous les connaissez. D’accord. Oui, ils le testent, puis nous donnent une note. Et en fonction de leur rétroaction, nous itérons à nouveau sur les changements et nous avons en quelque sorte une boucle cohérente, et oui, c’est en gros une vue d’ensemble de notre processus de développement. Ce que vous venez de décrire correspond exactement à ce que nous envisageons lorsque nous parlons d’accessibilité dès la conception, car cela a été intégré à notre processus dès le début, de la planification à la programmation, en passant par les tests. Et c’est un cycle. Je pense donc que vous venez de décrire ce qu’est l’accessibilité dès la conception dans la réalité.

Ce blog pourrait vous intéresser, « Comment nous concevons Formulaires GC : nos quatre approches accessibles ».

Donc, d’une manière générale, nous avons une liste de contrôle de base (le W3C fournissez, en anglais), qui peut vous guider. Donc, tant que nous atteignons ces objectifs, nous avons fait un pas vers la conformité. 

Ensuite, bien sûr, il y a le WCAG (en anglais) qui vous permettent d’atteindre la conformité. Et c’est très bien. Mais le problème, c’est que les WCAG ne cherchent pas à résoudre le fait qu’un site web peut être à la fois conforme aux WCAG et inaccessible. 

Par exemple, il y a beaucoup d’éléments subjectifs dans WCAG qui sont laissés à l’appréciation du concepteur ou du développeur, comme le texte alternatif ou le texte des liens. Par exemple, si tous les liens disent « cliquez ici », combien d’utilisateurs aiment parcourir un plan ? Ce n’est pas très utile. Ils ne peuvent vraiment pas l’utiliser sans parcourir le contenu et comprendre où mène chaque lien. Et certains de ces liens peuvent même avoir des conséquences. Par exemple, si vous cliquez sur un lien, cela peut envoyer quelque chose, et les utilisateurs peuvent alors avoir peur de ne pas pouvoir l’utiliser. Il existe de nombreux exemples de ce type.

Luna : C’est fantastique, car vous venez de montrer aux gens que le fait de respecter une norme ne signifie pas pour autant que l’accessibilité est garantie.

Cela fait environ 5 ans que nous développons le produit, que nous effectuons des recherches et que nous élaborons la solution. Nous n’avons pas toujours disposé d’une grande expertise en matière d’accessibilité au sein de l’équipe. L’une des premières mesures prises par le SNC a donc été de consacrer le vendredi au développement professionnel. Nous donnons ainsi aux employés le temps d’approfondir des sujets liés à l’accessibilité, à la sécurité, voire des domaines qui les intéressent et qui pourraient améliorer le produit à un stade ultérieur.

C’est bien connu, Gmail est né de ces périodes de développement chez Google. Nous essayons d’adopter une approche similaire. Voilà. Et puis, puisque Pete est parmi nous aujourd’hui, nous avons toute une équipe de développeurs qui se trouvent à différentes étapes de ce processus et qui testent manuellement, que ce soit avec VoiceOver, Jaws ou NVDA, pour essayer de vérifier ce qu’ils ont créé. 

Il s’agit donc de donner aux gens le temps d’étudier et d’apprendre. Demandez aux gens de poster ce qu’ils recherchent ou apprennent le vendredi. Mais en gros, nous partageons l’expertise au sein de l’équipe, nous en faisons la responsabilité de chacun et nous donnons aux gens le temps d’en apprendre davantage sur le sujet.

Nadine : Je vais vous expliquer brièvement pourquoi j’utilise les formulaires GC.

La première fois que je les ai utilisés, c’était dans le domaine des ressources humaines. Dès que vous avez passez en mode protégé B, souvent, si vous devez nommer quelqu’un à un poste en utilisant une gestion des talents ou dans le cadre d’un processus non annoncé, vous devez établir une Énoncé des critères de mérite et fournir une justification. Et vous savez, ces anciens formulaires avec un tableau dans Word ? Ils ne fonctionnent pas et ne sont pas accessibles.

Maintenant avec Formulaires GC, [nos formulaires RH] est accessible. Je peux y ajouter un Énoncé des critères de mérite, il est protégé B, et je peux remplir les informations dont j’ai besoin et l’envoyer aux RH. Ils peuvent ajouter des commentaires directement dans le formulaire, ce qui facilite grandement les choses et rend le tout accessible, ce qui est fantastique.

Luna : Les processus RH sont généralement inaccessibles. Ils sont tellement complexes. J’ai rempli beaucoup de ces évaluations d’Énoncé des critères de mérite. En tant que gestionnaire, je sais combien de temps il m’a fallu pour parcourir ces tableaux à l’aide d’un lecteur d’écran. C’est donc incroyable. Et c’est incroyable de penser que ceux qui viendront après nous auront la tâche de plus en plus facile grâce à des initiatives comme celle-ci.

Nous travaillons sur une fonctionnalité qui permettra aux utilisateurs d’ajouter des pièces jointes à leurs formulaires. Ainsi, si une personne doit joindre, par exemple, un permis de conduire ou une pièce d’identité, vous pourrez récupérer ces données auprès des membres du public qui remplissent les formulaires et les intégrer dans Formulaires GC. 

Cette année, nous cherchons à améliorer la modification des formulaires après leur publication. L’un des inconvénients actuels du produit est qu’il est un peu difficile de modifier un formulaire. Une fois que vous l’avez publié, vous devez le supprimer, puis le republier, ce qui n’est pas idéal. 

Nous cherchons également à corriger un autre petit inconvénient cette année, qui consiste à créer un moyen pour les équipes de gérer plusieurs formulaires avec des rôles différents pour différentes personnes. 

Explorez le feuille de route du produit Formulaires GC !