6.2 Funzionalità di testo in tempo reale (RTT)

6.2.1 Fornitura di testo in tempo reale (RTT)

6.2.1.1 Comunicazione di testo in tempo reale (RTT)

Laddove l’ICT sia in una modalità che fornisce un mezzo per la comunicazione vocale bidirezionale, l’ICT deve fornire un mezzo per la comunicazione RTT bidirezionale, tranne nei casi in cui ciò richiederebbe modifiche di progettazione per aggiungere hardware di input o output all’ICT.

NOTA 1: Questo requisito include quei prodotti che non dispongono di funzionalità di visualizzazione fisica o di immissione testo ma hanno la capacità di connettersi a dispositivi che dispongono di tali capacità. Include anche ICT intermedi tra i punti finali della comunicazione.

NOTA 2: Non è necessario aggiungere: un display hardware, una tastiera hardware o hardware per supportare la possibilità di connettersi a un display o tastiera, cablata o wireless, se questo hardware non fosse generalmente fornito.

NOTA 3: Ai fini dell’interoperabilità, viene ampiamente utilizzato il supporto della Raccomandazione ITU-T T.140 [i.36].

6.2.1.2 Voce e testo concomitanti

Laddove l’ICT fornisce un mezzo per la comunicazione vocale bidirezionale e per la comunicazione degli utenti tramite RTT, deve consentire la comunicazione vocale e di testo simultanea attraverso una singola connessione utente.

NOTA 1: Con la comunicazione multi-parte, come in un sistema per conferenze, è consentito (ma non necessario o necessariamente raccomandato) che la RTT sia gestita in un unico campo di visualizzazione e che sia necessario il “turno alternato” per evitare confusione (nello stesso modo in cui è richiesto il fare a turno per coloro che presentano / parlano con la voce).

NOTA 2: Con la comunicazione multi-parte, la migliore pratica è quella di alzare la mano per gli utenti voce e RTT da gestire allo stesso modo, in modo che gli utenti voce e RTT siano nella stessa coda.

NOTA 3: Con un sistema per conferenze a più parti che ha la chat come una delle sue caratteristiche - RTT (come la voce) dovrebbe in genere essere separato dalla chat in modo che l’uso di RTT non interferisca con la chat (cioè le persone possono inviare messagi nel campo della chat mentre la persona presenta / parla con RTT - nello stesso modo in cui le persone inviano messaggi utilizzando la funzione di chat mentre le persone parlano con la voce). Gli utenti RTT utilizzerebbero quindi RTT per presentare e utilizzare la funzione di chat per inviare messaggi mentre altri stanno presentando (tramite voce o RTT).

NOTA 4: La disponibilità di voce e RTT in esecuzione contemporaneamente (e separatamente dalla chat) può anche consentire al campo RTT di supportare i sottotitoli di testo quando qualcuno sta parlando (e quindi non viene utilizzato per RTT poiché non è il turno di parlare dell’utente RTT).

NOTA 5: Laddove sia il software lato server sia l’hardware locale e il software sono richiesti per fornire la comunicazione vocale, dove nessuna parte può supportare la comunicazione vocale senza l’altra e sono vendute come unità per la funzione di comunicazione vocale, i componenti locali e lato server sono considerati un singolo prodotto.

6.2.2 Visualizzazione di testo in tempo reale (RTT)

6.2.2.1 Visualizzazione visivamente distinguibile

Laddove l’ICT ha capacità di trasmissione e ricezione di RTT, il testo inviato visualizzato deve essere visivamente differenziato e separato dal testo ricevuto.

NOTA: La possibilità per l’utente di scegliere se visualizzare il testo inviato e ricevuto in linea o separatamente, e con le opzioni da selezionare, consente agli utenti di visualizzare RTT in una forma a loro più funzionale. Ciò consentirebbe agli utenti Braille di utilizzare un singolo campo e, a turno, di visualizzare il testo nel modo sequenziale di cui potrebbero aver bisogno o che preferiscono.

6.2.2.2 Direzione di invio e ricezione determinabile programmaticamente

Laddove l’ICT ha capacità di invio e ricezione RTT, la direzione di invio / ricezione del testo trasmesso / ricevuto deve essere determinabile programmaticamente, a meno che RTT non sia implementato con funzionalità chiuse.

NOTA: Ciò consente ai lettori di schermo di distinguere tra testo in entrata e testo in uscita quando utilizzato con la funzionalità RTT.

6.2.2.3 Identificazione del parlante

Laddove l’ICT ha delle funzionalità RTT e fornisce l’identificazione dei relatori per la voce, l’ICT fornirà l’identificazione dei relatori per RTT.

NOTA: Ciò è richiesto per consentire sia ai partecipanti vocali che a quelli RTT di sapere chi sta comunicando, sia in RTT che in vocale.

