iOS propose gratuitement de nombreuses fonctionnalités d'accessibilité, ce qui constitue un excellent point de départ pour rendre une application mobile accessible. Malheureusement, l'accessibilité est un sujet plus complexe que ne le permettent les fonctionnalités d'iOS, et le fait de se contenter des fonctionnalités par défaut peut en réalité entraîner des problèmes supplémentaires pour l'application.
La question est donc la suivante : quand dois-je me contenter des fonctionnalités offertes gratuitement par iOS, et quand dois-je recourir à des API supplémentaires pour améliorer ce qui est déjà disponible afin de rendre mon application aussi accessible que possible ?
Pour dissiper toute confusion à ce sujet, nous aborderons les points suivants :
- Ce qu'apporte l'accessibilité
- Quand il est nécessaire de remplacer le comportement par défaut en matière d'accessibilité
- Quelques cas de figure intéressants impliquant l'imbrication d'éléments d'accessibilité
Utilisation de l'API d'accessibilité sous iOS
L'une des principales interfaces de programmation d'applications (API) d'accessibilité sous iOS – et sans doute la plus importante – est la propriété `isAccessibilityElement `, ou le modificateur de vue `accessibility(hidden) ` dans SwiftUI. Cette propriété est disponible sur n'importe quelle vue lors du développement d'une application et indique si un élément est accessible par VoiceOver.
VoiceOver est le lecteur d'écran disponible sur iOS ; il s'agit de la principale technologie d'assistance utilisée par les utilisateurs aveugles ou malvoyants. Lorsque la propriété `isAccessibilityElement` est définie sur `true` pour une vue, cela signifie que l'accessibilité est activée pour cette vue : VoiceOver peut généralement y accéder et en lire le contenu à l'utilisateur. Si `isAccessibilityElement` est défini sur `false`, l'accessibilité n'est pas activée pour cette vue ; cela signifie que VoiceOver traitera cette vue comme si elle n'existait pas.
Quand l'accessibilité est-elle activée par défaut ?
L'accessibilité est prise en charge pour la plupart des composants de l'interface utilisateur et des autres vues présentant des informations (telles que les éléments de texte, les images, les boutons, etc.).
Lorsqu'un élément est sélectionné, VoiceOver lit :
- le texte visible de l'élément ou son « accessibilityLabel » (son nom d'accessibilité)
- sa valeur ou sa valeur d'accessibilité (sa valeur accessible)
- certaines caractéristiques d'accessibilité liées à son rôle en matière d'accessibilité (telles que bouton, lien, etc.),
- son conseil d'accessibilité, si les conseils sont activés dans les réglages de VoiceOver et s'il en existe un.
Sur la capture d'écran ci-dessus, on voit un champ de texte « Username » contenant le texte « MyUsername ». Le nom de ce champ de texte est « Username », sa valeur est « MyUsername » et son rôle est celui d'un champ de texte. Dans ce cas précis, VoiceOver lirait : « Username, MyUsername, champ de texte. Appuyez deux fois pour modifier. »
Dans quels cas l'accessibilité n'est-elle pas activée par défaut ?
VoiceOver ignorera complètement les éléments pour lesquels l'accessibilité n'est pas activée. Il s'agit du comportement par défaut des UIViews et des autres vues de mise en page (telles que les StackViews, TableViews, CollectionViews et ScrollViews).
Sur la capture d'écran ci-dessus, on voit un tableau contenant une liste de paramètres. Au lieu de se concentrer sur l'ensemble de la TableView, VoiceOver se concentre sur l'une des TableViewCells, plus précisément la cellule « Notifications », qui est actuellement sélectionnée. Cela permet aux utilisateurs de mieux comprendre le contenu de chaque cellule et d'interagir avec chacune d'entre elles individuellement.
Remplacer le comportement par défaut en matière d'accessibilité
Comme indiqué précédemment, la plupart des vues qui affichent des informations intègrent déjà des fonctionnalités d'accessibilité ; vous n'avez donc pas besoin de configurer l'accessibilité de chaque composant de votre application. Bien que cela soit très pratique, vous pouvez toutefois être amené à modifier l'accessibilité d'un élément dans certains cas. Cela peut se produire si vous avez :
- contrôles personnalisés/complexes (tels qu’un contrôle auquel sont associées plusieurs actions)
- images purement décoratives
- texte visible décrivant la fonction d'un élément de commande
Faites très attention lorsque vous modifiez l'accessibilité des éléments ! Une mauvaise configuration de cette propriété peut entraîner de graves problèmes d'accessibilité, au point de rendre votre application inutilisable pour un utilisateur de VoiceOver.
Pour savoir si l'accessibilité d'un élément doit être contournée, posez-vous la question suivante : «Cette vue présente-t-elle des informations spécifiques, ou est-elle répétitive ou purement décorative ?» N'oubliez pas que tous les composants de l'interface utilisateur, lorsqu'ils sont mis en surbrillance par VoiceOver, doivent comporter un nom, un rôle et une valeur clairement indiqués.
Scénarios
Voici quelques situations dans lesquelles un développeur peut envisager de modifier l'accessibilité d'un élément. Voyons si le comportement par défaut en matière d'accessibilité doit réellement être modifié ou non.
Scénario n° 1 : Bouton « Envoyer » désactivé
Le formulaire ci-dessus comporte un bouton « Envoyer » en bas de page, et ce bouton reste désactivé tant que le formulaire n’est pas entièrement rempli. Faut-il également désactiver l’accessibilité du bouton « Envoyer » ? Eh bien, revenons à la directive mentionnée plus haut et examinons ce qui suit :
Ce bouton « Envoyer » désactivé fournit-il des informations spécifiques ? Je dirais que oui. Un utilisateur voyant qui aperçoit un bouton « Envoyer » désactivé au bas d'un formulaire peut en déduire que celui-ci n'est pas entièrement rempli ; une action supplémentaire est nécessaire pour que le bouton devienne accessible.
Lorsque l'accessibilité du bouton « Envoyer » est désactivée, un utilisateur de VoiceOver comprendrait qu'il y a un formulaire à remplir, mais ne saurait pas comment procéder pour remplir ce formulaire et passer à l'écran suivant. De même, une fois le formulaire entièrement rempli, l'utilisateur pourrait être déconcerté par l'apparition soudaine d'un bouton qui n'était pas là auparavant.
Au lieu de supprimer le bouton de la hiérarchie d'accessibilité, il convient d’utiliser UIAccessibilityTraits.notEnabled doit être utilisé pour indiquer aux utilisateurs de VoiceOver que le bouton « Soumettre » est présent, mais qu’il ne peut pas être activé pour le moment. N’oubliez pas de supprimer UIAccessibilityTraits.notEnabled dès que le bouton « Soumettre » est à nouveau accessible !
Scénario n° 2 : un commutateur muni d'une étiquette visible
Dans une application, un bouton est visuellement identifié comme permettant de contrôler le « Mode sombre » et son attribut accessibilityLabel est défini sur « Mode sombre ». Le texte visible « Mode sombre » doit-il être accessible aux personnes malvoyantes ?
Le texte « Mode sombre » apporte-t-il des informations spécifiques? Imaginons un scénario dans lequel l’accessibilité est activée pour le texte visible. Lorsque le texte est sélectionné, VoiceOver lit « Mode sombre », puis, lorsque l'utilisateur balaye vers la droite pour déplacer la sélection sur le bouton, il lit « Mode sombre, bouton de commutation, désactivé ». Comme l'attribut accessibilityLabel du bouton est correctement défini, « Mode sombre » serait répété à un utilisateur de VoiceOver ; ce texte ne présente donc pas d'informations spécifiques et, par conséquent, il n'est pas nécessaire d'activer son accessibilité.
Meilleures pratiques pour ce scénario
Bien que l'exemple ci-dessus soit conforme aux WCAG, il peut être utile de garder à l'esprit que tous les utilisateurs de VoiceOver ne sont pas entièrement aveugles ; certains sont malvoyants. Dans ce cas, il peut être utile que la zone de focus de VoiceOver contienne à la fois le texte visible et le bouton ; cela aidera les utilisateurs malvoyants à mieux comprendre la structure de votre application. Cela peut être réalisé de différentes manières, notamment :
- remplacer la propriété ` accessibilityPath` du commutateur
- activer l'accessibilité de la vue parente qui contient le bouton bascule et son texte, puis mettre à jour les propriétés accessibilityLabel, accessibilityValue, accessibilityTraits et accessibilityActivationPoint de cette vue parente
- ajouter un détecteur de gestes à la vue parente, activer l'accessibilité de la vue parente et mettre à jour les propriétés `accessibilityLabel`, `accessibilityTraits` et `accessibilityValue` de la vue
La meilleure façon de mettre cela en œuvre (à mon avis) est d'intégrer un détecteur de gestes dans la vue parente, car cela offre également une zone tactile plus grande pour les utilisateurs de petits téléphones ou ceux qui ont des difficultés de motricité fine.
Scénario n° 3 : une image d'arrière-plan
Une image qui occupe une partie ou la majeure partie de l'arrière-plan d'un écran uniquement pour des raisons esthétiques doit-elle être rendue accessible ?
Cette image contient-elle des informations spécifiques ? Étant donné que cette image a uniquement une fonction esthétique et ne fournit aucune information importante à un utilisateur voyant, elle ne doit pas être rendue accessible. En effet, la présentation d’images purement décoratives à un utilisateur de technologies d’assistance peut constituer un manquement aux WCAG (1.1.1) ; il est donc important de distinguer avec soin ce qui est important de ce qui est essentiel.
Scénario n° 4 : les vues derrière une fenêtre modale
Une fenêtre modale (ou alerte) s'affiche à l'écran. Les vues situées derrière celle-ci sont visibles, mais il est impossible d'interagir avec elles tant que la fenêtre modale n'est pas fermée. Les vues situées derrière la fenêtre modale doivent-elles être accessibles aux personnes en situation de handicap ?
Les vues situées derrière la fenêtre modale présentent-elles des informations spécifiques ? Oui, elles contiennent bien des informations spécifiques, mais il n'est pas possible d'interagir avec elles tant que la fenêtre modale n'est pas fermée. Ces vues ne sont pas purement décoratives et ne constituent pas une répétition d'informations.
Dans cette optique, les vues situées derrière une fenêtre modale doivent être adaptées aux personnes à mobilité réduite, car elles affichent des informations une fois la fenêtre modale fermée ; toutefois, il ne faut pas qu'un utilisateur de VoiceOver puisse interagir avec ces vues tant que la fenêtre modale est encore affichée. Comment remédier à cela ?
Si le développeur a créé une fenêtre modale personnalisée sans utiliser la méthode `present`, il peut être nécessaire d'utiliser `UIAccessibility.Notification.screenChanged` peut s'avérer nécessaire pour informer un utilisateur de VoiceOver que l'écran a changé.
Au lieu de définir chaque vue située derrière la fenêtre modale sur « accessibilité désactivée » (puis de la réactiver lorsque la fenêtre modale est fermée), la propriété accessibilityViewIsModal peut être utilisée sur la vue racine de la fenêtre modale pour signaler à VoiceOver qu’une fenêtre modale est présente et que les vues situées derrière celle-ci ne doivent pas être accessibles pour le moment. Elle désactivera automatiquement l’accès de VoiceOver à ces vues jusqu’à ce que la fenêtre modale soit correctement fermée.
Scénario n° 5 : Une tuile « Achats »
Une application de shopping comporte des « vignettes » sur lesquelles vous pouvez voir une image de l'article avec son nom et son prix, l'ajouter à vos favoris, l'ajouter à votre panier et appuyer sur la vignette pour lire une description complète, les avis, etc.
Si vous n’activez pas l’accessibilité des vignettes, un utilisateur de VoiceOver risque de devoir faire défiler l’écran des centaines de fois rien que pour atteindre le bas de la page ! Dans l’exemple ci-dessus, VoiceOver mettrait d’abord en surbrillance l’image, puis le bouton « Ajouter aux favoris », le nom de l’article (« Exploronic Life »), le bouton « Ajouter au panier » et enfin le prix (26,00 $). Le fait de devoir faire glisser 5 fois pour chaque élément s'accumule rapidement et peut prêter à confusion s'il y a plusieurs vignettes sur un même écran. Après seulement quelques vignettes, il peut devenir difficile de savoir quel bouton « Ajouter aux favoris » correspond à quel article.
Afin de regrouper toutes les informations en un seul élément, l'accessibilité doit être activée pour l'ensemble de l'élément « tile ». Bien que le regroupement de toutes les informations d'une « tile » en un seul élément puisse faciliter considérablement la navigation à l'écran pour un utilisateur de VoiceOver, plusieurs actions sont associées à une même « tile » ; il est donc important de s'assurer que chaque action soit également accessible à un utilisateur de VoiceOver.
Éléments d'accessibilité imbriqués
Il est important de noter que, lorsqu'on rend un élément accessible, si celui-ci se trouve au sein d'une vue qui est elle-même accessible, VoiceOver n'a pas accès à la vue enfant. Pour remédier à cela, il faut regrouper les éléments associés tout en rendant plusieurs actions accessibles à VoiceOver.
Caractéristique d'accessibilité réglable
UIAccessibilityTraits.adjustable peut s'avérer utile si le composant d'interface utilisateur contient une valeur pouvant être augmentée ou diminuée à l'aide de boutons, comme un UIStepper. Envisagez d'encapsuler le contrôle, son libellé visible et son libellé de valeur visible dans une vue parente dont l'accessibilité est activée, puis d'ajouter le trait « adjustable » à cette vue.
Les utilisateurs de VoiceOver peuvent alors faire glisser leur doigt vers le haut ou vers le bas sur cet élément pour mettre à jour sa valeur, ce qui leur permet d’interagir avec le moins de glissements possible ; ils peuvent ajuster la valeur rapidement et entendre en temps réel l’évolution de la valeur du contrôle. Vous trouverez plus d’informations sur cette fonctionnalité dans cet article de blog consacré aux propriétés d’accessibilité d’iOS.
Actions d'accessibilité personnalisées
Si le composant de l'interface utilisateur ne comporte pas de valeur pouvant être modifiée, il peut être intéressant d'envisager des actions d'accessibilité personnalisées. Dans l'exemple ci-dessus concernant la vignette de l'application d'achats, il y avait trois (3) actions distinctes. L'ajout d'actions d'accessibilité personnalisées à la vignette permettrait aux utilisateurs de VoiceOver d'interagir rapidement et facilement avec celle-ci sans avoir à faire défiler tous les sous-éléments.
Lorsque vous utilisez des actions d'accessibilité personnalisées, attribuez à chacune d'elles un nom qui la décrit précisément. Cela permettra à un utilisateur de technologies d'assistance de comprendre plus facilement à quoi sert cette action.
Si vous utilisez SwiftUI, vous n'avez pas à vous en soucier. Si vous définissez une « tuile » comme élément d'accessibilité, SwiftUI convertira automatiquement vos contrôles individuels en actions personnalisées compatibles avec VoiceOver.
Conclusion
Vous êtes désormais prêt à résoudre les problèmes courants liés à l'accessibilité sous iOS et à rendre votre application plus accessible à tous. Utilisez les API d'accessibilité intégrées à iOS pour vous assurer que les informations parviennent bien à tous les utilisateurs de votre application. En remplaçant le comportement par défaut en matière d'accessibilité, vous pouvez faire en sorte que votre application offre la meilleure expérience possible. Enfin, l'utilisation de fonctionnalités d'accessibilité supplémentaires peut aider votre application à offrir une expérience plus conviviale et plus agréable aux utilisateurs de technologies d'assistance.
Si vous avez des questions concernant l'accessibilité de votre application, consultez nos outils de développement pour Objective-C, Swift et Swift UI, et n'hésitez pas à nous contacter ! Nous serons ravis de vous accompagner dans votre démarche en faveur de l'accessibilité.
