Le petit guide des apps iOS inclusives & accessibles

Ce petit guide se présente comme une introduction à l’accessibilité pour les développeurs et développeuses iOS. Les samples de code seront principalement proposés en SwiftUI.

Sommaire

• Introduction
• Les règles d’or de l’accessibilité
• VoiceOver: Le lecteur d’écran intégré à iOS pour les utilisateurs non-voyants
• Agrandissement des items et des polices (Dynamic Type)
• Contrastes et couleurs
• Actions tactiles accessibles à tous
• Outils de test
• Conclusion & Pour aller plus loin
  

Introduction

Pourquoi l’accessibilité est-elle importante ?

L’accessibilité numérique n’est pas un « nice-to-have », c’est une nécessité. Nos applications doivent être utilisables par le plus grand nombre, dans toutes les situations de la vie :

• Handicap durable ou temporaire : malvoyance, troubles moteurs, déficience auditive
• Fatigue : après une longue journée, notre capacité de concentration diminue
• Vieillissement : presbytie, arthrite, troubles cognitifs légers
• Difficultés de lecture : dyslexie, illettrisme, barrières linguistiques
• Diversité des appareils : différentes tailles d’écrans, conditions d’utilisation variées
• Et plus encore!
  

Il est important de prendre en compte l’ensemble de ses utilisateurs dès le début de la conception d’une application, ce n’est pas parce que « les personnes handicapées n’utiliseront pas mon app » qu’il ne faut rien faire, c’est un présupposé faux mais si votre app n’est pas accessible effectivement cela vous donnera raison… pourtant à tort.

Un contexte légal qui évolue

Depuis le 29 juin 2025, l’European Accessibility Act (EAA) est entré en vigueur. Cette directive européenne (disponible ici en anglais) impose aux entreprises de l’Union européenne de rendre leurs services numériques accessibles à tous, y compris aux personnes en situation de handicap.

À noter que l’État français ne donne pas l’exemple, ces services restent très très peu accessibles quand bien même c’est une obligation, un exemple à ne PAS suivre!

Du côté de l’App Store

Apple a également renforcé son engagement avec l’introduction d’étiquettes d’accessibilité sur les pages produits de l’App Store. Ces étiquettes mettent en évidence les fonctionnalités d’accessibilité intégrées aux apps :

Cela permet aux utilisateurs de vérifier l’accessibilité d’une app avant téléchargement et aux développeurs de valoriser leurs efforts d’accessibilité.

Attention, pour le moment il n’y a pas de vérifications de l’accessibilité du côté de l’App Store, ces étiquettes sont purement déclaratives!

Les règles d’or de l’accessibilité

Règle n°1 : diversifier les canaux d’information

Favorisez plusieurs manières de transmettre l’information, sans trop en faire :

Par exemple pour une carte géographique: proposez l’information sous forme de liste en parallèle de la carte

Vous pouvez également intégrer des retour haptiques (vibrations) quand l’action d’un bouton est réussie :

let impactMed = UIImpactFeedbackGenerator(style: .medium)

impactMed.impactOccurred()

Afin d’aider les utilisateurs, soignez vos indicateurs visuels : pensez aux contrastes et évitez de transmettre l’information uniquement par la couleur

Règle n°2 : La sobriété avant tout

Évitez la surcharge sensorielle, un trop plein d’animations :

• Fait perdre la concentration
• Favorise les nausées
• Augmente la fatigue cognitive

VoiceOver: Le lecteur d’écran intégré à iOS pour les utilisateurs non-voyants

Apple propose un outil de lecture d’écran, le Voice Over, pour les utilisateurs mal ou non-voyants. SwiftUI propose des règles et des outils simples pour implémenter le support de Voice Over.

Hiérarchiser les informations

Bien hiérarchiser vos informations, en plus d’être une règle universelle d’UX, permet une utilisation simplifiée du Rotor de Voice Over (menu circulaire virtuel dans VoiceOver, accessible par un geste de rotation à deux doigts comme un cadran rotatif) permettant de sauter rapidement entre différents types d’éléments sur l’écran.
Cette hiérarchisation des informations peut se faire facilement via les composants de base de SwiftUI:

