Text a veu enfront dels lectors de pantalla

El vostre contingut té una veu

La tecnologia de text a veu (TTS) converteix la informació escrita en àudio. Ajuda les persones amb ceguesa, discapacitats visuals, dislèxia i TDAH a consumir contingut d’una manera que els funciona. El TTS també s’utilitza àmpliament a les escoles, per part dels qui aprenen idiomes i per part de professionals que corregeixen amb l’oïda en comptes de fer-ho amb la vista.

Com que tant el TTS com els lectors de pantalla produeixen una veu sintètica, sovint la gent suposa que són la mateixa cosa — o que afegir un botó de «llegir en veu alta» a un lloc web el fa accessible per als usuaris cecs. Aquesta suposició és errònia, i actuar-hi pot deixar-vos amb un lloc que sona accessible però que és impossible d’utilitzar realment per a moltes persones. Aquest article explica com funciona cada tecnologia, qui hi confia, on se situa realment la línia entre totes dues i què cal per construir correctament per a lectors de pantalla. Si només recordeu una cosa, que sigui aquesta: un giny de lectura en veu alta és una funció de comoditat, no una funció d’accessibilitat.

Com funciona el TTS?

El TTS processa el text en tres etapes generals:

Anàlisi del text — determinar el to, la gramàtica i l’estructura, expandir números i símbols («$5» es converteix en «cinc dòlars») i segmentar frases.
Processament lingüístic — calcular la pronunciació, l’accent i l’èmfasi, sovint utilitzant un diccionari de pronunciació més regles per a paraules desconegudes.
Síntesi d’àudio — generar veu a partir de models matemàtics de veu, cada cop més utilitzant xarxes neuronals que sonen molt més naturals que els antics motors concatenatius.

Els sistemes moderns ofereixen personalització de la veu com ara velocitat, to, personatge de veu i selecció d’idioma. El punt crucial és què pren el TTS com a entrada: un bloc de text que algú ja ha seleccionat, enganxat o assenyalat. El TTS és fonamentalment una tecnologia de sortida de contingut. Diu allò que se li dóna. No explora una interfície i no té cap noció de botons, camps de formulari o estructura de pàgina.

Quines són les limitacions de la tecnologia TTS?

El TTS és realment útil, però no és perfecte, i els seus límits importen per a la comparació que segueix:

Buits de pronunciació — pot pronunciar malament paraules poc habituals, noms propis, termes mèdics o legals i abreviatures.
Suport desigual d’idiomes — moltes eines gestionen bé els idiomes principals però tenen dificultats amb els idiomes menys comuns i els dialectes regionals.
To i matís — el TTS té dificultats amb el sarcasme, l’humor i les expressions idiomàtiques, de manera que el contingut es pot transmetre amb el to equivocat.
Cap model d’interacció — i aquest és el més important: el TTS llegeix; no us permet fer res. No podeu omplir un formulari de pagament, tancar una finestra modal ni moure-us entre els elements del menú només amb el TTS.

Aquesta darrera limitació és exactament on comença la confusió amb els lectors de pantalla.

Quina és la diferència entre el text a veu i la tecnologia de lector de pantalla?

Aquí és on sorgeix el malentès comú. El text a veu llegeix el text en veu alta — aquesta és la seva funció principal. Un lector de pantalla fa molt més: permet als usuaris navegar i operar tot un ordinador o dispositiu mòbil amb l’oïda i el teclat (o amb gestos tàctils).

Els lectors de pantalla anuncien etiquetes d’interfície, camps de formulari, botons i enllaços; llegeixen el text alternatiu de les imatges perquè els usuaris entenguin el contingut visual; i exposen l’estat dels components — si una casella de selecció està marcada, si un menú està desplegat, si una pestanya està seleccionada o si ha aparegut un error. Converteixen una interfície visual i controlada amb el ratolí en una interfície lineal, audible i operable.

Una manera ràpida de notar la diferència: el TTS respon a la pregunta «Què diu aquest paràgraf?» Un lector de pantalla respon «On soc, què puc fer aquí i què acaba de passar?» El primer tracta de consumir contingut. El segon tracta de controlar el programari.

Com es mou realment un usuari de lector de pantalla per una pàgina

Els usuaris que hi veuen escanegen una pàgina en segons. Un usuari de lector de pantalla construeix un model mental de manera seqüencial i confia en l’estructura per moure’s de manera eficient. A la pràctica:

Salten entre encapçalaments per entendre l’esquema de la pàgina (per això una jerarquia d’encapçalaments correcta importa tant).
Mostren una llista de tots els enllaços o de tots els camps de formulari per navegar per punts de referència en comptes de llegir de dalt a baix.
Utilitzen regions de punts de referència (bàner, navegació, contingut principal, peu de pàgina) per saltar directament al contingut que volen.
Es mouen pels elements interactius amb la tecla Tab i esperen que el focus aterri en algun lloc visible i lògic.
Escolten anuncis en directe quan alguna cosa canvia sense una recàrrega completa de la pàgina.

Res d’això funciona tret que el marcatge subjacent descrigui la pàgina honestament. Una funció de «llegir en veu alta» no proporciona cap d’aquestes prestacions de navegació — només narra el text que hi ha a la pantalla, en ordre visual, sense cap manera d’operar els controls.

Qui utilitza cadascun, i per què importa

El TTS l’utilitza un públic ampli, sovint segons la situació: persones amb dislèxia, TDAH o baixa visió; persones que fan diverses coses alhora; persones que aprenen idiomes; i qualsevol que simplement prefereix escoltar. La majoria d’aquests usuaris encara poden veure la pantalla i utilitzar un ratolí.

Els usuaris de lectors de pantalla inclouen persones cegues o amb discapacitats visuals greus, així com algunes persones amb discapacitats cognitives o motrius, que depenen de la tecnologia per poder utilitzar un dispositiu. Per a ells no és una capa de preferència damunt d’una interfície usable — és la interfície. Les eines més comunes són NVDA i JAWS a Windows, VoiceOver als dispositius Apple i TalkBack a Android. Cadascuna interpreta la mateixa pàgina web una mica diferent, una de les raons per què importa fer proves amb totes.

Per què els ginys de lectura en veu alta no són un substitut de l’accessibilitat

Un nombre creixent de llocs web hi afegeixen un botó de «escolteu aquesta pàgina» o un giny de tercers que ressalta i pronuncia el text. Aquestes eines poden ajudar alguns lectors, i no hi ha res de dolent a oferir-ne una com a comoditat. El problema és tractar-la com a substitut del suport real de lector de pantalla. No ho és, per diverses raons concretes.

Només llegeixen; no operen. Un giny de lectura en veu alta narrarà la vostra taula de preus, però no pot permetre que un usuari cec seleccioni un pla, obri el cistell, introdueixi les dades de pagament i completi la compra. Les tasques reals requereixen controls operables, no narració.
No poden exposar l’estat ni els rols. Si un botó està premut, si un camp és obligatori, si una secció està plegada o si acaba d’aparèixer un missatge d’error — res d’això es transmet llegint el text visible. Els lectors de pantalla confien en els rols, els noms i els estats del marcatge per anunciar-ho.
Els usuaris de lectors de pantalla ja tenen una eina. Els usuaris cecs porten el seu propi lector de pantalla, ajustat finament a les seves preferències i memòria muscular. Un giny a nivell de pàgina hi competeix, de vegades hi interfereix i no fa res per arreglar el marcatge defectuós amb què s’està entrebancant el seu lector de pantalla.
Emmascaren els problemes en comptes d’arreglar-los. Si un camp de formulari no té etiqueta, el giny el passarà per alt igual que ho faria un lector de pantalla — però ara l’etiqueta que falta queda amagada darrere d’una funció que sembla útil. El defecte subjacent roman.

Aquesta mateixa lògica s’aplica, encara amb més força, a les anomenades superposicions d’accessibilitat — scripts que prometen un compliment instantani superposant correccions automatitzades i una barra d’eines a un lloc existent. No reparen el codi subjacent, sovint entren en conflicte amb la tecnologia d’assistència pròpia dels usuaris i no poden oferir una conformitat genuïna. El camí fiable és arreglar la font. Per a una explicació més completa de per què les correccions superficials es queden curtes, vegeu la nostra guia sobre l’accessibilitat digital real.

Un exemple concret: el pagament que «parla»

Imagineu una botiga en línia que ha afegit un giny de lectura en veu alta i està convençuda que el lloc ara és accessible. Un client cec hi arriba amb el seu propi lector de pantalla en marxa. La descripció del producte es llegeix bé — aquesta part és només text. Però el control «Afegir al cistell» és un div estilitzat amb un gestor de clic en comptes d’un botó real, de manera que el lector de pantalla mai no l’anuncia com a botó i el teclat no hi pot arribar. El selector de quantitat actualitza un total sense regió en directe, de manera que el canvi és silenciós. El camp del codi promocional té text de marcador de posició però cap etiqueta associada, de manera que només s’anuncia com a «editar text». El formulari d’enviament mostra visualment un error vermell, però l’error no està vinculat al camp i no s’anuncia en absolut. El giny de lectura en veu alta narra alegrement el text visible i no canvia res d’això. El client pot escoltar el text de màrqueting però no pot completar una compra. Aquesta bretxa — entre escoltar contingut i operar un producte — és tota la diferència entre una funció de comoditat i l’accessibilitat.

Què requereix realment construir per a lectors de pantalla

Donar suport als lectors de pantalla no consisteix a afegir una funció — consisteix a construir les vostres pàgines de manera que el significat, l’estructura i el comportament estiguin disponibles per al programari, no només per a l’ull humà. Els ingredients bàsics:

HTML semàntic i estructurat

Utilitzeu encapçalaments reals (h1–h6) en un ordre lògic, botons i enllaços natius per als propòsits adequats, llistes per a llistes i elements de punt de referència per a regions de pàgina. L’HTML semàntic transporta informació d’accessibilitat de manera gratuïta; un mur de contenidors genèrics no en transporta cap.

Alternatives de text per a contingut no textual

