Punto de partida. Actividad «Auditoría y mejora de accesibilidad», sesión 2 de 4. Abre el avance de la sesión anterior; los pasos de hoy indican qué conservar y qué completar. La guía de arranque permite preparar las herramientas sin depender de otros módulos.
Se explica
10 minutos · contexto, explicación y ejemplo
Las pautas de accesibilidad organizan requisitos en cuatro principios: perceptible, operable, comprensible y robusto. Sirven para clasificar problemas, pero citar una sigla no los resuelve. HTML semántico aporta comportamiento y significado: un button no es solo una caja con apariencia de botón.
ARIA describe roles, estados y propiedades a tecnologías de apoyo. No añade por sí sola interacción de teclado. Antes de utilizarla, comprobamos si un elemento HTML nativo cubre la necesidad y qué nombre, rol y estado debe comunicar el control.
Consultar ejemplos y conceptos de esta sesión
WCAG
Existe un conjunto internacional de recomendaciones:
WCAG · Web Content Accessibility Guidelines
La versión vigente es la WCAG 2.2, publicada por el W3C. Es la referencia que usan las herramientas y la que citan los requisitos legales.
No vamos a memorizar sus criterios. Nos interesan los cuatro principios que los ordenan, y que se recuerdan por sus iniciales en inglés:
POUR
| Principio | La pregunta | Problemas típicos |
|---|---|---|
| Perceptible | ¿Puede el usuario recibir la información? | Imágenes sin alternativa, contraste bajo, vídeo sin subtítulos, información solo por color |
| Operable | ¿Puede manejar la interfaz? | Botones inalcanzables con teclado, foco invisible, menús que exigen ratón, controles diminutos |
| Understandable | ¿Entiende qué pasa y qué debe hacer? | Errores incomprensibles, navegación inconsistente, formularios sin instrucciones |
| Robust | ¿Puede interpretarlo la tecnología que usa? | HTML no semántico, componentes inventados que ninguna tecnología asistiva reconoce |
Perceptible
Mal
«Los campos rojos son obligatorios.»
Bien
«Los campos marcados con * son obligatorios.»
Comprensible
Mal
«Error 483.»
Bien
«La contraseña debe contener al menos 8 caracteres.»
Un buen mensaje de error no dice que algo ha fallado: dice cómo arreglarlo.
Robusto
Esto puede parecer un botón:
<div onclick="comprar()">Comprar</div>Semánticamente, sin embargo, sigue siendo un div: no recibe foco, no responde a Enter, y un lector de pantalla no lo anuncia como botón. Lo correcto es:
<button onclick="comprar()">Comprar</button>El navegador y las tecnologías asistivas ya saben qué es un botón. Reconstruirlo a mano significa reconstruir también todo lo que un botón hace gratis.
HTML semántico
HTML no sirve solo para colocar cosas en pantalla: describe qué es cada cosa. <header>, <nav>, <main>, <section>, <article>, <footer>, <button>, <label>, <form>, <h1>, <h2>.
Usar el elemento correcto casi siempre es mejor que reconstruirlo todo a base de <div>.
Formularios
Solo se ve
<input type="text" placeholder="Correo">
Además se entiende
<label for="email">Correo electrónico</label><input id="email" type="email">
El placeholder desaparece en cuanto se empieza a escribir; la etiqueta permanece. La relación entre etiqueta y campo queda declarada, no sugerida visualmente.
Jerarquía de títulos
No se elige h1, h4 o h2 por el tamaño de letra que traen. Los encabezados describen la estructura del documento:
- h1 · Tienda
- h2 · Ordenadores
- h3 · Portátiles · h3 · Sobremesa
- h2 · Accesorios
Un usuario de lector de pantalla navega saltando entre encabezados. Si la jerarquía está rota, ha perdido el índice del documento. Del tamaño se encarga el CSS.
ARIA
Es posible que aparezcan atributos como aria-label, aria-expanded o role. ARIA sirve para dar información adicional sobre componentes que HTML no cubre.
Existe una regla que evita la mayoría de los problemas:
Si existe un elemento HTML nativo que hace el trabajo, úsalo antes que ARIA.
Primero HTML correcto. Después, y solo si hace falta, ARIA. Un div con cinco atributos ARIA suele ser peor que un button.
Se trabaja
45 minutos · trabajo guiado sobre la actividad
- Clasifica las barreras registradas según los cuatro principios y explica una clasificación. Si afecta a varios, señala el principal y justifica la relación.
- Localiza un control que parezca botón y consulta su HTML en el inspector. Compara su etiqueta con un botón nativo y anota las diferencias de teclado y significado.
- Aplica la corrección resuelta de la guía a un control de tu copia: etiqueta semántica, texto reconocible y foco visible. Conserva las clases necesarias para mantener el diseño.
- Repite el recorrido de teclado y comprueba la vista de accesibilidad del inspector: nombre y rol del control. No concluyas que ARIA sobra solo porque visualmente nada cambia al quitarla.
- Registra barrera, cambio y resultado. Revisa si la corrección mantiene la función del control y el aspecto usable antes de continuar con otros elementos.
Cierre
5 minutos · comprobar el resultado
Al terminar la sesión:
Has corregido y comprobado una barrera concreta. Puedes explicar qué aporta HTML y qué información añade, cuando es necesaria, ARIA.