• Group pour regrouper logiquement les éléments
• Le modifier .accessibilityElement(children: .combine/.ignore/.contain) : .combine pour grouper des éléments, .ignore pour fournir son propre label,.contain par défaut
• List et Section pour organiser les contenus
• NavigationTitle

Gestion des images

Pour une gestion correcte des images via le Voice Over vous avez deux stratégies:

• Masquer les images décoratives
• Décrire les images

Masquage des images :

Image("decoration")
    .accessibilityHidden(true)

Description des images :

Image("logo_book")
    .resizable()
    .scaledToFit()
    .frame(width: 175, height: 175)
    .accessibilityLabel("Oiseau avec des lunettes et une prothèse à la patte, lisant un livre")

Dans le cas où vos utilisateurs ajoutent leurs propres images,  demandez-leur de les décrire ! Stockez ce texte alternatif dans votre structure de données aux côtés de l’image.

Si vos images proviennent d’une API vous pouvez soit les spécifier comme décoratives soit utiliser les descriptions disponibles, quand elles existent.

Boutons

Si vous utilisez le composant Button de SwiftUI, le Voice Over le détectera bien comme tel, cela dit quelques règles s’appliquent:

• Le label doit être explicite (règle valable pour tous les utilisateurs)
• Pour les boutons sous forme d’icônes, vous devez leur attacher un label d’accessibilité

Button {
    showAlertReDO.toggle()
} label: {
    Image(systemName: "arrow.counterclockwise")
        .foregroundColor(.teal)
}
.accessibility(label: Text("Réinitialiser le test"))

Si vous souhaitez rajouter un complément d’information (hint), il faut utiliser le modifier .accessibilityHint().
Ce n’est pas obligatoire , à rajouter si l’action n’est pas évidente ou à des conséquences importantes, comme par exemple la suppression définitive d’informations.

Button("Supprimer") {
    deleteItem()
}
.accessibilityHint("Supprime définitivement la photo")

« Et si j’ai pris la (mauvaise) habitude de ne pas utiliser le composant Button mais de créer des éléments cliquables via onTapGesture?« 

Les « faux » boutons sont les ennemis de l’accessibilité! Le Voice Over ne les interprète pas comme des boutons! Il faut donc ajouter un « trait » d’accessibilité pour faire comprendre à l’outil que ce faux bouton en est un, en plus de décrire l’action qu’il effectue.

Image(systemName: "heart")
    .accessibilityHidden(true)
    .accessibility(addTraits: .isButton)
    .accessibility(label: Text("Ajouter le lieu à vos favoris"))
    .onTapGesture {
        // code de l'action
    }

Les utilisateurs de Voice Over peuvent également avoir plusieurs actions proposées pour un bouton :

Text("Article")
    .accessibilityAction(.default) {
        // Action principale
    }
    .accessibilityAction(.activate, "Partager") {
        // Action secondaire
    }

• L’action .default est l’action principale, déclenchée par un double-tap sur l’élément: ici le double-tap ouvre l’article
• L’action .activate avec le label « Partager » crée une action secondaire accessible via le « rotor » de VoiceOver (un geste de rotation avec deux doigts qui permet de naviguer entre les actions disponibles): ici le rotor permet de partager l’article sans même l’ouvrir

Et les autres composants alors?

Pour les autres composants SwiftUI (Picker, Link, TabView, etc), des labels explicites!
À noter que vous pouvez détecter si le Voice Over est activé ou non :

@Environment(\.accessibilityEnabled) private var accessibilityEnabled

@Environment(\.accessibilityVoiceOverEnabled) private var voiceOverEnabled

Très pratique parce que le lecteur d’écran n’implique pas seulement la description vocale des éléments mais aussi une manière différente d’effectuer les actions!
Par exemple un double tap au lieu d’un seul pour une action, les swipes non correctement gérés, les notifications d’état (voir ci-dessous), etc.

Notifications d’état

Les notifications d’état permettent d’annoncer vocalement un changement d’état à l’utilisateur, VoiceOver interrompt ce qu’il est en train de lire, annonce vocalement ce qui est spécifié puis reprend sa lecture normale

AccessibilityNotification.Announcement("Article sauvegardé")
   .post()

Agrandissement des items et des polices (Dynamic Type)

