Al llarg d'aquest mòdul hem anat deixant avisos: que posar onClick en un <article> funciona amb el ratolí però no amb el teclat, que el color no pot ser l'únic portador d'informació, que un missatge d'error vermell a sota d'un camp no n'hi ha prou perquè un lector de pantalla el relacioni amb ell. Ha arribat el moment de saldar tots aquests deutes alhora. L'accessibilitat no és una capa que s'afegeix al final ni una llista d'atributs exòtics: és, en un 90 %, escriure l'HTML correcte i no trencar el que el navegador ja et dona fet. En aquesta lliçó revisaràs tot el que s'ha construït al mòdul —els gestors d'esdeveniments, les llistes, el formulari de reserva— i el deixaràs usable amb teclat i amb lector de pantalla, aprenent pel camí quins atributs ARIA existeixen, quan fer-los servir i, més important, quan no fer-los servir.

1. Per què importa l'accessibilitat
2. Les quatre idees de les WCAG
3. HTML semàntic primer
4. El cas de la targeta prémable
5. Etiquetes i missatges d'error en formularis
6. Navegació per teclat i gestió del focus
7. Regions actives: anunciar el que canvia
8. Imatges, icones i el problema del color
9. Atributs ARIA d'ús comú
10. Com comprovar que funciona

Hi ha tres raons, i totes tres són bones.

Persones. Al voltant del 15 % de la població mundial viu amb alguna discapacitat. No parlem només de ceguesa total: hi ha baixa visió, daltonisme, discapacitat motriu que impedeix fer servir un ratolí amb precisió, discapacitat cognitiva, sordesa. I hi ha discapacitats temporals (un braç escaiolat) i situacionals (fer servir el mòbil a ple sol, amb una mà i amb pressa). A CicloUrbano, algú pot estar consultant el catàleg amb una mà mentre subjecta la bici amb l'altra.

Obligació legal. A la Unió Europea, la Directiva 2016/2102 obliga que els llocs i les aplicacions del sector públic siguin accessibles, i l'Acta Europea d'Accessibilitat estén requisits similars a nombrosos serveis privats, inclòs el comerç electrònic. A Espanya, el Reial Decret 1112/2018 desenvolupa aquestes obligacions. Als Estats Units, l'ADA s'aplica de manera consolidada als llocs web. Traduït: per a molts projectes, no és opcional.

Qualitat general. Una interfície accessible és millor per a tothom. Els subtítols serveixen en un vagó sorollós; un bon contrast ajuda al sol; les dreceres de teclat les agraeix qui introdueix cent reserves al dia; i el marcatge semàntic millora el SEO i facilita les proves automatitzades, com comprovaràs al Mòdul 9.

I hi ha un argument pràctic decisiu: arreglar l'accessibilitat al final costa cinc vegades més que fer-ho bé des del principi. Canviar un <div onClick> per un <button> mentre escrius el component costa zero; fer-ho sis mesos després implica refer estils, revisar la maquetació i tornar a provar-ho tot.

Les WCAG (Web Content Accessibility Guidelines) són l'estàndard internacional. Darrere de les seves desenes de criteris només hi ha quatre principis, que en anglès formen l'acrònim POUR:

Les WCAG defineixen a més tres nivells de conformitat: A (mínim), AA (el que exigeixen gairebé totes les normatives) i AAA (molt exigent, poc freqüent). L'objectiu raonable de qualsevol projecte és el nivell AA.

La primera regla de l'accessibilitat —i la que més problemes evita— és aquesta: fes servir l'element HTML que correspon al que estàs fent.

Un <button> no és un <div> amb estils de botó. Un <button> porta de sèrie:

Cinc coses que cal reconstruir, i n'hi ha prou d'oblidar-ne una per deixar algú fora.

