A lo largo de este módulo hemos ido dejando avisos: que poner onClick en un <article> funciona con el ratón pero no con el teclado, que el color no puede ser el único portador de información, que un mensaje de error rojo debajo de un campo no basta para que un lector de pantalla lo relacione con él. Ha llegado el momento de saldar todas esas deudas a la vez. La accesibilidad no es una capa que se añade al final ni una lista de atributos exóticos: es, en un 90 %, escribir el HTML correcto y no romper lo que el navegador ya te da hecho. En esta lección revisarás todo lo construido en el módulo —los manejadores de eventos, las listas, el formulario de reserva— y lo dejarás usable con teclado y con lector de pantalla, aprendiendo por el camino qué atributos ARIA existen, cuándo usarlos y, más importante, cuándo no usarlos.

1. Por qué importa la accesibilidad
2. Las cuatro ideas de las WCAG
3. HTML semántico primero
4. El caso de la tarjeta pulsable
5. Etiquetas y mensajes de error en formularios
6. Navegación por teclado y gestión del foco
7. Regiones activas: anunciar lo que cambia
8. Imágenes, iconos y el problema del color
9. Atributos ARIA de uso común
10. Cómo comprobar que funciona

Hay tres razones, y las tres son buenas.

Personas. Alrededor del 15 % de la población mundial vive con alguna discapacidad. No hablamos solo de ceguera total: hay baja visión, daltonismo, discapacidad motriz que impide usar un ratón con precisión, discapacidad cognitiva, sordera. Y hay discapacidades temporales (un brazo escayolado) y situacionales (usar el móvil a pleno sol, con una mano y con prisa). En CicloUrbano, alguien puede estar consultando el catálogo con una mano mientras sujeta la bici con la otra.

Obligación legal. En la Unión Europea, la Directiva 2016/2102 obliga a que los sitios y aplicaciones del sector público sean accesibles, y el Acta Europea de Accesibilidad extiende requisitos similares a numerosos servicios privados, incluido el comercio electrónico. En España, el Real Decreto 1112/2018 desarrolla esas obligaciones. En Estados Unidos, la ADA se aplica de forma consolidada a los sitios web. Traducido: para muchos proyectos, no es opcional.

Calidad general. Una interfaz accesible es mejor para todo el mundo. Los subtítulos sirven en un vagón ruidoso; un buen contraste ayuda al sol; los atajos de teclado los agradece quien introduce cien reservas al día; y el marcado semántico mejora el SEO y facilita las pruebas automatizadas, como comprobarás en el Módulo 9.

Y hay un argumento práctico decisivo: arreglar la accesibilidad al final cuesta cinco veces más que hacerlo bien desde el principio. Cambiar un <div onClick> por un <button> mientras escribes el componente cuesta cero; hacerlo seis meses después implica rehacer estilos, revisar la maquetación y volver a probarlo todo.

Las WCAG (Web Content Accessibility Guidelines) son el estándar internacional. Detrás de sus decenas de criterios hay solo cuatro principios, que en inglés forman el acrónimo POUR:

Las WCAG definen además tres niveles de conformidad: A (mínimo), AA (el que exigen casi todas las normativas) y AAA (muy exigente, poco frecuente). El objetivo razonable de cualquier proyecto es el nivel AA.

La primera regla de la accesibilidad —y la que más problemas evita— es esta: usa el elemento HTML que corresponde a lo que estás haciendo.

Un <button> no es un <div> con estilos de botón. Un <button> trae de fábrica:

Cinco cosas que hay que reconstruir, y basta olvidar una para dejar a alguien fuera.

Sobre los encabezados hay un matiz que se pasa por alto: su nivel comunica jerarquía, no tamaño. Quien navega con lector de pantalla salta de encabezado en encabezado para hacerse un mapa de la página; si eliges un <h4> porque «se ve más pequeño», ese mapa queda roto. El tamaño se decide en el CSS.

La estructura de CicloUrbano, con la semántica en su sitio:

Esos elementos crean regiones que las tecnologías de asistencia permiten saltar directamente: «ir al contenido principal», «ir a la navegación». Con <div> no existe esa posibilidad.

En la lección 03-01 pusimos onClick en el <article> de TarjetaBicicleta y dejamos anotada la deuda. Vamos a saldarla.

El problema, en concreto: con un <article onClick>, quien navega con teclado nunca llega a la tarjeta —no es enfocable— y quien usa lector de pantalla oye «artículo», sin ninguna pista de que se pueda pulsar.

Solo el título es pulsable, y es un <button> de verdad. Con estilos se puede hacer que parezca un enlace o un título normal. Esta es la opción recomendada: cero atributos ARIA, cero manejadores de teclado, todo funciona.

