Un site Web réactif et accessible n'est pas la même chose qu'une application accessible, même si les deux « fonctionnent sur le téléphone ». Cet article explique les différences essentielles entre rendre un site Web accessible et rendre accessible une application native iOS ou Android.
En bref : ce que couvre cet article
Technologie différente, règles similaires
Un site Web réactif est construit à partir de HTML, qui possède déjà une couche d'accessibilité intégrée (balises sémantiques, ARIA) que les navigateurs et les lecteurs d'écran savent interpréter. En revanche, une application native est construite à partir des composants d'interface utilisateur du système d'exploitation (UIKit/SwiftUI sur iOS, Jetpack Compose/Views sur Android) — et chaque composant a besoin de son propre balisage d'accessibilité, distinct de sa conception visuelle. Les principes sous-jacents ressemblent aux WCAG (contraste, taille de la cible tactile, nom clair et accessible), mais les outils pour les mettre en œuvre sont complètement différents.
VoiceOver et TalkBack : ce n'est pas le même lecteur d'écran
VoiceOver (iOS) et TalkBack (Android) sont deux lecteurs d'écran différents, avec des gestes de navigation différents et une prise en charge différente des composants personnalisés. Un composant parfaitement balisé sur iOS peut ne pas fonctionner correctement sur Android si les développeurs n'ont pas testé les deux plates-formes séparément. Vous ne pouvez pas supposer que "nous l'avons testé sur iOS, il doit donc également fonctionner sur Android".
💡Point important
Sur les deux plates-formes, chaque composant interactif (bouton, champ de saisie, image) a besoin : d'une étiquette d'accessibilité claire, d'un rôle/trait d'accessibilité défini, et parfois aussi d'un indice d'accessibilité qui explique ce qui se passe lorsqu'on l'appuie.
Ce qui est unique aux applications natives
Les applications natives sont également confrontées à des défis qui n'existent pas sur les sites Web : des gestes tactiles personnalisés (balayer, pincer) qui nécessitent une alternative accessible ; une navigation entre les écrans qui doit également avoir un sens via un lecteur d'écran ; et les notifications push qui doivent être accessibles même lorsqu'elles apparaissent en dehors de l'application elle-même. De plus, les tailles des cibles tactiles doivent atteindre un minimum de 44 x 44 pixels selon les directives d'Apple et de 48 x 48 dp selon les directives de Google – une exigence qui n'existe pas toujours sous la même forme sur les sites Web.
Comment tester une application accessible
- Activez VoiceOver ou TalkBack et essayez d'effectuer les tâches principales de l'application (inscription, achat, recherche) en les utilisant uniquement.
- Vérifiez le contraste et la taille du texte avec les paramètres d'accessibilité du système activés (texte plus grand, contraste élevé).
- Confirmez la prise en charge du dimensionnement dynamique du texte (Dynamic Type sur iOS) sans que la mise en page ne se « casse ».
- Testez séparément sur les deux plates-formes : tester une seule n'est pas suffisant.
Avez-vous également des documents qui accompagnent votre application ?
Notre outil analyse les fichiers PDF liés à votre application ou site Web (conditions d'utilisation, guides, formulaires) et vous montre exactement lesquels nécessitent votre attention.
Scannez votre site gratuitement ←Après le scan, vous pouvez également rendre accessibles directement et gratuitement les documents trouvés viaAccessiDoc.