Com funciona l'accessibilitat: la cadena de components

Quan una persona cega compra un bitllet de tren des del mòbil, en aquesta compra hi intervenen moltes peces alhora: el web de la companyia, el navegador, el sistema operatiu, el lector de pantalla, l'eina amb què es va publicar el contingut i la mateixa experiència d'aquesta persona. L'accessibilitat no és una propietat aïllada d'una pàgina, sinó el resultat que totes aquestes peces encaixin. En aquesta lliçó veiem quines són, com es passen la informació les unes a les altres i quina part de la cadena depèn de tu.

Els components essencials segons el W3C

La Iniciativa d'Accessibilitat Web (WAI) del W3C descriu l'accessibilitat web com un sistema de components que depenen els uns dels altres, en el document Essential Components of Web Accessibility. Són aquests:

• Contingut: tot el que hi ha en una pàgina o aplicació web: textos, imatges, sons i vídeos, i també el codi o marcatge que en defineix l'estructura i el comportament.
• Agents d'usuari: els programes que mostren el contingut a la persona, sobretot navegadors i reproductors multimèdia.
• Tecnologies de suport: lectors de pantalla, ampliadors de pantalla, teclats alternatius, polsadors, programari de reconeixement de veu… Les estudiaràs amb detall al curs «Persones i tecnologies de suport».
• Coneixements i estratègies de les persones usuàries: la seva experiència amb el navegador i amb la seva tecnologia de suport, i les estratègies que han desenvolupat per moure's pel web.
• Desenvolupadors, en sentit ampli: els qui dissenyen, programen i redacten, i també les persones usuàries que publiquen contingut (un comentari, una ressenya, un vídeo).
• Eines d'autor: el programari amb què es crea el contingut: gestors de continguts o CMS (content management system, com WordPress o Drupal), editors de text enriquit, generadors de PDF, plataformes de formularis i eines de disseny.
• Eines d'avaluació: validadors, comprovadors automàtics, analitzadors de contrast i similars.

