Accessibilité numérique pour les équipes RH : Rendre les systèmes de recrutement et de travail conformes aux WCAG

Introduction

Si votre site carrière, vos formulaires de candidature ou vos systèmes internes ne sont pas accessibles, vous excluez les candidats qualifiés et les employés en situation de handicap — et vous risquez de violer la loi. Les Directives pour l'accessibilité des contenus Web (WCAG) 2.2, publiées par le W3C, sont la version actuelle de la norme, et le niveau AA est l'objectif que la plupart des organisations visent. Elle est de plus en plus inscrite dans la réglementation : les organismes du secteur public britannique doivent respecter les WCAG 2.2 AA, et la règle ADA Title II 2024 du département américain de la Justice fait de WCAG 2.1 niveau AA la norme technique pour les contenus web et les applications mobiles des gouvernements des États et des collectivités locales.

Ce guide fournit aux équipes RH une feuille de route concrète et exploitable pour rendre les systèmes de recrutement et de travail accessibles.

Étape 1 : Auditer votre site carrière

Votre site carrière est la porte d'entrée de votre organisation pour tous les candidats. Un site carrière inaccessible envoie un message clair aux candidats en situation de handicap : vous n'êtes pas bienvenu ici.

Liste de contrôle WCAG 2.2 AA pour les sites carrière

Perceptible

• Tous les images ont un texte alternatif significatif (les images décoratives utilisent des attributs alt vides)
• Les vidéos ont des sous-titres et des descriptions audio
• Le contraste des couleurs respecte les ratios minimums (4,5:1 pour le texte normal, 3:1 pour le texte volumineux)
• Le texte peut être agrandi jusqu'à 200 % sans perte de contenu ou de fonctionnalité, et le contenu se réajuste sans défilement bidimensionnel à une largeur de 320 pixels CSS (équivalent à un zoom de 400 % sur un écran de 1280px de large)
• Les informations ne sont pas transmises par la couleur seule

Utilisable

• Toutes les fonctionnalités sont accessibles via le clavier (Tab, Entrée, Barre d'espace, Touches fléchées)
• Les indicateurs de focus sont visibles et distincts
• Il n'existe pas de pièges au clavier (les utilisateurs peuvent toujours utiliser Tab pour quitter n'importe quel élément)
• Les pages disposent de liens de navigation rapide
• Les utilisateurs ont suffisamment de temps pour accomplir les tâches (ou peuvent prolonger les délais impartis)
• Aucun contenu ne clignote plus de trois fois par seconde

Compréhensible

• La langue de la page est déclarée dans le HTML
• Les étiquettes de formulaire sont associées par programme aux entrées
• Les messages d'erreur sont clairs et précis (par ex., « L'adresse e-mail doit contenir un symbole @ » plutôt que « Entrée non valide »)
• La navigation est cohérente entre les pages

Robuste

• Les pages utilisent du HTML sémantique bien formé (WCAG 2.2 marque l'ancien critère 4.1.1 Analyse as obsolète et l'a supprimé, mais un balisage propre aide toujours la technologie d'assistance)
• Les widgets personnalisés utilisent correctement les rôles, états et propriétés ARIA
• Le contenu fonctionne avec la technologie d'assistance actuelle (lecteurs d'écran, grossisseurs, contrôle vocal)

Étape 2 : Rendre les formulaires de candidature accessibles

Les formulaires de candidature sont l'endroit où se produisent la plupart des défaillances en matière d'accessibilité. Problèmes courants et leurs solutions :

Étiquettes et instructions

• Défaillance : Texte de placeholder utilisé comme seule étiquette. Les lecteurs d'écran peuvent ne pas annoncer le texte de placeholder de manière cohérente.
• Solution : Utilisez des éléments `<label> visibles associés à chaque entrée via des attributs for/id`.

Gestion des erreurs

• Défaillance : Les erreurs s'affichent uniquement en texte rouge à côté du champ, sans association par programme.
• Solution : Utilisez `aria-describedby pour lier les messages d'erreur aux champs. Fournissez un résumé des erreurs en haut du formulaire. Utilisez aria-invalid="true"` sur les champs contenant des erreurs.

Navigation au clavier

• Défaillance : Les menus déroulants personnalisés et les sélecteurs de date qui ne fonctionnent qu'à la souris.
• Solution : Utilisez les éléments HTML natifs `<select>` si possible. Pour les widgets personnalisés, implémentez le support complet du clavier en suivant les Pratiques de rédaction WAI-ARIA.

Téléchargement de fichiers

• Défaillance : Téléchargement de CV uniquement par glisser-déposer sans alternative.
• Solution : Fournissez toujours une entrée de fichier standard (`<input type="file">`) aux côtés de toute interface de glisser-déposer.

Indicateurs de progression

• Défaillance : Les formulaires multi-étapes qui n'indiquent pas la position actuelle ou ne permettent pas la navigation en arrière.
• Solution : Utilisez `aria-current="step"` et fournissez des compteurs d'étapes clairs (par ex., « Étape 2 sur 4 »). Permettez aux utilisateurs de revenir aux étapes précédentes sans perdre les données.

