Fonctionnalités iOS : comment ça marche ? | Fonctionnalités d'accessibilité

Cet article a été rédigé conjointement par Chris McMeeking et Alistair Barrell.

Caractéristiques d'accessibilité

Les « traits d’accessibilité » constituent une autre fonctionnalité utile et importante dans le domaine de l’accessibilité sous iOS. Un trait d’accessibilité vous permet de choisir la description la plus appropriée pour la fonction d’un élément de votre application. Il est important de configurer correctement ces traits afin d’éviter toute confusion chez l’utilisateur lorsque, par exemple, un clic sur un « champ de texte » ouvre le navigateur Web.

Il existe beaucoup d’informations trompeuses concernant les traits. La plupart proviennent de descriptions simplistes. Ces descriptions conduisent les développeurs à mal utiliser les traits, car la description générique du trait s’applique à leur situation. Cet article adoptera une approche différente. Nous décrirons le comportement que chaque trait entraîne lorsqu’il est appliqué à un contrôle. Certains de ces traits se manifestent simplement par des changements dans l’annonce VoiceOver d’un contrôle, tandis que d’autres comportements sont moins évidents. Dans certains cas, il est difficile de mettre en place un exemple où le trait peut réellement produire son effet ! Dans cet article, nous aborderons :

Plusieurs catégories de traits.
Chaque fonctionnalité, sa finalité et le comportement qu’elle entraîne dans VoiceOver
Bonnes pratiques concernant l'utilisation des traits.

Caractéristiques correspondant aux rôles ARIA

Un concept important en matière d’accessibilité est le rôle joué par un objet dans l’interface utilisateur. Il est essentiel d’indiquer à l’utilisateur si un objet est un champ de texte statique, un bouton, un lien ou un champ de saisie de texte. Cette information peut souvent être déduite du type de l’objet. Par exemple, unUITextField doit toujours être utilisé pour la saisie de texte. Cependant, pour certains de ces rôles, les API iOS nécessitent une intervention du développeur. Par exemple, une image peut se comporter comme un bouton ou un lien, ou bien n’être qu’une simple image. On peut supposer qu’un UIButton est un bouton, mais que se passe-t-il si ce «bouton »ouvre une page dans Safari ? Les caractéristiques relevant de cette catégorie doivent être considérées comme mutuellement exclusives.

Fonctionnalités utiles pour VoiceOver

D'autres attributs n'ont pas d'incidence directe sur l'annonce de votre contrôle, mais influencent plutôt la manière dont VoiceOver interagit avec celui-ci ou fournissent à VoiceOver le contexte dans lequel votre contrôle est utilisé. Cela permet à VoiceOver de se comporter de manière plus pertinente pour certains types de contrôles. Il est important de bien comprendre l'effet de ces attributs, car leur signification apparente peut prêter à confusion. Contrairement aux attributs qui représentent les rôles ARIA, il est tout à fait pertinent d'utiliser ces attributs en combinaison avec d'autres attributs.

Énumération des traits

Vous trouverez ci-dessous une liste des traits disponibles dans le framework iOS (certains ont été omis, car nous poursuivons nos recherches sur leur comportement). Chaque trait est accompagné d’une description du comportement de VoiceOver lorsqu’il rencontre un objet doté du trait en question. Nous fournissons également une description générique ou un exemple des objets auxquels ces traits s’appliquent généralement. Il est préférable de garder à l’esprit à la fois la description et les comportements lorsque vous décidez d’appliquer ou non un trait. Les traits sont souvent mal utilisés.

Aucun (UIAccessibilityTraitNone)

Ce contrôle ne présente aucun comportement particulier. Il s'utilise par programmation lorsque vous souhaitez supprimer tous les traits du contrôle. L'utilisation de ce trait en association avec un autre trait n'a aucun sens.

Bouton (UIAccessibilityTraitButton)

Le trait « button » fait partie de la catégorie des traits qui représentent les rôles ARIA. Les objets dotés de ce trait verront le mot « button » prononcé après leur étiquette d'accessibilité lorsqu'ils sont lus à voix haute par VoiceOver.

