Découverte de l'engagement de Rocket Software en matière d'accessibilité

Chez Rocket Software, notre mission va bien au-delà de la simple fourniture de solutions innovantes. Chaque aspect de notre travail est guidé par nos valeurs fondamentales: l’empathie, l’humanité, la confiance et la bienveillance. Et, au sein de ces valeurs, Rocket Software accorde une importance capitale à l’accessibilité. Quels que soient la technologie, le système ou l’environnement informatique, nous nous engageons à fournir des solutions qui fonctionnent pour tous.

Pour en savoir plus sur notre approche de l'accessibilité de nos solutions, nous avons rencontré Brian Kunz, architecte logiciel principal chez Rocket Software.

Brian possède plus de 20 ans d'expérience dans la conception et le développement d'applications front-end. Il s'est pleinement investi dans l'accessibilité en 2024, en dirigeant le projet de création des composants d'accessibilité fondamentaux nécessaires à la nouvelle interface utilisateur de Rocket Content Services, Rocket Content Explorer.

Comment définiriez-vous l’accessibilité d’un point de vue logiciel et développement ?

D'un point de vue logiciel, il s'agit de faire fonctionner le clavier avec l'application. L'interface clavier est le moteur de toute technologie d'assistance comme les lecteurs d'écran. Si un élément doit être manipulé à l'écran, il doit pouvoir l'être par une série de commandes clavier ; ces commandes sont courantes et connues des utilisateurs finaux. En tant qu'utilisateur final, je dois pouvoir tout faire dans une application sans jamais toucher la souris.

Nous nous concentrons tellement sur la création d’applications pilotées par la souris: c’est cet état d’esprit qui doit changer.

Du point de vue du développement, l'accessibilité est une compétence que la plupart des développeurs ne possèdent pas vraiment. C'était vrai pour moi, et pour tous les développeurs qui ont travaillé sur notre nouveau projet d'interface utilisateur.

Les pratiques agiles expliquent probablement en partie pourquoi l'accessibilité n'est pas davantage prise en compte. Les développeurs se sont traditionnellement concentrés sur l'apparence de l'application et le bon fonctionnement de la souris ; c'est le seuil à partir duquel une fonctionnalité est considérée comme terminée. Une fois cette fonctionnalité terminée, on passe à la suivante, car l'objectif est d'en ajouter autant que possible.

Ainsi, l'accessibilité est victime du temps au profit de la « réalisation d'une fonctionnalité ». Ce n'est pas que les développeurs ne souhaitent pas créer d'applications accessibles, mais nous avons négligé l'importance du codage pour l'accessibilité, car cela demande du temps supplémentaire. L'attention portée à la gestion est également un facteur, car le codage pour l'accessibilité exige un peu plus de temps et d'efforts de la part de tous les acteurs.

L'accessibilité est parfois une compétence secondaire dont on ne parle ni ne promeut, mais c'est un aspect que nous souhaitons améliorer. Nous souhaitons que l'accessibilité fasse partie intégrante de tout projet.

En termes simples, pouvez-vous expliquer les quatre principes des Règles pour l’accessibilité du contenu Web (WCAG) et expliquer pourquoi ils sont importants ?

Il existe un acronyme pour cela: POUR. Cela signifie Perceptible, Exploitable, Compréhensible et Robuste.

Commençons par la perceptibilité. C'est ainsi que l'on crée une application complexe, à la fois visuellement attrayante et magnifiquement conçue, de manière à ce que les relations entre les éléments visuels à l'écran soient communiquées aux personnes non aveugles. Par exemple, comment un utilisateur sait-il qu'un bouton affiche un nouveau panneau d'informations lorsqu'il est pressé ? Ou, lorsqu'une opération se produit et que l'écran change, même subtilement, comment ce changement est-il communiqué à l'utilisateur autrement que visuellement ? La perceptibilité consiste à représenter mentalement l'endroit où l'utilisateur se trouve dans une application et sa structure.

Lorsqu'on parle d'opérabilité, cela signifie que tout élément manipulable doit être accessible via le clavier. Nous reconnaissons également que les technologies d'assistance incluent des options telles que la reconnaissance vocale pour les utilisateurs souffrant de déficiences motrices, car les claviers peuvent ne pas être une option. Opérabilité signifie que tout ce qui peut être manipulé, comme un bouton, une liste déroulante, une saisie de texte, etc., doit être accessible via le clavier ou la commande vocale. Cela crée des défis uniques pour les opérations traditionnellement effectuées à la souris, comme le glisser-déposer et le dimensionnement. Lors du codage axé sur l'accessibilité, nous devons considérer la souris non pas comme le principal moyen de modification, mais comme un outil parmi d'autres. Nous ne voulons pas exclure des fonctionnalités telles que le glisser-déposer simplement parce qu'un utilisateur ne peut pas utiliser de souris.

