Accessibilitat web: Com decidir què millorar al teu lloc

Una persona arriba a la teva pàgina de serveis, però no aconsegueix enviar el formulari: el teclat no assoleix el botó d'enviament, un avís d'error no s'entén o el contrast fa difícil llegir els camps. La informació està publicada, però la tasca no es completa.

L'accessibilitat web consisteix a reduir aquestes barreres per tal que més persones puguin percebre, entendre i utilitzar un lloc. En aquest cas pràctic hipotètic veuràs com passar d'una incidència concreta a un abast raonable de millora. En acabar podràs decidir què revisar primer, què demanar a qui desenvolupa la teva web i com comprovar que un canvi funciona en situacions reals.

Situació inicial hipotètica

Imagineu una petita empresa de serveis que rep sol·licituds des de la vostra web. El vostre responsable detecta que algunes persones abandonen el formulari i planteja una petició àmplia: "haig de fer la web accessible".

Aquesta intenció és vàlida, però encara no permet prendre decisions. Una web reuneix continguts, menús, imatges, formularis i elements interactius. Cada part pot generar una barrera diferent.

Abans de triar eines o canvis visuals, és bo concretar què ha de poder fer una persona a la web, i en aquest exemple, la tasca prioritària seria:

Trobar un servei, llegir la vostra informació, completar un formulari i saber si la petició s'ha enviat correctament.

L'objectiu no seria afegir una etiqueta d'accessibilitat al lloc, sinó facilitar aquest recorregut sense obligar a usar un dispositiu, una capacitat o una forma única de navegació.

Problema observable: el recorregut es trenca

En la revisió de l'escenari hipotètic apareixen diversos obstacles. No cal que tots estiguin presents en el teu lloc perquè l'exemple resulti útil:

• Els enllaços del menú només es distingeixen pel color i no mostren clarament quin té el focus en navegar amb teclat.
• Els camps del formulari mostren una frase dins de la caixa, però no una etiqueta persistent que expliqui quina dada es demana.
• Si falta un camp obligatori, el missatge d'error apareix lluny del lloc on s'ha produït el problema.
• Un botó conté només una icona i la seva funció no queda clara per a qui no veu aquesta icona o usa tecnologia de suport.
• El missatge final d'enviament es mostra breument i pot passar desapercebut.

El denominador comú no és estètic. Són barreres que dificulten accions concretes.

Aquí és útil separar dues preguntes. La primera és de negoci: quin recorregut ha de poder completar una persona? La segona és d'implementació: quin contingut, interacció i comportament s'ha d'ajustar per aconseguir- el? Confondre-les sol portar a arranjaments aïllats que no resolen la tasca completa.

Anàlisi de l'objectiu: fer servir una acció important

En el cas, l'empresa decideix prioritzar el formulari perquè és la via principal per iniciar una conversa. Aquest objectiu es pot expressar de forma comprovable:

Una persona ha de poder enviar una sol·licitud, entendre els camps requerits, corregir un error i rebre una confirmació clara.

Aquesta formulació ajuda a evitar decisions basades només en aparença. Per exemple, augmentar la mida d'un text pot ser útil, però no resoldrà un formulari que no es pot recórrer amb teclat. De la mateixa manera, afegir text alternatiu a una imatge no substitueix una estructura de capçaleres que permeti comprendre la pàgina.

L'accessibilitat web sol requerir revisar diversos modes d'ús: navegació amb teclat, lectura de continguts, interacció amb formularis, ampliació del text i comprensió d'avisos. El pes de cada revisió depèn del que faci la teva web.

Si el lloc ofereix reserves, compra, accés privat o eines de gestió, l'anàlisi ha d'incloure aquestes tasques i els seus estats: què passa abans de començar, durant el procés i quan hi ha un error. Les obligacions aplicables a la teva activitat o al tipus de servei s'han de validar amb l'assessorament especialitzat que correspongui; una revisió tècnica no substitueix aquesta valoració.

Abast proposat: intervenir on canvia l'experiència

Amb l'objectiu definit, l'abast del cas hipotètic no seria "revisar-ho tot" sense més. Es concentraria en el recorregut prioritari i en els elements que ho sostenen:

Estructura de la pàgina de servei. Revisar que els títols ordenin la informació i que els enllaços expliquin a on porten. 2.

Navegació amb teclat. Comprova que es pot accedir als enllaços, camps i botons en un ordre comprensible, i que el focus s'identifica visualment. El focus és el senyal que indica quin element rebrà la següent acció del teclat. 3.

Formulari. Associa cada camp amb una indicació clara, assenyala les dades necessàries i explica els errors al costat d'una manera de corregir-les. 4.

Botons i icones. Assegurar que l'acció s'entén sense dependre només d'una imatge, un color o una posició en pantalla. 5.

Confirmació d'enviament. Mostra un missatge visible i comprensible que confirmi el resultat o indiqui què s'ha de revisar.

Aquest abast no pressuposa una tecnologia concreta. Podeu requerir canvis de contingut, disseny o codi segons com estigui construït el lloc. També convé deixar fora, de forma expressa, les àrees que no s'hagin revisat encara. Així no s'evitaran donar per resolt el conjunt de la web quan la intervenció s'ha centrat només en un recorregut.

Solució i comprovació: prova la tasca, no només els components

A l'escenari, l'aplicació comença per millorar la pàgina i el formulari. Es manté una etiqueta visible en cada camp, es defineix un focus reconeixible, s'aclareixen els botons amb icones i es reordenenen els missatges per indicar què ha fallat i com corregir- el.

La comprovació posterior no es limita a confirmar que els canvis es publiquin. Es repeteix la tasca inicial en condicions diferents:

• recórrer la pàgina i el formulari usant només el teclat;
• ampliar el text per a comprovar si el contingut segueix sent llegible i operable;
• provocar un error de forma intencionada per revisar on apareix l'avís i si s'entén;
• enviar una sol·licitud correcta i confirmar que el resultat queda clar;
• revisar els continguts i components afegits per tal que no reintrodueixin la mateixa barrera.

Aquestes proves no permeten declarar que un lloc serà adequat per a totes les persones i tots els contextos. Si esdevenen una intenció general en criteris visibles d'acceptació. Si una persona no pot localitzar el camp amb error o no sap si l'enviament s'ha completat, la tasca encara no està resolta.

També importa mantenir les millores. Una nova plantilla, un formulari extern, un canvi de disseny o la càrrega de contingut poden modificar el comportament previ. Per això l'accessibilitat ha de formar part de les decisions habituals d'evolució del web, no quedar-se en una correcció aïllada.

Aprenentatges transferibles per a la teva web

El cas deixa tres idees aplicables a una pime o a un negoci autònom:

• Comença per una acció essencial per a la teva activitat: demanar informació, reservar, comprar, descarregar un document o accedir a una àrea privada.
• Descriu el resultat esperat des del punt de vista de qui visita el web. "Poden enviar una sol·licitud i entendre la resposta" permet decidir millor que "millorar l'accessibilitat".
• Demana que la solució inclogui una manera de comprovar-la. Un canvi està més ben definit quan es pot provar en el recorregut que pretén millorar.

L'accessibilitat web no es resol amb un únic ajust visual o amb una fórmula genèrica. Es treballa identificant barreres en tasques importants, prioritzant les que impedeixen avançar i verificant el resultat amb usos reals de la pàgina.

Si no tens clar quin recorregut revisar primer o quins canvis requereix el teu lloc, pots explicar el teu projecte de desenvolupament web per valorar l'abast tècnic que tindria una revisió i una millora proporcionada.