Comment faire les tests d’accessibilité de l’iPhone Duo ? Checklist de réception 2026 compatible avec l’iPhone 18 Pro

Dernière mise à jour : 17 septembre 2026. Les éléments relatifs à l’iPhone Duo sont à recouper avec les documents officiels Apple consacrés à l’appareil, à la mise en page adaptative et aux tests d’accessibilité.

Décision : il est adapté de commencer par l’iPhone 18 Pro pour valider les tâches communes, puis d’ajouter l’iPhone Duo pour les changements d’écran, la continuité du foyer VoiceOver et la restauration de l’état. Il n’est pas adapté de tenter toutes les combinaisons d’aides techniques et d’états d’affichage avant d’avoir identifié les parcours qui ne peuvent pas échouer.

Cette méthode convient aux équipes iOS qui doivent établir une base commune, aux responsables accessibilité des secteurs financier, médical ou public qui doivent conserver des preuves d’audit, ainsi qu’aux équipes QA qui veulent séparer inspection, automatisation et manipulation humaine. Elle est également utile aux équipes produit audio, vidéo et design, car la continuité d’un montage, d’une lecture ou d’une prévisualisation ne se juge pas uniquement avec un contrôle statique.

Le défaut le plus coûteux apparaît au milieu d’une tâche

Prenons un cas fréquent : une personne remplit un formulaire, saisit une adresse et sélectionne une option. Elle replie ensuite l’iPhone Duo pour poursuivre sur l’écran extérieur. Après la transition, le champ actif n’est plus annoncé, le texte saisi a disparu et le bouton de confirmation se trouve derrière une zone non atteignable avec VoiceOver. L’application n’a pas planté ; pourtant, la tâche accessible est interrompue.

Ce scénario montre pourquoi un contrôle limité à la présence d’étiquettes ou à l’absence de crash donne un faux sentiment de sécurité. Nous devons observer simultanément :

• la lisibilité et l’atteignabilité des commandes ;
• la position du foyer d’accessibilité après la transition ;
• la conservation des données et du contexte métier ;
• la possibilité de terminer l’action avec la méthode de saisie choisie.

Apple fournit une méthode générale pour tester l’accessibilité d’une application ; nous nous en servons comme base, sans considérer qu’elle décrit automatiquement le comportement propre à chaque état de l’iPhone Duo. Les caractéristiques précises des aides techniques et des transitions doivent être confirmées avec le SDK, les outils de simulation disponibles et l’appareil physique. La documentation officielle de développement pour l’iPhone Duo constitue le point de départ pour les changements de disposition et de taille d’affichage.

Les tests d’accessibilité de l’iPhone Duo commencent par un socle commun

Nous attribuons d’abord un niveau de risque à chaque parcours, plutôt qu’à chaque écran. Un parcours critique regroupe par exemple l’authentification, la saisie d’un formulaire, la confirmation d’une opération, la modification d’un contenu ou la reprise d’une lecture audio ou vidéo. Une page décorative ou une vue rarement visitée ne doit pas monopoliser le même temps de test.

Le socle commun est exécuté sur l’iPhone 18 Pro. Nous y vérifions les composants et les règles qui restent applicables quel que soit l’appareil :

• les titres, libellés et messages d’erreur sont annoncés dans un ordre compréhensible ;
• les contrôles essentiels possèdent un nom stable et une valeur utile ;
• la taille du texte ne masque ni le champ actif ni l’action suivante ;
• le gras, les formes de boutons et les contrastes ne dégradent pas la compréhension ;
• les états sélectionné, désactivé, chargé et en erreur sont perceptibles ;
• Voice Control, Switch Control et le clavier externe permettent d’atteindre les commandes principales.

Pour la typographie, nous confrontons les résultats aux recommandations Apple sur Dynamic Type et la mise en forme du texte. Nous ne validons pas un écran parce que ses caractères agrandis restent dans leur conteneur : il faut suivre le parcours jusqu’à l’envoi, l’achat, la confirmation ou la sortie.

