Llegas a la última lección del curso. Has recorrido un camino largo: de no saber qué era la accesibilidad a construir, verificar y mantener una plataforma —Cursalia— accesible, dinámica, aplicativa y multilingüe. Antes de cerrar, conviene levantar la vista del código y mirar el horizonte: ¿hacia dónde evoluciona todo esto? El estándar cambia (WCAG 3.0 asoma), la ley aprieta (la European Accessibility Act ya está en vigor), la inteligencia artificial entra en escena con sus promesas y sus riesgos, y la accesibilidad se desborda más allá de la web hacia el móvil, la voz y la realidad extendida. Esta lección te da un mapa de ese futuro para que no te pille desprevenido, con una advertencia importante: el panorama normativo y técnico evoluciona deprisa; lo que aquí se cuenta es una foto de 2026 y debes contrastarlo siempre con fuentes actualizadas y con profesionales. Y al final, cerraremos juntos el viaje completo.

1. WCAG 3.0 (Silver): un nuevo modelo, todavía en desarrollo
2. La evolución de ARIA
3. El empuje legal como motor de mercado
4. Inteligencia artificial: el arma de doble filo
5. Accesibilidad más allá de la web
6. Personalización y preferencias del usuario
7. El cambio cultural: "shift-left"
8. Una advertencia sobre un terreno en movimiento
9. Errores comunes y consejos
10. Ejercicios
11. Cierre del curso

A lo largo del curso has trabajado con WCAG 2.2, el estándar vigente, con su estructura de criterios superables (A / AA / AAA) que veías como requisitos en el Módulo 3. En el horizonte está WCAG 3.0, cuyo nombre en clave es "Silver". Es un rediseño profundo, no una simple actualización de la lista de criterios. Lo más importante que debes saber:

WCAG 3.0 está en desarrollo y NO reemplaza a WCAG 2.2. Es un borrador de trabajo del W3C; su publicación como estándar recomendado está a años vista. Hoy, y durante bastante tiempo, tu referencia sigue siendo WCAG 2.2. WCAG 3.0 es hacia dónde miramos, no lo que aplicamos aún.

Qué se propone cambiar respecto a 2.x:

La idea de la puntuación graduada es superar el "todo o nada". Con 2.2, un solo criterio incumplido tumba la conformidad AA de una página entera, aunque el otro 99% sea impecable. El modelo de 3.0 busca reflejar mejor la experiencia real: cuánto de accesible es algo, no solo si pasa o no pasa un umbral. Es un cambio de filosofía que encaja con lo que aprendiste en el Módulo 6 sobre priorizar por impacto real en el usuario, no por número de errores.

ARIA, que dominaste en los Módulos 4 y 5, también evoluciona. Es una especificación viva que se amplía para cubrir patrones nuevos y afinar los existentes. Dos frentes a seguir:

• Nuevos roles y atributos: se añaden a medida que aparecen patrones de interfaz que la semántica HTML nativa no cubre. La ARIA Authoring Practices Guide (APG), tu "contrato de comportamiento" del Módulo 5, se actualiza en paralelo.
• La regla de oro no cambia: "no ARIA es mejor que mal ARIA". Cuanto más capaz se vuelve el HTML nativo (por ejemplo, elementos como <dialog> que ya usaste, o los popover y controles nativos emergentes), menos ARIA manual necesitas. La tendencia de fondo es que la plataforma web absorba patrones que antes exigían ARIA a mano, reduciendo la superficie de error.

La lección práctica: prioriza siempre el elemento HTML nativo; recurre a ARIA solo cuando no exista una alternativa nativa, y vigila si un patrón que hoy programas a mano pasa a estar soportado de forma nativa.

La accesibilidad ha dejado de ser "una buena práctica opcional" para convertirse en obligación legal en cada vez más territorios, y eso es, probablemente, el mayor motor de cambio del mercado. El hito reciente más relevante en Europa:

La European Accessibility Act (EAA) —Directiva (UE) 2019/882— es aplicable desde junio de 2025. Obliga a que numerosos productos y servicios digitales (comercio electrónico, banca, transporte, e-books, y servicios en línea en general) cumplan requisitos de accesibilidad para poder venderse en la UE.

Consecuencias prácticas que ya notas:

• La accesibilidad pasa de "lo hacemos si hay tiempo" a requisito para operar en un mercado. Recuerda del Módulo 6 que un comprador (una universidad que contrata Cursalia) exige un ACR/VPAT: eso se generaliza y se vuelve exigible por ley.
• Aumenta la demanda de perfiles con conocimientos de accesibilidad —justo lo que has adquirido en este curso.
• Junto a la EAA conviven otras normativas (la norma europea EN 301 549, la Sección 508 en EE. UU., leyes nacionales…). El detalle concreto varía por jurisdicción y cambia: verifica siempre la que te aplica.

El mensaje: la accesibilidad es hoy también una cuestión de cumplimiento y negocio, no solo de ética. Ambas cosas empujan en la misma dirección.

La IA es la tendencia más comentada y la más malinterpretada en accesibilidad. Tiene un enorme potencial y unos riesgos igual de reales. La clave es entender dónde ayuda y dónde engaña.

La regla de oro con la IA en accesibilidad es la misma que aprendiste en el Módulo 6 sobre las herramientas automáticas: son un punto de partida, nunca la sentencia. Un alt generado por IA que dice "una persona sentada frente a un ordenador" puede ser correcto y a la vez inútil, si el propósito de esa imagen en Cursalia era mostrar "estudiante completando el cuestionario final del curso". La IA no conoce la intención; tú sí. Y sobre todo:

La IA no reemplaza las pruebas con usuarios reales (Módulo 6, 06-03). Ninguna herramienta, por inteligente que sea, te dirá lo que te dijo Marta al no oír su mensaje de matrícula. Usa la IA para acelerar el trabajo repetitivo y revisa siempre su salida con criterio humano y con usuarios.

Los overlays merecen una advertencia aparte: los widgets que prometen "cumplimiento de accesibilidad con una línea de código" son ampliamente rechazados por la comunidad de personas con discapacidad, porque a menudo interfieren con las tecnologías de asistencia que el usuario ya tiene configuradas. No hay atajos: la accesibilidad se construye en el producto, no se pega por encima.

Todo lo que has aprendido —semántica, foco, alternativas textuales, teclado— trasciende el navegador. El futuro es multi-plataforma:

• Apps móviles y nativas: iOS y Android tienen sus propias APIs de accesibilidad (VoiceOver, TalkBack) y sus guías. Los principios POUR del Módulo 3 son los mismos; cambian las herramientas.
• Interfaces de voz (asistentes tipo altavoz inteligente): sin pantalla, la accesibilidad es toda la interacción. Plantean retos nuevos para personas sordas (Diego) o con dificultades de habla.
• XR / AR / VR (realidad extendida): entornos inmersivos donde falta casi todo el vocabulario de accesibilidad. ¿Cómo navega Marta un espacio 3D? ¿Cómo recibe Lucía subtítulos espaciales? Es una frontera abierta, con estándares aún incipientes.

El patrón se repite: los principios (perceptible, operable, comprensible, robusto) permanecen; las técnicas se reinventan para cada medio. Quien entiende los principios —tú, ahora— se adapta a cualquier plataforma.

Una tendencia sólida y ya muy usable hoy: respetar las preferencias que el usuario declara en su sistema, que el navegador expone como media queries de CSS. En lugar de imponer una única experiencia, la adaptas a cada persona:

prefers-reduced-motion es especialmente importante y ya deberías usarlo: el movimiento puede provocar mareo o desorientación (relacionado con WCAG 2.3.3 y 2.2.2 del Módulo 3), y molesta a personas con TDAH como Hugo. La tendencia va hacia más señales de este tipo (preferencias de tipografía, de reducción de datos, de transparencia), moviendo la accesibilidad de una talla única a una experiencia personalizada que respeta lo que cada usuario ya ha configurado.

