Sottotitolazione: come farla bene (e accessibile) 

Perché i sottotitoli contano (per tutti) 

• Accessibilità: persone sorde o con ipoacusia; utenti in ambienti rumorosi/silenziosi. 
• Comprensione: supporto a non madrelingua e DSA. 
• SEO: testi indicizzabili e riutilizzabili (trascrizioni, snippet). 
• Conformità: contribuiscono ai criteri WCAG 1.2.x (audio/video). 

Tipi di sottotitoli: scegli quello giusto 

• Intralinguistici (captions): stessa lingua dell’audio. 
• Interlinguistici (subtitles): lingua diversa (traduzione). 
• CC/SDH (per sordi/ipoacusici): includono speaker ID e suoni ([applausi], [risate], [porta che sbatte]). 
• Live captions: in diretta; richiedono re-speaking e correzione post-evento. 

Consiglio: per contenuti istituzionali/di servizio, privilegia SDH/CC: aumentano davvero la fruibilità. 

Requisiti tecnici minimi (qualità percettiva) 

Sincronia 

• In/Out coerenti; ritardo consigliato ≤ 500 ms rispetto all’audio. 
• Evita “scatti” (titoli che lampeggiano). 

Leggibilità 

• CPS: 15–20 intralingua; 12–17 traduzioni. 
• Lunghezza: max 2 righe, 42–45 caratteri/linea (più strette su mobile). 
• Durata: min 1 s, max 6 s per blocco; spezzatura naturale. 

Stile 

• Punteggiatura reale, no ALL CAPS. 
• Posizionamento in basso centrato; sposta sopra grafiche se coprono info. 
• Contrasto adeguato; overlay se necessario. 

Contenuto informativo (SDH/CC) 

• Speaker ID quando cambia parlante. 
• Suoni chiave in quadre. 
• Lingua mista: marca switch non tradotti altrove. 

WCAG: quali criteri toccano i sottotitoli 

• 1.2.2 – Sottotitoli (A) per preregistrati con audio. 
• 1.2.4 – Sottotitoli in diretta (AA) per live streaming. 
• 1.2.5 – Audio-descrizione (AA) per video focalizzati sul visivo. 
• 1.4.x (contrasto, visibilità) e 2.1 (tastiera) impattano player e controlli.
  Precauzione: se il contenuto è istituzionale/di servizio, valuta anche interprete LIS in parallelo ai sottotitoli.

Flusso di lavoro professionale (end-to-end) 

1. Trascrizione accurata (time-coded), guida su nomi propri e termini. 
2. Spotting (timecoding) con regole di sincronia e spezzatura naturale. 
3. Adattamento (intra/interlingua) rispettando CPS, line length e registro. 
4. QC tecnico (formato, ortografia, sovrapposizioni, timing) + QC accessibilità (speaker ID, suoni, posizionamento, contrasto). 
5. Export in WebVTT/SRT; integrazione nel player (test tastiera, focus, responsive). 
6. Versioning: gestisci correzioni (v1 → v1.1) e coerenza multi-piattaforma. 
7. Live: predisponi re-speaking, canale backup, glossario e revisione post-evento. 

Errori comuni da evitare 

• “Solo SEO”: trascrizioni automatiche non editate. 
• Niente SDH: assenza di speaker ID/suoni → esperienza povera. 
• CPS eccessivo: l’utente non finisce di leggere. 
• Formati sbagliati: SRT “truccati” per lo stile; usa WebVTT per impostazioni. 
• Player inaccessibile: niente tastiera, focus invisibile, contrasto insufficiente. 
• Zero QA: nomi, date, cifre, acronimi non espansi. 

Checklist express (test rapido) 

• Sottotitoli attivabili (non bruciati)? 
• Sincronia ok, nessuna sovrapposizione? 
• 2 righe, ≤45 caratteri/linea, CPS entro soglia? 
• Speaker/suoni marcati quando servono? 
• Contrasto/posizione non coprono info importanti? 
• Player: tastiera, focus, aria-label pulsanti, stato on/off captions visibile? 

Dove entra E-Cute

• Sottotitolazione professionale: intralingua, interlingua, SDH/CC (prerecorded e live). 
• Pipeline accessibile: WebVTT/SRT + integrazione player conforme WCAG. 
• Video-LIS e QA combinato (tecnico + accessibilità). 
• Formazione team: linee guida, checklist, strumenti, QA.