De nombreux utilisateurs agrandissent la taille des caractères sur leurs téléphone, par confort, handicap ou parce que la vue baisse avec l’âge, ne les oubliez pas!

Agrandissement de polices : Le trio gagnant

1. Dynamic Type : utilisez les styles de police système ou adaptez vos fonts en fonction des types de tailles existantes (title, title2, body, footnote, etc)

Text("Mon texte")
    .font(.title)

2. ScrollView : rendez vos blocs de texte scrollables

3. Limitation des lignes : supprimez les limitations

Text("Long texte...")
    .lineLimit(nil)

Agrandissement des autres éléments

Utilisez @ScaledMetric pour adapter les espacements et tailles :

@ScaledMetric(relativeTo: .body) var defaultScaledPadding:
: CGFloat = 8

Contrastes et couleurs

Tester les contrastes

Faites attention aux contrastes (couleurs des textes sur les fonds et les images). Un manque de contraste peut rendre illisible vos textes ou fatiguer vos utilisateurs.
Utilisez des outils comme le Contrast Checker pour valider vos contrastes texte/fond.

Différentiation des couleurs

Ne vous appuyez jamais uniquement sur la couleur pour transmettre une information, ajoutez toujours :
– Des icônes
– Du texte explicatif
– Des patterns visuels différents

Actions tactiles accessibles à tous

Quand les gestes complexes sont impossibles

Certains handicaps et faiblesses musculaires rendent les actions tactiles compliquées voir impossible à effectuer. Proposez des alternatives aux gestes complexes :
– Clics longs → boutons dédiés
– Gestes multi-doigts → options dans les menus
– Pincer pour zoomer → boutons + et –

Switch Control

Switch Control est une technologie d’accessibilité d’Apple qui permet de contrôler l’appareil iOS/macOS avec des contacteurs externes (switches: bouton physiques adaptés par exemple un joystick, une manette, un bouton unique, le contacteur Blue2 Ablenet, le XBox Adaptative Controller, etc. ) au lieu de l’écran tactile. Cela concerne principalement des utilisateurs avec des handicaps moteurs très importants ne pouvant pas utiliser l’écran tactile normalement.

Votre app est scannée automatiquement : les éléments sont surlignés un par un ou par groupe, quand le bon élément est surligné, l’utilisateur appuie sur son contacteur pour le sélectionner.

Détecter si Switch Control est actif :

@Environment(\.accessibilityEnabled) var accessibilityEnabled

@Environment(\.accessibilitySwitchControlEnabled) var switchControlEnabled

Ensuite, vous pouvez revoir à la fois l’UI et l’UX de l’app, lorsque que cet outil est activé.
Quelques conseils : 

– Groupez les éléments pour faciliter la navigation
– Simplifiez les interfaces complexes
– Définissez l’ordre de scan des éléments (textes, boutons, etc)
– Masquez les éléments décoratifs et « inutiles ».

Une belle app c’est bien mais si elle n’est pas utilisable elle ne sert plus à rien! Un simple if/else vous permet néanmoins de garder votre design principal pour la grand majorité de vos utilisateurs.

var body: some View {

    VStack {

        if switchControlEnabled {
            Text("Mode Switch Control activé")
            AdaptativeView()
        } else {
            ClassicView()
        }
    }
}

Principe clé : Avec le Switch Control comme avec le Voice Over, moins c’est mieux. Chaque élément supplémentaire = plus de temps de scan pour l’utilisateur. L’idée est de réduire le nombre d’interactions nécessaires.

Quand aucune action tactile n’est possible: le contrôle vocal (Voice Control)

Assurez-vous que tous vos éléments interactifs peuvent être activés par la voix. SwiftUI gère cela automatiquement si vos labels d’accessibilité sont bien définis.

Lorsqu’un utilisateur active le Voice Control, il peut l’activer avec différents mode, activés avec les phrases :
– Afficher les numéros
– Afficher la grille
– Afficher les noms

