Une **candidature accessible** permet à un candidat de terminer chaque étape au clavier et avec une technologie d’assistance. Les contrôles exigent des libellés clairs, un focus logique et visible, des erreurs faciles à corriger, des solutions de remplacement au glisser-déposer, une saisie préservée et une voie claire pour demander un aménagement. Le niveau AA des WCAG 2.2 constitue une base pratique, mais seul un test du parcours de bout en bout permet de vérifier que le flux fonctionne.

Tout le parcours compte. Un portail carrière peut passer une analyse automatique alors que le dépôt du CV, le sélecteur de date, le choix du fuseau horaire, l’authentification externe ou la page de confirmation bloque la personne qui souhaite postuler.

## Pourquoi l’accès au clavier relève-t-il du recrutement, et pas seulement des utilisateurs experts ?

**L’accès au clavier détermine si certains candidats qualifiés peuvent ne serait-ce qu’entrer dans votre pipeline.** Il ne sert pas uniquement à accélérer les déplacements des utilisateurs chevronnés dans une interface graphique.

Un récent essai soutenant que [les interfaces graphiques devraient être entièrement pilotables au clavier](https://ckardaris.com/blog/2026/08/28/keyboard-driven-guis.html) a suscité un vaste débat sur Hacker News. Pour le recrutement, la leçon utile est plus précise que le titre : chaque action obligatoire d’une candidature doit pouvoir être réalisée sans mouvement précis de la souris, et la personne doit toujours savoir où se trouve le focus.

Cela aide les personnes aveugles ou malvoyantes, celles qui utilisent la saisie vocale, celles dont la dextérité est limitée ou qui ne peuvent pas utiliser de dispositif de pointage. Mais ne réduisez pas tous ces besoins à la formule « l’accessibilité améliore l’ergonomie ». Une fonction peut être indispensable à une personne, même si la plupart des candidats ne la remarquent jamais.

Les équipes de recrutement évaluent souvent les points de friction d’une candidature à partir de la longueur du formulaire et du taux de conversion. L’accessibilité change la question. Au lieu de demander seulement « Combien de personnes sont allées au bout ? », demandez-vous : « Une personne utilisant ce mode d’interaction pourrait-elle aller au bout sans aide ? » Un candidat bloqué ne devient jamais une ligne de votre entonnoir. Les analyses habituelles du pipeline ne peuvent donc pas révéler qui n’est jamais arrivé jusqu’à vous.

Le risque ne s’arrête pas au premier formulaire. Un candidat peut devoir ouvrir un lien magique, corriger un fichier refusé, choisir un créneau d’entretien, changer de fuseau horaire, retirer un fichier de son portfolio, mener à bien une authentification externe, puis revenir au bon endroit. Votre [expérience candidat](/docs/the-candidate-experience) correspond à la somme de ces transitions, pas au vernis du premier écran.

## Combien de candidatures en ligne fonctionnent-elles avec un lecteur d’écran ?

**Dans une étude évaluée par les pairs portant sur 90 tentatives de candidature, seules 50, soit 55,6 %, ont été terminées de façon autonome par des utilisateurs experts de lecteurs d’écran.** Ce résultat s’applique aux sites du classement Fortune 500 et aux configurations techniques étudiées, pas à tous les portails ni à tous les candidats en situation de handicap.

[Reuschel, McDonnall et Burton](https://pmc.ncbi.nlm.nih.gov/articles/PMC10961918/) ont sélectionné 30 employeurs du Fortune 500 et demandé à trois experts aveugles de postuler une fois sur chaque site, avec trois combinaisons différentes de navigateur et de lecteur d’écran. Vingt-trois sites sur 30 ont bloqué au moins une configuration. Seuls 23,3 % des sites permettaient de terminer la candidature avec les trois configurations.

Les chercheurs ont relevé 694 problèmes d’accessibilité et d’ergonomie, dont 73 problèmes bloquants ou critiques. Trois catégories représentaient 75 % de l’ensemble des problèmes consignés : l’accès au clavier, les informations et relations, et les libellés. L’accès au clavier était en cause dans 53 % des problèmes bloquants, tandis que les sélecteurs de date et les champs combinés apparaissaient dans 34 % d’entre eux.

Ces chiffres constituent la base factuelle la plus solide pour un audit d’accessibilité d’un ATS. Ils ne signifient pas que 44,4 % des candidats ont abandonné une candidature. Les 40 tentatives infructueuses mesuraient l’impossibilité de terminer le parcours de manière autonome dans des conditions de test précises, et non un abandon volontaire de la candidature.

L’étude constate aussi des progrès. Le taux de finalisation est passé de 28,1 % dans une étude antérieure de 2011 à 55,6 % dans les travaux plus récents, et 26 sites sur 30 fonctionnaient avec au moins une configuration testée. Le problème tient à **l’irrégularité des résultats selon les configurations**. Un parcours qui fonctionne avec l’une peut échouer avec une autre.

Ces résultats ont des limites importantes. L’étude portait sur trois utilisateurs aveugles experts, un par configuration, et sur des portails de grandes entreprises. Des experts peuvent contourner des défauts qui arrêteraient une personne moins expérimentée. Les conclusions concernent directement l’usage d’un lecteur d’écran : ne les présentez donc pas comme un taux d’échec global des utilisateurs qui naviguent uniquement au clavier.

## Que signifie le niveau AA des WCAG 2.2 pour un portail candidat ?

**Le niveau AA des WCAG 2.2 constitue une base technique pratique pour l’accessibilité d’un portail candidat, pas une obligation légale universelle.** Pour le clavier, il s’agit de vérifier que chaque fonction est utilisable sans dispositif de pointage, que le focus suit un parcours cohérent et que le contrôle actif reste visible et utilisable.

Les [Règles pour l’accessibilité des contenus Web 2.2](https://www.w3.org/TR/WCAG22/) transforment une intention générale en critères vérifiables. Dans un parcours de recrutement, leur traduction pratique ressemble à ceci :

| Critère WCAG | Points à examiner dans un parcours de recrutement |
|---|---|
| **2.1.1 Clavier (A)** | Postuler, déposer un fichier, sélectionner une option, planifier, envoyer et annuler sans souris ni séquence de touches soumise à une contrainte de temps. |
| **2.1.2 Pas de piège au clavier (A)** | Entrer dans les boîtes de dialogue, calendriers, menus, composants de dépôt et outils intégrés, puis en sortir avec les touches attendues. |
| **2.4.3 Parcours du focus (A)** | Parcourir la page dans un ordre qui préserve le sens du formulaire et suit les erreurs ou panneaux nouvellement affichés. |
| **2.4.7 Visibilité du focus (AA)** | Voir un indicateur de focus clair sur les liens, champs, boutons, options radio et contrôles personnalisés. |
| **2.4.11 Focus non masqué (AA)** | Empêcher le contrôle actif de disparaître derrière une barre « Postuler » fixe, une bannière de cookies ou une boîte de dialogue. |
| **2.5.1 Gestes pour le contrôle du pointeur (A)** | Proposer une solution simple aux gestes multipoints ou dépendant d’un tracé, sauf lorsqu’ils sont essentiels. |
| **2.5.7 Mouvements de glissement (AA)** | Prévoir des boutons ou une autre méthode sans glisser-déposer pour les dépôts, le classement et les actions similaires. |
| **2.5.8 Taille de la cible (AA)** | Prévoir des cibles d’au moins 24 pixels CSS sur 24, ou respecter les exceptions du critère concernant l’espacement ou un contrôle équivalent. |

La prise en charge du clavier ne se confond pas avec celle des lecteurs d’écran. Un sélecteur de date personnalisé peut réagir aux flèches sans annoncer la date choisie. Une nouvelle liste de créneaux d’entretien peut être techniquement atteignable, mais ne produire aucun signal sonore indiquant que la page a changé. Aux interactions au clavier doivent donc s’ajouter des noms, rôles, états, relations et annonces d’état sémantiques.

Les contrôles HTML natifs réduisent le nombre de comportements à recréer, mais ne règlent pas tout. Un champ peut encore être dépourvu de libellé utile, et un formulaire bien libellé peut tout de même effacer toutes les réponses après une seule erreur de validation.

## Comment appliquer cette liste de 12 tests à une candidature accessible ?

**Effectuez ces 12 vérifications depuis l’offre d’emploi jusqu’à l’envoi, puis lors de l’accès au portail et de la planification d’un entretien.** Testez le parcours normal et les cas d’erreur : la validation, les dépôts de fichiers, les panneaux dynamiques et les passages par des services tiers sont souvent les points de rupture de formulaires pourtant soignés.

### 1. Préférez les contrôles natifs aux composants personnalisés

Utilisez les champs de texte, boutons radio, cases à cocher, boutons, liens et sélecteurs de fichiers natifs, sauf si un contrôle personnalisé apporte un comportement indispensable. Les éléments natifs offrent des interactions au clavier et une sémantique d’accessibilité qu’un simple `div` stylisé ne possède pas.

Pour chaque liste combinée, calendrier ou fenêtre modale personnalisée, documentez les touches attendues et les états annoncés.

### 2. Donnez un nom accessible utile à chaque contrôle

Chaque champ et chaque bouton composé uniquement d’une icône doit porter un nom qui décrit son rôle. « Retirer le fichier du portfolio » est utile ; « bouton » ou une icône de corbeille sans libellé ne l’est pas. Regroupez les boutons radio et les cases à cocher associés sous une question explicite.

N’utilisez pas le texte indicatif comme libellé. Le caractère obligatoire du champ, les formats attendus et le texte d’aide doivent être reliés par le code au champ qu’ils expliquent.

### 3. Respectez un parcours de focus logique

Appuyez sur Tab depuis l’en-tête de la page jusqu’à l’action finale, puis revenez en arrière avec Maj+Tab. Le focus doit suivre l’ordre de lecture et des tâches, y compris pour les questions conditionnelles qui apparaissent après une réponse.

Évitez les valeurs de `tabindex` positives, qui créent un second ordre de parcours dans la page. Lorsqu’un récapitulatif ou une fenêtre modale s’ouvre, déplacez volontairement le focus. À la fermeture, ramenez-le vers un contrôle stable.

### 4. Maintenez le focus clavier visible et non masqué

À chaque étape, vous devez pouvoir désigner l’élément qui possède le focus. Ne supprimez pas le contour du navigateur, sauf si vous le remplacez par un indicateur tout aussi clair, quels que soient l’arrière-plan et l’état.

Vérifiez les en-têtes fixes, les bannières de consentement et les barres « Postuler » ancrées sur les affichages étroits ou agrandis. Les WCAG 2.2 ont ajouté le critère « Focus non masqué » au niveau AA, car un focus recouvert ne sert à rien.

### 5. Supprimez les pièges au clavier

Ouvrez chaque boîte de dialogue, sélecteur de date, menu et composant tiers, puis quittez-le avec les commandes clavier attendues. Testez Échap lorsque cet usage est habituel, mais ne faites pas d’un raccourci non documenté l’unique sortie.

Recommencez après une erreur de validation. Les pièges n’apparaissent souvent qu’au changement d’état d’un composant.

### 6. Facilitez la recherche et la correction des erreurs

Lors de l’envoi, placez le focus sur un récapitulatif concis des erreurs qui contient des liens vers les champs concernés. Chaque champ doit signaler sa propre erreur, conserver la valeur saisie et expliquer clairement comment la corriger.

Ne vous contentez pas d’annoncer « invalide ». Précisez ce qui est attendu, puis vérifiez qu’un utilisateur de lecteur d’écran entend le récapitulatif et que ses liens mènent aux bons contrôles.

### 7. Annoncez les changements d’état dynamiques

Lorsqu’un candidat choisit une date et que de nouveaux créneaux apparaissent, exposez l’état sélectionné et annoncez la mise à jour. La même règle s’applique à la fin d’un dépôt, au retrait d’un fichier, à l’ouverture d’une section ou à l’échec d’une vérification asynchrone.

Annoncez l’information dont le candidat a besoin pour poursuivre. Ne déplacez le focus que si l’enchaînement exige une attention immédiate.

### 8. Rendez les dépôts de CV et de portfolio utilisables

Conservez un bouton ordinaire de sélection de fichier, même si vous proposez aussi le glisser-déposer. Affichez les formats acceptés et la taille maximale avant la sélection, annoncez la progression et les échecs, et dotez chaque fichier déposé d’une action de retrait accessible.

Après le retrait, ramenez le focus vers un emplacement prévisible. Testez un fichier refusé, un dépôt interrompu, un nom de fichier en doublon et une nouvelle tentative.

### 9. Proposez des solutions de remplacement au glisser-déposer et aux gestes précis

Toute interaction de classement par glisser-déposer doit aussi proposer des contrôles « Monter » et « Descendre », ou une méthode équivalente. Les carrousels de dates doivent offrir des boutons ou des champs ordinaires au lieu d’exiger un balayage. Les petites cibles doivent respecter les règles WCAG de taille minimale ou d’espacement.

L’accessibilité des dispositifs de pointage concerne aussi les personnes qui utilisent un écran tactile, des commandes à contacteur ou d’autres modes de saisie.

### 10. Préservez les données saisies après une erreur ou un passage externe

Un candidat ne devrait pas ressaisir toute sa candidature parce qu’un champ a échoué, qu’une session a expiré ou qu’une autorisation externe a été annulée. Conservez les champs valides et les fichiers déposés lorsque cela ne présente pas de risque, puis expliquez ce qui doit être recommencé.

Hartwell, Orr et Edwards ont constaté que [la suppression de la ressaisie des données du CV réduisait l’abandon des candidatures](https://onlinelibrary.wiley.com/doi/abs/10.1111/ijsa.12282) sans diminuer leur qualité. Le résumé public ne donne ni ampleur de l’effet ni sous-groupe lié au handicap : n’inventez donc pas de gain de conversion.

### 11. Évitez les délais d’expiration inattendus

Ne faites pas expirer une candidature sans prévenir. Si une limite est nécessaire, permettez au candidat de la prolonger lorsque les exceptions WCAG applicables l’autorisent, préservez son travail et expliquez comment reprendre.

Testez au clavier et avec un lecteur d’écran l’état affiché après expiration. Le message de reprise doit être atteignable et compréhensible.

### 12. Publiez une procédure humaine pour les demandes d’aménagement

Affichez clairement une procédure du type « Besoin d’un aménagement pour postuler ? » avant que le formulaire ne puisse bloquer quelqu’un. Fournissez une adresse e-mail régulièrement relevée ou un autre moyen de contact accessible, annoncez un délai de réponse et proposez une autre façon de postuler.

N’exigez pas de renseignements médicaux détaillés ni la finalisation préalable du parcours défectueux. Ce filet de sécurité ne remplace pas la réparation du portail.

## Pourquoi tester le parcours plutôt que se fier à un badge ?

**Une analyse automatique, une surcouche, un badge ou une déclaration de conformité constituent un indice, pas la preuve qu’un candidat peut postuler.** Le W3C précise que les outils d’évaluation ne peuvent pas vérifier tous les aspects de l’accessibilité ni, à eux seuls, déterminer si un contenu est accessible.

Les [recommandations du W3C sur les outils d’évaluation](https://www.w3.org/WAI/test-evaluate/tools/selecting/) préconisent d’associer ces outils à une évaluation humaine menée par des personnes compétentes. Un analyseur peut rapidement repérer des libellés manquants, certains défauts de contraste et un balisage invalide. Il ne peut pas déterminer de façon fiable si le focus arrive au bon endroit après une erreur, si l’annonce d’une mise à jour des créneaux est compréhensible ou si une authentification externe ramène le candidat dans le bon contexte.

L’étude de Reuschel ajoute un avertissement opérationnel : des portails construits sur les mêmes grands systèmes proposés par les éditeurs ont produit des résultats différents. Votre configuration, vos questions personnalisées, votre habillage de marque, vos scripts, vos composants tiers et vos intégrations peuvent modifier l’accessibilité après leur acquisition. La déclaration d’un éditeur ne certifie pas votre parcours de candidature tel qu’il est configuré.

Utilisez plutôt une petite matrice de tests reproductible :

1. Cartographiez les parcours critiques : trouver une offre, postuler, déposer un fichier, provoquer une erreur de validation, corriger les erreurs, envoyer, conserver un reçu, entrer dans le portail, planifier, replanifier et terminer tout passage par un service externe.
2. Parcourez chacun avec Tab, Maj+Tab, Entrée, Espace, les flèches et Échap lorsque cette touche est attendue.
3. Testez plusieurs configurations de technologies d’assistance en consignant le navigateur, le lecteur d’écran, la version, la date et le résultat. Vous pouvez commencer par NVDA avec Chrome ou Firefox, JAWS avec Chrome ou Edge lorsque ces outils sont disponibles, et VoiceOver avec Safari.
4. Sortez du parcours idéal avec des fichiers invalides, des créneaux indisponibles, des sessions expirées, des requêtes réseau en échec et des autorisations annulées.
5. Faites participer des utilisateurs en situation de handicap à une évaluation par tâches, puis indiquez précisément les profils et configurations testés sans généraliser au-delà.

Consignez le parcours, la configuration, le résultat, le blocage, le responsable, la correction et la date du nouveau test. Exécutez les contrôles clavier à chaque mise en production concernée, puis recommencez l’évaluation sur plusieurs configurations après toute modification des formulaires, de la planification, de l’authentification, des dépôts ou des traductions. La [prise en charge de plusieurs langues](/docs/multi-language-support) permet aux candidats d’utiliser une langue disponible, mais traduction et accessibilité restent deux axes de test distincts.

## Qu’exigent réellement les règles d’accessibilité aux États-Unis et dans l’Union européenne ?

**Aucune règle unique n’impose le niveau AA des WCAG 2.2 à tous les portails de recrutement.** La taille de l’employeur, son statut public ou privé, le type de service, le contrat et la juridiction sont tous déterminants. Considérez donc cette section comme un repère opérationnel, pas comme un conseil juridique.

Aux États-Unis, le titre I de l’ADA couvre les procédures de candidature des employeurs concernés, généralement ceux qui comptent au moins 15 salariés. Les [recommandations de l’EEOC aux employeurs](https://www.eeoc.gov/publications/ada-your-responsibilities-employer) indiquent que les candidats qualifiés ont droit à un aménagement raisonnable pendant la candidature, sauf contrainte excessive. Confier le portail à un prestataire ne décharge pas l’employeur de sa responsabilité.

La règle du titre II du département américain de la Justice sur l’accessibilité du Web est différente. Elle adopte le **niveau AA des WCAG 2.1**, et non 2.2, pour les contenus Web et les applications mobiles fournis ou mis à disposition par les organismes publics des États et collectivités locales, y compris par l’intermédiaire de prestataires. Les [recommandations actuelles du département de la Justice](https://www.ada.gov/resources/web-rule-first-steps/) fixent les échéances au 26 avril 2027 et au 26 avril 2028 selon la taille et le type d’organisme. Il ne s’agit pas d’une règle générale applicable aux sites de tous les employeurs privés.

Dans l’Union européenne, l’acte législatif européen sur l’accessibilité couvre certains produits et services. Sa définition du commerce électronique concerne les services proposés en vue de conclure un contrat de consommation : il serait donc incorrect d’en faire une obligation générale pour les portails de recrutement. Les sites du secteur public peuvent relever d’une autre directive, tandis que les règles nationales relatives à l’égalité, à l’emploi, aux marchés publics et à l’accessibilité peuvent ajouter des obligations.

Retenez le niveau AA des WCAG 2.2 parce qu’il s’agit d’une base actuelle et pratique, qui comprend des critères utiles comme le focus non masqué, les solutions de remplacement au glisser-déposer et la taille minimale des cibles. Ne présentez pas ce choix technique comme une obligation légale universelle. Sollicitez un conseil adapté aux juridictions, aux employeurs, aux secteurs et aux pays que vous servez.

## Comment Kit aborde-t-il l’accessibilité du portail candidat ?

**Kit traite l’expérience candidat comme un parcours complet, pas comme un simple événement de conversion sur un formulaire.** Sa mise en œuvre actuelle comprend de bonnes bases d’accessibilité, mais Kit n’a pas encore mené d’audit public complet et ne revendique pas la conformité au niveau AA des WCAG 2.2.

Le formulaire de candidature utilise des contrôles et des libellés natifs pour les champs principaux. Après un échec de l’envoi, un récapitulatif des erreurs pouvant recevoir le focus et relié aux champs s’affiche. Les valeurs saisies et, lorsque c’est approprié, le CV déposé sont conservés : le candidat peut corriger au lieu de tout recommencer. Après un envoi réussi, il reçoit un reçu durable en lecture seule avec une référence qu’il peut conserver.

La [planification des entretiens](/docs/interview-scheduling) utilise des boutons pour choisir la date, des boutons radio natifs pour les créneaux, un indicateur de focus visible et une boîte de dialogue native dotée d’un nom accessible pour replanifier. Des tests dans le navigateur vérifient les interactions au clavier sur le périmètre de planification couvert. Les pages destinées aux candidats peuvent également proposer l’anglais, l’allemand, le français, l’espagnol et le polonais.

Il reste du travail. Le portail candidat a besoin d’un lien d’accès direct au contenu et d’une cible principale pouvant recevoir le focus. Les panneaux de dates nouvellement affichés doivent mieux gérer le focus ou les annonces de zone dynamique. Une action de retrait de fichier créée à la volée doit recevoir un nom accessible et rétablir le focus de manière ciblée. Le sélecteur enrichi de fuseau horaire et le parcours d’autorisation GitHub nécessitent encore des tests complets du parcours au clavier et avec un lecteur d’écran, dans les configurations prises en charge.

Ces lacunes expliquent pourquoi nous ne transformerons pas quelques composants solides en revendication générale d’accessibilité. La prochaine démarche responsable consiste à les corriger, à effectuer un audit avec plusieurs configurations, à faire participer des utilisateurs en situation de handicap, à publier le périmètre évalué et à intégrer les tests qui en résultent au processus de mise en production.

<div class="blog-inline-cta">
  <p><strong>Vous voulez examiner le parcours vous-même ?</strong> Commencez par le formulaire de candidature de Kit, dont les champs sont correctement libellés, le récapitulatif d’erreurs relié aux champs, le reçu durable et la planification testée au clavier, puis soumettez-nous aux mêmes 12 vérifications.</p>
  <p><a href="/users/sign_up">Démarrez votre essai gratuit</a></p>
</div>

Une candidature accessible n’est pas un badge que l’on achète une fois pour toutes. C’est un parcours qui doit rester utilisable malgré l’évolution des formulaires, des intégrations, des langues et des étapes de recrutement. Testez-le de bout en bout, consignez les blocages, maintenez un moyen de contact humain pour les demandes d’aménagement et corrigez tout ce qui empêche une personne qualifiée d’atteindre votre équipe.