Étape 3 : Configurer votre ATS pour l'accessibilité

Les systèmes de suivi des candidatures (ATS) génèrent la plupart des pages avec lesquelles les candidats interagissent. Problèmes d'accessibilité courants des ATS :

• Les pages d'annonces d'emploi générées automatiquement peuvent manquer de structure de titres. Collaborez avec votre fournisseur ATS pour vous assurer que les balises H1/H2/H3 sont utilisées correctement.
• Les fonctionnalités « Postuler avec LinkedIn » ou similaires en un clic peuvent ne pas être accessibles au clavier. Testez minutieusement ou fournissez une alternative manuelle.
• CAPTCHA sur les formulaires de candidature peut bloquer les utilisateurs de lecteurs d'écran et les personnes handicapées cognitives. Utilisez des méthodes de vérification qui ne reposent pas sur un puzzle visuel ou cognitif, et notez que le critère de succès WCAG 2.2 3.3.8 (Authentification accessible) restreint les tests de fonction cognitive dans les étapes de connexion.
• Les délais d'expiration de session pendant de longues candidatures pénalisent les utilisateurs qui tapent lentement. Prolongez ou supprimez les délais d'expiration, ou avertissez les utilisateurs avant l'expiration et permettez la prolongation.

Élément d'action : Demandez un rapport de conformité en matière d'accessibilité (ACR) — un VPAT (Voluntary Product Accessibility Template) complété — à votre fournisseur ATS. S'ils ne peuvent pas en fournir un, envisagez de changer pour un fournisseur qui prend l'accessibilité au sérieux.

Étape 4 : Créer des documents d'intégration accessibles

Les nouveaux employés reçoivent une multitude de documents : contrats, manuels, guides d'avantages sociaux, matériels de formation. Tous doivent être accessibles.

Accessibilité des PDF

• Utilisez des PDF balisés avec un ordre de lecture logique
• Assurez-vous que toutes les images ont du texte alternatif
• Utilisez du texte réel (pas des images numérisées de texte)
• Définissez la langue du document et le titre
• Testez avec un lecteur d'écran (le vérificateur d'accessibilité d'Adobe Acrobat est un point de départ, mais les tests manuels sont essentiels)

Diaporamas et matériels de formation

• Utilisez des mises en page de diapositives (pas des zones de texte libres) pour que les lecteurs d'écran suivent un ordre de lecture logique
• Ajoutez du texte alternatif à tous les éléments visuels
• Assurez un contraste des couleurs suffisant
• Fournissez des notes de l'orateur comme narratif de texte alternatif
• Enregistrez l'audio/vidéo avec des sous-titres

Formulaires et enquêtes

• Utilisez des générateurs de formulaires accessibles (Microsoft Forms et Google Forms sont raisonnablement accessibles ; testez les autres avant de les déployer)
• Ne jamais utiliser de formulaires PDF qui exigent que l'utilisateur les imprime, les remplisse à la main et les numérise

Étape 5 : Rendre les communications internes accessibles

E-mail

• Utilisez du HTML sémantique dans les modèles d'e-mail (titres, listes, texte alternatif pour les images)
• Évitez d'envoyer des informations critiques uniquement en tant que pièces jointes images
• Fournissez des alternatives en texte brut

Intranet

• Appliquez les mêmes normes WCAG 2.2 AA que sur votre site carrière
• Assurez-vous que la fonctionnalité de recherche fonctionne avec les lecteurs d'écran
• Rendez les référentiels de documents navigables au clavier

Slack, Teams et plateformes de chat

• Encouragez l'utilisation du texte alternatif sur les images partagées dans les canaux, où votre plateforme la supporte
• Utilisez des threads plutôt que de longues conversations non structurées (plus facile pour l'accessibilité cognitive)
• Activez et promouvez les sous-titres lors des appels vidéo
• Assurez-vous que les annonces critiques sont également publiées au format texte, pas seulement en vidéo ou audio

Outils de test

Processus de test

1. Balayage automatisé avec axe ou Lighthouse — détecte seulement une partie des problèmes, ne vous fiez jamais à cela seul
2. Test de navigation au clavier manuel — naviguez dans chaque page en utilisant uniquement Tab, Entrée, Barre d'espace et touches fléchées
3. Test avec lecteur d'écran — testez avec NVDA (Windows) ou VoiceOver (macOS) au minimum
4. Test utilisateur — recrutez des utilisateurs en situation de handicap pour tester les flux d'application réels

Défaillances et solutions courantes

Conclusion

L'accessibilité numérique pour les systèmes RH n'est pas un projet ponctuel — c'est un engagement continu. Auditez vos systèmes actuels, remédier d'abord aux barrières les plus critiques, testez régulièrement avec une véritable technologie d'assistance, et tenez vos fournisseurs responsables. Chaque amélioration rend votre lieu de travail plus inclusif et élargit votre vivier de talents.