Sobre els encapçalaments hi ha un matís que es passa per alt: el seu nivell comunica jerarquia, no mida. Qui navega amb lector de pantalla salta d'encapçalament en encapçalament per fer-se un mapa de la pàgina; si tries un <h4> perquè «es veu més petit», aquest mapa queda trencat. La mida es decideix al CSS.

L'estructura de CicloUrbano, amb la semàntica al seu lloc:

Aquests elements creen regions que les tecnologies d'assistència permeten saltar directament: «anar al contingut principal», «anar a la navegació». Amb <div> no existeix aquesta possibilitat.

A la lliçó 03-01 vam posar onClick a l'<article> de TargetaBicicleta i vam deixar anotat el deute. Anem a saldar-lo.

El problema, en concret: amb un <article onClick>, qui navega amb teclat mai no arriba a la targeta —no és enfocable— i qui fa servir lector de pantalla sent «article», sense cap pista que es pugui prémer.

Només el títol és prémable, i és un <button> de veritat. Amb estils es pot fer que sembli un enllaç o un títol normal. Aquesta és l'opció recomanada: zero atributs ARIA, zero gestors de teclat, tot funciona.

Si el disseny exigeix que tota la targeta sigui una àrea prémable, cal reconstruir a mà el que un botó dona gratis:

Quatre afegits per igualar un <button>, i encara queda un problema: si dins de la targeta hi ha un altre botó («Reservar»), acabes amb un control dins d'un altre control, una cosa que cap tecnologia d'assistència interpreta bé. Per això la solució 1 és preferible gairebé sempre.

La regla: si alguna cosa es pot prémer, que sigui un <button> o un <a>. Reconstruir el comportament només es justifica quan no hi ha alternativa.

Aquí tanquem el que vam prometre a la lliçó anterior. Un formulari accessible necessita tres coses: etiquetes associades, textos d'ajuda vinculats i errors anunciats.

Recorda de la lliçó 01-04: a JSX s'escriu htmlFor, no for, perquè for és una paraula reservada de JavaScript.

Què es guanya amb l'associació correcta:

• En prémer el text de l'etiqueta, el camp rep el focus. L'àrea prémable creix, la qual cosa ajuda especialment al mòbil i a qui té poca precisió motriu.
• El lector de pantalla anuncia «Durada (hores), quadre d'edició numèric» en arribar al camp. Sense etiqueta associada, només diu «quadre d'edició», i la persona no sap què escriure.

En llistes generades amb map, compte amb els id duplicats: han de ser únics a tota la pàgina. Genera'ls a partir de la dada: id={hores-${bicicleta.id}}.

Quan un camp necessita una explicació addicional, es vincula amb aria-describedby, que accepta un o diversos id separats per espais:

El lector de pantalla llegeix primer l'etiqueta i després la descripció. La diferència amb aria-label és important: l'etiqueta diu què és el camp; la descripció aporta detalls addicionals.

I aquí hi ha la peça que tancava la lliçó 03-05: un paràgraf vermell a sota del camp és invisible per a un lector de pantalla si no està associat al camp i no s'anuncia en aparèixer.

Els quatre mecanismes, un a un:

Fixa't que aria-describedby canvia segons hi hagi error o no, encadenant els dos id. Així el camp conserva la seva ajuda i hi suma l'error quan existeix.

I un detall que ara encaixa: a la lliçó 03-05 vam recomanar no deshabilitar el botó d'enviament. Un dels motius és d'accessibilitat: els elements amb disabled no reben focus, així que qui navega amb teclat pot arribar al final del formulari, no trobar el botó i no entendre per què. És millor un botó actiu que, en prémer-lo, expliqui què falta.

Tota la funcionalitat s'ha de poder fer servir només amb el teclat. Aquestes són les tecles que la gent espera:

L'ordre de tabulació és l'ordre del marcatge, no el visual. Si amb CSS col·loques un element a l'esquerra però a l'HTML és al final, el focus hi anirà en últim lloc i qui navegui amb teclat es desorientarà. La solució no és tocar tabIndex: és posar el marcatge en l'ordre lògic i maquetar amb order de flexbox o grid només quan no trenqui el sentit.

