guides
Millor experiència d'usuari per a eines web adaptatives
Els propietaris de llocs web no poden oferir plenament una bona experiència d'usuari si no coneixen les eines web adaptatives del mercat. QualiBooth identifica aquests problemes.
Les eines de la interacció
Per a les persones que depenen d’eines web adaptatives per navegar per internet, la manera com es construeix i es presenta el contingut ho és tot. La tecnologia assistiva més sofisticada del món no pot llegir, anunciar ni operar contingut que no existeixi en una forma accessible. Un botó que en realitat és un <div> estilitzat, una imatge sense alternativa textual o un desplegable personalitzat sense suport de teclat és simplement invisible — o pitjor, un carreró sense sortida — per a les persones que depenen d’aquestes eines cada dia.
QualiBooth t’ajuda a entendre dues coses alhora: com interpreten realment les eines d’un usuari el teu contingut, i quin contingut o estructura falta, està trencat o és ambigu. Aquesta combinació és el que separa un lloc web que tècnicament es carrega d’un que realment funciona per a tothom.
Aquesta guia recorre les principals categories de tecnologia assistiva i adaptativa, com espera cadascuna que es comporti un lloc web, i els passos pràctics que pots fer per construir amb aquestes eines en lloc de contra elles. També traça una línia clara entre la tecnologia assistiva genuïna i les superposicions d’accessibilitat — perquè sovint es confonen totes dues, i aquesta confusió té conseqüències reals per a usuaris reals.
Què signifiquen realment les «eines web adaptatives»
Les eines web adaptatives — més comunament anomenades tecnologia assistiva (AT) — són programari i maquinari que canvien la manera com una persona percep o opera una interfície digital. No són complements al teu lloc web; són l’entorn propi de l’usuari, configurat segons les seves necessitats i sovint utilitzat durant hores al dia a milers de llocs.
Les categories principals inclouen:
- Lectors de pantalla que converteixen el contingut de la pantalla en parla sintetitzada o braille actualitzable.
- Ampliació de pantalla que augmenta i redistribueix part o tota la pantalla.
- Dispositius d’accés per commutador per a persones que no poden utilitzar un teclat o ratolí estàndard.
- Control per veu que governa la interfície completament mitjançant ordres parlades.
- Funcions integrades del navegador i del sistema operatiu com ara modes d’alt contrast, moviment reduït i eines de lectura.
- Ajudes de lectura i comprensió que simplifiquen, narren o reestructuren el text.
Cadascuna d’aquestes es basa en el mateix fonament: una pàgina ben estructurada, semàntica i operable amb teclat que segueix estàndards establerts. Quan construeixes segons la WCAG 2.2, estàs construint el contracte del qual depèn cadascuna d’aquestes eines.
Lectors de pantalla: l’estructura és la interfície
Els lectors de pantalla són la tecnologia assistiva més coneguda i, per a molts equips, la més difícil de dissenyar — precisament perquè la disposició visual que veus no et diu gairebé res sobre el que anuncia un lector de pantalla.
Els lectors de pantalla més utilitzats són NVDA i JAWS a Windows, VoiceOver a macOS i iOS, i TalkBack a Android. No «veuen» la teva pàgina; construeixen un model a partir de l’arbre d’accessibilitat, que es deriva de la semàntica del teu HTML i de qualsevol ARIA que hi afegeixis a sobre.
Què necessiten de tu els lectors de pantalla
- Elements semàntics reals. Utilitza
<button>,<a>,<nav>,<main>,<h1>–<h6>i<table>per al que són. Un encapçalament ha de ser un encapçalament perquè els usuaris puguin saltar entre seccions; un enllaç ha de ser un enllaç perquè aparegui a la llista d’enllaços. - Alternatives textuals significatives. Cada imatge informativa necessita un atribut
altque descrigui el seu propòsit. Les imatges decoratives han de teniralt=""buit perquè s’ometin en lloc d’anunciar-se com a soroll. - Etiquetes programàtiques per als controls. Els camps de formulari necessiten elements
<label>associats; els botons només d’icona necessiten un nom accessible mitjançantaria-labelo text amagat visualment. - Una jerarquia lògica d’encapçalaments. Els encapçalaments són la manera principal com els usuaris de lectors de pantalla fullegen una pàgina. Saltar nivells o utilitzar encapçalaments només per a la mida visual trenca aquesta navegació.
- ARIA correcte — i només quan calgui. ARIA pot comunicar estats (expandit, seleccionat, desactivat) i rols per a ginys personalitzats, però un mal ARIA és pitjor que cap. La primera regla d’ARIA és utilitzar HTML natiu sempre que sigui possible.
Un punt de confusió habitual és la diferència entre un lector de pantalla i la conversió de text a veu ordinària. Una eina de lectura narra text; un lector de pantalla exposa i opera tota la interfície, inclosos els controls, els estats i la navegació. Cobrim aquesta distinció en profunditat a conversió de text a veu enfront de lectors de pantalla.
Com que les eines automatitzades només poden detectar una fracció dels problemes dels lectors de pantalla, l’única manera fiable de saber com sona el teu lloc és provar-lo tal com ho fan els usuaris. La nostra guia de proves amb lector de pantalla recorre el flux de treball pràctic, i una avaluació de lector de pantalla dedicada sotmet els teus recorreguts més importants a aquest procés amb provadors experimentats.
Ampliació de pantalla: dissenya per a la vista ampliada
Les persones amb baixa visió sovint amplien la pantalla des del 200% fins al 800% o més, veient només una petita part de la pàgina alhora. Algunes utilitzen l’ampliador del sistema operatiu; altres confien en el zoom del navegador o en programari especialitzat.
Amb molta ampliació, les decisions de disposició en què mai penses esdevenen crítiques:
- Redistribució. El contingut s’ha de redistribuir en una sola columna amb un zoom del 400% (criteri d’èxit WCAG 2.2 1.4.10) perquè els usuaris no hagin de desplaçar-se en dues direccions per llegir una frase.
- Proximitat dels elements relacionats. Si un missatge d’error apareix lluny del camp que descriu, un usuari amb ampliació pot no veure’ls mai a la mateixa finestra. Mantén juntes les etiquetes, els camps i la retroalimentació.
- Focus visible. Un indicador de focus clar i d’alt contrast permet a un usuari amb ampliació trobar on és després que la vista salti.
- Cap pèrdua de contingut ni de funció. Res no s’ha de retallar, superposar ni fer inoperable quan el text s’amplia fins al 200% (criteri d’èxit 1.4.4).
L’ampliació recompensa les disposicions netes i responsives, i castiga els dissenys de píxels fixos i el contingut que depèn del hover.
Accés per commutador i operabilitat amb teclat
Els dispositius de commutador permeten a les persones operar un ordinador amb una o dues entrades senzilles — un botó, un dispositiu de bufar i xuclar o un moviment del cap — normalment escanejant els elements interactius d’un en un. L’accés per commutador es construeix sobre el suport de teclat: si el teu lloc funciona completament des del teclat, gairebé segur que també funciona amb commutadors.
Això fa que l’operabilitat completa amb teclat sigui una de les coses de més impacte que pots fer bé:
- Tot accessible. Cada element interactiu ha de poder rebre el focus i ser operable sense ratolí — enllaços, botons, controls de formulari, menús, finestres modals, carrusels i ginys personalitzats per igual.
- Un ordre de focus visible i lògic. El focus s’ha de moure per la pàgina en un ordre que coincideixi amb el flux visual i de lectura, i l’element enfocat sempre ha d’estar clarament indicat.
- Cap trampa de teclat. Els usuaris han de poder moure el focus fora de qualsevol component, inclosos els mitjans incrustats i els diàlegs.
- Enllaços de salt. Un enllaç «saltar al contingut principal» permet a les persones ometre la navegació repetida en lloc d’escanejar-la a cada pàgina.
Si un client emplena un formulari, pot tabular per cada camp, activar un desplegable, triar un producte i enviar — tot sense tocar el ratolí? Cooperarà l’emplenament automàtic del navegador amb el teu marcatge? Aquestes són les preguntes que els usuaris de commutador i teclat responen sobre el teu lloc tant si les fas com si no.
Control per veu: els noms i les etiquetes visibles importen
Les eines de control per veu com Dragon, Voice Control i Voice Access permeten als usuaris dir ordres com «clica Enviar» o «desplaça’t avall». Perquè aquestes ordres funcionin, l’etiqueta visible d’un control ha de coincidir amb el seu nom accessible. Aquesta és la base del criteri d’èxit WCAG 2.2 2.5.3, Etiqueta al nom.
Orientació pràctica:
- El nom accessible ha de contenir el text visible. Si un botó diu «Envia el missatge», no li donis un
aria-labelde «Envia el formulari» — l’usuari que digui «clica Envia el missatge» serà ignorat. - Evita els controls només d’icona sense text, o dona’ls un nom accessible que coincideixi amb una ordre parlada probable.
- Mantén els objectius clicables prou grans perquè es puguin seleccionar de manera fiable, cosa que també satisfà el criteri de mida d’objectiu de la WCAG 2.2.
Funcions d’accessibilitat del navegador i del sistema operatiu
No totes les eines adaptatives són productes independents. Els navegadors i sistemes operatius moderns inclouen funcions integrades potents que els usuaris activen a tot el sistema, i el teu lloc les ha de respectar automàticament:
- Moviment reduït. Respecta la consulta de mitjans
prefers-reduced-motionper desactivar o suavitzar les animacions per als usuaris que experimenten nàusees o distracció amb el moviment. - Mode fosc i alt contrast. Dona suport a
prefers-color-schemei a l’Alt Contrast / Colors Forçats de Windows perquè la teva interfície es mantingui llegible sense lluitar contra la configuració de l’usuari. - Canvi de mida del text i zoom. Utilitza unitats relatives perquè l’escalat de text del navegador funcioni, en lloc de bloquejar les mides en píxels.
- Modes de lectura i eines de lectura. Les vistes de lectura del navegador i eines com Immersive Reader redueixen una pàgina al seu contingut essencial — cosa que funciona molt millor quan el teu HTML és semàntic i sense desordre.
Aquestes funcions no costen res addicional a l’usuari i molt poc a tu, però milloren dràsticament la comoditat per a un públic ampli, incloses persones sense discapacitats diagnosticades.
Eines de lectura i comprensió
Les eines de lectura serveixen persones amb dislèxia, TDAH, discapacitats cognitives o alfabetització limitada en l’idioma de la pàgina. Inclouen narradors de text a veu, regles de lectura, ressaltat de paraules, eines de resum i eines de traducció.
Perquè funcionin bé amb elles:
- Escriu en un llenguatge senzill i ben organitzat, amb encapçalaments descriptius i paràgrafs curts.
- Marca la pàgina perquè el contingut principal sigui clarament identificable i l’ordre de lectura sigui correcte.
- Evita transmetre significat només mitjançant el color, la disposició o les imatges — proporciona un equivalent textual.
- Assegura’t que l’idioma estigui declarat (atribut
lang) perquè la narració i la traducció utilitzin la pronunciació i les regles correctes.
Una bona estructura de contingut ajuda alhora cada eina d’aquest article, perquè totes parteixen del mateix marcatge subjacent.
Tecnologia assistiva genuïna enfront de superposicions d’accessibilitat
Aquesta és la distinció que més importa, i és on moltes organitzacions s’equivoquen.
La tecnologia assistiva genuïna — lectors de pantalla, ampliadors, accés per commutador, control per veu — s’executa al dispositiu de l’usuari, sota el control de l’usuari, i opera el teu lloc web mitjançant la seva semàntica i el seu suport de teclat. L’usuari ha passat anys configurant-la. La teva feina és simplement construir una pàgina que aquestes eines puguin entendre.
Les superposicions d’accessibilitat són scripts de tercers que afegeixes al teu propi lloc que prometen «fer-lo accessible» automàticament, normalment mitjançant un giny flotant. No són un substitut de la tecnologia assistiva, i no són una solució per a un lloc inaccessible. Heus aquí per què:
- No poden reparar el codi subjacent. Les superposicions s’asseuen a sobre de la pàgina; no poden inventar de manera fiable text alt que falta, arreglar estructures d’encapçalament trencades ni fer que un
<div>es comporti com un botó real a tots els lectors de pantalla. - Sovint entren en conflicte amb l’AT real. Molts usuaris de lectors de pantalla informen que les superposicions interfereixen amb les eines en què ja confien, fent de vegades els llocs més difícils d’utilitzar, no més fàcils.
- Creen una falsa sensació de conformitat. Instal·lar un giny no satisfà la WCAG 2.2, l’EAA ni l’ADA. S’han presentat demandes contra llocs que utilitzen superposicions precisament perquè les barreres subjacents es mantenien.
- No reflecteixen l’experiència viscuda. L’accessibilitat es jutja en última instància per les persones que utilitzen AT cada dia — per això fem auditories per part de persones amb discapacitat en lloc de confiar en les afirmacions d’un script.
El camí fiable és arreglar l’accessibilitat al codi i validar-la tant amb proves automatitzades com humanes. Expliquem aquesta filosofia més plenament a què significa l’accessibilitat digital veritable.
Un flux de treball pràctic per construir amb eines adaptatives
Construir per a la tecnologia assistiva no és un projecte únic; és un procés que encaixa en com ja lliures programari. Un enfocament sostenible normalment combina quatre coses:
- Escaneig automatitzat, d’hora i sovint. Eines com el programari d’escaneig d’accessibilitat detecten un gran volum de problemes a nivell de codi — etiquetes que falten, errors de contrast, ARIA trencat — abans que arribin a producció. Les comprovacions automatitzades són ràpides i repetibles, però només cobreixen part de la imatge.
- Proves manuals i amb tecnologia assistiva. Els problemes que més afecten els usuaris reals — ordre de focus confús, anuncis poc clars, ginys personalitzats inutilitzables — requereixen una persona. La nostra guia d’auditories manuals d’accessibilitat descriu com això complementa l’automatització.
- Incorporar l’accessibilitat al teu equip. Tractar l’accessibilitat com una disciplina contínua, amb el suport de la millora del procés d’accessibilitat, evita la regressió lenta que es produeix quan les correccions són puntuals.
- Les eines adequades per a la teva pila. L’eina d’accessibilitat de QualiBooth reuneix escaneig, monitoratge i informes, mentre que Agora i la nostra edició comunitària ofereixen punts d’entrada per a equips en diferents etapes de maduresa.
Si ets nou en la terminologia d’aquest article, el glossari d’accessibilitat és un company útil a mesura que poses en pràctica aquestes pràctiques.
On encaixa QualiBooth
QualiBooth identifica problemes al teu lloc web existent i també pot escanejar pàgines abans que es publiquin, perquè els clients que utilitzen qualsevol eina adaptativa tinguin una experiència fluida que augmenti la usabilitat i la fidelitat a la marca. Combinem la detecció automatitzada amb l’avaluació per part de provadors experimentats i persones amb discapacitat, i després ajudem el teu equip a convertir les troballes en correccions duradores — mai una superposició que emmascari el problema.
L’objectiu és senzill: un lloc web que funcioni amb les eines en què els teus usuaris ja confien, en els seus termes, cada cop que el visiten.
A punt per veure com es comporta el teu lloc per a la tecnologia assistiva real? Executa un escaneig d’accessibilitat gratuït per detectar guanys ràpids, sol·licita una demostració per veure QualiBooth en acció, o parla amb el nostre equip sobre una col·laboració de consultoria d’accessibilitat a mida.
Dissenya per a tecnologia assistiva real, no per a superposicions