Sur l’iPhone Duo, nous reprenons ensuite ces mêmes tâches dans les états réellement proposés par l’application. Les points supplémentaires sont les suivants :

• la transition entre écran extérieur et écran intérieur ;
• l’ouverture et la fermeture d’une vue modale ou d’un panneau de navigation ;
• le retour au même champ, élément de liste ou position de lecture ;
• la conservation des choix, du texte saisi et des erreurs ;
• la réorganisation éventuelle des commandes sans perte de sens.

Cette séparation évite de confondre compatibilité générale et adaptation au dispositif pliable. L’iPhone 18 Pro mesure la solidité du parcours commun ; l’iPhone Duo révèle les ruptures introduites par la continuité entre affichages.

Première étape : vérifier que le texte agrandi ne supprime pas l’action

Nous préparons les écrans avec Dynamic Type, le texte en gras et les formes de boutons activées lorsque ces options sont prises en charge par le système ou par l’application. Chaque état doit être examiné avec une tâche concrète, pas avec une simple capture visuelle.

Pour un formulaire, nous suivons le champ jusqu’au message d’erreur, puis jusqu’à la soumission. Pour un parcours commercial, nous contrôlons la sélection, le récapitulatif, la confirmation et la possibilité de revenir en arrière. Pour une interface audio ou vidéo, nous vérifions la lecture, la pause, la progression et la reprise.

Les défauts à consigner sont précis :

• un bouton tronqué ou déplacé hors de la zone atteignable ;
• une erreur visible mais non annoncée ;
• un texte qui recouvre le champ suivant ;
• une commande dont le libellé change entre les deux écrans ;
• une zone défilante qui empêche de retrouver l’action principale.

Nous conservons une capture, le nom du parcours, l’état d’affichage, la version du système et le numéro de build. Une anomalie d’apparence devient bloquante si elle empêche une personne de confirmer, corriger ou quitter une tâche essentielle.

Deuxième étape : tester le foyer VoiceOver après chaque changement d’affichage

Le foyer VoiceOver ne doit pas être supposé stable parce que la vue semble identique. Après un repliement, un dépliement, une rotation logique de la disposition ou une ouverture de panneau, nous relevons l’élément annoncé avant la transition et celui annoncé après.

Nous recherchons quatre résultats défavorables :

• le foyer revient au début de la page sans raison compréhensible ;
• il se place sur un élément caché ou devenu inutilisable ;
• il conserve un ancien contrôle alors que le contexte métier a changé ;
• il disparaît et oblige à parcourir toute la hiérarchie.

Lorsqu’une vue est remplacée, l’application doit communiquer le changement de manière cohérente. La documentation Apple sur la notification layoutChanged aide à déterminer quand une modification de disposition doit être annoncée et quand le foyer doit être repositionné. Cette référence ne dispense toutefois pas d’une observation avec VoiceOver : l’intention du développeur et l’expérience réelle peuvent diverger.

Nous vérifions également les fenêtres modales, les menus et les listes. Si une personne modifie le troisième élément d’une liste, elle doit pouvoir comprendre où elle se trouve après la transition, retrouver l’élément modifié et continuer sans recommencer toute la navigation. Le chiffre de position n’est pas une preuve suffisante ; l’annonce doit donner un contexte exploitable.

Troisième étape : provoquer une transition pendant un parcours non récupérable

Nous choisissons des actions dont la répétition est coûteuse ou impossible : connexion avec saisie de code, édition d’un formulaire, sélection d’une option, validation d’une commande et lecture multimédia en cours. Nous lançons la transition au milieu de la tâche, puis nous comparons l’état avant et après.

Les éléments à relever sont les suivants :

• le texte déjà saisi ;
• l’option sélectionnée ;
• l’étape atteinte dans le parcours ;
• le message d’erreur ou de validation ;
• la position de lecture audio ou vidéo ;
• le clavier visible ou masqué ;
• le foyer d’accessibilité et le contrôle actif.