Els elements interactius natius —<button>, <a href>, <input>, <select>, <textarea>— ja són enfocables: no els posis tabIndex.

L'error més estès i més perjudicial:

Eliminar el contorn de focus deixa qui navega amb teclat literalment a les fosques: no sap on és. Si el contorn per defecte no encaixa amb el teu disseny, substitueix-lo, no l'eliminis:

:focus-visible és la pseudoclasse moderna que mostra l'indicador quan el navegador estima que cal —navegació amb teclat— i l'omet després d'un clic de ratolí. És el millor de tots dos mons.

A la lliçó 03-01 ja vas afegir Escape al SelectorTipus per tornar al filtre «Totes». El patró general:

Es fa servir sempre esdeveniment.key amb el nom de la tecla ('Enter', 'Escape', 'ArrowRight', ' ' per a l'espai). esdeveniment.keyCode està obsolet des de fa anys: no el facis servir.

Quan alguna cosa canvia a la pantalla sense que la persona hagi mogut el focus —«Reserva creada», «3 bicicletes trobades», «Desant…»—, un lector de pantalla no diu res, perquè només llegeix el que hi ha sota el focus. La solució són les regions actives (live regions).

El detall que gairebé tothom es salta: la regió ha d'existir al DOM des del principi, encara que estigui buida. Si l'element amb aria-live apareix alhora que el seu contingut, molts lectors de pantalla no l'anuncien, perquè no estaven observant aquell node. Renderitza sempre el contenidor i canvia només el seu text.

A CicloUrbano hi ha tres llocs on una regió activa aporta de veritat:

1. Confirmació de reserva creada, amb role="status".
2. Recompte de resultats del catàleg en canviar el filtre: «S'han trobat 3 bicicletes.»
3. Missatges d'error del formulari, amb role="alert".

Tot <img> necessita un atribut alt. La pregunta clau és: si aquesta imatge no es carregués, quin text transmetria la mateixa informació?

alt="" i l'absència d'alt no són el mateix: el primer diu «aquesta imatge no aporta informació, ignora-la»; el segon deixa el lector de pantalla endevinant, i el més habitual és que acabi llegint la URL en veu alta.

I no comencis el text amb «Imatge de…»: el lector ja anuncia que és una imatge.

Les icones que són només decoració s'han d'ocultar; les que són la informació necessiten una alternativa textual:

Sense l'aria-label, el segon botó s'anuncia com a «botó», sense més. Un formulari ple de botons així és inutilitzable.

Aquest és el criteri 1.4.1 de les WCAG, i afecta directament EtiquetaEstat. Aproximadament el 8 % dels homes té alguna forma de daltonisme; per a molts d'ells, el verd de «disponible» i el vermell de «manteniment» són pràcticament el mateix to.

La bona notícia és que el nostre component ja ho feia bé des de la lliçó 03-02: mostra el text de l'estat a més del color. El deixem rodó:

Tres canals independents: color per a qui el distingeix, símbol per a qui no, i text per a tothom, inclòs el lector de pantalla.

Les WCAG nivell AA exigeixen un contrast mínim de 4,5:1 per al text normal i 3:1 per al text gran (a partir de 18,66 px en negreta o 24 px normal). El verd de marca de CicloUrbano, #12805c, sobre blanc arriba aproximadament a 4,8:1, així que compleix. Qualsevol comprovador de contrast en línia o el panell d'accessibilitat del navegador et dona la dada en un segon.

ARIA (Accessible Rich Internet Applications) és un conjunt d'atributs que afegeixen semàntica quan l'HTML no hi arriba. Són un complement, no un substitut.

És la primera de les cinc regles oficials de l'ús d'ARIA, i significa exactament el que diu: un atribut ARIA mal posat és pitjor que no posar-lo, perquè menteix a la tecnologia d'assistència i aquesta es creu la mentida.

Aquest últim cas és especialment perjudicial: qui veu la pantalla llegeix «Reservar» i qui l'escolta sent «Cancel·lar». I qui fa servir control per veu dirà «prémer Reservar» i no passarà res, perquè per al sistema aquest botó es diu «Cancel·lar».

Les altres quatre regles, resumides:

1. Fes servir l'element HTML natiu abans que ARIA.
2. No canviïs la semàntica nativa: <h2 role="button"> és un disbarat.
3. Tot control ARIA ha de ser usable amb teclat.
4. No posis aria-hidden="true" en alguna cosa enfocable: crearies un element invisible per al lector però accessible amb Tab.

Guarda el ratolí i recorre la pantalla només amb el teclat. Comprova:

1. Puc arribar a tot? Cada botó, enllaç i camp ha de ser accessible.
2. Veig on soc? L'indicador de focus ha de ser visible en tot moment.
3. L'ordre té sentit? Ha de seguir l'ordre visual de lectura.
4. Puc activar-ho tot amb Enter o Espai?
5. Em quedo atrapat? Si el focus entra en alguna cosa i no en pot sortir amb Tab, hi ha una fallada greu.

A CicloUrbano el recorregut correcte és aquest:

Detecta en temps d'escriptura una bona part dels errors d'aquesta lliçó:

Avisa, entre altres coses, d'imatges sense alt, d'elements no interactius amb gestors de clic, d'etiquetes sense camp associat, de tabIndex positius i d'atributs ARIA no vàlids. En projectes creats amb les plantilles de React sol venir ja configurat.

Les eines de desenvolupament porten dues utilitats imprescindibles:

• Lighthouse (pestanya del mateix nom a Chrome i Edge): executa una auditoria automàtica i puntua l'accessibilitat, amb la llista de problemes detectats i com corregir-los.
• Arbre d'accessibilitat (dins de l'inspector d'elements): mostra com veu la pàgina una tecnologia d'assistència —el nom, el rol i l'estat de cada element—. És la manera més directa de comprovar si el teu aria-label fa efecte.

També existeixen extensions especialitzades com axe DevTools o WAVE, que donen informes més detallats.

Advertència important: les eines automàtiques detecten aproximadament entre el 30 % i el 40 % dels problemes reals. Poden dir-te que falta un alt, però no si el text que has escrit és útil; poden verificar el contrast, però no si l'ordre de focus té sentit. La prova amb Tab i, quan sigui possible, amb un lector de pantalla real (NVDA a Windows, VoiceOver a macOS i iOS, TalkBack a Android) continua sent insubstituïble.

Existeix a més la possibilitat d'automatitzar comprovacions d'accessibilitat a les proves, amb eines com jest-axe integrades a la bateria de proves del projecte. És una pràctica excel·lent i es menciona aquí perquè sàpigues que existeix; el terreny de les proves és el Mòdul 9.

• <div onClick> en lloc de <button>. No és enfocable, no respon al teclat i no s'anuncia com a control. És, de llarg, la fallada d'accessibilitat més comuna a React.
• outline: none sense substitut. Deixa qui navega amb teclat sense saber on és. Fes servir :focus-visible amb un contorn propi.
• tabIndex positiu. Trenca l'ordre de tabulació de tota la pàgina. Només 0 i -1.
• Posar tabIndex a elements que ja són enfocables. Un <button tabIndex={0}> és redundant i confús.
• Etiquetes sense associar. Un <p> a sobre del camp no és una etiqueta. <label htmlFor> amb l'id corresponent, i recorda que a JSX és htmlFor, no for.
• id duplicats en llistes generades amb map. Trenquen l'associació etiqueta-camp. Genera'ls a partir de l'id de la dada.
• Missatges d'error només visuals. Sense role="alert" no s'anuncien en aparèixer, i sense aria-describedby no es llegeixen en enfocar el camp.
• Una regió aria-live que apareix juntament amb el seu contingut. No s'anuncia. El contenidor ha d'estar sempre al DOM.
• aria-live="assertive" per a tot. Interromp constantment i acaba sent insuportable. Reserva el mode assertiu per al que és urgent.
• Imatges sense alt, o amb «imatge de…». Sense alt es llegeix la URL; el prefix és redundant perquè el lector ja anuncia que és una imatge.
• Botons amb només una icona i sense nom accessible. S'anuncien com a «botó» a seques. aria-label obligatori.
• Transmetre informació només amb color. Afegeix sempre text o un símbol.
• Encapçalaments triats per la seva mida. Trenquen el mapa de la pàgina. El nivell és jerarquia; la mida es decideix al CSS.
• ARIA redundant o contradictori. <button role="button"> sobra; una aria-label diferent del text visible és una fallada greu. No ARIA és millor que mal ARIA.
• Consell: prova amb Tab cada vegada que acabis un component. Dos minuts que estalvien auditories senceres.
• Consell: instal·la eslint-plugin-jsx-a11y el primer dia del projecte. Corregeix mentre escrius en lloc de al final.
• Consell: escriu el marcatge en l'ordre lògic de lectura i fes servir CSS per col·locar-lo, no tabIndex per reordenar-lo.

Aquest component té sis problemes d'accessibilitat. Identifica'ls, explica a qui afecta cadascun i escriu la versió corregida.

Pren el camp «Bicicleta» del FormulariReserva de la lliçó 03-05 i fes-lo completament accessible. Ha d'incloure:

• Etiqueta correctament associada.
• Un text d'ajuda vinculat: «Només es mostren les bicicletes disponibles ara mateix.»
• aria-invalid quan el camp tingui un error visible.
• El missatge d'error associat i anunciat en aparèixer.
• Un aria-describedby que combini ajuda i error quan tots dos existeixin.

Escriu també les classes CSS necessàries perquè l'estat d'error es distingeixi sense dependre del color.

Dissenya el recorregut de teclat complet de la pantalla principal de CicloUrbano i descriu-lo pas a pas. Després respon:

1. On col·locaries una regió aria-live i què anunciaria en cada cas?
2. Què hauria de passar en prémer Escape a cada zona de la pantalla?
3. Si la llista de bicicletes tingués cent targetes amb un botó cadascuna, quin problema de navegació apareixeria i com el resoldries sense trencar res?

Solució 1.

Els sis problemes:

I al CSS, outline: none sense substitut elimina l'indicador de focus.

La decisió de fons: s'ha eliminat l'onClick de la targeta sencera. L'àrea prémable són dos botons de veritat amb text descriptiu, així que no calen role, tabIndex, onKeyDown ni aria-label.

Solució 2.

Les tres senyals de l'estat d'error, independents entre si: la vora més gruixuda i el fons (perceptibles sense distingir el color), el símbol ⚠ i el text del missatge. I per al lector de pantalla, aria-invalid l'anuncia com a camp no vàlid, aria-describedby li associa ajuda i error, i role="alert" fa que el missatge es llegeixi tan bon punt apareix.

Solució 3.

Recorregut de teclat proposat:

1. Enllaç «Saltar al contingut», ocult fins a rebre focus, que porta directament al <main>. És el primer element de la pàgina i evita haver de recórrer tota la navegació a cada visita.
2. Capcalera: enllaços «Catàleg», «Estacions», «Les meves reserves», amb aria-current="page" a l'actiu.
3. SelectorTipus: els quatre botons de filtre, en ordre.
4. LlistaBicicletes: per cada targeta, el seu botó «Reservar».
5. FormulariReserva: bicicleta → data → hores → casella de condicions → botó «Crear reserva».
6. Peu de pàgina: els seus enllaços.

1. Regions aria-live: dues, totes dues presents al DOM des del primer render.

Els errors del formulari no necessiten una regió compartida: cada missatge ja porta el seu role="alert".

2. Comportament de Escape:

3. El problema de les cent targetes: per arribar al formulari caldria prémer Tab cent vegades. És una barrera real, i les solucions que no valen són tabIndex positius (trenquen tot l'ordre) o treure els botons del recorregut amb tabIndex={-1} (els faria inabastables). El que sí que funciona:

• Enllaços de salt abans i després de la llista: «Saltar la llista de bicicletes» / «Tornar al filtre», visibles només en rebre el focus.
• Encapçalaments i regions ben marcats, perquè qui fa servir lector de pantalla salti per estructura en lloc de per tabulació.
• Paginació o càrrega progressiva, que a més millora el rendiment i beneficia tothom.
• Un <section aria-labelledby> per a la llista, de manera que s'anunciï com a regió identificable i es pugui saltar d'una vegada.

Amb aquesta lliçó tanques el Mòdul 3 i saldes tots els deutes que va anar deixant pel camí. Saps per què l'accessibilitat importa —persones, obligació legal i qualitat general— i coneixes els quatre principis de les WCAG: perceptible, operable, comprensible i robust. Sobretot, has interioritzat la regla que resol la major part dels problemes abans que existeixin: fes servir l'element HTML correcte. Un <button> porta de sèrie el focus, el teclat, el rol i l'estat; un <div> amb onClick obliga a reconstruir cinc coses i n'hi ha prou d'oblidar-ne una per deixar algú fora.

Ho has aplicat a tot el que s'ha construït al mòdul: la targeta prémable de la lliçó 03-01 passa a tenir botons de veritat; el FormulariReserva associa cada <label htmlFor> al seu id, vincula l'ajuda amb aria-describedby, marca els camps amb aria-invalid i anuncia els missatges amb role="alert" —tancant exactament el que va quedar pendent a 03-05—; EtiquetaEstat transmet l'estat per tres canals independents, color, símbol i text, per no deixar fora qui no distingeix els colors; i una regió aria-live avisa del que canvia sense que ningú mogui el focus. Saps gestionar l'ordre de tabulació, quan fer servir tabIndex={0} i tabIndex={-1} i per què els valors positius estan prohibits, i que l'indicador de focus se substitueix amb :focus-visible però mai no s'elimina. Coneixes els atributs ARIA habituals i la regla que els governa: no ARIA és millor que mal ARIA. I saps comprovar-ho: amb Tab en dos minuts, amb eslint-plugin-jsx-a11y mentre escrius i amb Lighthouse i l'arbre d'accessibilitat del navegador, recordant que les eines automàtiques només detecten un terç dels problemes reals.

Fent balanç del mòdul complet: CicloUrbano ha deixat de mirar-se i ha començat a respondre. Els esdeveniments connecten la interfície amb la lògica, amb gestors ben anomenats, esdeveniments sintètics i propagació sota control. El renderitzat condicional fa que cada targeta mostri el que correspon al seu estat i que el catàleg sàpiga què dir quan no hi ha res. Les llistes amb map i claus estables han eliminat la repetició escrita a mà i han tancat el deute de la reconciliació. Els formularis controlats recullen dades amb l'estat com a única font de veritat, la validació els filtra amb regles de negoci de veritat, i l'accessibilitat fa que tot això arribi a qualsevol persona.

Però queda un límit que hem fregat a cada lliçó sense poder-lo travessar. El SelectorTipus guarda el tipus triat en el seu propi estat i avisa el pare, però continua sense filtrar la llista, perquè LlistaBicicletes no pot veure aquest estat. TargetaBicicleta avisa amb alSeleccionar i App es limita a fer un console.log, perquè no hi ha on guardar la bicicleta seleccionada. L'estat és privat de cada component, i això és precisament el que impedeix que les peces treballin juntes. La solució té nom i obre el Mòdul 4: Conceptes Avançats de Components. La propera lliçó és Elevar l'Estat, i amb ella el catàleg de CicloUrbano filtrarà de veritat.