Si el diseño exige que toda la tarjeta sea un área pulsable, hay que reconstruir a mano lo que un botón da gratis:

Cuatro añadidos para igualar a un <button>, y aún queda un problema: si dentro de la tarjeta hay otro botón («Reservar»), acabas con un control dentro de otro control, algo que ninguna tecnología de asistencia interpreta bien. Por eso la solución 1 es preferible casi siempre.

La regla: si algo se puede pulsar, que sea un <button> o un <a>. Reconstruir el comportamiento solo se justifica cuando no hay alternativa.

Aquí cerramos lo prometido en la lección anterior. Un formulario accesible necesita tres cosas: etiquetas asociadas, textos de ayuda vinculados y errores anunciados.

Recuerda de la lección 01-04: en JSX se escribe htmlFor, no for, porque for es una palabra reservada de JavaScript.

Qué se gana con la asociación correcta:

• Al pulsar el texto de la etiqueta, el campo recibe el foco. El área pulsable crece, lo que ayuda especialmente en móvil y a quien tiene poca precisión motriz.
• El lector de pantalla anuncia «Duración (horas), cuadro de edición numérico» al llegar al campo. Sin etiqueta asociada, solo dice «cuadro de edición», y la persona no sabe qué escribir.

En listas generadas con map, cuidado con los id duplicados: deben ser únicos en toda la página. Genéralos a partir del dato: id={horas-${bicicleta.id}}.

Cuando un campo necesita una explicación adicional, se vincula con aria-describedby, que acepta uno o varios id separados por espacios:

El lector de pantalla lee primero la etiqueta y después la descripción. La diferencia con aria-label es importante: la etiqueta dice qué es el campo; la descripción aporta detalles adicionales.

Y aquí está la pieza que cerraba la lección 03-05: un párrafo rojo debajo del campo es invisible para un lector de pantalla si no está asociado al campo y no se anuncia al aparecer.

Los cuatro mecanismos, uno a uno:

Fíjate en que aria-describedby cambia según haya error o no, encadenando los dos id. Así el campo conserva su ayuda y suma el error cuando existe.

Y un detalle que ahora encaja: en la lección 03-05 recomendamos no deshabilitar el botón de envío. Uno de los motivos es de accesibilidad: los elementos con disabled no reciben foco, así que quien navega con teclado puede llegar al final del formulario, no encontrar el botón y no entender por qué. Es mejor un botón activo que, al pulsarlo, explique qué falta.

Toda la funcionalidad debe poder usarse solo con el teclado. Estas son las teclas que la gente espera:

El orden de tabulación es el orden del marcado, no el visual. Si con CSS colocas un elemento a la izquierda pero en el HTML está al final, el foco irá allí en último lugar y quien navegue con teclado se desorientará. La solución no es tocar tabIndex: es poner el marcado en el orden lógico y maquetar con order de flexbox o grid solo cuando no rompa el sentido.

Los elementos interactivos nativos —<button>, <a href>, <input>, <select>, <textarea>— ya son enfocables: no les pongas tabIndex.

El error más extendido y más dañino:

Eliminar el contorno de foco deja a quien navega con teclado literalmente a ciegas: no sabe dónde está. Si el contorno por defecto no encaja con tu diseño, sustitúyelo, no lo elimines:

:focus-visible es la pseudoclase moderna que muestra el indicador cuando el navegador estima que hace falta —navegación con teclado— y lo omite tras un clic de ratón. Es lo mejor de ambos mundos.

En la lección 03-01 ya añadiste Escape al SelectorTipo para volver al filtro «Todas». El patrón general:

Se usa siempre evento.key con el nombre de la tecla ('Enter', 'Escape', 'ArrowRight', ' ' para el espacio). evento.keyCode está obsoleto desde hace años: no lo uses.

Cuando algo cambia en la pantalla sin que la persona haya movido el foco —«Reserva creada», «3 bicicletas encontradas», «Guardando…»—, un lector de pantalla no dice nada, porque solo lee lo que está bajo el foco. La solución son las regiones activas (live regions).

El detalle que casi todo el mundo se salta: la región debe existir en el DOM desde el principio, aunque esté vacía. Si el elemento con aria-live aparece a la vez que su contenido, muchos lectores de pantalla no lo anuncian, porque no estaban observando ese nodo. Renderiza siempre el contenedor y cambia solo su texto.

En CicloUrbano hay tres sitios donde una región activa aporta de verdad:

1. Confirmación de reserva creada, con role="status".
2. Recuento de resultados del catálogo al cambiar el filtro: «Se han encontrado 3 bicicletas.»
3. Mensajes de error del formulario, con role="alert".

Todo <img> necesita un atributo alt. La pregunta clave es: si esta imagen no cargara, ¿qué texto transmitiría la misma información?

alt="" y la ausencia de alt no son lo mismo: el primero dice «esta imagen no aporta información, ignórala»; el segundo deja al lector de pantalla adivinando, y lo habitual es que acabe leyendo la URL en voz alta.

Y no empieces el texto con «Imagen de…»: el lector ya anuncia que es una imagen.

Los iconos que son solo decoración deben ocultarse; los que son la información necesitan una alternativa textual:

Sin el aria-label, el segundo botón se anuncia como «botón», sin más. Un formulario lleno de botones así es inutilizable.

Este es el criterio 1.4.1 de las WCAG, y afecta directamente a EtiquetaEstado. Aproximadamente el 8 % de los hombres tiene alguna forma de daltonismo; para muchos de ellos, el verde de «disponible» y el rojo de «mantenimiento» son prácticamente el mismo tono.

La buena noticia es que nuestro componente ya lo hacía bien desde la lección 03-02: muestra el texto del estado además del color. Lo dejamos redondo:

Tres canales independientes: color para quien lo distingue, símbolo para quien no, y texto para todo el mundo, incluido el lector de pantalla.

Las WCAG nivel AA exigen un contraste mínimo de 4,5:1 para el texto normal y 3:1 para el texto grande (a partir de 18,66 px en negrita o 24 px normal). El verde de marca de CicloUrbano, #12805c, sobre blanco alcanza aproximadamente 4,8:1, así que cumple. Cualquier comprobador de contraste en línea o el panel de accesibilidad del navegador te da el dato en un segundo.

ARIA (Accessible Rich Internet Applications) es un conjunto de atributos que añaden semántica cuando el HTML no llega. Son un complemento, no un sustituto.

Es la primera de las cinco reglas oficiales del uso de ARIA, y significa exactamente lo que dice: un atributo ARIA mal puesto es peor que no ponerlo, porque miente a la tecnología de asistencia y esta se cree la mentira.

Ese último caso es especialmente dañino: quien ve la pantalla lee «Reservar» y quien la escucha oye «Cancelar». Y quien usa control por voz dirá «pulsar Reservar» y no ocurrirá nada, porque para el sistema ese botón se llama «Cancelar».

Las otras cuatro reglas, resumidas:

1. Usa el elemento HTML nativo antes que ARIA.
2. No cambies la semántica nativa: <h2 role="button"> es un despropósito.
3. Todo control ARIA debe ser usable con teclado.
4. No pongas aria-hidden="true" en algo enfocable: crearías un elemento invisible al lector pero alcanzable con Tab.

Guarda el ratón y recorre la pantalla solo con el teclado. Comprueba:

1. ¿Puedo llegar a todo? Cada botón, enlace y campo debe ser alcanzable.
2. ¿Veo dónde estoy? El indicador de foco debe ser visible en todo momento.
3. ¿El orden tiene sentido? Debe seguir el orden visual de lectura.
4. ¿Puedo activar todo con Enter o Espacio?
5. ¿Me quedo atrapado? Si el foco entra en algo y no puede salir con Tab, hay un fallo grave.

En CicloUrbano el recorrido correcto es este:

Detecta en tiempo de escritura una buena parte de los errores de esta lección:

Avisa, entre otras cosas, de imágenes sin alt, de elementos no interactivos con manejadores de clic, de etiquetas sin campo asociado, de tabIndex positivos y de atributos ARIA inválidos. En proyectos creados con las plantillas de React ya suele venir configurado.

Las herramientas de desarrollo traen dos utilidades imprescindibles:

• Lighthouse (pestaña del mismo nombre en Chrome y Edge): ejecuta una auditoría automática y puntúa la accesibilidad, con la lista de problemas detectados y cómo corregirlos.
• Árbol de accesibilidad (dentro del inspector de elementos): muestra cómo ve la página una tecnología de asistencia —el nombre, el rol y el estado de cada elemento—. Es la forma más directa de comprobar si tu aria-label está surtiendo efecto.

También existen extensiones especializadas como axe DevTools o WAVE, que dan informes más detallados.

Advertencia importante: las herramientas automáticas detectan aproximadamente entre el 30 % y el 40 % de los problemas reales. Pueden decirte que falta un alt, pero no si el texto que has escrito es útil; pueden verificar el contraste, pero no si el orden de foco tiene sentido. La prueba con Tab y, cuando sea posible, con un lector de pantalla real (NVDA en Windows, VoiceOver en macOS e iOS, TalkBack en Android) sigue siendo insustituible.

