Le progrès de XWiki en matière d'accessibilité : Un chemin à suivre

28 oct. 2024 5 min read

Écrit par

Adina Milica

, Graphiste et conceptrice UI/UX

Nous sommes tous temporairement capables.

Je suis tombée sur cette citation alors que je réfléchissais à des idées pour cet article.

Mon idée initiale pour commencer l'article était la très évidente « Prenons une statistique ». Bien que prévisible pour un article sur l'accessibilité, la statistique « 1 personne sur 6 dans le monde souffre d'un handicap important » était factuelle, directe et semblait fonctionner.

Lorsqu'un collègue nous a fait part de la citation ci-dessus, toutes les statistiques que j'avais trouvées ont commencé à s'estomper. Bien qu'il s'agisse d'une phrase douce-amère et assez poétique... pourquoi la citation a-t-elle fait passer les faits au second plan, si rapidement ?


Se peut-il que, du point de vue d'une personne physiquement apte, seule l'image légèrement égoïste de la perte de cette aptitude la fasse réellement réfléchir à l'accessibilité ?


J'ai ressenti le besoin de le nier, et vous l'avez peut-être ressenti aussi, mais soyons honnêtes...

Il y a une différence entre :

  • défendre quelque chose quand on a « plus de temps libre » ou « assez de ressources pour le faire » et...
  • penser réellement à l'accessibilité comme une mission personnelle, continue et nécessaire tout au long de la vie.

Nous sommes tous temporairement capables. ❞ Oui, mais aujourd'hui, il ne s'agit pas de parler de nous-mêmes à l'avenir.

Il s'agit de toutes les personnes qui, en 2024, se heurtent encore à des obstacles pour accéder aux connaissances numériques, simplement parce qu'elles souffrent d'une certaine forme de handicap.

  • Ce sont des jeunes qui commencent à apprendre tout ce qu'il y a à savoir.
    Ce sont des adultes qui travaillent dur chaque jour.
    Ce sont des personnes âgées qui essaient de profiter de leur retraite.

L'image

Disons-le autrement :

Il semble que même en objectivant les êtres humains de la manière la plus capitaliste possible, nous ne soyons toujours pas en mesure d'influencer les sites web et les équipes informatiques pour qu'ils répondent aux besoins les plus élémentaires de ces personnes.

Même lorsque l'on passe au « bon côté » du développement des logiciels, à savoir le monde des logiciels open-source, il est douloureux de le dire : nous devrions en faire (beaucoup) mieux.

Un retour sur un événement open-source de cette année m'a rappelé qu'un quart de la salle est parti instantanément après que le titre de la présentation a été révélé : Accessibilité du Web et soutenabilité environnementale avec les SGC populaires.

Vous pensez peut-être que je blâme les développeurs qui sont partis, mais ce n'est pas le cas. Après tout, je comprends. Ils veulent très probablement apprendre des choses qui peuvent faire avancer leurs connaissances et, par conséquent, leur parcours dans l'open-source. Si les développeurs voient que l'objectif de leur groupe n'est clairement pas l'accessibilité... eh bien, la vie est courte, le temps est limité, ils se concentreront sur d'autres choses « plus pertinentes ».

Vous voyez... c'est un problème de vision, mais de la part des personnes qui n'ont pas besoin de lunettes ou de lecteurs d'écran. 🔍

D'accord, mais quelle devrait être cette vision ?

L'accessibilité ne devrait pas être un rêve, mais une fonctionnalité par défaut.

Le produit open-source XWiki a vu le jour en 2004 et s'est développé lentement pendant 20 ans. Alors que nous n'avions pas les moyens à l'époque de tout construire selon nos propres idéaux, les choses ont changé au cours des dernières années. Cela peut paraître pompeux, mais nous savions depuis le début qu'il était de notre devoir, en tant que créateurs de logiciels de partage de connaissances open source, de libérer le savoir dans le sens le plus vrai du terme : éliminer tous les obstacles qui s'y opposent.