Quizá la tendencia más importante no es técnica sino de proceso. Durante años la accesibilidad fue una fase final: se construía el producto y, al final, alguien "lo hacía accesible" (o lo intentaba). Ese modelo está muriendo. El movimiento "shift-left" significa mover la accesibilidad hacia la izquierda en el ciclo de desarrollo: que esté presente desde el diseño, no como parche final.

Esto conecta directamente con lo que viste en el Módulo 6: la accesibilidad en la Definition of Done, el linter en CI, los tests de axe automáticos, la checklist manual en cada componente. La idea de fondo:

La accesibilidad es responsabilidad de todo el equipo —diseño, desarrollo, contenido, QA, producto— y de todo el ciclo, no de una persona ni de una fase. Es más barata, más eficaz y más humana cuando se piensa desde el principio.

Diseñar accesible desde el inicio cuesta una fracción de lo que cuesta remediar al final. Y produce mejores productos para todo el mundo, no solo para quien tiene una discapacidad.

Un aviso honesto para cerrar la parte técnica: todo lo de esta lección evoluciona rápido. WCAG 3.0 avanzará y su modelo puede cambiar; ARIA añadirá roles; la legislación se ampliará y variará por país; la IA mejorará (y traerá riesgos nuevos); surgirán plataformas que hoy no imaginamos. Las fechas y detalles concretos que aquí se dan son una foto de 2026.

Por eso, más que memorizar el estado actual, llévate el hábito de verificar: consulta fuentes primarias y actualizadas (el W3C/WAI, la documentación oficial), sigue a la comunidad de accesibilidad y, ante decisiones legales o de conformidad importantes, apóyate en profesionales especializados. Los principios que has aprendido son estables; los detalles, no. Mantente al día.

• Creer que WCAG 3.0 ya sustituye a 2.2. No: 2.2 es la referencia vigente; 3.0 está en desarrollo. Aplicar hoy 3.0 como si fuera obligatorio es un error.
• Confiar ciegamente en la IA. alt y subtítulos automáticos son un borrador que hay que revisar. La IA no conoce el propósito ni sustituye a usuarios reales.
• Caer en los overlays. No hay "una línea de código" que haga accesible un sitio; suelen empeorar la experiencia.
• Pensar que la accesibilidad es solo web. Móvil, voz y XR aplican los mismos principios con otras técnicas.
• Ignorar prefers-reduced-motion y prefers-contrast. Están disponibles hoy y respetan lo que el usuario ya pidió. Úsalos.
• Tratar la accesibilidad como fase final. El "shift-left" la lleva al diseño; remediar al final es más caro y peor.
• Consejo: no memorices fechas ni versiones; interioriza los principios y adquiere el hábito de verificar en fuentes actualizadas. El estándar cambia; el porqué, no.

Ejercicio 1. Un responsable de producto te dice: "He leído que WCAG 3.0 puntúa de 0 a 100 en vez de aprobado/suspenso, así que a partir de ahora auditamos Cursalia con WCAG 3.0". Señala qué hay de cierto y qué de erróneo en su afirmación, y qué le recomiendas.

Ejercicio 2. El equipo quiere subtitular los 200 vídeos de Cursalia con una herramienta de IA para cumplir con Diego y con la ley. Explica el beneficio y el riesgo, y describe un flujo de trabajo responsable que use la IA sin renunciar a la calidad.

Ejercicio 3. Añade a la hoja de estilos de Cursalia el respeto por dos preferencias del sistema: reducir el movimiento del carrusel de la home y aumentar el contraste si el usuario lo tiene configurado. Escribe el CSS y explica a qué persona del curso ayuda cada regla.