Existe además la posibilidad de automatizar comprobaciones de accesibilidad en las pruebas, con herramientas como jest-axe integradas en la batería de pruebas del proyecto. Es una práctica excelente y se menciona aquí para que sepas que existe; el terreno de las pruebas es el Módulo 9.

• <div onClick> en lugar de <button>. No es enfocable, no responde al teclado y no se anuncia como control. Es, con diferencia, el fallo de accesibilidad más común en React.
• outline: none sin sustituto. Deja a quien navega con teclado sin saber dónde está. Usa :focus-visible con un contorno propio.
• tabIndex positivo. Rompe el orden de tabulación de toda la página. Solo 0 y -1.
• Poner tabIndex a elementos que ya son enfocables. Un <button tabIndex={0}> es redundante y confuso.
• Etiquetas sin asociar. Un <p> encima del campo no es una etiqueta. <label htmlFor> con el id correspondiente, y recuerda que en JSX es htmlFor, no for.
• id duplicados en listas generadas con map. Rompen la asociación etiqueta-campo. Genéralos a partir del id del dato.
• Mensajes de error solo visuales. Sin role="alert" no se anuncian al aparecer, y sin aria-describedby no se leen al enfocar el campo.
• Una región aria-live que aparece junto con su contenido. No se anuncia. El contenedor debe estar siempre en el DOM.
• aria-live="assertive" para todo. Interrumpe constantemente y acaba siendo insoportable. Reserva el modo asertivo para lo urgente.
• Imágenes sin alt, o con «imagen de…». Sin alt se lee la URL; el prefijo es redundante porque el lector ya anuncia que es una imagen.
• Botones con solo un icono y sin nombre accesible. Se anuncian como «botón» a secas. aria-label obligatorio.
• Transmitir información solo con color. Añade siempre texto o un símbolo.
• Encabezados elegidos por su tamaño. Rompen el mapa de la página. El nivel es jerarquía; el tamaño se decide en el CSS.
• ARIA redundante o contradictorio. <button role="button"> sobra; una aria-label distinta del texto visible es un fallo grave. No ARIA es mejor que mal ARIA.
• Consejo: prueba con Tab cada vez que termines un componente. Dos minutos que ahorran auditorías enteras.
• Consejo: instala eslint-plugin-jsx-a11y el primer día del proyecto. Corrige mientras escribes en lugar de al final.
• Consejo: escribe el marcado en el orden lógico de lectura y usa CSS para colocarlo, no tabIndex para reordenarlo.

Este componente tiene seis problemas de accesibilidad. Identifícalos, explica a quién afecta cada uno y escribe la versión corregida.

Toma el campo «Bicicleta» del FormularioReserva de la lección 03-05 y hazlo completamente accesible. Debe incluir:

• Etiqueta correctamente asociada.
• Un texto de ayuda vinculado: «Solo se muestran las bicicletas disponibles ahora mismo.»
• aria-invalid cuando el campo tenga un error visible.
• El mensaje de error asociado y anunciado al aparecer.
• Un aria-describedby que combine ayuda y error cuando ambos existan.

Escribe también las clases CSS necesarias para que el estado de error se distinga sin depender del color.

Diseña el recorrido de teclado completo de la pantalla principal de CicloUrbano y descríbelo paso a paso. Después responde:

1. ¿Dónde colocarías una región aria-live y qué anunciaría en cada caso?
2. ¿Qué debería ocurrir al pulsar Escape en cada zona de la pantalla?
3. Si la lista de bicicletas tuviera cien tarjetas con un botón cada una, ¿qué problema de navegación aparecería y cómo lo resolverías sin romper nada?

Solución 1.

Los seis problemas:

Y en el CSS, outline: none sin sustituto elimina el indicador de foco.

La decisión de fondo: se ha eliminado el onClick de la tarjeta entera. El área pulsable son dos botones de verdad con texto descriptivo, así que no hacen falta role, tabIndex, onKeyDown ni aria-label.

Solución 2.

Las tres señales del estado de error, independientes entre sí: el borde más grueso y el fondo (perceptibles sin distinguir el color), el símbolo ⚠ y el texto del mensaje. Y para el lector de pantalla, aria-invalid lo anuncia como campo no válido, aria-describedby le asocia ayuda y error, y role="alert" hace que el mensaje se lea en cuanto aparece.

Solución 3.

Recorrido de teclado propuesto:

1. Enlace «Saltar al contenido», oculto hasta recibir foco, que lleva directamente al <main>. Es el primer elemento de la página y evita tener que recorrer toda la navegación en cada visita.
2. Cabecera: enlaces «Catálogo», «Estaciones», «Mis reservas», con aria-current="page" en el activo.
3. SelectorTipo: los cuatro botones de filtro, en orden.
4. ListaBicicletas: por cada tarjeta, su botón «Reservar».
5. FormularioReserva: bicicleta → fecha → horas → casilla de condiciones → botón «Crear reserva».
6. Pie de página: sus enlaces.

1. Regiones aria-live: dos, ambas presentes en el DOM desde el primer render.

Los errores del formulario no necesitan una región compartida: cada mensaje ya lleva su role="alert".

2. Comportamiento de Escape:

3. El problema de las cien tarjetas: para llegar al formulario habría que pulsar Tab cien veces. Es una barrera real, y las soluciones que no valen son tabIndex positivos (rompen todo el orden) o quitar los botones del recorrido con tabIndex={-1} (los haría inalcanzables). Lo que sí funciona:

• Enlaces de salto antes y después de la lista: «Saltar la lista de bicicletas» / «Volver al filtro», visibles solo al recibir el foco.
• Encabezados y regiones bien marcados, para que quien usa lector de pantalla salte por estructura en lugar de por tabulación.
• Paginación o carga progresiva, que además mejora el rendimiento y beneficia a todo el mundo.
• Un <section aria-labelledby> para la lista, de forma que se anuncie como región identificable y se pueda saltar de una vez.

Con esta lección cierras el Módulo 3 y saldas todas las deudas que fue dejando por el camino. Sabes por qué la accesibilidad importa —personas, obligación legal y calidad general— y conoces los cuatro principios de las WCAG: perceptible, operable, comprensible y robusto. Sobre todo, has interiorizado la regla que resuelve la mayor parte de los problemas antes de que existan: usa el elemento HTML correcto. Un <button> trae de fábrica el foco, el teclado, el rol y el estado; un <div> con onClick obliga a reconstruir cinco cosas y basta olvidar una para dejar a alguien fuera.

Has aplicado eso a todo lo construido en el módulo: la tarjeta pulsable de la lección 03-01 pasa a tener botones de verdad; el FormularioReserva asocia cada <label htmlFor> a su id, vincula la ayuda con aria-describedby, marca los campos con aria-invalid y anuncia los mensajes con role="alert" —cerrando exactamente lo que quedó pendiente en 03-05—; EtiquetaEstado transmite el estado por tres canales independientes, color, símbolo y texto, para no dejar fuera a quien no distingue los colores; y una región aria-live avisa de lo que cambia sin que nadie mueva el foco. Sabes gestionar el orden de tabulación, cuándo usar tabIndex={0} y tabIndex={-1} y por qué los valores positivos están prohibidos, y que el indicador de foco se sustituye con :focus-visible pero jamás se elimina. Conoces los atributos ARIA habituales y la regla que los gobierna: no ARIA es mejor que mal ARIA. Y sabes comprobarlo: con Tab en dos minutos, con eslint-plugin-jsx-a11y mientras escribes y con Lighthouse y el árbol de accesibilidad del navegador, recordando que las herramientas automáticas solo detectan un tercio de los problemas reales.

Haciendo balance del módulo completo: CicloUrbano ha dejado de mirarse y ha empezado a responder. Los eventos conectan la interfaz con la lógica, con manejadores bien nombrados, eventos sintéticos y propagación bajo control. El renderizado condicional hace que cada tarjeta muestre lo que corresponde a su estado y que el catálogo sepa qué decir cuando no hay nada. Las listas con map y claves estables han eliminado la repetición escrita a mano y han cerrado la deuda de la reconciliación. Los formularios controlados recogen datos con el estado como única fuente de verdad, la validación los filtra con reglas de negocio de verdad, y la accesibilidad hace que todo ello llegue a cualquier persona.

Pero queda un límite que hemos rozado en cada lección sin poder cruzarlo. El SelectorTipo guarda el tipo elegido en su propio estado y avisa al padre, pero sigue sin filtrar la lista, porque ListaBicicletas no puede ver ese estado. TarjetaBicicleta avisa con alSeleccionar y App se limita a hacer un console.log, porque no hay dónde guardar la bicicleta seleccionada. El estado es privado de cada componente, y eso es justo lo que impide que las piezas trabajen juntas. La solución tiene nombre y abre el Módulo 4: Conceptos Avanzados de Componentes. La próxima lección es Elevando el Estado, y con ella el catálogo de CicloUrbano filtrará de verdad.