Cela signifiait évidemment :

  • consacrer du temps et des ressources à notre feuille de route 🕰
  • intégrer de nouvelles personnes 👩‍💻
  • faire des recherches et utiliser des outils qui pourraient nous permettre d'identifier les problèmes plus rapidement 📚

...tout cela pour accélérer notre progression vers l'atteinte de notre objectif : le WCAG 2.2 (niveau AA) du W3C.

Les détails de notre mission

Quelle est notre mission, comment avons-nous réussi à la mener à bien et comment cela se passe-t-il ?

Alimenter nos moteurs open-source 🚀

L'équipe produit de XWiki SAS a toujours fait des efforts conscients pour écrire du code qui améliore l'accessibilité du projet.

Les projets qui ont contacté notre équipe pour un travail sur mesure clairement axé sur l'accessibilité ont joué un rôle de catalyseur dans notre mission. Ils nous ont permis de prévoir ce dont nous avons besoin pour atteindre ces objectifs – du temps et du personnel –, ce qui nous a permis d'accélérer notre travail sur l'accessibilité, à un rythme stable.

Le premier de ces projets est venu d'une organisation néerlandaise en 2009 qui promouvait l'utilisation des standards aux Pays-Bas. Elle souhaitait utiliser XWiki pour son site web, car c'était l'un des rares projets de wiki, à l'époque, qui respectait le plus les directives d'accessibilité. C'est la première fois que nous avons eu l'occasion de progresser vers notre objectif de conformité aux WCAG.