6.2.2.4 Indicatore visivo di audio con testo in tempo reale (RTT)

Laddove l’ICT fornisce una comunicazione vocale bidirezionale e ha funzionalità RTT, l’ICT fornirà un indicatore visivo in tempo reale dell’attività audio sul display.

NOTA 1: L’indicatore visivo può essere una semplice posizione del soggetto sul display che si accende e si spegne per riflettere l’attività audio o la presentazione delle informazioni in un altro modo che può essere sia visibile agli utenti vedenti sia trasmessa agli utenti non vedenti che utilizzano un display braille.

NOTA 2: Senza questa indicazione una persona a cui manca la capacità di sentire non sa quando qualcuno sta parlando.

6.2.3 Interoperabilità

Laddove l’ICT con funzionalità RTT interagisce con altro ICT con funzionalità RTT (come richiesto dal punto 6.2.1.1), deve supportare meccanismi di interoperabilità RTT applicabili descritti di seguito:

• ICT che interagisce con altri ICT direttamente collegati alla rete telefonica pubblica commutata (PSTN), usando la raccomandazione ITU-T V.18 [1.23] o uno dei suoi allegati per i segnali di telefonia di testo sull’interfaccia PSTN;
• ICT che interagisce con altri ICT utilizzando VOIP con Session Initiation Protocol (SIP) e utilizzando RTT conforme a IETF RFC 4103 [i.13]. Per l’ICT che interagisce con altri ICT utilizzando l’IP Multimedia Sub System (IMS) per implementare VOIP, il set di protocolli specificato in ETSI TS 126 114 [i.10], ETSI TS 122 173 [i.11] e ETSI TS 134 229 [i.12] descrivono come si applicherebbe IETF RFC 4103 [i.13];
• ICT che interagisce con altri ICT utilizzando tecnologie diverse da a o b, di cui sopra, utilizzando una specifica comune pertinente e applicabile per lo scambio di RTT pubblicata e disponibile per gli ambienti in cui opereranno. Questa specifica comune deve includere un metodo per indicare la perdita o la corruzione dei soggetti;
• ICT che interagisce con altri ICT usando uno standard per RTT che è stato introdotto per l’uso in uno qualsiasi degli ambienti di cui sopra, ed è supportato da tutti gli altri ICT attivi che supportano voce e RTT in quell’ambiente.

NOTA 1: In pratica, vengono introdotti nuovi standard come codec / protocollo alternativi che sono supportati insieme allo standard comune esistente e utilizzati quando tutti i componenti end-to-end lo supportano mentre lo sviluppo della tecnologia, combinato con altri motivi tra cui lo sviluppo della società e l’efficienza dei costi, può far diventare gli altri obsoleti.

NOTA 2: Laddove vengono utilizzate più tecnologie per fornire comunicazioni vocali, potrebbero essere richiesti più meccanismi di interoperabilità per garantire che tutti gli utenti siano in grado di utilizzare RTT.

ESEMPIO: Un sistema di conferenza che supporta la comunicazione vocale tramite una connessione Internet potrebbe fornire RTT su una connessione Internet utilizzando un metodo RTT proprietario (opzione c). Tuttavia, indipendentemente dal fatto che il metodo RTT sia proprietario o non proprietario, se il sistema di conferenza offre anche comunicazioni telefoniche, deve anche supportare le opzioni a o b per garantire che RTT sia supportato tramite la connessione telefonica.

6.2.4 Reattività del testo in tempo reale (RTT)

Laddove l’ICT utilizza l’input RTT, tale input RTT deve essere trasmesso alla rete o piattaforma ICT su cui l’ICT viene eseguito entro 500 ms dal momento in cui la più piccola unità composta in modo affidabile di immissione di testo è disponibile all’ICT per la trasmissione. I ritardi dovuti alle prestazioni della piattaforma o della rete non devono essere inclusi nel limite di 500 ms.

NOTA 1: Per l’inserimento carattere per carattere, “la più piccola unità composta in modo affidabile di immissione testo” sarebbe un carattere. Per la previsione delle parole sarebbe una parola. Per alcuni sistemi di riconoscimento vocale, è possibile che il testo non esca dal software di riconoscimento finché non è stata pronunciata un’intera parola (o frase). In questo caso, la più piccola unità composta in modo affidabile di immissione testo disponibile per l’ICT sarebbe la parola (o la frase).

NOTA 2: Il limite di 500 ms consente il buffering dei caratteri per questo periodo prima della trasmissione, pertanto non è richiesta la trasmissione carattere per carattere a meno che i caratteri non vengano generati più lentamente di 1 per 500 ms.

NOTA 3: Un ritardo di 300 ms o inferiore produce una migliore impressione del flusso verso l’utente.