Lorsqu’il faut établir un nouveau produit au gouvernement, l’accessibilité n’est pas une possibilité, mais une nécessité.

Une partie du défi que présente le programme de boursiers de Code for Canada consiste à arriver dans un nouvel environnement et à devoir travailler dans des cadres stratégiques qui existent rarement dans le secteur privé, mais qui ont une incidence profonde sur les choix de produits que nous faisons au gouvernement.

Dans le cas particulier du projet de Boîte de réception pour la gestion – électronique (BRG-e), nous travaillons à l’intérieur de trois grands cadres stratégiques.

Loi sur les langues officielles

La Loi a été a été instaurée afin :

(a) d’assurer le respect du français et de l’anglais à titre de langues officielles du Canada, leur égalité de statut et l’égalité de droits et privilèges quant à leur usage dans les institutions fédérales, notamment en ce qui touche les débats et travaux du Parlement, les actes législatifs et autres, l’administration de la justice, les communications avec le public et la prestation des services, ainsi que la mise en œuvre des objectifs de ces institutions.

Cela signifie qu’en tant qu’équipe qui élabore un nouveau produit, nous avons le devoir de faire en sorte que les Canadiens francophones et anglophones puissent utiliser le produit. Nous sommes allés un peu plus loin en menant certaines de nos entrevues dans le cadre de la recherche sur les utilisateurs dans les deux langues officielles, et en offrant tous les documents aux participants dans les deux langues.

Étant donné que la BRG-e est une évaluation, nous avons aussi dû tenir compte du fait que les candidats ont le droit d’être évalués dans la langue officielle de leur choix, ou même dans les deux langues:

37 (1) Les examens ou entrevues, lorsqu’ils ont pour objet d’évaluer les qualifications visées à l’alinéa 30(2)a) et au sous-alinéa 30(2)b)(i), à l’exception de la langue, se tiennent en français ou en anglais, ou dans les deux langues, au choix du candidat.

Lors de la conception de la BRG-e, nous avons décidé de mettre en place un bouton permettant de basculer d’une langue à l’autre dans l’ensemble de la plateforme de l’outil d’évaluation des compétences (OEC). L’utilisateur peut passer d’une langue officielle à l’autre à tout moment sans perdre son travail, et ce, sans devoir demander un format spécial ou déclarer sa langue préférée à l’avance.

Loi canadienne sur l’accessibilité (C-81)

Jusqu’à ce que le projet de loi C-81 soit proposé, les évaluations de la Commission de la fonction publique étaient considérées comme des outils internes, et n’étaient donc pas assujetties aux mêmes normes sur l’accessibilité que les outils externes.

La BRG-e sera le premier outil conçu à la CFP en tenant compte de l’accessibilité. Contrairement à la pratique courante, les évaluations hébergées sur l’OEC n’exigeront pas la création par défaut d’un format adapté pour les candidats handicapés. Nous concevons l’OEC pour qu’il soit conforme aux Règles pour l’accessibilité des contenus Web 2.1, comme l’exigera la nouvelle loi, et nous faisons régulièrement l’essai de notre produit avec des utilisateurs réels pour nous assurer qu’il est compatible avec les lecteurs d’écran. Nous avons également établi un partenariat avec le programme d’Accessibilité, adaptation et technologie informatique adaptée (AATIA), qui contribuera à la formation des développeurs de la CFP, plus précisément à leur apprentissage de nouvelles façons d’assurer l’accessibilité de leur code.

L’un des motifs du choix de notre infrastructure technologique était de profiter des pratiques Web modernes en matière d’accessibilité qui sont soutenues par ReactJS pour les applications interactives. Cela nous a aidés à faire en sorte que les candidats puissent avoir accès à un certain nombre de paramètres de navigateur par défaut leur permettant, par exemple, de changer la taille et la couleur de la police, le Ministère ayant mentionné que les mesures d’adaptation les plus communément demandées portent sur ce genre de changements.

Protégé B / Stockage de données

Chaque fois qu’on développe une application qui exige qu’un utilisateur entre des données personnelles, il faut penser aux risques en matière de sécurité. Pour notre part, nous devons penser non seulement à ce que les utilisateurs entrent, mais à toute l’application.

Le contenu des tests et, par extension, les grilles de notation (la façon dont les tests sont notés) sont considérés comme des données Protégé B, qui exigent la prise de mesures de sécurité plus élevées que les renseignements permettant d’identifier les personnes (Protégé A) que les candidats saisissent quand ils passent un examen.

Cela a amené des défis intéressants sur la façon de stocker notre code et de concevoir nos machines, et sur le déploiement et la configuration de notre serveur. Concrètement, cela a posé des problèmes importants au moment de chercher un environnement moderne pour héberger l’application, car il n’existe pas à l’heure actuelle de services d’infonuagique sûrs pour les données Protégé B qui sont approuvés par le gouvernement du Canada.

On nous a demandé de suivre un bon nombre de politiques et de lignes directrices internes, et nous avons appris qu’il faut faire un véritable exercice d’équilibre pour assurer la conformité tout en mettant au point un produit qui utilise des éléments de conception intéressants et des outils Web modernes.

Nous avons construit le système de l’OEC à l’aide d’Aurora, un système de conception conçu pour correspondre à la normalisation des sites Internet de Canada.ca, par l’entremise de GCcollab.

Remerciements à tous eux chez le Le Service numérique canadien (notamment Sean, Stevie-Ray, Lucas and Meg!) pour nous aider à naviguer la politique entourant ce projet.