Cette année, les dernières nouvelles positives à ce sujet sont représentées par le financement du BMI (le ministère allemand fédéral de l'Intérieur et de la Patrie), qui s'est concentré sur l'amélioration de l'accessibilité de XWiki et de CryptPad.

Bien qu'il s'agisse souvent d'une obligation légale, l'accessibilité des projets open-source fait rarement l'objet d'un parrainage. Nous espérons que, grâce à une meilleure prise de conscience du sujet et à la collaboration, davantage de projets open-source pourront bénéficier des mêmes opportunités d'amélioration de l'accessibilité.

Quelles sont les normes que nous cherchons à respecter ?

Bien que notre objectif principal soit de respecter les règles pour l'accessibilité des contenus web (WCAG), nous essayons également de résoudre les problèmes liés à d'autres standards d'accessibilité lorsqu'ils nous sont signalés.

Cela comprend :

  • BITV (Barrierefreie Informationstechnik-Verordnung)
  • Les standards de l'ADA (Loi sur les Américains avec handicap)
  • Les règles a11y — a11y est une initiative communautaire visant à faciliter l'accessibilité numérique.

Nous cherchons aussi à résoudre les problèmes de l'ATAG (Règles pour l’accessibilité des outils d’édition) dans l'avenir.

Tester l'accessibilité efficacement et facilement

💡 TL;DR (si vous n'êtes pas intéressé par les aspects techniques) :

  • l'équipe produit XWiki SAS a intégré AxeCore dans l'environnement de test existant pour automatiser les tests d'accessibilité
  • ils ont également inclus des tests manuels
  • en plus pour vous : quelques suggestions d'outils de vérification de l'accessibilité

XWiki a commencé par utiliser les Dutch Web Guidelines pour valider l'accessibilité, mais depuis la version 15.2, il utilise Axe Core pour détecter les violations des WCAG 2.1 (niveau AA). Axe Core est un moteur de test d'accessibilité rapide, sécurisé et léger, choisi par nos développeurs grâce à son intégration transparente dans notre environnement de test actuel. Pour effectuer ces validations WCAG, nous avons réutilisé nos tests fonctionnels basés sur docker, couvrant toutes les interfaces statiques.

Les tests WCAG n'étant pas entièrement automatisables, nous testons manuellement notre accessibilité de la même manière que les tests manuels de l'interface utilisateur et organisons de temps à autre des sessions de tests manuels.

Les développeurs utilisent également des outils de validation WCAG comme Axe devTools directement dans leurs navigateurs pour reproduire facilement les problèmes sur leurs ordinateurs. Cela permet de visualiser rapidement les problèmes et de les résoudre.

Une liste d'autres outils possibles pour vérifier et valider les problèmes d'accessibilité a été mise à la disposition de ceux qui souhaitent contribuer au projet XWiki :

En ligneFonctionnant sur navigateurChecklist pour les tests manuels

 

Un style de codage qui garantira l'accessibilité pour le développement à long terme

Pour s'assurer que nos efforts actuels pour atteindre le niveau AA des WCAG 2.2 ne se perdent pas dans les multiples styles de codage, nous avons organisé une page sur les meilleures pratiques. Si vous contribuez à XWiki ou si vous l'intégrez, cette page peut vous être utile.

Audits externes et openDesk

Comme vous le savez probablement déjà, XWiki SAS est l'un des 8 partenaires inclus dans le projet openDesk (Der Sovereign Workplace). Comme ce projet est destiné à servir l'administration publique allemande et toute autre équipe qui pourrait choisir openDesk à l'avenir, l'accessibilité est indispensable.

DataPort a été d'une grande aide dans ce contexte. Ils ont organisé des audits internes sur la plateforme XWiki en relation avec l'ensemble du projet, ont fait des recommandations pour des problèmes particuliers et ont confirmé nos progrès rapides vers notre objectif.

Une validation détaillée et complète de nos progrès a également été effectuée par Zendis, qui a récemment publié son audit !

Vous pouvez lire le document original en allemand.

Voici un résumé des critères WCAG applicables et de ceux que nous... ✅ remplissons, ✔️ remplissons en grande partie ou ❌ ne remplissons pas.  Les critères que nous ne respectons pas entièrement sont accompagnés d'un lien vers le problème correspondant.

Catégorisation des problèmes

✅ Rempli (37 critères, 77%)

✔️ Rempli en grande partie (2 critères, 4%)❌ Pas rempli (9 critères, 19%)

9.1.3.1a Éléments de structure HTML pour les titres

9.1.3.1b Éléments de structure HTML pour les listes

9.1.3.1d Contenu structuré

9.1.3.1h Étiquettes d'éléments de formulaire déterminables par programmation

9.1.3.2 Séquence logique

9.1.3.4 Pas de restriction sur l'orientation de l'écran

9.1.4.1 Utilisable sans couleur

9.1.4.2 Le son peut être désactivé

9.1.4.3 Contraste des textes suffisant

9.1.4.4 Texte redimensionnable à 200%

9.1.4.5 Éviter les polices de caractères graphiques

9.1.4.10 Le contenu est correctement décomposé

9.1.4.12 Espacement du texte réglable

9.1.4.13 Le contenu affiché est utilisable

9.2.1.2 Pas de piège au clavier

9.2.1.4 Les raccourcis clavier peuvent être désactivés ou personnalisés

9.2.2.1 Délais

9.2.2.2 Le contenu mobile peut être désactivé

9.2.3.1 Pas de clignotement

9.2.4.1 Sections pouvant être sautées

9.2.4.2 Titres de documents pertinents

9.2.4.4 Textes des liens pertinents

9.2.4.5 Chemins d'accès alternatifs

9.2.4.6 Des titres et des étiquettes pertinents

9.2.4.7 Indication claire de la position actuelle de focus

9.2.5.2 Les entrées gestuelles du pointeur qui peuvent être annulées ou révoquées

9.2.5.3  Partie d'étiquette visible du nom accessible

9.3.1.1 Langue principale indiquée

9.3.1.2 Mots étrangers et sections marquées

9.3.2.1 Pas de changement de contexte inattendu dans le focus

9.3.2.2 Pas de changement de contexte inattendu dans l'entrée

9.3.2.3 Une navigation uniforme

9.3.2.4 Étiquetage cohérent

9.3.3.2 Présence d'étiquettes pour les éléments du formulaire

9.3.3.3 Aide en cas d'erreur

9.4.1.1 Syntaxe correcte

9.4.1.2 Nom, rôle, valeur disponibles

9.1.1.1a Textes de remplacement pour les contrôles (tâche)
9.1.4.11 Contraste suffisant des éléments graphiques et des commandes graphiques (tâche)

9.1.1.1b Textes de remplacement pour les éléments graphiques et les objets

9.1.2.3 Description audio ou alternative en texte intégral pour les vidéos

9.1.2.5 Description audio pour les vidéos

9.1.3.3 Utilisable sans référence aux caractéristiques sensorielles (tâche #1, tâche #2)

9.2.4.3 Séquence logique dans l'utilisation du clavier (tâche)

9.4.1.3 Messages d'état disponibles par programmation (tâche)

11.7 Paramètres personnalisés (tâche)

11.8.1 Technologie du contenu (tâche)

Déclaration sur l'accessibilité (tâche)

Nos progrès à ce jour

En novembre 2023, un total de 389157 tests automatisés ont été effectués. 99,18% de nos tests automatisés WCAG sont réussis.

Il y avait :

  • 1816 avertissements à corriger dans les tests (0,45%)
  • 1349 tests incomplets (0.34%) qui nécessitent une validation manuelle.

Sur la base de ces avertissements et des tests incomplets, nous créons des tâches et les résolvons dans les délais disponibles. Vous pouvez consulter les tâches ouvertes ici. 🕵️‍♀️

Ces tests contiennent des doublons, car plusieurs tâches peuvent avoir les mêmes causes.

Notez que les tests automatisés WCAG ont deux limites :

  1. Les tests WCAG ne sont exécutés que pour les interfaces utilisateur pour lesquelles nous disposons de tests fonctionnels automatisés.
  2. La bibliothèque sous-jacente que nous utilisons pour les tests (AxeCore) estime qu'elle ne détecte qu'environ 50 % des problèmes liés aux WCAG.
    • À l'avenir, nous prévoyons également d'effectuer des tests WCAG manuels une fois que nous aurons résolu tous les problèmes que nous pouvons détecter automatiquement.

Nous suivons nos progrès en matière d'accessibilité sur notre JIRA public, où vous pouvez également consulter notre tableau des tâches créées par rapport aux tâches résolues.

  • Au cours des dernières années, 215 tâches WCAG ont été créées 🎁
  • Parmi eux, 183 ont été résolues (85%)

image-20240515164552-1.png

Progrès de l'année dernière

Lors de l'analyse de nos problèmes d'accessibilité, nous avons identifié les principaux thèmes des problèmes résolus au cours des années 2023 et 2024.

Voir les pourcentages ci-dessous et les détails des problèmes résolus dans cette liste.

acc.png

Nos promesses pour l'avenir

  • Promesse n° 1 : Le logiciel XWiki sera bientôt en pleine conformité avec les WCAG 2.2. 🎯
  • Promesse n° 2 : L'accessibilité du site xwiki.com sera fortement améliorée dans un futur proche. 🔍
  • Promesse n° 3 : Nous continuerons à encourager les gens à prendre l'accessibilité au sérieux, non pas comme une option facultative, mais comme une caractéristique par défaut. ✨

Un grand « Merci ! »

Merci beaucoup d'avoir lu tout cela. Savoir que des gens s'intéressent à la question de l'accessibilité est vraiment très important.

Si vous avez une vision similaire à la nôtre, nous serions ravis de savoir comment vous abordez les questions de l'accessibilité dans votre propre projet ou équipe. Écrivez-nous sur notre forum dès que vous en avez le temps.

Si vous avez d'autres questions sur ce sujet du point de vue professionnel, n'hésitez pas à nous envoyer un courriel (contact@xwiki.com).


Si vous souhaitez voir des articles comme celui-ci plus souvent, n'hésitez pas à vous inscrire à notre lettre d'information.

À la prochaine fois ! 👋

Articles similaires :