Recherche…


Introduction

L'accessibilité d'iOS permet aux utilisateurs malentendants et malvoyants d'accéder à iOS et à votre application en prenant en charge diverses fonctionnalités telles que VoiceOver, Contrôle vocal, Blanc sur noir, Mono Audio, Parole au texte, etc. Fournir l’accessibilité dans l’application iOS signifie rendre l’application utilisable par tous.

Rendre une vue accessible

Marquez votre sous-classe UIView comme un élément accessible afin qu'il soit visible pour VoiceOver.

myView.isAccessibilityElement = YES;

Assurez-vous que la vue indique une étiquette, une valeur et un indice significatifs. Apple fournit plus de détails sur la manière de choisir de bonnes descriptions dans le Guide de programmation de l’ accessibilité .

Cadre d'accessibilité

Le cadre d'accessibilité est utilisé par VoiceOver pour effectuer des tests de réussite, dessiner le curseur VoiceOver et calculer où dans l'élément ciblé pour simuler un appui lorsque l'utilisateur double-touche l'écran. Notez que le cadre est en coordonnées d'écran!

myElement.accessibilityFrame = frameInScreenCoordinates;

Si vos éléments ou la disposition de votre écran changent souvent, envisagez de ne pas négliger - accessibilityFrame pour toujours fournir un rectificatif à jour. Le calcul de l'image relative à l'écran des sous-vues de la vue de défilement peut être source d'erreurs et fastidieux. iOS 10 introduit une nouvelle API pour faciliter les choses: accessibilityFrameInContainerSpace .

Changement d'écran

VoiceOver fonctionne très bien la plupart du temps, en lisant à voix haute des écrans pleins de contenu et en suivant intuitivement l'utilisateur. Hélas, aucune solution générale n'est parfaite. Parfois, vous seul, le développeur de l'application, savez où se concentrer VoiceOver pour une expérience utilisateur optimale. Heureusement, VoiceOver écoute les notifications d’accessibilité du système pour obtenir des indices sur la place du focus. Pour déplacer le curseur VoiceOver manuellement, publiez une notification sur l'écran d'accessibilité:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstElement);

Lorsque cette notification est publiée, une courte série de tonalités informe les utilisateurs du changement. Le second paramètre peut être l'élément suivant à focaliser ou une chaîne annonçant la modification. Ne publiez une notification de changement d'écran que si l'expérience VoiceOver est mauvaise sans cette solution et qu'aucune autre solution n'existe. Déplacer le curseur VoiceOver revient à ouvrir l’écran d’un utilisateur voyant. Cela peut être gênant et désorientant de se retrouver dans cette situation.

Changement de disposition

Dans de nombreux cas, le contenu d'un seul écran sera mis à jour avec un contenu nouveau ou différent. Par exemple, imaginez un formulaire qui révèle des options supplémentaires en fonction de la réponse de l'utilisateur à une question précédente. Dans ce cas, une notification de «modification de la mise en page» vous permet d'annoncer la modification ou de vous concentrer sur un nouvel élément. Cette notification accepte les mêmes paramètres que la notification de changement d'écran.

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, firstElement);

Annonce

Les annonces sont utiles pour alerter les utilisateurs des événements qui ne nécessitent aucune interaction, tels que «verrouillé» ou «chargement terminé». Utilisez une annonce plus spécifique pour informer les utilisateurs des modifications d'écran ou d'autres modifications mineures de la mise en page.

UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @"The thing happened!");

Éléments de commande

VoiceOver navigue de haut en bas à droite, quelle que soit la hiérarchie de vue. C'est généralement la manière dont le contenu est arrangé dans les langues de gauche à droite, car les individus voyants ont tendance à scanner l'écran dans un «motif en forme de F». Les utilisateurs de VoiceOver s’attendent à naviguer de la même manière que les utilisateurs classiques. La prévisibilité et la cohérence sont très importantes pour l'accessibilité. Veuillez vous abstenir de faire des personnalisations qui «améliorent» le comportement par défaut (par exemple, ordonnez d'abord la barre d'onglets dans l'ordre de glissement). Cela dit, si vous avez reçu des commentaires selon lesquels l'ordre des éléments de votre application est surprenant, vous pouvez améliorer l'expérience de plusieurs façons.

Si VoiceOver doit lire les sous-vues d'une vue les unes après les autres mais que ce n'est pas le cas, vous devrez peut-être indiquer à VoiceOver que les éléments contenus dans une seule vue sont liés. Vous pouvez le faire en définissant shouldGroupAccessibiltyChildren :

myView.shouldGroupAccessibilityChildren = YES;

