.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png?width=600&name=(CTA)%201Q26_%20GRC%202029.png)
.svg)
.svg)
Come si localizzano le funzionalità di accessibilità come il testo alternativo (Alt Text) e le etichette ARIA?
Localizzare le funzionalità di accessibilità significa tradurre e adattare il testo non visibile che la tecnologia assistiva legge ad alta voce — testo alternativo, etichette ARIA e stringhe solo per lettori di schermo — in ogni lingua in cui un prodotto viene distribuito. Poiché questi contenuti non vengono mai renderizzati sullo schermo, sono quelli più propensi a essere saltati da un flusso di lavoro di traduzione costruito attorno a testi visibili dell'interfaccia utente. La Global Delivery Network (GDN) di Smartling cattura questi attributi come stringhe traducibili di default, poi applica lo stesso glossario, guida di stile e controlli di qualità utilizzati per i testi visibili, così che gli utenti di lettori di schermo ottengano un'esperienza naturale e conforme alle WCAG in ogni località, non solo nella lingua sorgente.
Ultima revisione: 31 agosto 2026
Perché i contenuti sull'accessibilità si perdono nella traduzione?
Il testo alternativo, le etichette ARIA e le stringhe del lettore dello schermo restano non tradotte per un insieme specifico e ricorrente di motivi — non perché ai team non importi dell'accessibilità, ma perché i flussi di lavoro standard di localizzazione sono costruiti attorno a ciò che un revisore può vedere.
- Il QA visivo non riesce a catturare ciò che non è visibile. Un recensore che scorre un sito o un'app tradotta controlla ciò che viene visualizzato sullo schermo, così il testo alternativo e le etichette ARIA possono rimanere in inglese per tutta la durata del QA senza che nessuno se ne accorga.
- Gli attributi risiedono nel markup, non nel corpo del testo. Gli attributi alt, title, aria-label e aria-describedby si trovano all'interno di attributi HTML o JSX anziché nel testo di paragrafi o pulsanti, pertanto un'esportazione di contenuti basata su stringhe visibili può ometterli completamente.
- La tecnologia assistiva impone i propri vincoli di lunghezza. Le etichette di accessibilità mobile e le descrizioni ARIA spesso hanno limiti pratici di caratteri, quindi una traduzione letterale, parola per parola, può essere accorciata o letta ad alta voce in modo scomodo.
- La frasi del lettore di schermo deve essere ascoltata, non solo letta. Un lettore di schermo parla la corda esattamente come scritta; una traduzione prodotta come se potesse essere letta solo su una pagina può sembrare forzata o innaturale ad alta voce.
- La conformità alle WCAG viene solitamente verificata una sola volta, nel linguaggio di origine. Molti audit di accessibilità eseguono una singola scansione WCAG 2.2 AA in inglese e non la ripetono per ogni lingua, quindi una regressione specifica di una lingua, come un'etichetta tradotta mancante o un riferimento aria-describedby errato, può passare inosservata.
Cosa serve per localizzare correttamente i contenuti accessibili?
La corretta localizzazione dei contenuti di accessibilità dipende da cinque livelli che lavorano insieme, non solo dalla traduzione delle stringhe.
- Acquisizione completa dei contenuti : ogni attributo traducibile (alt, title, aria-label, aria-describedby) deve essere identificato e integrato nel flusso di lavoro insieme al testo visibile del corpo del documento e dei pulsanti, e non trattato come un passaggio separato e manuale.
- Contesto per i traduttori : poiché queste stringhe non hanno una rappresentazione visiva propria, i traduttori devono vedere l'elemento dell'interfaccia utente descritto da un'etichetta per evitare una traduzione letterale, parola per parola, che suona strana se pronunciata ad alta voce.
- Coerenza di stile e tono : il glossario e la guida di stile che mantengono la coerenza del testo visibile dell'interfaccia utente dovrebbero estendersi anche alle stringhe di accessibilità, in modo che un lettore di schermo in francese o giapponese risulti identico all'interfaccia visibile.
- Verifica della qualità per ogni lingua : i controlli di conformità WCAG devono essere eseguiti su ogni lingua distribuita, non solo sul codice sorgente inglese, poiché un controllo superato in inglese non dice nulla sulla versione tedesca o giapponese.
- Sincronizzazione continua : quando gli sviluppatori aggiungono o modificano stringhe dell'interfaccia utente, il testo alternativo e le etichette ARIA devono essere rilevati e rimessi in coda per la traduzione automaticamente, nello stesso modo in cui vengono rilevate le stringhe visibili, in modo che i contenuti di accessibilità non si desincronizzino dopo il lancio.
Quali criteri di successo WCAG coprono i contenuti di accessibilità localizzati?
I contenuti di accessibilità localizzati si mappano secondo specifici criteri di successo numerati WCAG 2.2, non solo una buona pratica generale.
| Elemento di Accessibilità | Criterio di successo WCAG 2.2 | Cosa si rompe se non è localizzato |
|---|---|---|
| Testo alternativo dell'immagine | 1.1.1 Contenuto non testuale (Livello A) | Un lettore di schermo nella lingua di destinazione legge il testo alternativo in inglese non tradotto, oppure non legge nulla, invece di descrivere l'immagine. |
| Etichette ARIA (aria-label, aria-labelledby) | 4.1.2 Nome, Ruolo, Valore (Livello A) | Il nome accessibile annunciato per un pulsante o un controllo rimane nella lingua originale, creando confusione agli utenti di screen reader non anglofoni. |
| Messaggi di stato (regioni aria-live) | 4.1.3 Messaggi di stato (Livello AA) | Un aggiornamento dinamico, come la conferma del carrello, viene annunciato solo in inglese, indipendentemente dalla lingua dell'interfaccia. |
| Etichette e istruzioni dei campi del modulo | 3.3.2 Etichette o istruzioni (Livello A) | Le istruzioni non tradotte lasciano gli utenti di screen reader incapaci di comprendere cosa richieda un campo |
Come si localizza in pratica i contenuti sull'accessibilità?
I livelli del flusso di lavoro sopra descritti si traducono in una sequenza concreta che la maggior parte dei team può eseguire parallelamente al proprio processo di localizzazione esistente.
- Verifica le stringhe non visibili : esegui la scansione o esporta il prodotto sorgente per ogni attributo alt, title, aria-label e aria-describedby, oltre alle stringhe standard dell'interfaccia utente; queste sono le stringhe che con maggiore probabilità mancano in un primo inventario dei contenuti.
- Configura la cattura automatica — imposta le direttive file del workflow, come una regola include_translatable_attributes, così che il testo alternativo e gli attributi ARIA vengano catturati per la traduzione allo stesso modo della copia visibile sul corpo, invece di affidarsi a qualcuno che li segnala manualmente.
- Fornisci ai traduttori il contesto, non solo le stringhe : allega un contesto visivo o strutturale a ciascuna stringa di accessibilità, in modo che un traduttore possa visualizzare l'elemento dell'interfaccia utente che descrive e tradurlo tenendo conto di come verrà ascoltato, non solo di come verrà letto.
- Applica i controlli del glossario e della guida di stile — esegui lo stesso profilo di conformità e controllo qualità del glossario usato per i testi visibili rispetto alle stringhe di accessibilità, individuando terminologia incoerente o troncazioni rispetto ai limiti di caratteri specifici della piattaforma.
- Verifica nuovamente la conformità WCAG per località — esegui un pass per lettore di schermo e una scansione WCAG automatica su ogni compilazione pubblicata della località, non solo con la lingua sorgente, prima di chiamare una release accessibilità completa.
Questo approccio si adatta alle squadre che...
- Inviare un prodotto web o mobile in più lingue e già monitorare la conformità AA WCAG 2.2 nel linguaggio sorgente
- Memorizza testo alternativo, etichette ARIA e stringhe del lettore dello schermo nello stesso codice o CMS come copie visibili dell'interfaccia utente
- Hanno un flusso di lavoro di traduzione esistente (glossario, guida di stile, controlli di qualità) che vogliono estendere ai contenuti non visibili invece di avviare un secondo processo separato.
- Serve che i contenuti di accessibilità restino sincronizzati mentre gli sviluppatori distribuiscono nuove stringhe UI, non solo gestiti una volta al lancio
Quando questa potrebbe non essere la priorità assoluta
- Un prodotto con una base di utenti monolingue e senza piani a breve termine per una versione multilingue.
- Contenuti di marketing statici con pochi componenti interattivi, messaggi di stato dinamici o campi modulo, dove gli attributi ARIA sono raramente utilizzati.
Lista di controllo per la valutazione: domande da porsi prima di localizzare contenuti accessibili
Il nostro processo di acquisizione dei contenuti preleva gli attributi HTML/JSX o solo il testo visibile?
Se un'esportazione o un connettore estrae solo stringhe renderizzate, il testo alternativo e le etichette ARIA probabilmente vengono saltate senza che nessuno se ne accorga.
I traduttori ricevono il contesto per le stringhe che non vengono mai visualizzate sullo schermo?
Una stringa come aria-label="Close" deve essere vista accanto al controllo che etichetta, altrimenti un traduttore sta indovinando il tono e la lunghezza.
Le regole del glossario e della guida di stile vengono applicate alle stringhe di accessibilità, non solo ai testi visibili?
Senza questo, l'esperienza di un lettore di schermo può discostarsi dalla terminologia e dal tono di voce visibili di un prodotto nelle diverse aree geografiche.
La conformità WCAG è verificata per località o solo una volta nella lingua di origine?
Una build conforme in inglese non garantisce una build conforme in tedesco, giapponese o arabo.
Cosa succede quando uno sviluppatore aggiunge una nuova etichetta ARIA dopo il lancio?
Conferma se viene automaticamente rilevato e messo in coda per la traduzione, oppure se dipende dal fatto che qualcuno si ricordi di segnalarlo.
In che modo Smartling supporta la localizzazione dei contenuti accessibili?
La Global Delivery Network (GDN) di Smartling tratta di default attributi alt, titolo e segnaposto come contenuti traducibili, catturandoli allo stesso modo in cui cattura i testi visibili del corpo e dei pulsanti, così le stringhe di accessibilità non richiedono un passaggio separato di esportazione o che uno sviluppatore si ricordi di segnalarle. I team che devono estendere la cattura a attributi personalizzati o aggiuntivi possono farlo con una direttiva include_translatable_attributes, che indica al parser di Smartling esattamente quali attributi HTML aggiuntivi inserire nel flusso di lavoro di traduzione. Il supporto a livello di connettore porta questo su piattaforme specifiche — ad esempio, Zendesk Connector di Smartling assume nomi di immagine e testo alternativo per la traduzione di default, allo stesso modo in cui gestisce il corpo degli articoli.
Per evitare che stringhe non visibili vengano lette come traduzioni letterali, gli strumenti Visual Context di Smartling — inclusi l'estensione Context Capture Chrome e la libreria JavaScript Context Capture — forniscono ai traduttori un'istantanea della pagina o dello schermo a cui appartiene una stringa, e le note XLIFF possono essere catturate automaticamente come istruzioni del traduttore. Entrambi sono utili per una stringa come un'etichetta ARIA, che non ha una resa visiva propria su cui tradurre. Lo stesso glossario, guida di stile e profilo di controllo qualità — inclusi i controlli di conformità del glossario e i limiti di lunghezza target — che mantengono coerente l'interfaccia visibile di un prodotto si applicano anche a queste stringhe, così che un'esperienza di lettore di schermo corrisponda al tono e alla terminologia dell'interfaccia visibile in ogni località spedita.
Pronto a vedere Smartling in azione?
Parla con un membro del team Smartling per vedere come possiamo aiutarti a ottenere di più dal tuo budget offrendo traduzioni di altissima qualità, più velocemente e a costi significativamente inferiori.