Le trait « button » doit être appliqué aux contrôles qui acceptent des événements d'entrée de base et qui ne correspondent à aucun des traits plus spécifiques. Les objets UIButtons, les segments au sein des contrôles segmentés et les objets de contrôle d'interface utilisateur similaires se verront attribuer ce trait par défaut. Vous devez le supprimer explicitement si ce trait ne doit pas s'appliquer. Par exemple, un UIButton qui ouvre une page Web dans Safari doit voir ce trait supprimé et letrait « link » appliqué à la place.

Lien (UIAccessibilityTraitLink)

L'attribut « link » fait partie de la catégorie des attributs qui représentent les rôles ARIA. Les objets dotés de cet attribut verront le mot « lien » prononcé après leur étiquette d'accessibilité lorsqu'ils sont lus par VoiceOver. Les liens ouvrent une URL dans un navigateur externe. C'est là la distinction importante par rapport aux boutons. N'appliquez l'attribut « link » que lorsque l'interaction de l'utilisateur avec le contrôle le fera sortir de votre application pour l'amener dans Safari.

Champ de recherche (UIAccessibilityTraitSearchField)

Les objets dotés de ce trait sont désignés sous le nom de « champ de recherche ». De nombreuses applications iOS (App Store, iTunes, etc.) utilisent un simple champ de recherche pour permettre aux utilisateurs de trouver facilement des éléments au sein de l'application. Comme il s'agit d'une pratique courante sous iOS, il est logique de disposer d'un trait dédié à cet usage. Notez toutefois que ce trait s'applique spécifiquement aux recherches effectuées dans le contexte de l'application. Le champ de texte de Google.com, par exemple, ne serait pas doté de ce trait.

Image (UIAccessibilityTraitImage)

L'attribut « image »s'inscrit dans la catégorie des attributs représentant les rôles ARIA. Les objets dotés de cet attribut verront le mot « image » prononcé après leur étiquette d'accessibilité lorsqu'ils sont lus à voix haute par VoiceOver. Contrairement aux autres attributs de la catégorie des rôles ARIA, vous pouvez tout à fait associer cet attribut à d'autres rôles ARIA. Il est tout à fait plausible qu'un bouton soit également une image.

Cette caractéristique doit être appliquée lorsque l'aspect visuel d'un objet fournit des informations importantes. Par exemple, si vous avez une image qui n'est qu'un bouton personnalisé et que son apparence n'apporte aucune information nouvelle, il ne s'agit probablement pas vraiment d'une image. Il s'agit en fait simplement d'un bouton. En revanche, si vous avez un bouton et que celui-ci présente un aspect personnalisé fournissant des informations à son sujet, ou s'il comporte une image d'arrière-plan, ce bouton peut alors être considéré comme une image.

Sélectionné (UIAccessibilityTraitSelected)

Les objetssélectionnés sont identifiés comme « sélectionnés ». Il convient de considérer cela comme l'état d'un contrôle. Contrairement aux technologies web, dans lesquelles des groupes de contrôles fonctionnent par paires « sélectionné/désélectionné », ce contrôle sert uniquement à marquer des éléments spécifiques comme étant sélectionnés.

Cette fonctionnalité serait notamment utilisée pour indiquer l'onglet actif dans une barre d'onglets.

Élément de résumé (UIAccessibilityTraitSummaryElement)

Le fait de marquer un élément comme «élément de résumé»entraîneun comportement intéressant. Lors du premier chargement de l'application, l'élément de résumé est lu à voix haute, y compris ses caractéristiques et ses indications. Cependant, il ne reçoit pas le focus. Notez également queles éléments de résumé ne sont lus à voix haute qu'au moment du chargement de votre application. Ainsi, si vous naviguez dans une application à plusieurs pages, vos éléments de résumé ne seront pas lus à voix haute de manière répétée.

Utilisez cette fonctionnalité sur les éléments de votre page d'accueil qui méritent d'attirer l'attention, mais qui ne figurent pas parmi les premiers dans l'ordre de priorité de votre application. Vous ne voulez pas que les utilisateurs écoutent votre élément de résumé, glissent vers la droite, puis soient obligés de l'écouter à nouveau immédiatement ! Enfin, vous ne pouvez avoir qu'un seul élément de résumé par vue.

Interaction utilisateur activée (UIAccessibilityTraitNotEnabled)

