EN 301 549 Exigences d’accessibilité pour les produits et services TIC - 6. TIC avec communication vocale bidirectionnelle
Table des matières de la section 6
6.1 Largeur de bande audio pour la parole
NOTE 1 : À des fins d’interopérabilité, la prise en charge de la Recommandation UIT-T G.722 [i.21] est largement utilisée.
NOTE 2 : Si une négociation par codec est mise en œuvre, d’autres codecs normalisés tels que la Recommandation UIT‑T G.722.2 [i.22] sont parfois utilisés afin d’éviter le transcodage.
6.2 Fonctionnalité de texte en temps réel (RTT)
6.2.1 Fourniture de RTT
6.2.1.1 Communication de RTT
Lorsque la TIC se trouve dans un mode qui offre un moyen de communication vocale bidirectionnelle, la TIC doit offrir un moyen de communication de RTT bidirectionnelle, sauf si cela exigerait des changements de conception pour ajouter du matériel d’entrée ou de sortie à la TIC.
NOTE 1 : Cette exigence inclut les produits qui ne disposent pas de capacité physique d’affichage ou d’entrée de texte, mais ont la capacité de se connecter à des dispositifs disposant de telles capacités. Elle inclut également une TIC intermédiaire entre les extrémités de la communication.
NOTE 2 : Il n’existe aucune exigence à ajouter : un afficheur matériel, un clavier physique ou un matériel destiné à prendre en charge la possibilité de se connecter à un écran ou un clavier, câblé ou sans fil, si ce matériel ne serait normalement pas fourni.
NOTE 3 : À des fins d’interopérabilité, la prise en charge de la Recommandation UIT-T T.140 [i.36] est largement utilisée.
6.2.1.2 Voix et texte simultanés
Lorsque la TIC offre un moyen de communication vocale bidirectionnelle et pour que les utilisateurs puissent communiquer par RTT, elle doit permettre la voix et le texte simultanés au travers d’une seule connexion d’utilisateur.
NOTE 1 : Avec la communication entre plus de deux personnes, comme dans un système de conférence, il est permis (mais pas exigé ou nécessairement recommandé) que le RTT soit traité dans un seul champ d’affichage et que la « prise de tour » soit nécessaire pour éviter une confusion (de la même manière que la prise de tour est exigée pour ceux qui se présentent/entrent en conversation).
NOTE 2 : Avec la communication entre plus de deux personnes, la meilleure pratique consiste à traiter de la même manière la main levée des utilisateurs vocaux et des utilisateurs RTT, de sorte que les utilisateurs vocaux et mode RTT soient dans la même file d’attente.
NOTE 3 : Avec un système de conférence à plus de deux personnes dont l’une des fonctionnalités est la discussion en direct, le RTT (comme la voix) serait normalement séparé de la discussion en direct afin que l’utilisation de RTT n’interfère pas avec la discussion en direct (ce qui veut dire que les utilisateurs peuvent échanger des messages dans le champ de discussion en direct pendant que la personne se présente/entre en conversation avec RTT – de la même manière que les utilisateurs échangent des messages en utilisant la fonctionnalité de discussion en direct pendant qu’ils sont en conversation vocale). Les utilisateurs du RTT utiliseraient alors le RTT pour la présentation et l’utilisation de la fonctionnalité de discussion en direct pour échanger des messages tandis que d’autres sont en train de se présenter (par le biais de la voix ou du RTT).
NOTE 4 : La disponibilité de la voix et du RTT exécutés simultanément (et séparément de la discussion en direct) peut également permettre au champ de RTT de prendre en charge le sous-titrage par texte lorsque quelqu’un parle (et qu’il n’est donc pas utilisé pour le mode RTT, car ce n’est pas le tour de l’utilisateur du RTT de parler).
NOTE 5 : Lorsque le logiciel côté serveur ainsi que le matériel et le logiciel locaux sont tous deux exigés pour fournir la communication vocale, quand aucune des deux parties ne peut prendre en charge la communication vocale sans l’autre et sont vendues sous la forme d’unité pour la fonction de communication vocale, les composants locaux et côté serveur sont alors considérés comme un seul et même produit.
6.2.2 Affichage du RTT
6.2.2.1 Affichage visuellement différentiable
Lorsque la TIC possède des fonctions d’émission et de réception de RTT, le texte émis affiché doit être visuellement différencié et séparé du texte reçu.
NOTE : L’aptitude de l’utilisateur à choisir entre l’affichage en ligne ou séparément du texte émis et reçu, et avec des options à sélectionner, permet aux utilisateurs d’afficher le RTT sous une forme qui leur convient le mieux. Cela permettrait aux utilisateurs du braille d’utiliser un seul champ et de prendre leur tour et aussi d’afficher le texte de la manière séquentielle dont ils peuvent avoir besoin ou qu’ils préfèrent.
6.2.2.2 Sens émission et réception déterminable par programme
Lorsque la TIC possède des fonctions d’émission et de réception de RTT, le sens émission/réception du texte émis/reçu doit pouvoir être déterminé par programme, sauf si le RTT est mis en œuvre comme une fonctionnalité verrouillée.
NOTE : Cela permet aux lecteurs d’écran de distinguer le texte entrant du texte sortant lors d’une utilisation avec la fonctionnalité RTT.
6.2.2.3 Identification du locuteur
Lorsque la TIC possède des fonctions RTT et réalise l’identification du locuteur pour la voix, la TIC doit fournir une identification du locuteur pour le RTT.
NOTE : Cela est nécessaire pour permettre aux participants à la fois vocaux et RTT de savoir qui est actuellement en train de communiquer, qu’ils soient en mode RTT ou vocal.
6.2.2.4 Indicateur visuel de l’audio avec RTT
Lorsque la TIC réalise la communication vocale bidirectionnelle et possède des capacités de RTT, la TIC doit fournir un indicateur visuel en temps réel de l’activité audio sur l’affichage.
NOTE 1 : L’indicateur visuel peut être une simple position de caractère sur l’affichage qui fluctue pour refléter l’activité audio, ou la présentation de l’information d’une autre manière qui peut être à la fois visible pour les utilisateurs voyants et transmise aux utilisateurs sourds-aveugles qui utilisent un dispositif d’affichage en braille.
NOTE 2 : Sans cette indication, une personne qui n’a pas la possibilité d’entendre ne sait pas quand quelqu’un parle.
6.2.3 Interopérabilité
Lorsque la TIC possédant une fonctionnalité de RTT est en interfonctionnement avec une autre TIC possédant une fonctionnalité de RTT (comme exigé par le paragraphe 6.2.1.1), elles doivent prendre en charge les mécanismes d’interopérabilité de RTT applicables décrits ci-après :
- TIC en interfonctionnement avec une autre TIC connectée directement au réseau téléphonique public commuté (RTPC), en utilisant la Recommandation UIT-T V.18 [i.23] ou l’une quelconque de ses annexes relatives aux signaux de téléphonie en mode texte sur l’interface RTPC ;
- TIC en interfonctionnement avec une autre TIC de type VOIP avec protocole d’initiation de session (SIP) et utilisant le RTT conformément à l’IETF RFC 4103 [i.13]. Pour une TIC en interfonctionnement avec une autre TIC utilisant le sous‑système multimédia IP (IMS) pour la mise en œuvre du VOIP, l’ensemble de protocoles spécifié dans l’ETSI TS 126 114 [i.10], l’ETSI TS 122 173 [i.11] et l’ETSI TS 134 229 [i.12] décrivent comment s’appliquerait l’IETF RFC 4103 [i.13] ;
- TIC en interfonctionnement avec une autre TIC utilisant des technologies différentes de a ou b ci-dessus, utilisant une spécification commune pertinente et applicable pour les échanges de RTT qui est publiée et disponible pour les environnements dans lesquels elles fonctionneront. Cette spécification commune doit comprendre une méthode de signalisation de la perte ou de la corruption de caractères ;
- TIC en interfonctionnement avec une autre TIC utilisant une norme pour le RTT qui a été adoptée pour être utilisée dans l’un quelconque des environnements ci-dessus et qui est prise en charge par toutes les autres TIC actives qui prennent en charge la voix et le RTT dans cet environnement.
NOTE 1 : En pratique, de nouvelles normes sont adoptées sous la forme d’un codec/protocole alternatif pris en charge en même temps que la norme commune existante et utilisé lorsque tous les composants de bout en bout le prennent en charge alors que le développement technologique, combiné à d’autres raisons, y compris l’évolution de la société et le rendement économique, peuvent en rendre d’autres obsolètes.
NOTE 2 : Lorsque plusieurs technologies sont utilisées pour réaliser la communication vocale, plusieurs mécanismes d’interopérabilité peuvent être nécessaires pour garantir que tous les utilisateurs sont en mesure d’utiliser le RTT.
EXEMPLE : Un système de vidéoconférence qui prend en charge la communication vocale à travers une connexion Internet peut réaliser le RTT via une connexion Internet en utilisant une méthode RTT propriétaire (option c). Toutefois, indépendamment du fait que la méthode RTT soit ou non propriétaire, si le système de conférence offre aussi une communication de téléphonie, il sera également nécessaire qu’il prenne en charge les options a ou b afin de garantir que le RTT est pris en charge sur la connexion téléphonique.
6.2.4 Réactivité du RTT
Lorsque la TIC utilise la saisie de RTT, cette saisie doit être transmise au réseau TIC ou à la plate-forme sur laquelle la TIC fonctionne dans un délai de 500 ms à partir du moment où la plus petite unité d’entrée de texte composée de manière fiable est disponible à la TIC pour l’émission. Les retards dus aux performances de la plate-forme ou du réseau ne doivent pas être inclus dans la limite des 500 ms.
NOTE 1 : Pour la saisie caractère par caractère, la « plus petite unité d’entrée de texte composée de manière fiable » serait un caractère. Pour la prédiction de mot, il s’agirait d’un mot. Pour certains systèmes de reconnaissance vocale, le texte peut ne pas quitter le logiciel de reconnaissance jusqu’à ce qu’un mot (ou une phrase) complet ait été prononcé. Dans ce cas, la plus petite unité d’entrée de texte composée de manière fiable disponible à la TIC serait le mot (ou la phrase).
NOTE 2 : La limite de 500 ms permet la mise en mémoire tampon des caractères pendant cette période avant l’émission, de sorte que l’émission caractère par caractère n’est pas exigée à moins que les caractères soient générés plus lentement que 1 toutes les 500 ms.
NOTE 3 : Un retard de 300 ms ou moins produit une meilleure impression de flux pour l’utilisateur.
6.3 Identification de l’appelant
Lorsque la TIC dispose d’une identification de l’appelant ou de fonctions de télécommunications similaires, l’identification de l’appelant et les fonctions de télécommunications similaires doivent être disponibles sous forme textuelle et aussi pouvoir être déterminées par programme, à moins que la fonctionnalité ne soit verrouillée
6.4 Alternatives aux services vocaux
Lorsque la TIC réalise des communications vocales en temps réel et offre aussi des fonctions de messagerie vocale, de répondeur automatique ou de réponse vocale interactive, la TIC doit offrir aux utilisateurs une possibilité d’accéder aux informations et d’accomplir les tâches réalisées par la TIC sans utiliser l’audition ou la parole.
NOTE 1 : Les tâches qui impliquent à la fois l’actionnement de l’interface et la perception des informations exigeraient que l’interface et les informations soient toutes deux accessibles sans utiliser la parole ou l’audition.
NOTE 2 : Des solutions permettant de traiter les médias audio, RTT et vidéo pourraient satisfaire à cette exigence
6.5 Communication vidéo
6.5.1 Généralités (informatif)
Le paragraphe 6.5 (Communication vidéo) indique les exigences de performances pour l’assistance aux utilisateurs communiquant via la langue des signes et la lecture labiale. Pour ces utilisateurs, une bonne possibilité d’utilisation est obtenue grâce à une résolution minimale QVGA (quart de carte vidéographique – 320 x 240), un débit de trames de 20 trames par secondes et plus, avec un décalage temporel maximum de 100 ms entre l’audio et la vidéo.
Une augmentation supplémentaire de la résolution et du débit de trames améliore à la fois la langue des signes (en particulier l’épellation digitale) et la lecture labiale, le débit de trames étant plus important que la résolution.
Les décalages temporels entre l’audio et la vidéo (asynchronicité) peuvent avoir un impact important sur la lecture labiale – une vidéo qui affiche un retard par rapport à l’audio ayant un effet négatif plus important.
La latence de bout en bout peut poser un problème dans la communication vidéo (signes). Les valeurs de retard total inférieures à 400 ms sont préférables, avec une préférence pour une réduction à 100 ms. Le retard total dépend de différents facteurs, notamment le retard réseau et le traitement vidéo, par exemple. C’est pourquoi il n’est pas possible de produire une exigence pouvant être soumise à essais sur les valeurs minimales de retard total.
NOTE : La Recommandation UIT‑T F.703 [i.37] définit et donne les exigences relatives à la conversation totale qui se rapportent à l’intégration de l’audio, du RTT et de la vidéo dans une connexion d’utilisateur unique.
6.5.2 Résolution
Lorsque la TIC qui réalise la communication vocale bidirectionnelle comporte des fonctions de vidéo en temps réel, cette TIC :
- doit prendre en charge au moins la résolution QVGA ;
- il convient de préférence qu’elle prenne en charge au moins la résolution VGA.
6.5.3 Débit de trames
Lorsque la TIC qui réalise la communication vocale bidirectionnelle comporte des fonctions de vidéo en temps réel, cette TIC :
- doit prendre en charge un débit de trames de 20 trames par seconde (FPS) au minimum ;
- il convient de préférence qu’elle prenne en charge un débit de trames de 30 trames par seconde (FPS) au minimum avec ou sans langue des signes dans le flux vidéo.
6.5.4 Synchronisation entre audio et vidéo
Lorsqu’une TIC qui réalise la communication vocale bidirectionnelle comporte une fonctionnalité de vidéo en temps réel, cette TIC doit garantir un décalage temporel minimum de 100 ms entre la parole et la vidéo affichée pour l’utilisateur.
NOTE : Les recherches récentes révèlent que si l’audio précède pas la vidéo, l’intelligibilité en souffre beaucoup plus que l’inverse.
6.5.5 Indicateur visuel de l’audio avec vidéo
Lorsque la TIC réalise la communication vocale bidirectionnelle et inclut la fonctionnalité de vidéo en temps réel, la TIC doit fournir un indicateur visuel en temps réel de l’activité audio.
NOTE 1 : L’indicateur visuel peut être un point visuel simple ou une LED ou tout autre type d’indicateur allumé/éteint qui papillote pour refléter l’activité audio.
NOTE 2 : Sans cette indication, une personne qui n’a pas la possibilité d’entendre ne sait pas quand quelqu’un parle.
6.5.6 Identification du locuteur avec communication vidéo (langue des signes)
Lorsque la TIC réalise l’identification du locuteur pour les utilisateurs vocaux, elle doit fournir un moyen d’identification du locuteur pour la signature en temps réel et les utilisateurs de la langue des signes une fois que le début de la signature a été indiqué.
NOTE 1 : L’ID du locuteur peut se trouver au même endroit que pour les utilisateurs vocaux des appels à participants multiples.
NOTE 2 : Ce mécanisme peut être déclenché manuellement par un utilisateur ou automatiquement lorsque cela est techniquement réalisable
6.6 Alternatives aux services vidéo
Lorsque la TIC réalise des communications vocales en temps réel ainsi que des fonctions de répondeur téléphonique, de répondeur automatique ou de réponse vocale interactive, il convient que la TIC offre aux utilisateurs une possibilité d’accéder aux informations et d’effectuer les tâches associées à ces fonctions :
- pour les informations audibles, sans utiliser l’audition ;
- pour les commandes vocales, sans utiliser la parole ;
- pour les informations visuelles, sans utiliser la vision.
NOTE : Des solutions permettant de générer des sous-titres en temps réel ou de traiter le RTT peuvent satisfaire à cette exigence.