Pour prendre en charge des structures de navigation complexes couvrant plusieurs conteneurs ou inclure des interfaces rendues sans UIKit, envisagez d'implémenter le protocole de conteneur dans la vue parente.

Conteneur d'accessibilité

VoiceOver peut naviguer dans de nombreuses applications sur iOS car la plupart des classes UIKit implémentent le UIAccessibilityProtocol . Les fonctionnalités qui ne représentent pas des éléments à l'écran à l'aide de UIView , y compris les applications qui utilisent Core Graphics ou Metal pour effectuer le dessin, doivent décrire ces éléments pour l'accessibilité. A partir d'iOS 8.0, cela peut être fait en assignant une propriété sur UIView contenant des éléments inaccessibles:

myInaccessibleContainerView.accessibilityElements = @[elements, that, should, be, accessible];

Chaque objet du tableau peut être une instance de UIAccessibilityElement ou toute autre classe adhérant à UIAccessibilityProtocol . Les éléments enfants doivent être renvoyés dans l'ordre dans lequel l'utilisateur doit les parcourir. En tant qu'auteur de l'application, vous pouvez utiliser des conteneurs d'accessibilité pour remplacer la commande par défaut en haut à gauche de la navigation par balayage VoiceOver. Étant donné UIView implémente UIAccessibilityProtocol , vous pouvez combiner des instances de UIAccessibilityElement et UIView dans le même tableau d'éléments d'accessibilité enfants. Notez que si vous affectez des éléments manuellement, vous n'avez pas besoin d'implémenter de méthodes de protocole d'accessibilité dynamique, mais vous devrez peut-être émettre une notification de changement d'écran pour les éléments à détecter par VoiceOver.

Vue modale

Les vues modales capturent complètement l'attention de l'utilisateur jusqu'à ce qu'une tâche soit terminée. iOS clarifie cela pour les utilisateurs en atténuant et en désactivant tous les autres contenus lorsqu'une vue modale, telle qu'une alerte ou une fenêtre pop-up, est visible. Une application qui implémente une interface modale personnalisée doit indiquer à VoiceOver que cette vue mérite toute l'attention de l'utilisateur en définissant accessibilityViewIsModal . Notez que cette propriété ne doit être définie que sur la vue contenant le contenu modal, pas sur les éléments contenus dans une vue modale.

myModalView.accessibilityViewIsModal = YES;

Marquer une vue comme modale encourage VoiceOver à ignorer les vues fraternelles. Si, après avoir défini cette propriété, vous trouvez que VoiceOver navigue toujours sur d'autres éléments de votre application, essayez de masquer les vues de problème jusqu'à ce que le modal soit supprimé.

Éléments cachés

La plupart des classes UIKit, y compris UIView, adhèrent à UIAccessibilityProtocol et renvoient des valeurs correctes par défaut. Il est facile de considérer qu'un UIView défini sur caché est également absent de la hiérarchie d'accessibilité et ne sera pas parcouru par VoiceOver. Bien que ce comportement par défaut soit généralement suffisant, il peut arriver qu'une vue soit présente dans la hiérarchie de la vue, mais pas visible ou navigable. Par exemple, une collection de boutons peut être recouverte par une autre vue, ce qui les rend invisibles pour un utilisateur voyant. VoiceOver essaiera néanmoins de les naviguer car ils ne sont techniquement pas cachés par UIKit et sont donc toujours présents dans la hiérarchie d'accessibilité. Dans ce cas, vous devez indiquer à VoiceOver que la vue parent n'est pas accessible. Vous pouvez le faire en masquant explicitement la vue depuis UIKit en définissant la valeur masquée lorsque la vue devient hors écran:

myViewFullofButtons.hidden = YES;

Vous pouvez également laisser la vue parent visible et simplement masquer ses enfants dans la hiérarchie d'accessibilité:

myViewFullofButtons.accessibilityElementsHidden = YES;

Les vues temporaires sont un autre endroit où vous souhaitez masquer des éléments de la hiérarchie d'accessibilité tout en les laissant visibles aux utilisateurs. Par exemple, la vue qui apparaît lorsque vous appuyez sur le bouton de volume est visible pour les utilisateurs voyants mais ne nécessite pas d'attention comme le fait une alerte normale. Vous ne voudriez pas que VoiceOver interrompe l'utilisateur et déplace le curseur loin de ce qu'il faisait pour annoncer le nouveau volume, d'autant plus que l'ajustement du volume fournit déjà un retour auditif via le son de clic. Dans de tels cas, vous souhaiterez masquer la vue en utilisant accessibilityElementsHidden .



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow