Accessibilitat ≠ Overlay: quan un overlay interfereix amb el lector de pantalla
Els lectors de pantalla presenten mitjançant veu o braille la informació que una interfície exposa programàticament. Les persones que els utilitzen aprenen les seves ordres, configuren preferències i desenvolupen estratègies per moure’s per encapçalaments, enllaços, regions, formularis i controls. W3C inclou els lectors de pantalla entre les tecnologies d’assistència utilitzades per interactuar amb el web. Per tant, el punt de partida ha de ser un web ben construït, no substituir des de la pàgina la tecnologia de l’usuari.
El lector de pantalla ja és la tecnologia d’assistència de l’usuari
Els lectors de pantalla presenten mitjançant veu o braille la informació que una interfície exposa programàticament. Les persones que els utilitzen aprenen les seves ordres, configuren preferències i desenvolupen estratègies per moure’s per encapçalaments, enllaços, regions, formularis i controls. W3C inclou els lectors de pantalla entre les tecnologies d’assistència utilitzades per interactuar amb el web. Per tant, el punt de partida ha de ser un web ben construït, no substituir des de la pàgina la tecnologia de l’usuari.
Què necessita realment un lector de pantalla d’un web
La interoperabilitat depèn de la informació del codi: HTML semàntic, encapçalaments reals, enllaços i botons recognoscibles, etiquetes associades als camps, noms accessibles, rols, estats i valors correctes, i una gestió coherent del focus. W3C explica que els lectors de pantalla poden utilitzar l’estructura d’encapçalaments per navegar i que els controls HTML estàndard afavoreixen la interoperabilitat. Si aquesta base falla, el problema és a la implementació.
Què canvia quan entra un overlay
Alguns overlays injecten JavaScript de tercers que analitza la pàgina i intenta reparar problemes al front-end. La tecnologia d’assistència pot rebre així una versió modificada de la interfície. L’Overlay Fact Sheet adverteix que aquestes reparacions poden alentir la càrrega o provocar canvis inesperats per als usuaris de tecnologies d’assistència. No significa que tots els overlays provoquin sempre el mateix error, però afegeixen una variable entre el web i el lector de pantalla.
Focus, teclat i estructura: petits canvis poden ser grans barreres
Per a una persona que navega sense visió, el focus determina on és i quin element utilitzarà. Canvis inesperats de focus, tecles interceptades o semàntica alterada poden desorientar completament. També els encapçalaments artificials, noms poc fiables o estats mal anunciats. Les experiències recollides per l’Overlay Fact Sheet inclouen usuaris de lector de pantalla que descriuen salts de focus, navegació alterada i webs més difícils d’utilitzar amb l’overlay actiu.
Un botó de «perfil per a lector de pantalla» planteja la pregunta equivocada
La pregunta no és si l’usuari ha activat un perfil especial, sinó si el web funciona des del principi amb la seva tecnologia d’assistència habitual. W3C assenyala que les persones amb discapacitat utilitzen configuracions i eines diferents segons les seves necessitats i preferències. Haver de descobrir un giny, obrir-lo i seleccionar un mode addicional afegeix passos sense garantir que es corregeixin les barreres originals.
No tots els usuaris de lector de pantalla naveguen igual
NVDA, JAWS, VoiceOver, TalkBack i altres solucions tenen ordres i modes diferents. Cada persona també configura veu, velocitat, puntuació, braille i preferències. És arriscat dissenyar una experiència universal de «lector de pantalla». L’accessibilitat robusta exposa informació estàndard i previsible perquè navegadors i tecnologies d’assistència interoperin.
La semàntica correcta permet a l’usuari decidir com navegar
Un bon encapçalament no és només text gran. Un camp no és accessible només perquè tingui una paraula visualment a prop. Amb HTML apropiat i, quan cal, ARIA correcte, el lector de pantalla pot comunicar l’estructura i l’usuari pot navegar amb les seves pròpies ordres. W3C recomana utilitzar elements natius sempre que sigui possible i defineix ARIA per comunicar rols, estats i propietats.
Provar amb un lector de pantalla no és només comprovar que la pàgina parla
Sentir text no demostra que una pàgina sigui usable. Cal provar tasques completes: arribar al contingut principal, entendre la jerarquia, utilitzar menús i formularis, identificar errors, treballar amb diàlegs i components dinàmics i recuperar l’orientació. També cal provar amb teclat i, sempre que sigui possible, amb persones usuàries habituals d’aquestes tecnologies.
Què hauria de fer una empresa en lloc de confiar en una capa
Primer cal identificar les barreres reals i corregir-les al component, plantilla, tema o aplicació que les genera. HTML semàntic, patrons accessibles, bona gestió del focus i proves amb combinacions representatives de navegador i tecnologia d’assistència. L’automatització pot detectar alguns problemes, però l’experiència amb lector de pantalla necessita proves funcionals i humanes.
Accessibilitat ≠ Overlay
L’entrega 06 posa el focus en una idea senzilla: el lector de pantalla pertany a l’usuari, no al web. El web ha d’oferir una interfície sòlida i previsible amb la qual aquesta tecnologia pugui interoperar. Si una capa altera estructura, focus o semàntica, pot transformar una barrera coneguda en una altra de més difícil de diagnosticar. La solució sostenible continua sent corregir en origen i provar amb tecnologies d’assistència reals.
Fonts oficials i tècniques
W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview
Overlay Fact Sheet
Overlay Fact Sheet — experiències i limitacions relacionades amb tecnologies d’assistència
Aquest article forma part de la sèrie «Accessibilitat ≠ Overlay». Entrega 06 — Overlays i lectors de pantalla.