L'accessibilitat afecta gairebé totes les etapes d'un projecte. Això s'explica habitualment dient que l'accessibilitat és necessària abans, durant i després de fer el projecte. És una manera elegant d'il·lustrar que l'accessibilitat s'ha de tenir en compte en la fase de planificació, durant el desenvolupament i com a part del Control de Qualitat (QA) quan el projecte ja és en marxa.
Aquesta simplificació és útil per explicar que l'accessibilitat no és només una preocupació durant la implementació; però com tota simplificació, és inexacta perquè pot induir a error. Aclarim alguns d'aquests malentesos.
L'accessibilitat en la fase de planificació va més enllà del disseny visual
Moltes directrius s'apliquen específicament al disseny visual, com les que s'engloben sota el principi general de ser Perceptible. Però fins i tot aquestes estan estretament lligades a l'arquitectura de continguts i a la redacció.
Per tenir un lloc web fàcil d'entendre, habitualment es té en compte la complexitat del text mitjançant algun dels models i fórmules existents (com ara les proves de llegibilitat de Flesch-Kincaid, que es basen en la longitud de les paraules i les frases per assignar una puntuació entre 0 i 100, on 100 correspon a un text fàcil de llegir i 10 o menys a un text extremadament difícil).
Això també s'aplica a la navegació. Una estructura amb moltes categories molt poblades i diversos nivells de subcategories és més difícil de recórrer que una navegació senzilla d'un sol nivell.
També s'aplica a qualsevol procés, com el de compra. És millor demanar als usuaris només la informació mínima necessària per fer una compra, i preguntar després si volen crear un compte amb les dades facilitades, i no a l'inrevés. Això redueix la fricció, cosa que afavoreix la conversió, però facilitar les coses també ajuda els usuaris que, d'altra manera, podrien sentir-se aclaparats.
Sempre val la pena tenir present que els passos que demanem als usuaris no han de coincidir necessàriament amb els passos que tenen lloc a la nostra empresa. Sovint podem simplificar la feina dels usuaris centrant-nos en allò que volen aconseguir i gestionant la resta internament.
L'accessibilitat durant el desenvolupament va més enllà del codi
En la fase d'implementació, les coses comencen a concretar-se. En aquesta etapa és més fàcil detectar quan alguna cosa desentona. A més, pel simple fet d'estar en context, els components són més fàcils d'analitzar.
Si tenim un element superposat (un botó), independentment d'on aparegui a la pantalla, el seu ordre de tabulació depèn de la seva posició dins de l'HTML. Si el botó activa un modal, aquest s'ha de col·locar dins del DOM de manera que el seu ordre de navegació per teclat (comunament conegut com a ordre de tabulació) tingui sentit. O bé, si és un modal a pantalla completa, cal desactivar temporalment la resta de la navegació. Encara que hàgim dissenyat el botó i el modal com un component cohesionat, pot ser necessari implementar-los en parts diferents de l'HTML perquè la navegació per teclat funcioni com es pretén.
Això és més important quan fem servir un enfocament atòmic del disseny, en el qual els components es dissenyen de manera aïllada i poden necessitar ajustos quan s'apliquen en contextos diferents. Aquests ajustos poden ser variacions visuals o implementacions de codi completament diferents.
No cal que això impliqui una comunicació constant entre dissenyadors i desenvolupadors (cosa que sempre genera cert recel). Simplement tenir en compte l'accessibilitat pot facilitar-ho tot.
L'accessibilitat després del llançament del projecte va més enllà del QA
Un cop en marxa, si tot s'ha fet correctament, només cal estar atents als errors, oi? Ni de bon tros.
Un dels principals factors de l'accessibilitat és el contingut, ja que els projectes digitals són sistemes vius que canvien, creixen i s'adapten. Els textos acuradament elaborats per desenvolupar i llançar el lloc web aviat conviuran amb contingut nou o necessitaran una actualització quan quedin desactualitzats. I l'accessibilitat del nou contingut requereix la mateixa atenció que el contingut original.
El contingut nou manté un projecte al dia, però també és un risc. El contingut continu per al blog i la presència a les xarxes socials d'una empresa és, alhora, una manera de créixer de manera orgànica i un pou sense fons d'entropia. El contingut nou aporta noves perspectives, però també nous problemes. Quelcom tan senzill com la necessitat de recontextualitzar contingut antic quan s'incorpora contingut nou pot resultar una càrrega si no som metòdics.
Per exemple, si volem ampliar la nostra audiència creant contingut informatiu o educatiu sobre temes tècnics o acadèmics complexos, hem de trobar la manera d'incloure'l al costat del contingut més precís i tècnic de manera que no col·lisioni ni entri en conflicte amb la veu i el to utilitzats en cadascun d'ells. Si fem servir contingut planer i accessible només en una part del projecte, la resta resultarà més confusa o, en el pitjor dels casos, dissonant per als usuaris.
Cada nou contingut ha de ser coherent amb el seu context, tant en fons com en to, i també en la seva implementació. Una imatge que resumeix a la perfecció un tema complex pot ser adequada per a certes plataformes. Però cal adaptar-la a un element textual o interactiu, segons el seu context, perquè tingui sentit per a l'usuari.
Conclusió
A l'article L'accessibilitat no és només una bona experiència d'usuari, vaig escriure sobre com l'accessibilitat i l'experiència d'usuari no poden abordar-se simplement en la mateixa conversa. Això no vol dir que l'estratègia d'experiència d'usuari i els esforços en matèria d'accessibilitat hagin d'estar renyits. Necessitem entendre com es manifesta l'accessibilitat en cada aspecte d'un projecte per evitar el conflicte.
Això de vegades s'interpreta malament com un escenari ideal, només possible si l'empresa va molt bé i vol invertir diners en accessibilitat. La realitat és que aquesta és la manera eficient de fer accessibles els projectes. El que fa que la remediació d'accessibilitat resulti aclaparadora és, generalment, que està desconnectada del procés habitual. Ja sabem com és la planificació, però què passa quan sorgeix un problema fora del nostre pla original? Sempre porta més temps i és més costós, i habitualment dona pitjors resultats que l'alternativa.
Fran Rosa. Desenvolupador sènior, especialista en accessibilitat i defensor del desenvolupament centrat en les persones
Quan es remedien problemes d'accessibilitat en un projecte existent, les incorporacions solen acceptar-se sense reserves. Si es demana afegir alternatives textuals, elements visuals, instruccions o subtítols a un vídeo, rarament sorgeix cap conflicte. Fins i tot l'aplicació de patrons ARIA (Accessible Rich Internet Applications) complexos mai no genera objeccions.
Tanmateix, de vegades la remediació exigeix replantejar certs components, modificar-los o rebutjar alguna implementació existent. I això genera més fricció.
És comprensible, ja que la remediació implica admetre que alguna cosa no funciona bé (en termes d'accessibilitat) i s'ha de refer. Aquest tipus de canvis pot fer que un projecte superi els seus terminis.
L'accessibilitat consisteix a complir un estàndard, i alguns dels criteris són molt específics i no admeten discussió. Per tant, no sempre és només qüestió d'"afegir-ne més".
ARIA n'és un bon exemple. Hi ha una col·lecció d'atributs i patrons existents que podem utilitzar, però de maneres molt concretes. Un principi fonamental és que "cap ARIA és millor que un ARIA mal implementat", la qual cosa vol dir que una mala implementació pot ser pitjor per als usuaris que cap implementació en absolut.
En planificar l'accessibilitat des del principi, un enfocament minimalista és l'òptim. Per exemple, alguns elements HTML tenen rols i atributs ARIA implícits. Els elements de formulari HTML natius al navegador utilitzen atributs ARIA implícits com ara aria-checked. L'ús d'elements semàntics adequats (<head>, <main>, <footer>, <nav>, o <article>…) afegeix molts rols ARIA implícits a l'estructura d'un lloc web.
És una vella broma que la primera pàgina de la World Wide Web ja era accessible perquè és simplement HTML sense imatges ni estils. Com en la majoria de bromes, hi ha una veritat en el fons. La manera com els diferents navegadors implementen els components HTML segueix estàndards estrictes, de manera que una implementació uniforme a escala del sector probablement millorarà una de personalitzada (si és una opció).
Podem crear interfícies complexes amb components personalitzats i fer-les accessibles. Però hem de ser conscients dels compromisos que assumim i oferir una alternativa que sigui tan bona com els components natius que substituïm. I segons l'informe WebAIM Million 2026, "les pàgines amb ARIA presentaven significativament més errors (59,1 de mitjana) que les pàgines sense ARIA (42 de mitjana)".
Un enfoc minimalista és més fàcil de mantenir, generalment més robust entre navegadors i redueix el risc d'errors. La complexitat pot ser inevitable en alguns projectes, però mai no hauria de ser l'opció per defecte.
Fran Rosa. Desenvolupador sènior, especialista en accessibilitat i defensor del desenvolupament centrat en les persones
Com fem servir el color en el disseny d'un lloc web pot donar lloc a problemes d'accessibilitat. I tot i que aquests semblen, en principi, fàcils de solucionar, poden portar molta feina si no es van tenir en compte des del principi en el disseny.
Hi ha dos aspectes que són els més importants per avaluar si tenim problemes amb el color: contrast i ús del color.
Contrast
És la més freqüent, i podem trobar llocs web en els quals no existeix gairebé cap pàgina sense problemes d'aquest tipus.
El principi és molt simple: el contrast entre el text i el fons ha de ser de 4.5:1 com a mínim per al text base, o 3:1 per a textos grans (en general, textos de 18pt o més, o de 14pt o més si estan en negreta, o mides equivalents per a alfabets xinès, coreà i japonès) per al nivell AA, i de 7:1 i 4.5:1 respectivament per al nivell AAA..
Sembla que només n'hi hauria prou amb triar colors adequats per al disseny, però això a vegades no és tan senzill.
El problema més fàcil de solucionar és deixar d'intentar amagar o dissimular algunes parts del contingut. Per exemple, amb textos legalment obligatoris o confirmacions d'acceptació de condicions. Creem tot un disseny pensant en el que volem comunicar i podem caure en la temptació de posar en un color que destaqui menys les parts que creiem que no encaixen amb el to general del nostre lloc.
Si fem això, no estem eliminant el contingut ni l'obligació de tenir-lo, només estem fent més difícil la seva lectura per raons estètiques. Però hem de ser capaços de dissenyar llocs web que siguin, alhora, visualment atractius i funcionals.
Un altre problema que ocorre amb freqüència és que els colors corporatius o de la marca no tenen un bon contrast. Per exemple, quan adaptem colors d'una marca que es va dissenyar per a colors impresos a pantalla, els colors no sempre són adequats. Els colors impresos són sostractius, amb la qual cosa barrejar colors dona un resultat més fosc, mentre que els colors en pantalla són additius, i ocorre el contrari. Per això intentar copiar un color exactament en pantalla no sempre funciona, encara que ho faci en paper. Aquest error és fàcil de corregir a nivell tècnic, però requereix més feina des del punt de vista del disseny.
Ús del color
A més de fer servir colors amb bon contrast, no podem fer servir el color per traslladar informació o distingir elements.
Per exemple, en un formulari. Marcar en vermell un camp si hi ha un error està bé, perquè assenyalem l'error on ocorre, però no podem fer servir aquest vermell com a única indicació de l'error. Hem de fer servir text o altres elements visuals per indicar-ho.
O si tenim una llista d'opcions, assenyalar quines estan seleccionades només amb un canvi en el color del fons no és suficient. Hem de fer servir elements com icones addicionals (per exemple) per poder distingir-ho encara que no puguem percebre el color.
Aquesta norma sol costar una mica més d'entendre perquè, a vegades, visualment és molt clar i fàcil de percebre un canvi o informació mitjançant el color, i sembla obvi. Però algunes persones no poden percebre el color, o ho fan de manera distinta, per la qual cosa la interpretació de l'ús del color no és sempre tan òbvia com ens pot semblar.
Conclusió
L'ús del color afecta l'accessibilitat d'un lloc web tant per les qualitats dels colors escollits com per la intencionalitat del seu ús per mostrar la informació. I solucionar-ho implica, a vegades, repensar quins colors fem servir i com; això pot ser una tasca complexa. Però al final sempre obtenim un disseny millor, més útil i adequat per a un sector més ampli del nostre públic.
Fran Rosa. Desenvolupador sènior, especialista en accessibilitat i defensor del desenvolupament centrat en les persones
No. Desafortunadament, no podem automatitzar l'accessibilitat. I no és probable que això canviï en el futur.
Ja existeixen eines que analitzen automàticament l'accessibilitat d'un lloc web. Per exemple, WAVE és un conjunt d'eines que ens ajuda a identificar fallades en el compliment de les pautes d'accessibilitat. Si fem servir una de les seves extensions per a diferents navegadors, tenim una llista de possibles incompliments mentre naveguem per la mateixa pàgina, assenyalant el punt on s'incompleix i amb informació sobre com solucionar-ho.
Un altre exemple és Axe-core. És una eina de codi obert que podem fer servir per analitzar automàticament un lloc web complet. També tenim una llista d'incompliments amb informació precisa sobre com localitzar-los. Aquests són només dos exemples d'eines gratuïtes, però existeixen moltes altres eines i serveis de pagament.
Llavors, per què no podem automatitzar l'accessibilitat en un lloc web?
Primer, perquè les eines generalment informen d'un incompliment, però no necessàriament són capaces de solucionar-ho. L'exemple més senzill és amb les imatges. Una eina ens indica que una imatge no té text alternatiu, però no pot valorar si aquesta imatge és purament decorativa o no, ni quin text alternatiu seria apropiat.
I pot ser que estiguis pensant: I no pot una IA veure el que hi ha a la imatge? I la resposta és sí, més o menys. Perquè el text alternatiu d'una imatge depèn d'una decisió humana intencionada de fer servir aquesta imatge, i cal conèixer aquesta intenció per oferir un bon text alternatiu.
Un exemple: un dels membres de l'equip d'una empresa rep un premi, i publiquem una foto al blog de la companyia. En aquesta foto veiem «dues persones, una d'elles amb un premi a la mà». ¿Seria aquest un bon text alternatiu? Perquè si ho publiquem per donar a conèixer que algú ha guanyat aquest premi, hauríem d'incloure el seu nom, esmentar que forma part de l'equip de l'empresa, i si el premi està relacionat amb un projecte de l'empresa, probablement esmentar-ho també. Tot depèn de la intenció que teníem en publicar aquesta foto.
Una altra raó per la qual les eines automàtiques a vegades no són suficients és perquè hi ha errors (fins i tot els que són errors en el codi) que són impossibles de detectar.
Un altre exemple: si tenim en una part del lloc web una navegació per pestanyes, la implementació requereix relacionar cada pestanya amb el seu contingut corresponent, marcar quina està activa o visible en aquell moment, fer que sigui navegable amb el teclat, etc. Pots veure exemples complets d'una implementació del patró de pestanyes a l'Accessible Rich Internet Applications (ARIA) Authoring Practices Guide. Si hem fet tota la implementació correctament i només se'ns ha oblidat marcar quina pestanya està activa, una eina automàtica podria reconèixer el patró d'implementació i indicar la part que falta.
Però si només ho hem implementat visualment sense afegir cap de les parts necessàries en el codi, ¿com pot saber l'eina automàtica que estem implementant una navegació per pestanyes?
Aquestes limitacions fan que automatitzar la detecció de problemes d'accessibilitat sigui molt útil, però insuficient. Ens pot ajudar a detectar descuidis i millorar el desenvolupament i implementació de nous continguts, però no pot detectar-ho tot ni oferir solucions. I podem caure en l'error de pensar que si una eina automàtica no detecta cap fallada és perquè no n'hi ha cap, quan no necessàriament és així. Les eines ens ajuden, però no substitueixen ni el coneixement ni factors humans com la intenció.
Fran Rosa. Desenvolupador sènior, especialista en accessibilitat i defensor del desenvolupament centrat en les persones
El document que marca les pautes sobre les quals es mesura l'accessibilitat de llocs web i aplicacions mòbils es coneix com a «Pautes d'Accessibilitat per al Contingut Web» (conegudes freqüentment com a WCAG, per les seves sigles en anglès).
Aquest document s'utilitza com a referència per desenvolupar projectes digitals accessibles i auditar l'accessibilitat dels que ja existeixen. Per això, per incloure's en el document, les pautes han de complir dos criteris:
- Ser problemes d'accés importants que afectin especialment persones amb discapacitats (és a dir, que van més enllà dels problemes d'usabilitat que afecten tothom).
- Ser verificables, perquè se'n pugui mesurar la conformitat amb un alt nivell de fiabilitat.
Les lleis que regulen els llocs que estan obligats a ser accessibles es basen en aquest document.
Un aspecte que de vegades genera una mica de confusió és que les pautes es divideixen en tres nivells: A, AA i AAA. I aquests són acumulatius, cosa que significa que per complir el nivell AA (que és la recomanació habitual i el que esmenten les lleis) cal complir totes les pautes dels nivells A i AA. També és possible que algunes no s'apliquin. Per exemple, les que fan referència a continguts d'àudio i/o vídeo no apliquen si el lloc no té aquest tipus de contingut.
Els nivells s'assignen segons com d'essencial és cada pauta, si és possible complir-la en diferents tipus de llocs i continguts, i si és raonable que els creadors de contingut la compleixin. Així, les pautes A són mínims que eliminen obstacles bàsics; les pautes AA són l'estàndard que millora l'accessibilitat per a un ventall més ampli de persones; i les pautes AAA són el nivell més alt d'exigència, i no és realista esperar que tots els tipus de contingut les compleixin.
Si analitzem les pautes per a elements interactius o formularis, l'expectativa de coneixement en l'ús de codi és més gran que per a pautes com l'ús d'imatges o colors, ja que és raonable pensar que qui implementa interactivitat o formularis en un lloc web tindrà prou coneixements de codi per complir amb els criteris.
Els nivells existeixen perquè la feina rigorosa que es fa en crear les pautes no només se centra en com afecten les persones que faran servir aquest lloc web, sinó que també té en compte la tasca d'implementar-les. I encara que, generalment, ens centrem en l'obligació de complir certes pautes, tenim accés a una llista àmplia de criteris significatius i mesurables, i els nivells són informació afegida per al seu compliment.
Fran Rosa. Desenvolupador sènior, especialista en accessibilitat i defensor del desenvolupament centrat en les persones
En una conversa recent amb un dissenyador expert en disseny digital i experiència d'usuari (UX), vaig comentar que generalment no és bona idea considerar l'accessibilitat i l'experiència d'usuari al mateix temps. La seva resposta va ser que l'accessibilitat no és més que una bona experiència d'usuari per a tothom. Tot i que és una manera bonica d'expressar-ho, continuo creient que és un error considerar l'accessibilitat com una part de l'experiència d'usuari.
Per començar, la manera com avaluem l'una i l'altra és molt diferent. Malgrat que existeixen bones pràctiques, l'experiència d'usuari es mesura en cada projecte segons com una persona percep, utilitza i completa satisfactòriament certes tasques. En aquest sentit, estar satisfet amb el resultat o aconseguir el que volem inicialment no té per què ser el mateix.
Aquí és important conèixer una mica la història de la UX com a disciplina. Tot i que podem considerar alguns avenços en ergonomia o psicologia com a precursors, va ser el 1982 quan va sorgir el concepte d'Interacció Persona-Ordinador, centrat a fer la interacció possible i efectiva. A partir de la publicació de les «10 heurístiques d'usabilitat» de Jakob Nielsen i Rolf Molich el 1989, el terme usabilitat es va popularitzar centrant-se a reduir errors i millorar l'eficiència.
L'experiència d'usuari és un concepte de Don Norman quan treballava a Apple el 1993, i se centrava a analitzar els sistemes que es creaven de manera holística i sempre des del punt de vista de l'usuari. Aquí hi ha un canvi essencial en l'enfocament, perquè el que l'usuari pensa, experimenta o sent es converteix en la principal mètrica de l'èxit. Durant la primera dècada dels anys 2000 s'estén la idea que tots els processos i decisions s'han de mesurar des d'aquesta experiència d'usuari.
Això és revolucionari, sobretot des del punt de vista comercial, però també fa més difícils algunes converses. Per exemple, un concepte que neix d'aquesta manera d'entendre el disseny és la «interfície d'usuari optimista» (l'article «True Lies Of Optimistic User Interfaces» de Denis Mishunov, en anglès, parla sobre aquest tema). Aquest concepte es basa en la idea que, quan interactuem amb una interfície en un mòbil, en lloc d'esperar a rebre la resposta del servidor, el millor és mostrar a la interfície que s'ha completat la tasca, encara que no sigui veritat, perquè l'usuari ho percebi com una cosa instantània, i que si finalment hi ha un error, es pugui mostrar més tard. És una pràctica molt habitual a les xarxes socials quan reaccionem a un contingut amb un «m'agrada» o afegint un comentari i veiem instantàniament com s'afegeix, encara que encara no s'hagi enviat al servidor.
En aquest cas, la interfície ens està mentint per vendre'ns una il·lusió d'immediatesa, perquè es considera que l'efecte positiu de veure la interacció de manera instantània supera l'efecte negatiu que aquesta interacció acabi desapareixent després per alguna fallada. I és que, en barrejar tantes parts del procés i disciplines dins de la mateixa olla, l'experiència d'usuari sempre acaba sent una negociació entre molts factors.
Quan parlem d'accessibilitat, els criteris solen ser més rígids. Està el component ben implementat per ser utilitzat amb un lector de pantalla? Pot l'usuari aturar o pausar vídeos o animacions? Existeix text alternatiu per a continguts com imatges o elements multimèdia? La resposta sol ser un sí o un no, no hi ha negociació. En accessibilitat, no és acceptable tenir un botó massa petit o un contrast de color inadequat perquè l'usuari tingui una experiència emocional diferent.
Per això, tot i que integrar l'accessibilitat en diferents parts del procés (com el disseny o el desenvolupament) facilita que un projecte en evolució contínua segueixi sent accessible, també cal entendre que els criteris d'accessibilitat són mínims indispensables que s'han de complir i no uns objectius que es puguin negociar juntament amb altres consideracions.
Fran Rosa. Desenvolupador sènior, especialista en accessibilitat i defensor del desenvolupament centrat en les persones