Les contrôles dotés de cette caractéristique sont lus comme « grisé » lorsque leurs caractéristiques sont lues à voix haute. Cette fonctionnalité est généralement utilisée lorsque vous souhaitez désactiver temporairement un bouton. Celui-ci fait toujours partie de votre interface utilisateur, et les utilisateurs de VoiceOver doivent savoir qu’il est présent, mais il ne peut pas être activé pour le moment.

ATTENTION : Interface Builder affiche ce trait sous la forme « Interaction utilisateur activée », tandis que la méthode programmatique d’application des traits utilise le trait nomméUIAccessibilityTraitNotEnabled. Ainsi, désactiver ce trait dans Interface Builder revient à l’appliquer via le code. Par conséquent, dans Interface Builder, vous aurez presque toujours intérêt à ce que cette case soit cochée dans la liste des traits d’un élément donné. Si vous décochez cette case, vos éléments seront lus comme « grisés » !

Meilleure pratique : cette propriété peut être associée à la plupart des autres propriétés. Toutefois, les propriétés «Static Text » et« Dimmed » n’ont probablement pas de sens dans ce contexte. Il n’est pas possible de désactiver l’interaction avec le texte. Si vous souhaitez réellement le faire, vous devriez plutôt marquer un élément comme n’étant PAS un élément d’accessibilité.

Mises à jour fréquentes (UIAccessibilityTraitUpdatesFrequently)

Cette fonctionnalité permet à VoiceOver de mieux gérer les contrôles dont le contenu est dynamique. Dans ce cas, VoiceOver interroge le contrôle lorsqu'il est sélectionné, plutôt que d'essayer de lire tout le texte qui y a jamais figuré.

Prenons l'exemple d'un chronomètre numérique, avec une heure, une minute et une seconde. Une description d'accessibilité appropriée pour cet élément pourrait être la suivante :

Affichage : 1 h 02 min 55 s

VoiceOver : Une heure, deux minutes et cinquante-cinq secondes.

C'est parfait ! Cependant, pendant la lecture de ce message, le compteur s'est mis à jour et a ajouté quelques secondes. Il affiche donc désormais 1:02:58. Envisageons deux scénarios. Premièrement, supposons que letrait « Mises à jour fréquentes» n'ait pas été activé. Après l'annonce ci-dessus, nous aurions alors ce qui suit.

Affichage : 1 h 02 min 58 s

VoiceOver : Une heure, deux minutes etcinquante-six secondes

Remarquez que VoiceOver a détecté la mise à jour ! Même si l'on en est désormais à la 58e seconde, VoiceOver a pris du retard et annonce l'heure à 1 h 02 min 56 s. Ce problème ne fera que s'aggraver à mesure que l'utilisateur restera sur le champ de mise à jour, VoiceOver annonçant chaque mise à jour effectuée !

Supposons maintenant que leparamètre « Mises à jour fréquentes» ait été correctement configuré. Après notre première annonce, pendant 1 h 02 min 55 s, nous aurions

Affichage : 1 h 02 min 58 s

VoiceOver : Une heure, deux minutes et cinquante-huit secondes

Ce comportement est évidemment préférable ! Notez que si le contrôle n'a pas le focus d'accessibilité, VoiceOver n'informera pas l'utilisateur des mises à jour. D'autres solutions, telles que les notifications dynamiques, doivent être utilisées dans les cas où vous souhaitez que l'utilisateur soit informé des modifications apportées au contenu, sans que ce dernier ne soit spécifiquement mis en évidence.

Lance une session multimédia (UIAccessibilityTraitStartsMediaSession)

Lorsqu'un utilisateur de VoiceOver appuie deux fois sur l'écran au niveau d'un bouton, celui-ci est activé et son libellé lui est lu à voix haute. Cela serait évidemment frustrant si le but du bouton était de lire un son ! Surtout s'il s'agit d'un son court. Interrompre les premières secondes de « Yellow Submarine » n'est pas la fin du monde, mais qu'en est-il si un utilisateur teste de nouvelles alertes sonores ? Le son peut être plus court que l'annonce ! Ce serait extrêmement frustrant. L’application de cette caractéristique à un bouton empêche ce comportement, annulant toute annonce et permettant ainsi d’entendre les sons déclenchés par l’interaction avec le contrôle.

Réglable (UIAccessibilityTraitAdjustable)

Les commandes réglables seront annoncées comme « réglables » et une annonce plus longue sera ajoutée à l'indication :

