Éviter les annonces prêto-parles sur Android

Chris McMeeking

Par Chris McMeeking

23 septembre 2015

Deque Logo « U Best Practices »
Cet article a été rédigé conjointement par Chris McMeeking et Alistair Barrell.

Lorsque vous effectuez des tests d'accessibilité, à quelle fréquence écoutez-vous une annonce longue dans son intégralité ? Par exemple, si vous deviez mettre ce paragraphe en surbrillance avec TalkBack, que écouteriez-vous ? L'intégralité ? Ou écouteriez-vous seulement les premières lignes, puis liriez-vous le reste du texte, en partant du principe que les API Android gèrent correctement cette situation ?

Mais attendez un peu, qu'en est-il de ce petit mot-là : « API » ? Comment ça se prononce ? Et si je l'écrivais « api » au lieu de « API » ? Y a-t-il une différence ?

N'oubliez pas non plus que le système d'exploitation Android existe en d'innombrables versions différentes sur des milliers d'appareils à travers le monde. Chacun de ces appareils présente une combinaison potentiellement différente de version de TalkBack, de version de l'API d'accessibilité, de modifications apportées au système d'exploitation par le fabricant, etc. Ainsi, ce n'est pas parce que cela fonctionne dans votre configuration que cela fonctionne forcément pour tout le monde !

Par exemple, certaines versions de VoiceOver interprètent cette phrase :

Le vol DQ 132 partira à l'heure pour Los Angeles, en Californie, dans 45 minutes.

comme

Le vol DQ 132 est prêt à décoller à l'heure prévue à destination de Los Angeles Certificate Authority dans 45 mètres.

Cette annonce est manifestement erronée ! La personne qui l'entendrait ne comprendrait absolument pas pourquoi son vol est à destination de l'autorité de certification de Los Angeles, ni pourquoi il doit décoller à 45 mètres de l'endroit où elle se trouve actuellement.

Utiliser les descriptions de contenu

Heureusement pour nous, il existe une solution simple. Il suffit d'ajouter une description du contenu pour le texte, en remplaçant les acronymes par leur prononciation réelle. Pour l'exemple ci-dessus, la description du contenu serait la suivante :

Le vol D Q 132 partira à l'heure pour Los Angeles, en Californie, dans quarante-cinq minutes.

Notez que « D Q » est divisé de manière à ce que les lettres soient lues séparément, et que nous avons épelé « California » et « minutes ». En modifiant la description du contenu sans changer le texte affiché dans la vue de texte, nous n'avons pas besoin de modifier notre interface utilisateur, tout en présentant les informations aux utilisateurs de TalkBack d'une manière qui ne prête pas à confusion.

Bonnes pratiques

Chaque fois que vous utilisez des lettres abrégées pour des acronymes ou des substitutions courantes de lettres par des mots (m = minutes), vérifiez bien que TalkBack les annonce correctement. Deux prononciations sont acceptables. La première consiste à lire le texte mot pour mot, la seconde à le lire sous sa forme développée exacte. Par exemple, « 45m 15s » peut être lu « 45 m 15 s » ou « 45 minutes 15 secondes ». En revanche, « 45 mètres quinze » n’est pas acceptable.

Veillez à écouter toutes les annonces de TalkBack et vérifiez qu’elles sont lues de manière compréhensible ! Ce n’est pas parce qu’un élément est sélectionnable et annoncé par TalkBack qu’il est pour autant entièrement accessible, et ce n’est pas parce qu’il fonctionne sur votre configuration qu’il fonctionne pour tout le monde !

En savoir plus…

 

Chris McMeeking

Chris McMeeking

Chris McMeeking est ingénieur logiciel et architecte chez Deque Systems, où il dirige les efforts de développement des produits natifs d’analyse de l’accessibilité mobile de Deque. Son parcours dans le domaine de l’accessibilité a débuté avec un projet mené à l’université du Michigan, le clavier à balayage ASK. Cette application a remporté de nombreux prix, notamment l’Intel Innovator’s Award d’une valeur de 100 000 dollars, la deuxième place au Mobile World Congress et le prix « Student of Da Vinci » décerné par la Fondation pour la sclérose en plaques. Chris est le développeur principal de l’Android Analyzer et un membre actif du groupe de travail chargé d’élaborer ces nouvelles normes d’accessibilité pour les appareils mobiles.

Mots-clés :  a11y Accessibilité Android développeurs mobile

Recevez les articles de blog directement dans votre boîte mail

Pas de bavardages inutiles, mais des informations concrètes sur l'accessibilité, fournies par des experts qualifiés.

Vous acceptez que Deque , utilise et partage des informations conformément à Dequedéclaration de confidentialité. Vous pouvez modifier votre consentement à tout moment en nous contactant.

En savoir plus sur ce sujet

Deuxième jour de l'Axe-con 2026

Logo de Deque
26 février 2026 Par Deque

L'Axe-con 2026 est peut-être terminé, mais l'élan ne cesse de prendre de l'ampleur. Entre les témoignages poignants sur le capacitisme et les réflexions révélatrices sur l'impact de l'IA sur la vitesse d'accessibilité, cet événement a été tout simplement incroyable. Découvrez ici notre compte-rendu de la deuxième journée !

Lire l'article
Deuxième jour de l'Axe-con 2026

Premier jour de l'Axe-con 2026

Logo de Deque
24 février 2026 Par Deque

La première journée de l'Axe-con 2026 est désormais derrière nous ! Des thèmes tactiques et techniques aux sujets éducatifs et inspirants, l'Axe-con couvre tous les domaines : de l'IA à l'EAA, en passant par l'inclusion proactive et le « Shifting Left » !

Lire l'article
Premier jour de l'Axe-con 2026