Cada imatge significativa necessita un text alternatiu precís, i les imatges decoratives s’han de marcar perquè s’ometin. Les icones que actuen com a botons necessiten noms accessibles. Els gràfics i les infografies necessiten un equivalent textual que transmeti la mateixa informació.

Noms, rols i estats accessibles

Els camps de formulari necessiten etiquetes associades de manera programàtica. Els components personalitzats — pestanyes, acordions, comboboxes, finestres modals — necessiten els rols i estats correctes perquè el lector de pantalla anunciï què són i com es comporten. Quan l’HTML natiu no és suficient, ARIA omple el buit, però s’ha d’utilitzar amb precisió; una ARIA incorrecta és pitjor que cap.

Operabilitat amb el teclat i gestió del focus

Tot el que funciona amb un ratolí ha de funcionar amb un teclat, l’ordre del focus ha de ser lògic, l’indicador de focus ha de ser visible, i els canvis dinàmics (obrir un diàleg, revelar un error) han de moure o anunciar el focus adequadament. El suport de teclat i el suport de lector de pantalla estan profundament entrellaçats.

Anunciar canvis dinàmics

Quan el contingut s’actualitza sense una recàrrega de pàgina — un missatge de validació de formulari, un comptador de cistell, un estat de càrrega — utilitzeu regions en directe perquè el lector de pantalla digui a l’usuari que ha passat alguna cosa. Les actualitzacions silencioses són invisibles per a les persones que no poden veure la pantalla.

Totes aquestes expectatives estan codificades en els criteris d’èxit del WCAG 2.2, que formen l’espina dorsal tècnica de l’European Accessibility Act i de l’ADA tal com s’apliquen al web. Si voleu el detall pràctic, la nostra guia de proves de lectors de pantalla recorre pas a pas com verificar cadascun d’aquests comportaments amb eines reals.

Per què «a mi se’m llegeix bé» és enganyós

Un desenvolupador que hi veu pot activar una funció de lectura en veu alta, escoltar frases netes i concloure que la pàgina és accessible. El parany és que la lectura en veu alta reprodueix l’ordre de lectura visible i el text visible, tots dos dels quals ja tenen sentit per a algú que mira la pantalla. No us diu res sobre si un menú desplegable personalitzat anuncia les seves opcions, si el focus està atrapat dins d’un diàleg obert, si un botó amb només una icona té un nom o si l’ordre de tabulació coincideix amb la disposició visual. Aquestes són precisament les coses que es trenquen per als usuaris de lectors de pantalla i precisament les coses que una demostració de lectura en veu alta no pot revelar. L’única manera de saber-ho és fer proves de la manera que ho fan els usuaris reals.

Com fer proves per a tots dos — i per què l’automatització sola no és suficient

No podeu confirmar que una pàgina funciona per als usuaris de lectors de pantalla escoltant un botó de lectura en veu alta. Ho confirmeu comprovant l’estructura, els noms, els rols, els estats, l’operació amb teclat i l’experiència real de lector de pantalla en múltiples eines i plataformes.

Un procés sòlid combina tres capes:

Escaneig automatitzat per detectar els problemes de gran volum i detectables per màquina — text alternatiu que falta, etiquetes buides, referències ARIA trencades, errors de contrast. El nostre programari d’escaneig d’accessibilitat i un escaneig d’accessibilitat gratuït són una manera ràpida d’establir on us trobeu.
Proves manuals d’experts per avaluar tot allò que l’automatització no pot jutjar: si un nom és significatiu, si l’ordre del focus té sentit, si un giny personalitzat és realment operable. El raonament darrere d’aquesta capa es tracta a la nostra guia d’auditories manuals d’accessibilitat.
Proves amb tecnologia d’assistència real i usuaris reals. Res no substitueix conduir la pàgina amb NVDA, JAWS, VoiceOver i TalkBack — i, idealment, observar persones que utilitzen aquestes eines cada dia. Les nostres auditories per persones amb discapacitats aporten exactament aquesta experiència viscuda.

Les eines automatitzades normalment detecten només una part dels criteris d’èxit del WCAG 2.2; la resta requereix judici humà. Tractar un escaneig automatitzat superat com a prova d’accessibilitat és la mateixa categoria d’error que tractar un giny de lectura en veu alta com a suport de lector de pantalla.

On encaixa QualiBooth

QualiBooth prova el vostre lloc web tant per als casos d’ús de TTS com per als de lector de pantalla, de manera que el vostre contingut sigui accessible per als usuaris que confien en qualsevol de les dues tecnologies — i de manera que les persones que depenen d’un lector de pantalla puguin no només escoltar el vostre contingut sinó operar realment el vostre producte. El nostre kit d’eines d’accessibilitat i la plataforma Agora combinen l’escaneig amb una revisió manual estructurada, i el nostre equip de consultoria d’accessibilitat us ajuda a esmenar el que les proves revelen i a alinear-vos amb els requisits de WCAG 2.2, EAA i ADA.

La conclusió és senzilla. Afegir una veu al vostre contingut és un detall agradable. Fer que el vostre contingut sigui navegable, operable i anunciat correctament a un lector de pantalla és accessibilitat — i només una d’aquestes coses satisfà la llei i les persones que protegeix.