Nous ne classons pas l’essai comme réussi simplement parce que l’application reste ouverte. Une application peut éviter le crash tout en effaçant le contenu, en masquant l’erreur ou en renvoyant la personne vers une page sans explication. Dans un produit de création audio, perdre la position de lecture peut interrompre une écoute ; dans un outil de montage vidéo, perdre la sélection en cours peut rendre la reprise ambiguë ; dans un outil de design, une modification non confirmée peut être impossible à retrouver.

Les développeurs peuvent utiliser la simulation pour reproduire plus vite les changements de contrainte et isoler un défaut logique. La décision de réception reste fondée sur l’appareil physique lorsque la transition, le foyer ou le comportement du système intervient.

Quatrième étape : donner une place réelle aux méthodes de commande assistée

Une commande atteignable au toucher n’est pas nécessairement atteignable avec Voice Control, un clavier externe ou Switch Control. Nous sélectionnons les commandes indispensables et vérifions leur nom, leur ordre, leur état visible et leur retour après activation.

Avec Voice Control, nous essayons le libellé affiché et le nom annoncé. Si deux boutons portent des noms proches, la commande vocale peut devenir ambiguë. Avec un clavier externe, nous suivons l’ordre de déplacement, l’accès aux actions principales et la visibilité du focus. Les recommandations Apple sur l’interaction au clavier servent de référence pour cette partie.

Nous excluons les parcours qui exigent exclusivement :

• un glissement très précis ;
• un survol qui n’a pas d’équivalent au clavier ou à la voix ;
• une succession de gestes sans indication de l’état ;
• une zone active sans libellé ni retour visuel ;
• une commande disponible uniquement dans une région difficile à localiser.

Il ne s’agit pas de parcourir mécaniquement toute l’application avec chaque méthode. Nous priorisons les tâches définies avec les utilisateurs réels et les fonctions dont l’échec bloque l’inscription, l’achat, l’édition ou la consommation d’un contenu.

Cinquième étape : répartir inspection, automatisation et manipulation humaine

Nous organisons la validation en trois couches distinctes.

La première couche est statique. Accessibility Inspector aide à repérer une étiquette absente, une valeur incohérente, une hiérarchie difficile à comprendre ou une propriété mal exposée. La documentation Apple d’Accessibility Inspector décrit son rôle et ses limites. Nous enregistrons les défauts qu’il trouve, mais nous ne transformons pas son absence d’alerte en preuve de conformité.

La deuxième couche est automatisée. Les tests XCTest peuvent vérifier des identifiants, la présence de contrôles, certains états et la progression d’un parcours stable. La documentation XCTest permet de rattacher ces contrôles à la chaîne de régression. Les tests automatisés sont particulièrement utiles sur l’iPhone 18 Pro pour les parcours communs et sur l’iPhone Duo pour les transitions reproductibles que l’équipe a explicitement modélisées.

La troisième couche est humaine. Une personne utilise VoiceOver, agrandit le texte, change de méthode de commande et interrompt la tâche à des moments réalistes. Cette couche est obligatoire pour les parcours critiques, car elle évalue la compréhension, l’orientation, la récupération et l’effort demandé. Les principes d’accessibilité des interfaces Apple complètent les tests techniques, sans se substituer à l’usage observé.

Cette organisation réduit la matrice sans éliminer les risques. Une montée en capacité des machines peut résoudre un blocage de compilation ou de concurrence, mais elle ne remplace pas la session manuelle avec les aides techniques.

La checklist de réception à joindre au build

Nous attachons cette liste à chaque version candidate et nous inscrivons le résultat, la preuve et le responsable à côté de chaque ligne.