Voici un petit conseil : faites glisser votre doigt vers le haut ou vers le bas pour régler la valeur.

L'utilisation de cette fonctionnalité a quelques conséquences intéressantes. Tout d'abord, tout contrôle auquel cette propriété est appliquée doit savoir s'adapter et veiller à le faire en réponse aux gestes de balayage vers le haut ou vers le bas. Cela signifie également que cela perturbe les gestes VoiceOver habituels de balayage vers le haut ou vers le bas. Ainsi, des fonctionnalités telles que la navigation par titre (ou d'autres, en fonction du réglage du rotor) ne fonctionneront pas sur les éléments auxquels cette propriété est appliquée. Il convient d'éviter toute utilisation excessive de cette propriété !

Recommandation : n'utilisez cette méthode que sur les éléments `UISlider`.

Interaction directe (UIAccessibilityTraitAllowsDirectInteraction)

Cette propriété est particulièrement intéressante. Les objets dotés de cette propriété permettent à VoiceOver de transmettre les événements tactiles, afin que le contrôle puisse les gérer directement. Il est peu probable que vous ayez à l'utiliser dans un contexte d'accessibilité ; elle s'applique plutôt lorsque l'interaction de VoiceOver avec un contrôle au nom de l'utilisateur n'a tout simplement pas de sens. Prenons l’exemple d’une application de dessin. Si vous deviez implémenter Paint sous iOS, serait-il logique que VoiceOver interagisse avec la fenêtre de Paint ? Bien sûr que non.

En-têtes (UIAccessibilityTraitHeader)

Les éléments d'en-tête ajoutent deux fonctionnalités aux commandes. La première, évidente, est qu'ils s'affichent sous la forme « en-tête ». De plus, si le rotor est réglé sur « En-têtes », un balayage vers le haut ou vers le bas sur l'écran permet d'accéder directement aux en-têtes dans l'ordre. L'ajout d'en-têtes à votre application facilite la navigation.

Bon à savoir : ajoutez au moins un titre par page ! Pour les applications comportant de longues sections de contenu sur un même écran, ajoutez des titres supplémentaires, si nécessaire et dans la mesure du raisonnable, afin de faciliter la navigation des utilisateurs.

Bonnes pratiques

Même si l'impact des caractéristiques peut sembler quelque peu subtil et insignifiant, il revêt une grande importance pour les utilisateurs de VoiceOver. Les caractéristiques fournissent à l'API d'accessibilité des informations spécifiques sur vos éléments, ce qui permet à VoiceOver et à d'autres composantes de l'API de gérer vos éléments de manière plus claire et plus uniforme. Une annonce cohérente des contrôles de l'interface utilisateur, en particulier ceux liés aux rôles ARIA, contribue à fournir un contexte aux utilisateurs malvoyants. Si elles ne sont pas utilisées de manière cohérente et correcte, les caractéristiques de votre application peuvent être source de confusion, annuler tout effet positif, voire aggraver la situation.

Dans les descriptions de chaque caractéristique, nous avons mentionné certaines combinaisons de caractéristiques qui ne sont pas cohérentes entre elles. Il existe de nombreuses autres associations de caractéristiques susceptibles de poser problème qui n’ont pas été abordées ici. Le meilleur moyen d’éviter ces contradictions et ces situations prêtant à confusion est simplement de bien réfléchir avant d’associer deux caractéristiques d’accessibilité entre elles. Votre association est-elle vraiment cohérente ? Pourriez-vous la simplifier en omettant l’une de vos caractéristiques tout en restant fidèle à la fonction de votre élément ?

Conseils

Assurez-vous que les caractéristiques que vous attribuez aux éléments reflètent fidèlement la nature ou la fonction de ces derniers !
Si le contenu de la page est dynamique, assurez-vous que vos traits changent lorsque la fonction d'un élément change.
Tenez compte non seulement de la description du trait, mais aussi du comportement qu’il va entraîner. Est-ce que cela a du sens dans le contexte de votre application ? Les traits ne font rien d’autre qu’aider VoiceOver ; ils NE provoquent AUCUN autre comportement. Ainsi, si une annonce donnée dans VoiceOver n’a pas de sens pour votre cas d’utilisation, il faudrait peut-être supprimer ce trait. Même s’il répond aux critères génériques définis dans le résumé de l’API Apple concernant ce trait.