Solución 1. Cierto: WCAG 3.0 propone un modelo de puntuación graduada en lugar del binario aprobado/suspenso de 2.2. Erróneo: WCAG 3.0 está en desarrollo y no es aún un estándar recomendado; no reemplaza a WCAG 2.2, que sigue siendo la referencia vigente y la exigible legalmente. Recomendación: seguir auditando con WCAG 2.2 (nivel AA) como base de conformidad, vigilar la evolución de 3.0 para prepararse, pero no adoptarla como criterio oficial hasta que se publique y lo exijan las normativas aplicables. Verificar el estado en las fuentes del W3C/WAI.

Solución 2. Beneficio: la IA subtitula 200 vídeos en una fracción del tiempo y coste de hacerlo a mano, lo que hace viable el objetivo. Riesgo: los subtítulos automáticos fallan en nombres propios, terminología técnica, puntuación y con acentos o ruido; publicados sin revisar, dan a Diego una experiencia pobre y podrían no cumplir de verdad la ley (WCAG 1.2.2, Módulo 5). Flujo responsable: (1) generar el borrador con IA; (2) revisión humana obligatoria de cada vídeo, corrigiendo términos, nombres y puntuación; (3) validar el resultado, idealmente con la persona destinataria o con alguien que use subtítulos; (4) mantener los subtítulos por idioma (07-03). La IA acelera; la revisión humana garantiza la calidad.

Solución 3.

La primera regla respeta prefers-reduced-motion y detiene la animación del carrusel: ayuda a Hugo (TDAH/dislexia), a quien el movimiento distrae, y a cualquiera con sensibilidad vestibular. La segunda respeta prefers-contrast y refuerza contraste y bordes: ayuda a Sofía (baja visión). Ambas preferencias las declara el usuario en su sistema; nosotros solo las honramos.

Y aquí termina el viaje. Merece la pena mirar atrás y ver cuánto has recorrido.

Empezaste sin saber qué era la accesibilidad web (Módulo 1) y entendiste que no es un extra, sino un derecho y una obligación legal. Conociste a las personas para quienes trabajamos y las tecnologías que usan (Módulo 2). Convertiste los principios POUR en requisitos concretos con WCAG (Módulo 3). Construiste con HTML semántico, formularios, ARIA y contraste (Módulo 4); diste vida a widgets, teclado y multimedia con JavaScript (Módulo 5); aprendiste a verificar con pruebas manuales, herramientas automáticas, usuarios reales e informes (Módulo 6); y en este último módulo domaste el contenido dinámico y las live regions, las SPAs, el multilingüismo y este vistazo al futuro. Levantaste, pieza a pieza, una Cursalia accesible: su catálogo, su reproductor, su matrícula, sus cuestionarios, su panel del alumno, en tres idiomas.

Pero Cursalia nunca fue el objetivo. El objetivo siempre fueron las personas:

• Marta, que ahora oye el resultado de su matrícula, navega el panel como SPA y escucha cada idioma con su voz correcta.
• Lucía, que recorre toda la plataforma con el teclado sin quedarse atrapada ni perder el foco.
• Sofía, que amplía a 300% sin que nada se rompa ni se solape.
• Diego, que sigue cada vídeo con subtítulos en su idioma.
• Hugo, que encuentra una interfaz clara, sin movimiento que le distraiga, que puede seguir a su ritmo.

Ellos son el porqué de todo lo que has aprendido. Cada alt, cada aria-live, cada foco bien gestionado, cada lang correcto es la diferencia entre que puedan o no puedan usar lo que construyes.

Recuerda las dos ideas que atraviesan el curso entero: la accesibilidad no es una fase final, sino una forma de trabajar desde el primer boceto; y las herramientas ayudan, pero nada sustituye a probar con personas reales. Si te llevas eso, te llevas lo esencial.

La web se construye para todos, o no está terminada. Ahora tienes el conocimiento para construirla bien. El estándar seguirá cambiando y siempre habrá algo nuevo que aprender —mantén la curiosidad, verifica en fuentes actualizadas y sigue practicando—, pero el compromiso es el mismo desde la primera lección hasta esta última. Gracias por llegar hasta el final. Ahora ve y hazlo accesible.