• [ ] Identifier les trois parcours dont l’échec empêcherait une connexion, une validation, une modification ou une lecture.
• [ ] Exécuter les parcours communs sur l’iPhone 18 Pro avec texte agrandi, texte en gras et formes de boutons lorsque l’application les prend en charge.
• [ ] Vérifier que chaque champ, erreur, bouton de confirmation et action de sortie reste visible, annoncé et atteignable.
• [ ] Examiner les mêmes parcours sur l’iPhone Duo dans les états d’affichage réellement utilisés par l’application.
• [ ] Déclencher une transition pendant une saisie, une sélection, une confirmation et une lecture audio ou vidéo.
• [ ] Noter le foyer VoiceOver avant et après la transition, y compris dans les listes, panneaux et fenêtres modales.
• [ ] Confirmer la conservation du texte, des choix, de l’erreur, de l’étape et de la position de lecture.
• [ ] Tester les commandes prioritaires avec Voice Control, un clavier externe et Switch Control.
• [ ] Lancer Accessibility Inspector sur les écrans à risque et joindre les résultats utiles au ticket.
• [ ] Exécuter la régression automatisée prévue avec XCTest, sans la présenter comme une preuve de validation humaine.
• [ ] Réaliser la session manuelle finale sur l’iPhone Duo pour les changements d’écran et sur l’iPhone 18 Pro pour le socle commun.
• [ ] Archiver l’état de l’appareil, la version du système, le numéro de build, les réglages d’accessibilité et les captures nécessaires.

Le score de risque est simple à appliquer. Un défaut qui bloque une tâche critique est bloquant et doit être fermé avant publication. Un défaut qui rend la tâche compréhensible seulement après plusieurs essais est dégradant : il doit recevoir un responsable, une solution de repli et une version de réexamen. Une imperfection visuelle sans conséquence sur l’accès à l’action est une anomalie générale, à documenter sans la confondre avec une conformité complète.

Une matrice réduite reste défendable si elle explique ses exclusions

Nous ne conservons pas toutes les combinaisons possibles dans la batterie permanente. Nous gardons le socle commun sur l’iPhone 18 Pro, puis les transitions qui correspondent aux usages de l’iPhone Duo. Si une application ne propose aucun parcours continu pendant la lecture vidéo, la reprise vidéo ne mérite pas le même niveau de couverture qu’une authentification ou qu’un formulaire.

Chaque exclusion doit cependant avoir une raison écrite : fonctionnalité absente, risque faible démontré, contrôle déjà couvert par une inspection ou scénario reporté vers une session manuelle. Les équipes financières, médicales et publiques doivent ajouter les preuves imposées par leur processus interne, notamment pour les messages d’erreur, la confirmation des choix et la traçabilité de la version testée.

Au 17 septembre 2026, nous considérons les documents Apple comme la base méthodologique, et non comme une garantie sur chaque interaction de l’iPhone Duo. Une nouvelle version du SDK, un outil de simulation ou la disponibilité de Xcode 27.1 beta peut modifier ce qui doit être réexaminé ; les comportements de foyer, de restauration d’état et de commande assistée doivent donc être revérifiés avant la publication avec les versions effectivement utilisées par l’équipe.

Les limites de la solution actuelle avant de louer un environnement Mac

Une équipe qui conserve uniquement un Mac local peut se heurter à une file d’attente de compilation, à l’indisponibilité de l’appareil physique au moment de la réception et à une collaboration difficile entre développeurs, QA et responsable accessibilité. Un environnement généraliste ou une machine partagée ajoute souvent une autre contrainte : les réglages d’accessibilité et les preuves de test ne restent pas toujours isolés pour la version candidate.

La location d’un environnement Mac chez zekmac peut être plus adaptée lorsqu’il faut ouvrir temporairement une capacité de construction, organiser une validation distante ou donner à plusieurs intervenants un accès coordonné à un environnement de test. Elle ne remplace ni l’iPhone Duo physique ni l’observation par une personne utilisant VoiceOver ; elle évite surtout que la file de construction ou la disponibilité limitée des outils empêche la session prévue. Pour un usage permanent, très intensif ou dépendant d’interfaces physiques particulières, l’achat d’un Mac dédié reste à comparer avec honnêteté.

Avant de retenir cette option, nous recommandons de définir les trois tâches non négociables, la preuve attendue pour chacune et le moment où l’appareil physique doit être réservé. La capacité distante doit servir ce plan de réception, pas masquer l’absence de validation humaine.