Accessibilité

Cette section justifie à elle seule la publication de cette page. Chaque point est réel, nous le connaissons, et aucun n'est présenté ici comme résolu.

Le site est publié en trente langues et n'a pas été testé avec un lecteur d'écran dans chacune d'elles. Les tests ont été effectués en anglais. La prononciation et l'ordre de lecture dans les langues qui s'écrivent de droite à gauche, ainsi que dans les écritures pour lesquelles nos polices d'affichage ne couvrent aucun caractère et où la police de la plateforme prend le relais, n'ont pas été vérifiés avec des technologies d'assistance.

Nos deux polices couvrent uniquement l'alphabet latin. Le cyrillique, le devanagari, le géorgien, le thaï, l'arabe, l'hébreu, le bengali, l'éthiopien et les écritures CJK utilisent les polices intégrées à la plateforme. C'est généralement une bonne chose pour la lisibilité, mais cela signifie que nous ne contrôlons pas dans ces langues les détails typographiques que nous maîtrisons en anglais — le poids, l'espacement, la taille à partir de laquelle un petit texte cesse d'être suffisamment petit.

Certains éléments interactifs sont récents et moins testés. La matrice de comparaison et le filtre de recherche de l'aide actualisent les lignes sur place, ce qui est le bon modèle, mais l'annonce à un lecteur d'écran du nombre de résultats modifié a été implémentée sans encore avoir été testée auprès d'utilisateurs.

La même exigence s'applique à l'app, qui est toutefois auditée moins souvent que le site. Elle prend en charge le redimensionnement du texte et le lecteur d'écran de la plateforme, qui font l'essentiel du travail, mais nous n'effectuons actuellement pas d'audit formel de l'accessibilité à chaque version.

Aucun audit formel par un tiers n'a été réalisé sur le site ou sur l'app. Nous préférons le dire plutôt que de laisser entendre que nous détenons une certification que nous n'avons pas.

L'app Telvio s'appuie sur les fonctions d'accessibilité du système d'exploitation sur lequel elle fonctionne : VoiceOver et Dynamic Type sur iOS, TalkBack et le redimensionnement des polices sur Android. Elles couvrent l'essentiel de ce qui compte dans une app dont l'interface se résume à un clavier, un solde et une liste de tarifs.

Une décision de conception mérite d'être mentionnée comme une caractéristique d'accessibilité plutôt que comme une fonctionnalité. Comme l'app ne nécessite aucun compte, il n'y a ni formulaire d'inscription, ni mot de passe à saisir, ni étape de vérification de l'adresse e-mail, ni code à récupérer dans un message : toute cette catégorie d'interactions qui met le plus souvent en difficulté les personnes utilisant des technologies d'assistance, ou toute personne pour qui les formulaires sont difficiles, n'existe tout simplement pas. Installez, composez, parlez.

La limitation correspondante se trouve au même endroit que tout le reste : l'app ne peut pas appeler les services d'urgence, comme indiqué dans la page appels d'urgence. Si quelqu'un installe cette app pour un proche — un cas fréquent, notamment pour les personnes âgées qui appellent leur famille à l'étranger — c'est la chose la plus importante à lui expliquer à ce moment-là.

Envoyez un e-mail à [email protected] avec pour objet Accessibility. Informations utiles : la page ou l'écran concerné, ce que vous essayiez de faire, la technologie d'assistance que vous utilisiez, avec sa version, et ce qui s'est produit à la place. Rien de tout cela n'est obligatoire : une phrase comme “Je ne peux pas utiliser le tableau des tarifs avec un lecteur d'écran” constitue un très bon signalement, et nous préférons en recevoir un plutôt que rien.

Nous nous efforçons de répondre sous cinq jours ouvrés en indiquant notre évaluation et, lorsque nous reconnaissons l'existence d'un problème, un délai approximatif. Les problèmes qui empêchent quelqu'un d'accomplir une tâche sont traités avant les autres ; ceux qui la rendent plus difficile sont planifiés honnêtement plutôt que promis de manière vague.

Si vous êtes dans l'Union européenne et pensez qu'une obligation d'accessibilité n'est pas respectée, vous pouvez également saisir l'organisme national compétent chargé de son application. Nous préférerions que vous vous adressiez d'abord à nous, et nous vous répondrons dans tous les cas.

Deux points méritent d'être décrits, car ils font la différence entre une déclaration et une pratique.

Le contraste est calculé sur ce qui est affiché, pas analysé dans le code. Une valeur de couleur lue dans une feuille de style indique ce qu'un élément devait être, pas l'apparence qu'il a finalement — un élément semi-transparent au-dessus d'une bande sombre, une fonction de couleur moderne qu'une expression régulière ne comprend pas, un en-tête fixe au-dessus d'une image de couverture. La vérification restitue l'arrière-plan réel de chaque élément en remontant jusqu'au premier ancêtre opaque et en calculant la couleur via le navigateur lui-même, puis calcule le ratio. Elle a détecté du texte courant sur ce site à 4.49:1, ce qui est inférieur au niveau AA tout en paraissant parfaitement normal lorsqu'on le regarde isolément.

La page est vérifiée telle qu'elle est affichée, et non telle qu'elle est écrite. Une sonde distincte charge chaque page dans un vrai navigateur et vérifie si du texte visible dans la fenêtre a une opacité nulle, si le document défile horizontalement et si un élément est affiché dans la même couleur que son propre arrière-plan. Ce dernier cas peut sembler absurde jusqu'au jour où il arrive en production : une seule règle CSS groupée a un jour défini la couleur et l'arrière-plan d'un libellé avec la même valeur, produisant un ratio de contraste de 1:1, invisible dans le code, invisible dans le DOM et invisible dans une capture d'écran de la source.