Nouvelles API, commande vocale et autres améliorations en matière d'accessibilité dans iOS 13
En matière d'accessibilité mobile, iOS fait figure de référence, et iOS 13 creuse encore davantage l'écart avec ses concurrents. Si vous connaissez déjà les fonctionnalités d'accessibilité d'iOS, ces changements vous sembleront être des améliorations bienvenues. Si vous ne les connaissez pas encore, nous vous conseillons de vous familiariser un peu avec le menu des réglages d'accessibilité d'iOS avant de poursuivre votre lecture !
Bon nombre des modifications qu'ils ont apportées ont un impact significatif sur les technologies existantes et interagissent avec celles-ci de manière significative, notamment :
- Activer une configuration à l'échelle du système pour la lecture automatique des fichiers multimédias.
- Commande vocale : une toute nouvelle technologie d'assistance.
- De nouvelles API qui facilitent la création d'actions d'accessibilité personnalisées pour les développeurs.
Commande vocale
Imaginez : vous rentrez d’une mission à l’étranger. Vous avez perdu l’usage de vos mains lors d’une opération de combat. Vous commencez à prendre conscience à quel point vous dépendez de cette capacité. Vous avez du mal à commander une pizza pour votre famille, à envoyer des SMS à vos enfants, à tenir un blog et à collaborer efficacement avec vos collègues. Ne serait-ce pas formidable de pouvoir contrôler facilement votre téléphone avec votre voix ?
La commande vocale est une technologie destinée à aider les utilisateurs iOS souffrant d’un handicap physique à accomplir cette tâche. Lorsque la commande vocale est activée, une fenêtre contextuelle s’affiche, indiquant des numéros correspondant à chaque élément actif. Vous pouvez alors utiliser ces numéros pour identifier et actionner chaque commande individuellement. La commande vocale ne dispose pas d’une introduction efficace destinée aux « nouveaux utilisateurs » ; il a donc été un peu difficile de découvrir le format approprié des commandes vocales – du moins selon les normes d’ergonomie des produits Apple.
Les commandes vocales que j'ai testées avec succès sont les suivantes :
- Afficher les noms : modifie la superposition pour afficher les noms.
- Afficher les numéros : modifie la superposition pour afficher les numéros.
- Appui 1 : clique sur le premier élément de commande à l'écran.
- Appuyez sur « Applications » : cliquez sur le bouton intitulé « Applications ».
- Increment {Number/Name}: Increments an adjustable control.
- Decrement {Number/Name}: Decrements an adjustable control.
- Retour à la page d'accueil
- Retour
- Dis-moi ce que je dois dire. ? J'adore celle-là !!!
Je souhaite tout de même essayer d'utiliser les `CustomAccessibilityActions` de VoiceControl et peut-être explorer plus en profondeur les contrôles interactifs (comme les carrousels ou les widgets de calendrier). Cela dit, mon expérience avec VoiceControl a été très positive jusqu'à présent. Malgré une courbe d'apprentissage assez raide, VoiceControl est un formidable ajout à la famille des fonctionnalités d'accessibilité d'iOS.
Regardez-moi utiliser VoiceControl ici pour effectuer quelques tests d'accessibilité rapides et faciles :
Tests d'accessibilité sur iOS : la commande vocale à la rescousse !
L'une des choses que j'apprécie particulièrement chez iOS et la commande vocale, c'est leur potentiel pour simplifier le processus de test de l'accessibilité sur iOS. Voici quelques problèmes que je rencontre avec la manière dont ce processus est actuellement mis en œuvre :
- En tant que développeur, activer et désactiver VoiceOver fait perdre de précieuses secondes à vérifier des détails insignifiants. Exemple : cette étiquette a-t-elle été ajoutée correctement ?
- En tant que testeur d'accessibilité, le processus devient répétitif, et chaque minute que je peux gagner pour chaque écran que je teste est précieuse.
- En particulier, s'assurer que chaque élément interactif puisse être activé par des technologies d'assistance est un processus extrêmement lent !
La commande vocale peut s'avérer d'une grande aide dans ces deux cas de figure ! Voyons quelques exemples concrets.
Accélérer les tests relatifs à l'ordre de focalisation (WCAG 2.4.3)
L'un des aspects des tests d'accessibilité qui prend le plus de temps est celui consacré à la vérification de l'ordre de sélection. S'assurer minutieusement que chaque élément à l'écran puisse être sélectionné par VoiceOver et SwitchControl est une tâche difficile et chronophage, même pour des testeurs expérimentés. Si seulement nous disposions d'une meilleure solution ! Attendez un peu…
En testant la commande vocale, j'ai pu constater ce qui suit :
- Toutes les fonctionnalités que vous pouvez activer dans « Commande par commutateur » peuvent également être activées dans « Commande vocale ».
- Tout ce que vous pouvez activer dans la Commande vocale peut également être activé dans la Commande par commutateur.
Nous pouvons tirer parti de ces informations lors des tests d'accessibilité ! Imaginez que vous puissiez jeter un simple coup d'œil à une image et savoir ainsi que tous les utilisateurs de VoiceOver, de Switch Control et de Voice Control peuvent activer chaque élément de contrôle de votre application. Eh bien, voilà :
À partir de cette image seule, on peut en conclure que chaque commande est :
- Fonctionnalité disponible avec VoiceOver
- Compatible avec Switch Control
- Compatible avec la commande vocale
- ET il n'y a pas de problèmes flagrants liés à l'ordre de mise au point
Les tests de la commande vocale sont plus rapides que ceux de la commande par commutateurs. Cependant, la commande par commutateurs nécessite tout de même de prendre en compte certains aspects, notamment en ce qui concerne le regroupement des commandes et l'ergonomie.
Connaissez bien votre contenu et vos utilisateurs, et effectuez des tests avec la technologie qui vous semble la plus adaptée ; toutefois, une fois que vous aurez testé l'une d'entre elles, l'autre deviendra nettement moins prioritaire.
Tests d'accessibilité iOS pour les développeurs
On me pose tout le temps cette question :
« Quels tests faut-il effectuer dans le cadre du processus de développement et lesquels faut-il laisser aux experts en accessibilité ? »
Ma réponse a toujours été que les développeurs devraient :
- Assurez-vous que chaque contrôle actif porte un nom descriptif et puisse être activé.
- Effectuer des tests d'accessibilité automatisés.
Il n’est pas raisonnable de demander aux développeurs de réaliser des évaluations complètes de l’accessibilité. Je travaille avec de nombreux développeurs brillants ici, chez Deque , qui font preuve d’une formidable passion pour l’accessibilité. Ici, nous vivons et respirons cette cause. Peut-être qu’une poignée d’entre eux serait capable de réaliser une évaluation de l’accessibilité qui ne ferait pas rire un expert en la matière. Même le simple fait de distinguer les images nécessitant une description de celles qui sont purement décoratives est une décision qui devrait être validée par un expert.
Cependant, rien ne justifie qu’une application soit commercialisée avec des commandes qui ne peuvent pas être activées par les technologies d’assistance. Cela dit, il est important de réduire au minimum le temps que les développeurs consacrent aux tests de leur application et de maximiser celui qu’ils consacrent à l’écriture du code. C’est là qu’intervient la commande vocale… Découvrez cette superbe capture d’écran ci-dessous !
Vous vous souvenez de quel était mon premier objectif pour les développeurs ?
- Assurez-vous que chaque contrôle actif porte un nom descriptif et puisse être activé.
Grâce à la commande vocale, cette vérification devient un jeu d'enfant ! Et le meilleur dans tout ça : la commande vocale peut rester activée sans affecter l'utilisation normale de l'appareil. Les développeurs n'ont donc pas besoin de l'activer et de la désactiver à chaque fois. Cela permet d'effectuer des tests très rapidement et d'instaurer un cycle de tests d'accessibilité auquel aucun développeur ne peut s'opposer !
Conclusion : tout développeur voyant devrait effectuer des tests de base sur la commande vocale. Il n’y a aucune raison de ne pas le faire. Cela permet en effet d’éviter très facilement les problèmes d’accessibilité les plus graves et les plus bloquants que l’on puisse rencontrer dans les applications iOS.
Paramètres d'accessibilité : désactiver la lecture automatique des vidéos
iOS 13 introduit un nouveau paramètre d'accessibilité applicable à l'ensemble du système : la possibilité de désactiver la lecture automatique des vidéos. De plus, pour une personne aveugle, il n'y a peut-être pas beaucoup de différence entre une vidéo et, par exemple, un podcast. Étendons donc cette fonctionnalité à tous les contenus multimédias à lecture automatique.
La possibilité de désactiver la lecture automatique des fichiers multimédias à l'échelle du système est un atout considérable pour les utilisateurs en situation de handicap, et cette fonctionnalité, bien que discrète, ne doit pas être négligée. Cependant, il faudra du temps à la communauté des développeurs pour adopter ce paramètre. Cette fonctionnalité est déjà prise en charge individuellement par de nombreuses applications depuis un certain temps, en particulier celles dont l'objectif principal est l'affichage de contenus multimédias, comme YouTube ou Facebook.
Il est très utile de regrouper ces paramètres dans un espace commun que les autres applications peuvent facilement respecter. D'autant plus que la plupart des autres contenus multimédias à lecture automatique ont nettement moins de valeur que ceux de Facebook ou de YouTube (*hum* les publicités).
Implications en matière de conformité à la norme WCAG 1.4.2
Cette API est directement liée à la norme WCAG 1.4.2 – Contrôle audio. Pour citer le document explicatif des WCAG : « Les personnes qui utilisent un logiciel de lecture d'écran peuvent avoir des difficultés à entendre la synthèse vocale si un autre son est diffusé en même temps. »
Ce paramètre permet aux utilisateurs d'éviter ce scénario. Dans la terminologie des WCAG, le respect de ce paramètre constitue une « technique suffisante » pour satisfaire à ce critère de succès.
Selon moi, le fait de NE PAS respecter ce paramètre constitue une violation de ce critère de succès, même si je suis sûr que les puristes des WCAG me contrediraient sur ce point, car des « mécanismes alternatifs » resteraient conformes. À tout le moins, le respect du paramètre « isVideoAutoplayEnabled » fait partie des bonnes pratiques iOS, et les développeurs d’applications devraient s’y conformer avant de lancer la lecture automatique d’un contenu multimédia pendant plus de quelques secondes.
En plus, c'est plus simple que de gérer soi-même ce genre de processus. Regarde un peu comme c'est facile :
Documentation de l'API iOS « UIAccessibility.isVideoAutoplayEnabled »
Si UIAccessibility.isVideoAutoplayEnabled {
// Lancer automatiquement la lecture des contenus multimédias gênants
} sinon {
// Ne pas lancer automatiquement la lecture des contenus multimédias gênants.
}
Nouvelle API pour les développeurs : UIAccessibilityCustomActionHandler
Documentation de l'API iOS : UIAccessibilityCustomAction.Handler
Les `UIAccessibilityCustomActions` constituent un outil puissant pour les développeurs d’applications iOS axées sur l’accessibilité. Elles vous permettent d’associer plusieurs actions à une seule cible pouvant recevoir le focus. C’est idéal pour permettre aux utilisateurs de VoiceOver ou de la Commande par commutateurs d’effectuer des actions qui seraient normalement réalisées par des gestes, comme faire glisser vers la droite la fiche de contact de votre ennemi juré pour la supprimer. Muhahaha !!!
La nouvelle API Handler facilite la création de ces actions. Ce qui nécessitait auparavant une cible associée et un sélecteur se résume désormais à une simple fermeture. Il suffit d’associer votre action personnalisée à un nom et à un gestionnaire ; ce dernier sera alors exécuté lorsque les utilisateurs de VoiceOver activeront l’action.
En termes techniques, nous échangeons ceci :
init(nom : String, cible : Any?, sélecteur : Selector)
Pour cela :
init(nom : String, gestionnaire d'action : Handler)
Même s'il ne s'agit pas d'une amélioration spectaculaire, cela facilite tout de même ce processus. De plus, cela renforce l'engagement d'Apple en faveur d'un modèle de conception d'accessibilité exceptionnel, associé à une approche de développement fonctionnelle qui semble plus moderne.
Résumé
iOS 13 n'apporte pas de changements révolutionnaires en matière d'accessibilité. En particulier, il n'y a pas de mises à jour significatives concernant VoiceOver. On note toutefois la présence de quelques outils bienvenus et d'améliorations progressives solides qui témoignent de l'engagement d'Apple envers les utilisateurs en situation de handicap. Par ailleurs, la commande vocale est un nouvel outil formidable qui devrait désormais faire partie intégrante du processus de test de toute équipe de développement d'applications.
