Cómo nacen las normas y cómo vigilar el horizonte

Hablar del futuro de la accesibilidad exige primero saber leer el presente: qué documento es una norma, cuál es un borrador, cuál una nota informativa y cuál una opinión en un blog. Buena parte de los errores que verás en ofertas, pliegos y formaciones nacen de confundir esas categorías. Esta lección te da dos herramientas que usarás en el resto del curso: cómo maduran las especificaciones en el W3C y las normas en Europa, y un método sencillo para vigilar el horizonte y convertir tendencias en decisiones para tu organización.

Cómo madura una especificación en el W3C

El W3C publica sus documentos técnicos en la dirección w3.org/TR/ y cada uno lleva, justo después del resumen, un apartado titulado Status of This Document (estado del documento). Ahí se indica la fase, el grupo responsable y la fecha. Es la primera línea que debe leer un experto antes de citar nada. Las fases del llamado proceso de recomendación son:

1. Borrador del editor (Editor's Draft): la versión de trabajo diaria, normalmente en un repositorio público. Sirve para seguir los debates, nunca para citar.
2. Borrador de trabajo (Working Draft): publicación oficial en /TR/ para recibir comentarios. El primero se llama First Public Working Draft. Puede cambiar en profundidad o abandonarse. WCAG 3.0 y WAI-ARIA (se abre en una ventana nueva) 1.3 están en esta fase.
3. Recomendación candidata (Candidate Recommendation): el grupo considera el contenido estable y busca experiencia de implementación real (navegadores, herramientas) para demostrar que se puede aplicar.
4. Recomendación propuesta (Proposed Recommendation): revisión final por los miembros del W3C.
5. Recomendación del W3C (W3C Recommendation): el estándar publicado. Es lo que pueden citar leyes y normas técnicas. WCAG 2.2 y WAI-ARIA 1.2 están aquí.

Existe además una vía paralela, la de las notas de grupo (Group Note): documentos informativos que no son normativos, como WCAG2ICT, los requisitos de usuario de realidad extendida (XAUR) o la guía de accesibilidad cognitiva Making Content Usable. Son muy útiles para orientar el trabajo, pero no establecen requisitos de conformidad. Y los informes de los grupos comunitarios (Community Groups), abiertos a cualquiera, no son estándares del W3C aunque estén alojados en su web.

Dentro de la iniciativa WAI, varios grupos se reparten el trabajo: el de pautas de accesibilidad (WCAG y sus documentos de apoyo), el de ARIA (WAI-ARIA y la guía de patrones APG (se abre en una ventana nueva)), el de arquitecturas de plataformas accesibles (que revisa otras especificaciones del W3C y elabora documentos como XAUR o WAI-Adapt) y el de educación y divulgación. Saber qué grupo firma un documento te ayuda a saber dónde seguirlo y dónde comentar.

Cómo se convierte un estándar en obligación en Europa

El W3C no legisla. En la Unión Europea, el puente entre el estándar técnico y la obligación legal lo construye el sistema de normalización regulado por el Reglamento (UE) n.º 1025/2012. La secuencia es siempre la misma:

1. Una directiva fija requisitos de accesibilidad funcionales (por ejemplo, el anexo I de la Directiva (UE) 2019/882 (PDF, se abre en una ventana nueva)).
2. La Comisión dirige una petición de normalización a los organismos europeos CEN, CENELEC y ETSI.
3. Estos elaboran una norma europea (EN), como la EN 301 549 (PDF, se abre en una ventana nueva), con requisitos técnicos verificables. Para la web, la EN incorpora las WCAG por referencia.
4. La Comisión publica la referencia de la norma en el Diario Oficial de la UE como norma armonizada, lo que otorga presunción de conformidad a quien la cumple.
5. Los organismos nacionales la adoptan sin cambios. En España, UNE la publica como UNE-EN 301549, y el RD 1112/2018 (PDF, se abre en una ventana nueva) remite a las normas armonizadas.

Este circuito explica los desfases que verás una y otra vez: WCAG 2.2 es recomendación desde octubre de 2023, pero la versión armonizada de la EN 301 549 sigue siendo la v3.2.1 de 2021, con WCAG 2.1 (la v4.1.1, alineada con WCAG 2.2, se publicó en septiembre de 2026 y espera su cita); y el Acta Europea de Accesibilidad se aplica desde junio de 2025 sin que sus normas armonizadas se hayan citado todavía en el Diario Oficial, como veremos en la lección sobre evolución normativa. Entre que el W3C publica y la ley exige suelen pasar años.

Vigilar el horizonte: fuentes y rutina

El experto en accesibilidad es, para su organización, el radar que avisa de lo que viene. Para que ese radar sea fiable conviene separar tres tipos de fuentes:

• Primarias normativas: páginas de estado y anuncios de la WAI, publicaciones de ETSI, Diario Oficial de la UE, EUR-Lex, BOE y el portal de administración electrónica, donde se publican los informes del Observatorio de Accesibilidad Web.
• Primarias técnicas: documentación de navegadores y plataformas (MDN, notas de versión de Chrome, Firefox y Safari, guías de accesibilidad de Apple y Android) y las notas de versión de los lectores de pantalla, que indican cuándo una propiedad nueva empieza a funcionar de verdad.
• Secundarias: estudios como el WebAIM Million, asociaciones como CERMI y ONCE, comunidades profesionales. Aportan contexto y datos, pero se contrastan con las primarias.

Una rutina realista: una revisión mensual de 30 minutos de las fuentes primarias, una ficha por cada novedad relevante y una revisión trimestral del radar con el equipo. La ficha de tendencia tiene seis campos: qué es, estado formal (con enlace a la fuente), qué cambia para nosotros, a quién afecta (diseño, desarrollo, contenidos, compras, jurídico), horizonte temporal y acción decidida.

Del radar a la decisión

Una tendencia no es una tarea. Para traducirla en decisiones, clasifica cada novedad en uno de cuatro anillos, inspirados en los radares tecnológicos que usan muchos equipos de desarrollo:

• Adoptar: estable, con soporte suficiente y beneficio claro. Se incorpora a estándares internos, plantillas y pliegos. Ejemplos: auditar con WCAG 2.2 AA, usar <dialog> con showModal(), :focus-visible.
• Probar: prometedora, con soporte parcial. Se usa en pilotos con alternativa y pruebas con tecnologías de apoyo. Ejemplos: propiedades nuevas de ARIA 1.3 con soporte desigual, remediación asistida por IA en el repositorio con revisión humana.
• Vigilar: relevante, pero inmadura o sin forma definitiva. Se sigue y se forma al equipo, sin exigirla. Ejemplo: el modelo de conformidad de WCAG 3.0.
• Evitar: desaconsejada por la evidencia disponible. Ejemplo: sustituir la corrección del código por un overlay.

El radar también sirve como herramienta formativa: explicar por qué algo está en «Vigilar» y no en «Adoptar» enseña al equipo a distinguir borrador de norma mejor que cualquier definición. Para profundizar en el proceso, consulta la visión general de estándares de la WAI y el documento de proceso del W3C.

Resumen

• En el W3C, un documento pasa de borrador del editor a borrador de trabajo, recomendación candidata, recomendación propuesta y recomendación; las notas de grupo informan pero no obligan.
• En Europa, una petición de normalización da lugar a una EN; su publicación en el Diario Oficial como norma armonizada otorga presunción de conformidad, y la ley nacional la hace exigible.
• Entre la publicación de un estándar y su exigencia legal pasan años: de ahí los desfases entre WCAG 2.2, la EN 301 549 y el Acta Europea de Accesibilidad.
• Vigila el horizonte con fuentes primarias, fichas de tendencia y un radar de cuatro anillos: adoptar, probar, vigilar y evitar.