Per a cada grup de components hi ha unes pautes de referència del W3C. Les WCAG (Pautes d'Accessibilitat per al Contingut Web) s'ocupen del contingut. Les ATAG 2.0 (Pautes d'Accessibilitat per a Eines d'Autor, 2015) demanen dues coses a aquestes eines: que les pugui fer servir una persona amb discapacitat i que ajudin a produir contingut accessible. Les UAAG 2.0 (Pautes d'Accessibilitat per a Agents d'Usuari, publicades com a nota tècnica el 2015) orienten navegadors i reproductors. La llei i les auditories se centren en les WCAG, però convé conèixer les altres dues, sobretot quan es contracta un CMS.

Com viatja la informació fins a la persona

Un lector de pantalla no «mira» la pàgina com ho fa una persona que hi veu. El recorregut de la informació és, simplificant, aquest:

1. El servidor envia el codi: HTML per a l'estructura, CSS per a la presentació i JavaScript per al comportament.
2. El navegador interpreta aquest codi i construeix el DOM (Document Object Model), la representació interna de la pàgina amb tots els seus elements.
3. A partir del DOM, el navegador genera l'arbre d'accessibilitat: una versió simplificada en què cada element té un rol (botó, enllaç, encapçalament, casella de selecció), un nom («Compra el bitllet») i, si escau, un estat (marcada, desplegat, desactivat).
4. El navegador exposa aquest arbre al sistema operatiu mitjançant les seves interfícies de programació d'accessibilitat, diferents a Windows, macOS, iOS, Android o Linux.
5. La tecnologia de suport consulta aquestes interfícies i converteix la informació en veu, braille, ampliació o ordres de veu.

La conseqüència pràctica és senzilla: si el codi no diu què és cada cosa, el navegador no ho pot explicar i la tecnologia de suport no s'ho pot inventar. Veuràs l'arbre d'accessibilitat en detall al curs d'HTML semàntic del nivell 3.

<!-- Incorrecte: l'enllaç no té nom -->
<a href="/"><img src="logo_ayto_v3.png"></a>

<!-- Correcte: el text alternatiu dona nom a l'enllaç -->
<a href="/"><img src="logo_ayto_v3.png" alt="Ajuntament de Villaserena: pàgina d'inici"></a>

Quan una baula falla

Com que els components depenen els uns dels altres, un error en qualsevol d'ells repercuteix en els altres. Aquests són alguns casos habituals:

• Una eina d'autor que no ajuda: un CMS que no té camp per al text alternatiu, o un editor que converteix els títols en text en negreta en lloc d'encapçalaments. Qui redacta vol fer-ho bé i l'eina li ho impedeix.
• Contingut que no aprofita el que el navegador ja ofereix: un desplegable construït amb <div> i JavaScript que imita un <select>, però no informa del seu rol, de l'opció triada ni de si està obert o tancat.
• Un agent d'usuari o una tecnologia de suport sense compatibilitat: una característica recent d'HTML o d'ARIA que alguns navegadors o lectors de pantalla encara no interpreten bé.
• Una persona usuària que encara està aprenent: algú que acaba de perdre la visió i encara no domina el seu lector de pantalla depèn més que ningú que el web sigui senzill, coherent i previsible.

El W3C descriu també el cercle virtuós contrari: quan els navegadors i les tecnologies de suport admeten bé una característica, els desenvolupadors la fan servir i les eines d'autor la incorporen, i produir contingut accessible deixa d'exigir un esforç especial. Si un component falla, els altres recorren a pedaços fràgils i cars.

«Funciona al meu navegador» no n'hi ha prou

Les WCAG introdueixen un concepte que aquí només apuntem: les tecnologies s'han de fer servir d'una manera compatible amb l'accessibilitat (en anglès, accessibility supported), és a dir, d'una manera que funcioni amb els navegadors i les tecnologies de suport que la gent fa servir realment. No n'hi ha prou que el codi sigui tècnicament vàlid ni que funcioni a l'ordinador de l'equip de desenvolupament.

Això té dues conseqüències pràctiques. La primera: el més segur és fer servir els elements natius d'HTML (<button>, <a>, <input>, <select>), que els navegadors i les tecnologies de suport admeten des de fa anys i que ja inclouen rol, nom, estat i maneig amb teclat. La segona: les proves s'han de fer amb diverses combinacions reals, per exemple NVDA amb Firefox o Chrome a Windows, VoiceOver amb Safari a l'iPhone i TalkBack amb Chrome a Android, i no amb una de sola. Aprendràs a fer-ho al nivell d'auditoria.

Les preferències del sistema també formen part de la cadena

Una baula que sovint s'oblida són els ajustos que la persona ja té configurats al dispositiu: mida del text, zoom, mode fosc, alt contrast, reducció de moviment o subtítols activats per defecte. Un web accessible respecta aquests ajustos en lloc d'anul·lar-los: no bloqueja el zoom al mòbil, no fixa mides que impedeixen fer més gran el text i no ignora la preferència de moviment reduït. Per això un botó propi per «fer més gran la lletra» no substitueix que la pàgina funcioni bé amb el zoom del navegador, que la persona ja coneix.

Resum

• L'accessibilitat depèn d'una cadena: contingut, agents d'usuari, tecnologies de suport, coneixements de la persona, desenvolupadors i eines d'autor i d'avaluació.
• Les WCAG cobreixen el contingut; les ATAG (s'obre en una finestra nova), les eines d'autor; les UAAG, els navegadors i reproductors.
• El navegador tradueix el codi en un arbre d'accessibilitat amb rol, nom i estat: si el codi no ho diu, la tecnologia de suport no ho pot saber.
• El més fiable és fer servir HTML natiu i provar amb diverses combinacions reals de navegador i tecnologia de suport.
• Un web accessible respecta les preferències que la persona ja té configurades al dispositiu.