Ensuite, il y a la compréhension. Garantir la compréhension d'un élément signifie garantir que chaque widget fonctionne comme prévu par l'utilisateur. Les technologies d'assistance identifient les éléments à l'écran et diffusent des messages tels que « bouton » ou « tableau » lors de la navigation. Ce type de description simple explique à l'utilisateur comment manipuler cet élément et comment utiliser les raccourcis clavier courants fournis par les technologies d'assistance. Par exemple, si un utilisateur sait que l'élément sélectionné est une zone de liste déroulante, il sait qu'il peut l'activer avec la touche Entrée, la flèche vers le bas, etc. En tant que développeurs, nous devons nous assurer que les activités et l'ordre des activités pour un élément particulier correspondent à l'expérience attendue d'un utilisateur utilisant des technologies d'assistance. Dans le cas contraire, vous créez un scénario confus pour l'utilisateur et une technologie inutilisable.

Enfin, nous en arrivons à la robustesse. Il existe des conventions et des attributs de codage que les développeurs doivent utiliser pour garantir la compatibilité de leurs logiciels avec toutes les technologies d'assistance. Les normes WCAG constituent le contrat que nous, développeurs, respectons et qui est également utilisé par les développeurs de technologies d'assistance. Tant que les deux équipes de développement contribuent à leur mission, nous obtenons une expérience fonctionnelle et accessible pour nos utilisateurs finaux. Nous codons selon une norme, et non pour une technologie d'assistance spécifique.

La robustesse implique la conception de logiciels compatibles avec divers agents utilisateurs et technologies d'assistance. Elle permet également à l'utilisateur de se déplacer rapidement dans l'application en quelques clics. Si les développeurs ont bien conçu une application, celle-ci permet à l'utilisateur, muni d'un clavier, de naviguer rapidement à l'écran sans avoir à parcourir chaque commande ou élément à l'aide de la touche Tab.

Pour les personnes daltoniennes, comment pouvez-vous garantir que les directives de contraste des couleurs sont respectées dans la conception d'un site Web ou d'une application et quels types d'outils pourriez-vous utiliser ?

Les WCAG recommandent un ratio de 4,5 pour 1 pour les couleurs de premier plan et d'arrière-plan. Il est difficile de décrire précisément ce que cela signifie, mais cela traite des nuances de couleurs entre le premier plan et l'arrière-plan dans l'application.

Comment déterminer cela ? Cela commence dès le début de la conception. Nous avons utilisé un outil appelé Figma pour créer des wireframes riches pour l'application. Cet outil nous permet de garantir que la conception elle-même respecte le rapport de contraste des couleurs. Nous voulons éviter de concevoir quelque chose que nous trouvons beau et d'y consacrer du temps et des ressources, pour finalement nous rendre compte qu'il ne passera pas les contrôles de contraste des couleurs.

Nous utilisons également un outil dans notre navigateur, « Accessibility Insights », un plugin que vous pouvez activer pour chaque page et qui vous indiquera tout non-respect du ratio mentionné précédemment. Cet outil permet également de générer l'application en niveaux de gris, ce qui est une excellente façon de visualiser le développement: vous pouvez ainsi supprimer complètement la couleur de l'équation, observer le contraste des niveaux de gris et évaluer la facilité de distinction des éléments.

Quelles stratégies avez-vous utilisées pour éduquer et promouvoir les meilleures pratiques en matière d’accessibilité parmi les équipes de développement et de conception ?

La spécification WCAG pourrait vous effrayer. C'est un document volumineux, très technique et difficile à assimiler. Mais une fois passé le premier cap, c'est très simple à comprendre. C'est ce qui m'est arrivé au cours de mon parcours. Je savais que je devais le faire, et c'était la bonne décision à prendre.

J'ai découvert qu'une fois cette compréhension acquise, j'ai développé un nouvel enthousiasme pour l'accessibilité. Coder de cette manière renforce considérablement nos applications, et ce n'est finalement pas si complexe… et on commence à se demander pourquoi on a évité ces stratégies de codage jusqu'à présent.

Mon objectif est de faire du codage accessible une seconde nature pour les développeurs front-end, afin qu'il ne soit pas perçu comme une tâche superflue, difficile ou inutile. J'ai aidé notre équipe de développement en fournissant des schémas de base sur les conceptions visuelles pour la prise en compte de l'accessibilité. En tant qu'expert de l'équipe, j'ai pu dire: « Lorsque vous créez cet écran, tenez compte de ces aspects et de ces autres éléments pour l'accessibilité. » Ils ont appliqué ces pratiques lors de la finalisation de leur codage, et nous l'avons ensuite évalué lors de notre processus standard de revue de code. Il y avait toujours quelques retouches à effectuer, car c'était nouveau pour tout le monde ; nous développions de nouvelles compétences et chacun apprenait. Nous avons donc testé et peaufiné le code jusqu'à obtenir l'expérience souhaitée.

Fort de cette expérience, j'ai créé une série de vidéos de formation progressive, accessibles à tous les Rocketeers souhaitant intégrer l'accessibilité. J'ai généré près de 5 heures de contenu ; cela ne vous prendra pas beaucoup de temps. Ces vidéos offrent une introduction aux concepts de base et permettent d'apprendre à les mettre en pratique grâce à un petit exemple d'application.

