Accessibilité web et mobile (partie 2)

| 1 Comment | 8 minutes read

La semaine dernière, nous avons discuté des aspects d’accessibilité sur le web (http://www.ekito.fr/people/?p=2455). On se penche aujourd’hui sur les solutions existantes dans le développement mobile et pour cette partie sur l’Accessibilité iOS.

Accessibilité sous iOS

Apple est l’un des principaux acteurs en matière d’accessibilité et considère les non-voyants comme des utilisateurs à part entière. Apple met notamment à disposition de ses consommateurs une équipe dédiée, assez facilement joignable. Les appareils Apple sont accessibles dès leur première utilisation et ne nécessitent pas l’installation d’autres logiciels.

En ce qui concerne le développement sous iOS, la même approche est de rigueur. Une application, en utilisant les éléments de base fournis par le SDK, est accessible en majeure partie (environ 80 %) sans que nous, développeurs, n’ayons rien à faire mais ce n’est souvent pas suffisant pour qu’elle soit entièrement utilisable pour des utilisateurs non voyants.
Ajouter des éléments d’accessibilité ne requiert pas beaucoup de travail mais ouvre votre application à une plus grande audience.

“iOS accessibility is the easiest application accessibility in the history of computing. Quit blowing it.”
(Joe Clark http://blog.fawny.org/2012/12/17/vo-camera/)

iOS permet aux utilisateurs de “zoomer” sur l’écran, inverser les couleurs et plus, notamment avec VoiceOver. VoiceOver convertit la présentation visuelle d’une application en une description audio permettant aux utilisateurs “d’écouter” l’interface. Le développement se concentre sur les fonctionnalités VoiceOver au travers du protocole UIAccessibility.

Le protocole UIAccessibility contient les propriétés suivantes :

  • accessibilityTraits : Ensemble d’indicateurs qui décrit un élément d’interface. Ils spécifient comment VoiceOver doit interpréter l’élément en question et comment cet élément agit.
  • accessibilityLabel : Décrit le rôle d’une vue ou l’action d’un contrôle.
  • accessibilityHint : Décrit le comportement d’un élément suite à une action de l’utilisateur.
  • accessibilityFrame : Indique le rectangle qu’occupe l’élément sur l’écran.
  • accessiblityValue : Indique la valeur associée à l’élément (valeur OUI/NON pour un interrupteur, valeur courante pour un slider, …).

Un élément UIControl est par défaut accessible mais cette propriété peut être changée en assignant la valeur NO à isAccessibilityElement. En règle générale, il faut toujours activer l’accessibilité d’un élément à moins que cet élément contienne des sous-vues qui ont besoin d’être accessibles. Dans ce cas, il faut rendre seulement accessibles les éléments utiles à la compréhension de l’interface. Les cellules d’une liste sont un bon exemple de ces éléments qui en contiennent d’autres.

iOS accessibility interface builder

Accessibility Traits

Les traits sont un ensemble d’indicateurs définissant la nature de l’élément accessible. Parmi tous les types d’éléments, on peut citer les indicateurs suivants :

  • UIAccessibilityTraitButton – bouton
  • UIAccessibilityTraitLink – lien hypertexte
  • UIAccessibilityTraitSearchField – champ de recherche
  • UIAccessibilityTraitImage – image
  • UIAccessibilityTraitStaticText – texte statique

Les éléments de type Button, Link, Static Text, ou Search Field ne peuvent pas être combinés et Apple exige de ne choisir qu’un seul trait parmi ces quatre pour définir un élément. Par contre, un élément de type Button peut très bien afficher une image.

Les traits permettent également de définir l’état ou la fonction d’un élément :

  • UIAccessibilityTraitSelected : L’élément courant est sélectionné.
  • UIAccessibilityTraitNotEnabled : L’élément est désactivé.
  • UIAccessibilityTraitAdjustable : L’élément peut prendre plusieurs valeurs comme pour un slider ou un picker.
  • UIAccessibilityTraitPlaysSound : L’élément jouera un son quand il sera activé par VoiceOver.
  • UIAccessibilityTraitUpdatesFrequently : L’élément change assez souvent d’état (un compteur par exemple), il serait donc pénible d’avertir l’utilisateur à chaque changement.
  • UIAccessibilityTraitStartsMediaSession : L’élément lance un média. Cet indicateur permet de limiter les interruptions VoiceOver au cours de la lecture du média.
  • UIAccessibilityTraitCausesPageTurn : L’élément doit automatiquement tourner la page quand VoiceOver a fini de lire le texte qu’il contient (iBooks par exemple).

Accessibility Label

Il doit dire à l’utilisateur ce qu’est l’élément qu’il est entrain de survoler. Le label est souvent un seul mot.
Quelques conseils pour choisir un bon label :

  • Pas la peine d’ajouter le type de l’élément dans le label. VoiceOver ajoute automatiquement la nature de l’élément (AccessibilityTrait) après avoir énoncé le label.
  • Les majuscules et la ponctuation sont prises en compte par VoiceOver. Commencer le label par une majuscule sonnera donc plus juste. Et le label n’étant pas une phrase, il ne faut pas ajouter de point à la fin.

Accessibility Hint

Cet indice indique à l’utilisateur quoi attendre de l’action sur un élément.
Quelques conseils :

  • Utiliser des phrases.
  • Eviter de mentionner l’action utilisateur. Il n’y a pas besoin de décrire l’action utilisateur comme par exemple “Cliquer sur ce bouton pour appeler ce numéro”.

Dans notre exemple, une fois positionné sur le bouton téléphone, VoiceOver indiquera “Bouton Téléphone. Passe un appel au numéro entré.”.

Les labels et les hints sont internationnalisables, on peut donc gérer plusieurs langues.

Notifications

Pour notifier VoiceOver d’un changement, on utilise l’helper void UIAccessibilityPostNotification (UIAccessibilityNotifications notification, id argument);

  • UIAccessibilityAnnoucementNotification : Pour prononcer n’importe quel texte.
  • UIAccessibilityLayoutChangeNotification ou UIAccessibilityScreenChangeNotification : Notifie VoiceOver d’un changement important dans l’interface graphique.

Il est très utile de s’abonner à la notification UIAccessibilityVoiceOverStatusChanged qui est lancée à chaque fois que l’utilisateur active ou désactive VoiceOver. On peut également savoir si VoiceOver est actuellement activé grâce à la fonction UIAccessibilityIsVoiceOverRunning(). Cela peut permettre d’adapter l’interface graphique en fonction de la présence de VoiceOver (passer d’un graphe très visuel à une liste par exemple).

Tips and tricks

  • Si vous paramètrez votre élément avec un alpha à zéro, il ne sera pas visible sur l’interface graphique mais il sera “visible” par VoiceOver. Si vous voulez vraiment cacher un élément, il faut utiliser le paramètre hidden (valeur à YES).
  • Pour des projets sous iOS 5, dans InterfaceBuilder, l’ordre des éléments disposés rentre en compte dans la manière dont VoiceOver parcourt l’écran. Il est donc important de lister les éléments dans l’ordre où ils apparaissent à l’écran.
    Dans l’exemple ci-dessous, bien que l’ordre à l’écran soit d’abord le champ de texte puis le bouton d’appel, l’ordre des éléments sur Interface Builder est inversé. VoiceOver traitera donc le bouton avant le champ de texte.

iOS accessibility interface builder order

  • Vous pouvez contrôler le langage utilisé dans toute l’application [[UIApplication sharedApplication] setAccessibilityLanguage:@”fr-FR”]; indépendamment de la langue du téléphone.

Tester votre application

Depuis le device, pour activer VoiceOver, rendez vous à l’écran de réglages Accessibilité (Réglages > Général > Accessibilité) et placez VoiceOver à ON. Vous pouvez ensuite activer ou désactiver VoiceOver en triple-cliquant sur le bouton Home du device. Si vous n’avez pas touché aux réglages de base de votre device, VoiceOver est déjà activable via le triple-click.
Pour naviguer dans l’application, il existe des gestes d’accessibilité de base (cf documentation Apple) pour passer d’un élément à l’autre. Pour vous rendre compte au mieux de comment votre application va être retranscrite par VoiceOver, testez la en fermant les yeux (ou en cachant l’interface avec un tissu) et en utilisant seulement les gestes d’accessibilité.

Depuis le simulateur, l’outil Accessibility Inspector ajoute une popup à l’écran décrivant l’élément courant d’interface révélant toutes ses propriétés d’accessibilité (label, hint, trait …). Pour activer Accessibility Inspector, comme sur le device, il faut se rendre à l’écran de Réglages du simulateur (Réglagles > Général > Accessibilité) et enclencher l’option Accessibility Inspector.
La croix en haut à gauche permet d’activer ou désactiver l’inspecteur : cliquez une fois pour réduire la popup à une seule ligne et ainsi interagir avec votre application. Lorsque vous êtes positionné sur l’élément que vous voulez inspecter, cliquez à nouveau sur la croix pour activer l’inspecteur.

iOS accessibility inspector

Pour aller plus loin

Par défaut, VoiceOver ne couvre pas les vues dessinées par drawRect: . Il y a donc un peu plus de travail à fournir pour que votre application soit entièrement accessible mais encore une fois, tous les outils sont dans les mains des développeurs.

Il suffit d’implémenter le protocole UIAccessibilityContainer qui définit trois méthodes qui permettent de rendre accessible les éléments personnalisés :

  • (NSInteger)accessibilityElementCount;
  • (id)accessibilityElementAtindex:(NSInteger)index;
  • (NSInteger)indexOfAccessibilityElement:(id)element;

Références

E. Sadun, “Accessibility,” in The Core iOS 6 Developer’s Cookbook, 4e éd., Addison-Wesley, 2012, pp. 341-352.

Apple, Accessibility Programming Guide for iOS, 2012. [En ligne]. Disponible : https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/iPhoneAccessibility/Introduction/Introduction.html

David Rönnqvist, Making drawRect: accessible, 2013. [En ligne]. Disponible : http://ronnqvi.st/making-drawrect-accessible/

Share Button

Mélanie Bessagnet Author: Mélanie Bessagnet

Développeuse iOS, experte en pommes.
Ma citation préférée : "Choose a job you love and you will never have to work a day in your life" (Confucius)
Mes hashtags : #iOS #Cocoa #Objective-C #artoys #muffins

One Comment

  1. Pingback: Accessibilité web et mobile (partie 2) | ekito people | Laurent Chastrusse UX Designer Ergonome Web WebDesigner | Scoop.it

Leave a Reply

Required fields are marked *.


CommentLuv badge