Qu’est-ce qui différencie un candidat capable de réciter la structure du RGAA d’un candidat capable de corriger, en vingt minutes, un menu qui se referme tout seul au clavier ? La question mérite d’être posée avant tout entretien de recrutement pour un poste orienté accessibilité, car les deux profils se ressemblent beaucoup sur un CV, et beaucoup moins face à un vrai bug.
Cette checklist rassemble sept questions retenues après plusieurs sessions de recrutement, organisées pour distinguer une connaissance réellement opérationnelle des mécanismes ARIA d’un vocabulaire mémorisé sans compréhension du fonctionnement sous-jacent. Elle ne traite pas de la formation continue une fois le développeur en poste, sujet à part entière.
Pourquoi les questions de définition ne suffisent pas
Demander « Que signifie ARIA ? » ou « Citez les quatre principes du WCAG » donne rarement une information utile : ces réponses se mémorisent en quelques minutes de lecture, sans jamais avoir touché à un composant réel. Un candidat qui répond parfaitement à ce type de question peut tout à fait se retrouver démuni face à un bug concret, faute d’avoir manipulé les mécanismes derrière le vocabulaire.
La grille de questions retenue
- « Racontez un bug d’accessibilité que vous avez corrigé récemment. » Cette question ouverte révèle immédiatement si le candidat a une pratique réelle : un candidat qui a réellement corrigé des bugs décrit un contexte précis, une méthode de diagnostic, un correctif, alors qu’un candidat sans pratique reste vague ou généralise à l’excès.
- « Quelle est la différence entre aria-hidden et display: none ? » La réponse attendue distingue un masquage purement sémantique, qui retire un élément de l’arbre d’accessibilité sans changer son rendu visuel, d’un masquage qui retire l’élément à la fois visuellement et de l’arbre d’accessibilité. Une confusion entre les deux trahit une compréhension superficielle.
- « Comment testeriez-vous, sans outil automatisé, qu’un menu déroulant fonctionne au clavier ? » Cette mise en situation teste la méthode plus que la connaissance théorique : tabulation, flèches, touche Échap, retour du focus après fermeture — un candidat expérimenté énumère ces étapes naturellement.
- « Un attribut aria-expanded ne change jamais de valeur malgré un clic. Comment chercheriez-vous la cause ? » Une bonne réponse commence par vérifier si l’attribut est bien mis à jour par le script au moment du clic, avant d’aller chercher plus loin — un réflexe de diagnostic ordonné, plutôt qu’une liste de causes possibles récitées sans hiérarchie.
- « Pourquoi éviter tabindex avec une valeur positive ? » La réponse attendue explique que cela modifie l’ordre de tabulation naturel du document, créant un parcours différent de l’ordre visuel et source de confusion, plutôt qu’une réponse du type « c’est interdit », qui ne révèle aucune compréhension du mécanisme.
- « Que se passe-t-il si l’on ajoute un rôle ARIA à un élément qui a déjà une sémantique native équivalente ? » Un bon candidat mentionne le risque de conflit ou de redondance, et l’idée que l’élément natif est presque toujours préférable au rôle ARIA ajouté artificiellement.
- « Décrivez comment vous corrigeriez un piège clavier, sans savoir encore quel composant en est responsable. » Cette dernière question teste la méthode d’investigation générale : isoler le composant, reproduire le blocage de façon fiable, avant de proposer un correctif — une démarche transférable à n’importe quel bug, pas seulement à un piège clavier.
Ce que ces questions révèlent en pratique
Sur les dernières sessions de recrutement menées avec cette grille, la question la plus discriminante s’est révélée être la troisième, celle du test manuel au clavier. Un candidat sans pratique réelle propose souvent de tester « avec un lecteur d’écran » sans plus de précision, incapable de décrire les étapes concrètes d’un test clavier basique. Un candidat expérimenté, à l’inverse, décrit spontanément une séquence précise, parfois même sans qu’on lui demande d’aller plus loin.
Ce qu’il ne faut pas transformer en éliminatoire
Un candidat qui hésite sur le nom exact d’un attribut ARIA ne mérite pas d’être écarté pour autant : la documentation reste accessible en permanence sur un poste de travail réel, et personne ne travaille de mémoire. Ce qui compte est la capacité à raisonner sur le mécanisme, pas la mémorisation du vocabulaire exact. Un entretien qui pénalise un candidat pour avoir dit « je vérifierais dans la documentation » plutôt que d’avoir récité une réponse exacte se trompe de cible.
Conseil maison : garder une question ouverte de retour d’expérience en première position d’entretien met le candidat en confiance et donne, souvent en moins de deux minutes, une indication plus fiable que le reste de la grille.
En résumé
La grille présentée ici privilégie systématiquement le mécanisme sur le vocabulaire, et la mise en situation sur la définition théorique. Un candidat capable d’expliquer pourquoi un mécanisme fonctionne, ou de décrire une méthode de diagnostic ordonnée, se révèle presque toujours plus fiable sur le poste qu’un candidat qui maîtrise le lexique sans jamais avoir eu à l’appliquer face à un vrai bug.
