Un expert accessibilité mobile passe ses journées avec un iPhone et un téléphone Android, VoiceOver et TalkBack activés. Il audite, rédige les anomalies dans le vocabulaire des développeurs (accessibilityLabel, traits, contentDescription, semantics de Jetpack Compose) et contrôle les correctifs. Le RGAA 4.1.2 décrit une méthode pour le web. Pour une application native, les équipes s'appuient sur la norme EN 301 549 ou sur le RAAM 1.1, publié par le gouvernement luxembourgeois et aligné sur cette norme.
Beaucoup de candidats viennent de l'audit web. Ils connaissent les critères mais n'ont jamais parcouru une hiérarchie de vues dans l'Accessibility Inspector de Xcode, ni poussé la taille du texte au maximum sur Android. Il s'agit de savoir comment ils testent un écran écrit en SwiftUI, en Compose ou en React Native, et ce qu'ils mettent dans un ticket. Sans aucun nom d'API dans la réponse, le profil reste web.
L'European Accessibility Act s'applique depuis le 28 juin 2025 aux applications de commerce en ligne, de services bancaires ou de transport de voyageurs. La DINUM annonce le RGAA 5 pour décembre 2026, avec un référentiel propre aux applications mobiles. Le PDF prolonge l'entretien avec 30 questions, un cas de 20 minutes et une grille de notation.
Plateformes, API et référentiels de l'accessibilité mobile
VoiceOver (iOS)
Le lecteur d'écran d'Apple, piloté par des gestes : balayage pour passer d'un élément à l'autre, exploration au toucher, rotor pour sauter de titre en titre. Le même appareil propose Commande vocale, Contrôle de sélection et l'accès au clavier complet. Un expert teste sur un vrai téléphone, le simulateur ne suffit pas.
TalkBack (Android)
Le lecteur d'écran de Google, avec Switch Access et Voice Access pour d'autres handicaps moteurs. Son comportement varie selon la version d'Android, la version de TalkBack et le constructeur. Un rapport sérieux note donc le modèle et les versions utilisés pour chaque test.
UIKit et SwiftUI
Les deux frameworks d'interface d'iOS. En UIKit, l'accessibilité passe par isAccessibilityElement, accessibilityLabel, accessibilityValue et accessibilityTraits. En SwiftUI, par des modificateurs comme accessibilityLabel, accessibilityElement(children:) ou accessibilityAddTraits(.isHeader). Le candidat doit écrire ses recommandations avec ces noms.
Android Views et Jetpack Compose
Côté Android, les vues classiques utilisent contentDescription, labelFor ou importantForAccessibility. Compose décrit l'accessibilité dans un arbre de semantics : mergeDescendants, Role, heading(), stateDescription, liveRegion. Beaucoup d'applications mélangent encore les deux, et l'expert doit lire les deux.
React Native et Flutter
Les applications multiplateformes ont leurs propres API : propriétés accessibilityLabel, role ou accessibilityState en React Native, widget Semantics en Flutter. La correction se fait dans le code partagé, puis se vérifie sur chaque système, car le même code ne produit pas toujours le même rendu vocal.
Accessibility Inspector, Accessibility Scanner et tests automatisés
L'Accessibility Inspector de Xcode affiche l'arbre d'accessibilité et lance un audit. Accessibility Scanner fait de même sur Android. En intégration continue, XCTest propose performAccessibilityAudit depuis Xcode 15 et Espresso dispose des AccessibilityChecks. Ces outils trouvent les libellés manquants, les contrastes et les cibles trop petites, jamais la pertinence d'un libellé.
EN 301 549, RAAM et WCAG 2.2
La norme EN 301 549 v3.2.1 est la version harmonisée en vigueur ; sa partie logiciel couvre les applications. La V4.1.1, publiée par l'ETSI le 2 septembre 2026 sur la base des WCAG 2.2, n'est pas encore citée au Journal officiel de l'UE. Le RAAM 1.1, publié en février 2025 par le Service information et presse du Luxembourg, la traduit en 108 critères testables. WCAG 2.2 ajoute des critères utiles au mobile, comme la taille minimale des cibles et les alternatives au glisser.
Réglages système et Dynamic Type
Texte dynamique sur iOS, taille de police jusqu'à 200 % depuis Android 14, contraste augmenté, mode sombre, réduction des animations. L'application doit respecter ces réglages sans casser ses écrans. Sur l'App Store, les Accessibility Nutrition Labels permettent à l'éditeur de déclarer ce qu'il prend en charge ; ils restent facultatifs pour l'instant.
Le poste existe chez les éditeurs d'applications grand public, dans les équipes digitales des grands groupes et dans les cabinets spécialisés en accessibilité, souvent en mission. Selon l'organisation, l'expert fait surtout de l'audit, ou il est intégré à une équipe produit et revoit chaque sprint. Les profils viennent soit de l'audit web, soit du développement iOS ou Android. Les premiers maîtrisent les référentiels, les seconds les API ; le poste demande les deux. L'anglais compte aussi si l'application est publiée dans plusieurs langues, car les tests se font dans chaque langue.
Ce qu'un expert accessibilité mobile doit prouver en entretien
- Lecteurs d'écran et aides techniques mobiles
- API d'accessibilité iOS (UIKit, SwiftUI)
- API d'accessibilité Android (Views, Compose)
- Texte agrandi, cibles tactiles et gestes
- Référentiels mobiles et méthode d'audit
- Tests automatisés et non-régression
Cinq questions posées à un expert accessibilité iOS et Android
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une cellule de liste affiche une photo, un nom de produit, un prix et un bouton favori. VoiceOver s'arrête quatre fois par ligne. Que demandez-vous à l'équipe iOS ?
Une bonne réponseRegrouper la cellule en un seul élément : accessibilityElement(children: .combine) ou un libellé composé en SwiftUI, isAccessibilityElement sur la cellule avec un label « nom, prix » en UIKit. La photo décorative sort de l'arbre. Le favori devient une action personnalisée (accessibilityCustomActions, ou accessibilityAction(named:) en SwiftUI) dont l'état est annoncé. Il précise l'ordre de lecture : le nom avant le prix.
Signal d'alerteAjouter « image produit » comme libellé de la photo et laisser les quatre arrêts, ou masquer le bouton favori pour simplifier la lecture.
Question 2 · confirmé
Dans une application en Jetpack Compose, une carte cliquable contient un titre, une date et une icône de suppression. TalkBack lit tout séparément et la suppression n'est atteignable qu'en visant l'icône. Que proposez-vous ?
Une bonne réponseFusionner la carte avec Modifier.semantics(mergeDescendants = true), ou laisser clickable le faire, avec un Role adapté. L'icône reçoit une contentDescription qui nomme l'action et l'objet (« Supprimer la réservation du 12 mars »). La suppression est aussi proposée comme action personnalisée (customActions), accessible depuis le menu d'actions de TalkBack. La zone tactile de l'icône fait au moins 48 dp.
Signal d'alerteUne contentDescription « icône poubelle », ou un clearAndSetSemantics qui efface le titre et la date sans les remplacer.
Question 3 · confirmé
À la plus grande taille de texte d'iOS, des libellés de boutons sont tronqués et un formulaire devient inutilisable. Qu'exigez-vous de l'équipe ?
Une bonne réponseDes styles de texte dynamiques (preferredFont(forTextStyle:) avec adjustsFontForContentSizeCategory en UIKit, polices sémantiques en SwiftUI), des libellés sur plusieurs lignes, aucune hauteur fixe et un contenu qui défile. Aux tailles d'accessibilité, les éléments alignés horizontalement passent à la verticale. Pour une barre d'onglets qui ne peut pas grandir, le Large Content Viewer. Sur Android, du texte en sp testé à 200 %.
Signal d'alertePlafonner la taille du texte dans toute l'application, ou répondre que l'utilisateur n'a qu'à réduire son réglage.
Question 4 · senior
Un client demande un audit de son application Android « selon le RGAA ». Que lui répondez-vous sur le référentiel et la méthode ?
Une bonne réponseLa méthode du RGAA 4.1.2 est écrite pour le web : on ne peut pas inspecter du HTML dans une application native. Il propose la norme EN 301 549 v3.2.1, partie logiciel, ou le RAAM 1.1 et ses 108 critères comme grille de test, et l'écrit dans le rapport avec le périmètre, les appareils et les versions. Il signale que le RGAA 5, annoncé par la DINUM pour décembre 2026 et officialisé par décret en 2027, permettra l'audit des applications mobiles avec un référentiel propre. Les webviews restent auditées avec le RGAA.
Signal d'alerteAppliquer le RGAA web à la lettre sur une application, ou affirmer qu'aucune obligation ne pèse sur les applications mobiles.
Question 5 · junior à confirmé
Vous recevez une application iOS et Android en recette. Comment organisez-vous vos tests avec VoiceOver et TalkBack ?
Une bonne réponseSur appareils réels, avec les versions de système les plus présentes chez les utilisateurs. Il déroule les parcours prioritaires d'abord au balayage, puis à l'exploration au toucher. Il contrôle les libellés, rôles et états, l'ordre de lecture, la position du focus après chaque action, les modales et les annonces de changement. Il ajoute un clavier externe et la commande vocale, et note l'appareil et les versions dans chaque résultat.
Signal d'alerteTester uniquement sur simulateur, sur une seule plateforme, ou se fier au rapport d'un outil automatique.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Expert accessibilité mobile : les questions fréquentes
Un expert accessibilité web peut-il auditer une application mobile ?
Il connaît les principes et souvent les critères WCAG, ce qui aide. Il lui manque en général la pratique des gestes VoiceOver et TalkBack, la lecture d'un arbre d'accessibilité natif et le vocabulaire des API iOS et Android. Sans eux, ses tickets restent vagues et les développeurs les corrigent mal. Un audit d'application déjà mené, avec les appareils utilisés et deux exemples d'anomalies écrites pour un développeur, le montre vite.
Un expert accessibilité mobile doit-il savoir coder ?
Il n'écrit pas forcément de code en production, mais il doit lire un extrait SwiftUI, UIKit, Compose ou React Native et proposer la bonne propriété. Un ticket qui dit « ajouter accessibilityAddTraits(.isHeader) sur ce titre » se corrige en dix minutes. Un ticket qui dit « le titre n'est pas un titre » revient avec des questions. Les profils passés par le développement mobile ont un avantage net sur ce point.
Quel test technique proposer à un expert accessibilité mobile ?
L'exercice porte sur une application publique ou une build de recette, avec vingt minutes sur un parcours court, sous VoiceOver ou TalkBack. Trois anomalies sont rédigées comme des tickets : écran, étapes, comportement entendu, comportement attendu, critère, correction proposée. On juge la méthode de test, la précision du vocabulaire et le sens des priorités. L'exercice se fait en direct, téléphone partagé à l'écran, pour suivre ses gestes.
Quelles certifications regarder sur le CV d'un expert accessibilité mobile ?
Les certifications de l'IAAP, CPACC pour les fondamentaux et WAS pour la technique, sont les plus citées. Elles portent surtout sur le web et sur les principes généraux. Une formation à l'audit mobile ou au RAAM montre un intérêt pour le sujet. Rien de tout cela ne remplace un audit d'application réalisé, avec son rapport et le suivi des corrections. Un extrait anonymisé suffit à en juger.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
