SwiftUI a véritablement révolutionné le développement iOS et l'accessibilité. En plus de faciliter la création d'applications élégantes avec moins de code, il offre de nombreuses fonctionnalités qui aident les développeurs à proposer une expérience d'accessibilité de qualité. Si vous avez lu la première partie de cette mini-série d'articles, vous connaissez déjà les atouts de l'accessibilité avec SwiftUI, mais pas encore ses pièges.
Qu'est-ce qu'un « piège » ? Les pièges sont des éléments susceptibles d'inciter les développeurs à commettre des erreurs d'accessibilité. Il est important de noter qu'une fonctionnalité utile peut se transformer en piège si elle est mal utilisée. Dans la deuxième partie de notre série d'articles consacrés à SwiftUI et à l'accessibilité, nous aborderons le revers de la médaille des fonctionnalités utiles : les pièges !
Astuce n° 1 : Accessibilité de base par défaut
Vous vous souvenez quand j’ai dit tout à l’heure que les fonctionnalités utiles pouvaient aussi devenir des pièges si elles étaient mal utilisées ? Eh bien, l’accessibilité de base par défaut – notre premier piège – en est un parfait exemple ! Aussi impressionnantes que soient les capacités d’accessibilité par défaut, cette expérience d’accessibilité « prête à l’emploi » peut varier considérablement selon la vue. L’expérience d’accessibilité de base peut être suffisante pour certaines vues d’une application, mais elle peut se traduire par une mauvaise expérience d’accessibilité pour d’autres !
Prenons l’exemple de l’écran « Ajouter une plante » dans Plantiverse. Cet écran contient un champ de texte par défaut, deux sélecteurs, un bouton bascule personnalisé, un curseur personnalisé et un sélecteur à pas personnalisé. Plusieurs éléments sautent aux yeux lorsque l’on parcourt cet écran avec VoiceOver ; d’une part, les éléments situés dans des vues contenantes ne sont pas regroupés (par exemple, les deux sélecteurs) ; ce qui entraîne une répétition des informations et nécessite des balayages supplémentaires pour accéder à toutes les informations nécessaires concernant les commandes. De plus, il est difficile de savoir quelles informations correspondent à quoi. Un autre point qui ressort particulièrement concerne les commandes personnalisées de notre écran : les annonces de VoiceOver les concernant sont, au mieux, prêtant à confusion et, au pire, inexistantes.
Nous avons vu que les contrôles personnalisés ne disposent pas des mêmes fonctionnalités d'accessibilité par défaut que les contrôles standard. Nous pouvons le constater à l'écran avec les trois contrôles personnalisés : le bouton bascule, le curseur et le sélecteur à pas. Voyons maintenant ce qu'il en est pour chacun de ces contrôles :
L'annonce personnalisée associée au bouton bascule ne précise pas clairement qu'il s'agit d'un bouton ; par conséquent, un utilisateur de VoiceOver ne pourrait pas le deviner à partir de l'annonce seule.
Le curseur personnalisé met en évidence et sélectionne l'étiquette et l'étiquette de valeur associées au contrôle, mais le contrôle actif (le curseur lui-même) est complètement ignoré et n'est jamais sélectionné.
Cette expérience est déplorable : cela signifie qu’une personne utilisant une technologie d’assistance ne peut pas utiliser ce curseur. VoiceOver met bien en surbrillance les libellés et les boutons du curseur à paliers personnalisé ; cependant, nous devons tout de même faire défiler d’avant en arrière entre le libellé de la valeur et les boutons d’augmentation/diminution si nous voulons entendre la valeur actuelle associée au curseur. Cette expérience n’est pas aussi mauvaise que celle offerte par le curseur personnalisé, mais elle n’est pas idéale, et son utilisation avec des technologies d’assistance s’avère très fastidieuse et déroutante.
Cet enregistrement illustre parfaitement pourquoi les fonctionnalités d'accessibilité par défaut de SwiftUI ne suffisent pas toujours. Certes, VoiceOver annonce et met en surbrillance la plupart des éléments, mais ces annonces sont souvent insuffisantes, et certains contrôles personnalisés sont complètement ignorés par les technologies d'assistance. Ce scénario soulève une réelle préoccupation concernant l'accessibilité « prête à l'emploi » et montre pourquoi celle-ci peut rapidement devenir un piège !
Gotcha n° 2 : accessibilitySortPriority
Une autre fonctionnalité intéressante, mais qui comporte également un piège : `accessibilitySortPriority` ! Depuis l’annonce de ce modificateur de vue lors de la WWDC, je suis hanté par des visions cauchemardesques de tous les problèmes d’accessibilité potentiels en cas d’utilisation abusive. Modifier l’ordre dans lequel les éléments d’accessibilité reçoivent le focus avec une technologie d’assistance est une décision importante qu’un développeur ne doit pas prendre à la légère. Si cela est mal fait, votre application peut devenir source de confusion et rendre la navigation inefficace pour les utilisateurs de technologies d’assistance. Si vous envisagez d’utiliser `accessibilitySortPriority`, voici quelques éléments qui vous aideront à prendre cette décision :
- Quels éléments un utilisateur souhaiterait-il parcourir, et dans quel ordre ?
- Quel ordre est le plus logique ?
- Quel ordre de tri fournit tout le contexte nécessaire ?
La priorité de tri des éléments doit être déterminée en fonction de ce qui est le plus logique d'un point de vue sémantique pour l'utilisateur, et non en fonction de l'endroit où vous SOUHAITEZ que les utilisateurs glissent en premier. Vous ne devriez utiliser cette API que si elle rend la navigation dans votre application plus simple et plus logique.
Par ailleurs, je m’en voudrais de ne pas préciser que vous ne devez JAMAIS utiliser .accessibilitySortPriority pour accroître la visibilité ou le taux d’utilisation d’un élément générateur de revenus – cela constituerait une utilisation abusive et un détournement grave de cette API. L'objectif de .accessibilitySortPriority est d'améliorer la navigation au sein de votre application, et non de manipuler l'expérience utilisateur dans le but d'augmenter les revenus ou l'attention portée à un élément (par exemple, ne modifiez pas la priorité de tri pour mettre en avant un bouton « Payer » en premier si cela n'a pas de sens d'un point de vue logique pour la navigation).
Une autre raison pour laquelle .accessibilitySortPriority peut s'avérer piégeuse est qu'il existe des cas où cette solution peut sembler appropriée, alors qu'elle ne l'est pas. Si une vue contient plusieurs instances d'un élément sur lequel la technologie d'assistance se positionne fréquemment, envisagez plutôt d'utiliser le comportement .accessibilityChildren(.contain) afin d'éviter une expérience de navigation potentiellement répétitive et fastidieuse.
Prenons l’exemple de l’écran principal de Plantiverse : nous avons des éléments d’en-tête pour chaque pièce ; cet élément d’en-tête contient un bouton à gauche, du texte au centre et un autre bouton à droite du texte. Au départ, je pensais que l’en-tête serait un bon candidat pour l’attribut .accessibilitySortPriority, car on peut raisonnablement s’attendre à ce que les utilisateurs souhaitent entendre d’abord le nom de la pièce ; après tout, à quoi sert un bouton de modification si l’on ne sait pas d’abord ce que l’on modifie ? J’ai tenté l’expérience et j’ai rapidement constaté que le résultat n’était pas satisfaisant. L’enregistrement d’écran ci-dessous montre le résultat obtenu.
Dans l'enregistrement ci-dessus, il faut faire défiler l'écran pour entendre l'annonce du nom de la pièce et des deux boutons. Après avoir parcouru plusieurs éléments d'en-tête de cette manière, les défauts deviennent très évidents : de nombreux balayages et certaines informations annoncées alors qu'on ne souhaite pas toujours les entendre. J'ai décidé d'utiliser .accessibilityChildren(.contain) pour améliorer l'expérience ; cela a permis de parcourir chaque en-tête de salle comme un élément unique, plutôt que de devoir passer par chaque élément contenu dans l'en-tête. L'enregistrement d'écran ci-dessous illustre l'expérience obtenue lorsque .accessibilityChildren(.contain) est utilisé à la place de .accessibilitySortPriority.
Remarquez à quel point l'exemple .accessibilityChildren(.contain) est concis et efficace, sans pour autant sacrifier le contexte ni les informations. Nous traitons l’en-tête et ses éléments enfants comme un seul et même élément lors de la navigation, afin de faciliter la tâche de l’utilisateur. L’annonce nous indique toujours que des actions sont disponibles au sein de l’en-tête ; cela permet aux utilisateurs de découvrir les actions disponibles s’ils le souhaitent, plutôt que de les obliger à écouter l’annonce à chaque fois pour chaque en-tête affiché à l’écran.
Astuce n° 3 : Images de symboles de science-fiction
Notre troisième « Gotcha » concerne les images SF Symbol. Dans SwiftUI, l’initialiseur `Image` basé sur `systemName` est un moyen pratique de créer un bouton à partir d’un SF Symbol. Supposons que nous utilisions cet initialiseur sans ajouter d’`accessibilityLabel`. Dans ce cas, l’annonce VoiceOver relative à l’image manquera de contexte, sera beaucoup moins significative et prêtera davantage à confusion. Regardez l’enregistrement d’écran ci-dessous pour découvrir à quoi ressemble l’expérience avec une image SF Symbol sans `accessibilityLabel` ajouté.
« Gear Shape.fill, bouton »… aïe ! Cette annonce manque de contexte et prête à confusion, car, en se basant uniquement sur l’annonce de VoiceOver, on ne sait pas avec certitude à quoi sert ce contrôle ; « gear shape.fill » ne donne pas d’indication claire et précise sur la fonction de ce bouton. Heureusement, la solution est simple : il suffit d’ajouter un « accessibilityLabel » à l’image pour obtenir une annonce plus précise et plus significative pour les utilisateurs.
Astuce n° 4 : superposition d'images sous forme de texte
Les superpositions d’images à base de texte constituent notre quatrième piège. L’une des nouveautés les plus intéressantes de SwiftUI est la fonctionnalité de superposition d’images : un élément qui permet d’appliquer une superposition (forme, couleur, texte ou autre) à une image. Les superpositions à base de texte se sont particulièrement démarquées comme un piège potentiel majeur ; on peut facilement se laisser emporter par ce qu’elles apportent à un élément en termes de design et en oublier les subtilités liées à l’accessibilité.
Dans le cas où un développeur ajoute une superposition textuelle sur une image, il pourrait sembler suffisant d’ajouter une balise « accessibilityLabel » ; cependant, cela n’est pas suffisant. Cette « solution » ne tient pas compte des utilisateurs malvoyants ou daltoniens qui n’utilisent peut-être pas VoiceOver ; ces utilisateurs ne seraient pas en mesure d’accéder aux mêmes informations contenues dans l’image que les autres utilisateurs… ce n’est pas accessible !
Jetez un œil à la capture d’écran de notre écran de détails sur les plantes ci-dessous : l’image de la plante comporte une superposition de texte indiquant son nom. Certes, c’est esthétique, mais la couleur et la transparence du texte ne contrastent pas suffisamment avec l’image. Par conséquent, les informations contenues dans cette superposition de texte ne seront pas accessibles aux utilisateurs malvoyants ou daltoniens qui n’utilisent pas VoiceOver — ce n’est pas accessible — et nous voulons que tout le monde puisse accéder à ces informations !
Pour éviter ce problème, veillez à ce que la couleur du texte superposé offre un contraste suffisant avec l'image, afin que le texte soit parfaitement visible pour les utilisateurs daltoniens ou malvoyants !
Astuce n° 5 : « Personne n’est parfait »
Notre cinquième et dernier point à retenir est que « personne n’est parfait ». Peu importe le nombre de fonctionnalités géniales offertes par SwiftUI, peu importe la qualité de l’accessibilité par défaut, rien ne remplacera JAMAIS le fait de tester soi-même l’accessibilité de son application. En matière d’accessibilité, le contexte est EXTRÊMEMENT important ; c’est pourquoi l’aspect humain lié à l’expérience de l’accessibilité d’une application est crucial pour créer une application accessible.
Peu importe le niveau d’avancée, de robustesse ou de stabilité de SwiftUI aujourd’hui ou à l’avenir, ces principes resteront toujours valables. De plus, ne partez jamais du principe que tout fonctionne parfaitement dans SwiftUI, ni même comme il se doit : il est toujours préférable de vérifier deux, voire trois fois, en particulier en matière d’accessibilité. Imaginons qu’une API d’accessibilité ne fonctionne pas comme prévu et qu’aucun développeur ne la teste jamais directement. Dans ce cas, ce problème d’accessibilité pourrait rapidement toucher vos utilisateurs et avoir un impact négatif considérable sur eux.
Un dernier point concernant ce piège : SwiftUI et les API d’accessibilité dont nous avons parlé sont encore relativement récentes ; par conséquent, il subsiste encore quelques bugs – ça arrive ! Repensez à notre écran « Ajouter une plante » dans Plantiverse : bien que nous utilisions .accessibilityRepresentation sur nos contrôles personnalisés, VoiceOver a complètement ignoré notre curseur personnalisé en raison d’un bug dans .accessibilityRepresentation. Imaginez si nous n’avions pas testé nous-mêmes l’accessibilité de Plantiverse : cette décision aurait eu de graves répercussions négatives sur nos utilisateurs, car nous n’aurions pas su qu’un bug rendait nos contrôles personnalisés inaccessibles. Les bugs, ça arrive, personne n’est parfait ; c’est pourquoi vous devriez vérifier vous-même l’accessibilité de votre application !
L'enregistrement d'écran ci-dessous illustre le comportement du bug « .accessibilityRepresentation » si vous souhaitez y jeter un coup d'œil. Notez qu'à moins de désactiver puis de réactiver VoiceOver, nous n'obtenons pas l'expérience d'accessibilité souhaitée pour nos contrôles personnalisés.
Pour résumer le conseil n° 5 : personne n'est parfait : les erreurs et les bugs, ça arrive, alors assurez-vous de tester votre application avec des technologies d'assistance pour la rendre pleinement accessible !
Comment puis-je résoudre les problèmes signalés dans la rubrique « Pièges » ?
Cet article a abordé cinq pièges à éviter en matière d'accessibilité dans SwiftUI ; bien qu'ils soient insidieux, ils peuvent être corrigés. Il existe plusieurs approches différentes que vous pouvez adopter pour remédier aux problèmes liés à ces pièges.
- Utilisez l'aperçu d'accessibilité dans Xcode : cela peut vous faire gagner du temps lors du développement en vous donnant un aperçu de l'accessibilité des éléments à l'écran.
- Utilisez TOUJOURS votre application avec une technologie d'assistance
- axe DevTools XCUI, compatible avec SwiftUI, est désormais disponible !
- axe DevTools pour iOS prend en charge UIKit
- Deque peut aider:
- Évaluations et audits manuels
- Conseil en accessibilité
- Consultez l'application d'exemple de cet article sur GitHub pour découvrir des exemples d'accessibilité dans SwiftUI.
