Com neixen les normes i com vigilar l'horitzó

Parlar del futur de l'accessibilitat exigeix primer saber llegir el present: quin document és una norma, quin és un esborrany, quin una nota informativa i quin una opinió en un blog. Bona part dels errors que veuràs en ofertes, plecs i formacions neixen de confondre aquestes categories. Aquesta lliçó et dona dues eines que utilitzaràs a la resta del curs: com maduren les especificacions al W3C i les normes a Europa, i un mètode senzill per vigilar l'horitzó i convertir tendències en decisions per a la teva organització.

Com madura una especificació al W3C

El W3C publica els seus documents tècnics a l'adreça w3.org/TR/ i cadascun porta, just després del resum, un apartat titulat Status of This Document (estat del document). Allà s'indica la fase, el grup responsable i la data. És la primera línia que ha de llegir un expert abans de citar res. Les fases de l'anomenat procés de recomanació són:

1. Esborrany de l'editor (Editor's Draft): la versió de treball diària, normalment en un repositori públic. Serveix per seguir els debats, mai per citar.
2. Esborrany de treball (Working Draft): publicació oficial a /TR/ per rebre comentaris. El primer s'anomena First Public Working Draft. Pot canviar en profunditat o abandonar-se. WCAG 3.0 i WAI-ARIA (s'obre en una finestra nova) 1.3 són en aquesta fase.
3. Recomanació candidata (Candidate Recommendation): el grup considera el contingut estable i busca experiència d'implementació real (navegadors, eines) per demostrar que es pot aplicar.
4. Recomanació proposada (Proposed Recommendation): revisió final pels membres del W3C.
5. Recomanació del W3C (W3C Recommendation): l'estàndard publicat. És el que poden citar les lleis i les normes tècniques. WCAG 2.2 i WAI-ARIA 1.2 són aquí.

Hi ha a més una via paral·lela, la de les notes de grup (Group Note): documents informatius que no són normatius, com WCAG2ICT, els requisits d'usuari de realitat estesa (XAUR) o la guia d'accessibilitat cognitiva Making Content Usable. Són molt útils per orientar la feina, però no estableixen requisits de conformitat. I els informes dels grups comunitaris (Community Groups), oberts a tothom, no són estàndards del W3C encara que estiguin allotjats al seu web.

Dins de la iniciativa WAI, diversos grups es reparteixen la feina: el de pautes d'accessibilitat (WCAG i els seus documents de suport), el d'ARIA (WAI-ARIA i la guia de patrons APG (s'obre en una finestra nova)), el d'arquitectures de plataformes accessibles (que revisa altres especificacions del W3C i elabora documents com XAUR o WAI-Adapt) i el d'educació i divulgació. Saber quin grup signa un document t'ajuda a saber on seguir-lo i on comentar-lo.

Com es converteix un estàndard en obligació a Europa

El W3C no legisla. A la Unió Europea, el pont entre l'estàndard tècnic i l'obligació legal el construeix el sistema de normalització regulat pel Reglament (UE) núm. 1025/2012. La seqüència és sempre la mateixa:

1. Una directiva fixa requisits d'accessibilitat funcionals (per exemple, l'annex I de la Directiva (UE) 2019/882 (PDF, s'obre en una finestra nova)).
2. La Comissió adreça una petició de normalització als organismes europeus CEN, CENELEC i ETSI.
3. Aquests organismes elaboren una norma europea (EN), com l'EN 301 549 (PDF, s'obre en una finestra nova), amb requisits tècnics verificables. Per al web, l'EN incorpora les WCAG per referència.
4. La Comissió publica la referència de la norma al Diari Oficial de la UE com a norma harmonitzada, cosa que atorga presumpció de conformitat a qui la compleix.
5. Els organismes nacionals l'adopten sense canvis. A Espanya, UNE la publica com a UNE-EN 301549, i el RD 1112/2018 (PDF, s'obre en una finestra nova) remet a les normes harmonitzades.

Aquest circuit explica els desfasaments que veuràs una vegada i una altra: WCAG 2.2 és recomanació des de l'octubre del 2023, però la versió harmonitzada de l'EN 301 549 continua sent la v3.2.1 del 2021, amb WCAG 2.1 (la v4.1.1, alineada amb WCAG 2.2, es va publicar el setembre del 2026 i n'espera la citació); i l'Acta Europea d'Accessibilitat s'aplica des del juny del 2025 sense que les seves normes harmonitzades s'hagin citat encara al Diari Oficial, com veurem a la lliçó sobre l'evolució normativa. Entre que el W3C publica i la llei exigeix solen passar anys.

Vigilar l'horitzó: fonts i rutina

L'expert en accessibilitat és, per a la seva organització, el radar que avisa del que ve. Perquè aquest radar sigui fiable convé separar tres tipus de fonts:

• Primàries normatives: pàgines d'estat i anuncis de la WAI, publicacions d'ETSI, Diari Oficial de la UE, EUR-Lex, BOE i el portal d'administració electrònica, on es publiquen els informes de l'Observatori d'Accessibilitat Web.
• Primàries tècniques: documentació de navegadors i plataformes (MDN, notes de versió de Chrome, Firefox i Safari, guies d'accessibilitat d'Apple i Android) i les notes de versió dels lectors de pantalla, que indiquen quan una propietat nova comença a funcionar de debò.
• Secundàries: estudis com el WebAIM Million, associacions com el CERMI i l'ONCE, comunitats professionals. Aporten context i dades, però es contrasten amb les primàries.

Una rutina realista: una revisió mensual de 30 minuts de les fonts primàries, una fitxa per cada novetat rellevant i una revisió trimestral del radar amb l'equip. La fitxa de tendència té sis camps: què és, estat formal (amb enllaç a la font), què canvia per a nosaltres, a qui afecta (disseny, desenvolupament, continguts, compres, jurídic), horitzó temporal i acció decidida.

Del radar a la decisió

Una tendència no és una tasca. Per traduir-la en decisions, classifica cada novetat en un dels quatre anells, inspirats en els radars tecnològics que utilitzen molts equips de desenvolupament:

• Adoptar: estable, amb suport suficient i benefici clar. S'incorpora als estàndards interns, les plantilles i els plecs. Exemples: auditar amb WCAG 2.2 AA, utilitzar <dialog> amb showModal(), :focus-visible.
• Provar: prometedora, amb suport parcial. S'utilitza en pilots amb alternativa i proves amb tecnologies de suport. Exemples: propietats noves d'ARIA 1.3 amb suport desigual, remediació assistida per IA al repositori amb revisió humana.
• Vigilar: rellevant, però immadura o sense forma definitiva. Se segueix i es forma l'equip, sense exigir-la. Exemple: el model de conformitat de WCAG 3.0.
• Evitar: desaconsellada per l'evidència disponible. Exemple: substituir la correcció del codi per un overlay.

El radar també serveix com a eina formativa: explicar per què una cosa és a «Vigilar» i no a «Adoptar» ensenya l'equip a distingir esborrany de norma millor que qualsevol definició. Per aprofundir en el procés, consulta la visió general d'estàndards de la WAI i el document de procés del W3C.

Resum

• Al W3C, un document passa d'esborrany de l'editor a esborrany de treball, recomanació candidata, recomanació proposada i recomanació; les notes de grup informen però no obliguen.
• A Europa, una petició de normalització dona lloc a una EN; la seva publicació al Diari Oficial com a norma harmonitzada atorga presumpció de conformitat, i la llei nacional la fa exigible.
• Entre la publicació d'un estàndard i la seva exigència legal passen anys: d'aquí els desfasaments entre WCAG 2.2, l'EN 301 549 i l'Acta Europea d'Accessibilitat.
• Vigila l'horitzó amb fonts primàries, fitxes de tendència i un radar de quatre anells: adoptar, provar, vigilar i evitar.