Mon objectif est de dissiper les craintes liées à l'adoption des normes WCAG en démontrant leur simplicité. De plus, nos équipes ont développé une bibliothèque de widgets d'interface utilisateur qui gèrent déjà la plupart des aspects de l'accessibilité. Cela aidera les autres équipes à développer de meilleurs produits grâce à ces widgets. Elles n'auront pas à se soucier de l'accessibilité de ces widgets, car ils les gèrent déjà.

Auriez-vous des conseils ou des astuces à partager avec les développeurs ou les équipes qui se lancent dans un parcours d’accessibilité ?

Mon conseil est d'utiliser HTML5 comme prévu. Vous bénéficiez ainsi d'une grande accessibilité gratuite. Ensuite, examinez les éléments de base lorsque vous codez pour une conception visuelle.

Si un élément représente une liste de contenu, utilisez les éléments de liste HTML5. Si un élément se comporte comme un bouton, transformez-le en bouton. Si vous présentez des données tabulaires, utilisez les éléments de tableau, car les technologies d'assistance fourniront des informations sémantiques à leurs utilisateurs si vous utilisez ces éléments de base. En tant que développeurs, nous avons tendance à utiliser des conteneurs génériques, stylisés pour ressembler à quelque chose de spécifique, puis à leur appliquer manuellement des gestionnaires de clics. C'est la solution de facilité: cela crée un élément esthétique et cliquable à la souris, mais qui n'a aucun sens pour les utilisateurs de technologies d'assistance. L'utilisation des éléments de base HTML5 vous apportera au moins la moitié de ce dont vous avez besoin.

Côté ressources techniques, il existe une page dédiée aux modèles. C'est grâce à elle que j'ai tout compris. Cette page propose des spécifications pour chaque type de widget: exemples, exemples de code, spécifications de clavier pour divers éléments, etc. Vous pouvez même utiliser une technologie d'assistance comme JAWS pour tester les widgets d'exemple et voir comment JAWS gère les choses. C'était une excellente façon pour moi de comprendre, lorsque j'ai commencé à apprendre, que coder pour l'accessibilité n'était pas si compliqué ; je n'ai eu qu'à modifier quelques éléments pendant le codage.

Quelle est la chose la plus intéressante que vous ayez apprise en travaillant sur un projet axé sur l’accessibilité ?

La réponse est simple: je perçois l’empathie, valeur fondamentale de Rocket Software, dans tout ce que nous faisons. Nous souhaitons que nos logiciels soient accessibles à tous. Comme je l’ai mentionné précédemment, dans notre environnement de développement agile, nous privilégions la rapidité d’exécution pour la mise en œuvre d’une fonctionnalité, ce qui peut nous amener à développer des applications excluant certains utilisateurs. Ce n’est pas intentionnel et il n’y a aucune malice, mais il est facile d’oublier les personnes en situation de handicap et de ne pas tenir compte de leur expérience ni des difficultés qu’elles peuvent rencontrer lors de l’utilisation de nos logiciels.

Nous devons changer notre approche pour tout ce que nous réalisons sous le nom de Rocket Software. Il s'agit de prendre en compte la diversité des besoins de nos utilisateurs et de ne pas créer d'outils exclusifs, même si cela implique un délai de développement et de test légèrement plus long. C'est pourquoi je souhaite que les pratiques de codage accessible deviennent un réflexe pour nos développeurs, afin qu'ils ne se disent même plus « Je fais ça pour l'accessibilité », mais que ce soit un principe fondamental du codage pour tout projet.

L'avenir est prometteur. Les nouvelles fonctionnalités que nous avons mises en place offrent un potentiel considérable. J'étudie actuellement comment utiliser un outil comme Rocket^® Content Smart Chat pour faciliter l'interaction avec le contenu d'une application, et pas seulement avec l'application elle-même. Par exemple, si nous présentons une image à un utilisateur, Rocket^® Content Smart Chat pourrait-il lui fournir un résumé de l'image, en précisant par exemple: « Ceci est une image de XYZ » ? Ou encore, un résumé d'un document, par exemple: « Ce document est un reçu pour des matériaux achetés. » Ce genre de fonctionnalité permettrait de gagner du temps. Les utilisateurs n'auraient plus besoin de lire l'intégralité du document pour se rendre compte qu'il ne s'agit pas de celui qu'ils recherchent.

Au lieu de cela, ils reçoivent ce résumé rapidement et peuvent ensuite passer à la tâche suivante. Je pense que nous pouvons faire encore plus en utilisant les technologies de pointe pour améliorer encore davantage notre expérience accessible.

C'est passionnant pour moi et je suis très fier de voir que nous sommes à l'avant-garde de ce type d'initiative en interne. Proposer cette expérience WCAG aux utilisateurs est une véritable révolution.

Découvrez les toutes nouvelles fonctionnalités de Rocket Content Services .