Déclaration d'accessibilité

Nous travaillons à nous conformer aux Web Content Accessibility Guidelines (WCAG) 2.1, niveau AA. C'est la norme la plus couramment exigée par les législations sur l'accessibilité dans le monde, et celle à laquelle nous nous tenons sur l'ensemble de la plateforme, pas seulement sur quelques pages vitrines.

Nous exécutons un audit automatisé réel — axe-core, piloté par Playwright — sur un ensemble représentatif des pages de la plateforme : la page d'accueil publique, les pages d'inscription, de connexion et de réinitialisation du mot de passe, les offres d'emploi publiques et les pages légales, ainsi que le tableau de bord, les offres d'emploi, les identifiants, le recrutement, les appels, la confidentialité, les évaluations, le créateur, le guide des compétences, le jeu de découverte et les pages d'administration une fois connecté.

Chaque page est analysée dans trois langues : l'anglais (de gauche à droite), l'arabe (de droite à gauche — le sens le plus susceptible de révéler un bug qu'un audit uniquement en anglais manquerait) et l'espagnol (une deuxième langue de gauche à droite, pour détecter tout problème lié à la longueur du texte plutôt qu'au contenu anglais lui-même). Les pages connectées sont analysées à la fois avec un compte candidat ordinaire et, le cas échéant, avec un compte administrateur de la plateforme.

Le script d'audit est versionné dans le code à l'emplacement scripts/a11y-audit.mjs et s'exécute avec une seule commande, npm run check:a11y, afin de pouvoir être relancé avant chaque mise en production plutôt que de supposer qu'il reste exact avec le temps.

À la date ci-dessus, l'audit a analysé 54 combinaisons page/langue (18 pages distinctes × 3 langues) et a initialement trouvé trois défauts réels et distincts :

Les trois défauts ont été corrigés directement dans le code source : les couleurs du texte et des liens ont été modifiées vers des teintes respectant le rapport de contraste de 4,5:1 exigé par WCAG 2.1 AA pour le texte de taille normale, chaque étiquette concernée a été associée à son champ, et les deux menus déroulants ont reçu un véritable nom accessible décrivant ce qu'ils contrôlent.

Le même audit automatisé a ensuite été relancé sur les 54 combinaisons page/langue et n'a trouvé aucune infraction. Ce résultat — pas seulement cette déclaration — est ce que signifie ici « étayé par un audit réel ».

Nous tenons à être directs sur les limites des tests automatisés plutôt que de laisser un audit propre laisser croire à plus qu'il ne l'est réellement. Des outils comme axe-core détectent de manière fiable une part importante des défauts d'accessibilité — étiquettes manquantes, contraste insuffisant, ARIA invalide, etc. — mais, selon la documentation de l'outil lui-même, les vérifications automatisées seules ne peuvent détecter qu'environ un tiers à deux cinquièmes des critères de réussite WCAG. Elles ne peuvent pas juger si le texte alternatif d'une image la décrit réellement, si le contenu se lit dans un ordre logique pour une personne naviguant uniquement au clavier ou au lecteur d'écran, ni si un utilisateur du clavier peut se retrouver piégé dans une partie de la page.

Nous n'avons pas encore effectué de passage manuel dédié avec un lecteur d'écran (comme NVDA ou VoiceOver), de parcours complet au clavier seul de chaque flux, ni de tests avec des personnes utilisant quotidiennement des technologies d'assistance. Ce sont de réelles lacunes, clairement identifiées, dans notre processus actuel, que nous ne cachons pas — les combler fait l'objet d'un travail de suivi distinct.

La liste des pages du script d'audit s'étoffe à mesure que la plateforme évolue, et nous prévoyons de l'exécuter avant de publier tout changement sur une page qu'il couvre. À la date de cette déclaration, son exécution est une étape manuelle, pas une barrière automatique dans l'intégration continue — ce projet ne dispose pas encore de pipeline CI du tout, ce qui est en soi une lacune connue dans notre façon de publier des changements en général, et non spécifique à l'accessibilité.

Si vous utilisez une technologie d'assistance et rencontrez sur Talaskill quelque chose qui ne fonctionne pas comme il le devrait, nous voulons le savoir. Contactez Talaskill1@gmail.com en précisant la page où vous étiez et ce qui s'est passé, et nous le traiterons comme un véritable bug — avec le même sérieux que pour tout autre défaut signalé de cette manière.