Du côté du développeur, on va pouvoir modifier ce qui touche à l’affichage par noms, pour rendre l’expérience la plus facile possible (des nom courts et intuitifs).
Comme pour le Voice Over, sur nos composants effectuants des actions (boutons, pickers, toggles, etc.) on rajoute des labels d’entrée, c’est à dire une liste de mots clés vocaux : .accessibilityInputLabels() qui prend en paramètre un tableau de Strings (localisées)

         Button {
            isShown = false
        } label: {
            Image(systemName: "xmark"
        }
        .accessibility(label: Text("Close the page"))
        .accessibilityInputLabels(["Close", "Close the page", "Previous", "Return"])

Utilisez de préférence des phrases (très) courtes et classez les mots-clés par ordre d’importance.

Outils de test

Accessibility Inspector (Xcode)

L’inspecteur d’accessibilité est un outil au sein de XCode qui va permettre de:
– Tester la sémantique des composants
– Naviguer dans l’arborescence d’accessibilité
– Simuler VoiceOver
– Effectuer un audit de l’accessibilité

Tests sur appareils physiques

N’oubliez pas de tester directement sur vos différents devices iPhone, iPad et Mac en activant les différentes options d’accessibilités présentes dans les réglages.

Vous devez tester tout vos parcours utilisateur en activant les différentes options d’accessibilité. N’hésitez pas non plus à varier les devices! (petit iPhone, iPad, etc).

Il y a beaucoup d’outils d’accessibilités et beaucoup de composants dans vos différents écrans à tester, pour vous aider à être le plus exhaustif possible, Apple a documenté de nombreux cas à tester consultable ici (en anglais).

Tests automatisés

SwiftUI permet aussi d’écrire des tests d’accessibilité via le framework XCTest, en vérifiant que les éléments importants sont bien reconnus par VoiceOver (label correct, élément existant et utilisable) et que la navigation reste accessible. Par exemple, dans une vue de connexion :

Button("Se connecter") {
    login()
}
.accessibilityLabel("Se connecter au compte")
.accessibilityHint("Valide l'email et le mot de passe puis ouvre l'écran principal")
.accessibilityIdentifier("loginButton")

On peut ensuite écrire un test UI simple pour vérifier que l’accessibilité du bouton est correcte:

func testLoginButtonAccessibility() {
    let app = XCUIApplication()
    app.launch()    
    let loginButton = app.buttons["loginButton"]    
XCTAssertTrue(loginButton.exists)
    XCTAssertTrue(loginButton.isHittable)
    XCTAssertEqual(loginButton.label, "Se connecter au compte")
}

Depuis iOS 17, on peut aussi lancer un audit automatique d’accessibilité qui détecte les labels manquants, tailles tactiles insuffisantes ou problèmes de contraste, n’hésitez pas à explorer cette nouvelle fonctionnalité! Plus d’infos ici.

unc testAccessibilityAudit() throws {
    let app = XCUIApplication()
    app.launch()
    try app.performAccessibilityAudit()
}

Tests utilisateurs

Peut être le plus important et le plus pertinent: Pensez à inclure des personnes en situation de handicap dans vos tests utilisateurs, par leurs habitudes, leurs manières d’utiliser leurs téléphones et applications parfois d’une manière très différente de la nôtre, tout cela fait que leurs retours sont les plus précieux!

Conclusion

L’accessibilité n’est pas une fonctionnalité à ajouter en fin de projet, c’est une philosophie de conception qui doit être intégrée dès le début. En suivant ces principes et en utilisant les outils fournis par SwiftUI et iOS, vous créerez des applications véritablement inclusives, et le temps passé à géré l’accessibilité sera minime!

L’effort initial de formation et de conception peut sembler important, mais les bénéfices sont immenses : une meilleure UX pour tous, un cadre légal respecté et la satisfaction de contribuer à un numérique plus équitable!

N’oubliez pas : une application accessible est une application de meilleure qualité pour tous ! 💪🦾

Ressources pour aller plus loin

– Documentation Apple : Les incontournables HIG – Human Interface Guidelines qui incluent en l’accessibilité dans leur guide (en anglais).

– WWDC : Écrire de bons labels accessibles: Writing Great Accessibility Labels (2019, en anglais)

– Communautés en ligne : mobilea11y et le hashtag #a11y sur les réseaux sociaux

– Podcast : Le podcast Tech Etic pour les enjeux éthiques du numérique, avec des épisodes dédiés à l’accessibilité.