Hoy · Hoja de ruta
- 1. Aprende: Que casi toda la accesibilidad de una web sale de usar bien HTML, y por qué ARIA no es el punto de partida.
- 2. Haz: Recorre tu sitio entero sin ratón y anota dónde se rompe.
- 3. Comprueba: Puedes alcanzar todas las partes interactivas y sabes siempre dónde está el foco.
Antes de empezar · 5 minutos, sin apuntes
- ¿Qué comparten los botones de opción que pertenecen al mismo grupo?
- ¿Qué aportan
fieldsetylegend? - Detecta dos fallos en un formulario con campos sin
labely varios radios con nombres distintos.
Una web no se hace solo para nosotros
Una web no debería funcionar únicamente para:
una persona que ve perfectamente, usa ratón, tiene una pantalla grande y navega exactamente como nosotros.
La buena noticia es que HTML bien utilizado proporciona buena parte de la accesibilidad automáticamente. No constituye una capa que se incorpore al final, sino el resultado del trabajo de quince sesiones.
1 · Usa el elemento correcto
<button>Comprar</button>es mejor punto de partida que:
<div>Comprar</div>si representa una acción.
2 · Mantén una jerarquía lógica
h1
h2
h3
h2Sin saltos. Es el índice por el que se navega.
3 · Describe las imágenes
alt informativo, funcional o vacío, según su función. Nunca ausente.
4 · Etiqueta los formularios
label asociado, no solo placeholder.
5 · Usa HTML semántico
nav, main, header, footer, section, article informan de la estructura del documento y permiten recorrerlo por zonas.
6 · No uses ARIA por defecto
Encontrarás código como este:
<div role="button" tabindex="0">Guardar</div>ARIA
Un conjunto de atributos para describir el papel, el estado y las propiedades de un elemento cuando HTML no llega. Puede ser necesaria en componentes complejos.
No debe emplearse, sin embargo, para reconstruir manualmente algo que HTML ya proporciona. Ese div con role="button" necesita además que le programes la activación con Enter y con espacio, el foco, y el estado. Un <button> trae todo eso.
El orden es siempre:
- HTML nativo
- Si de verdad no llega, ARIA
La primera regla de ARIA
Está escrita en la propia especificación y viene a decir esto: si existe un elemento HTML con la semántica que necesitas, úsalo en lugar de reconstruirlo con ARIA. Una ARIA mal puesta deja la página peor que no poner ninguna.
Ahora tú · La prueba del teclado, sobre tu sitio
Suelta el ratón. Recorre tus cuatro páginas usando solo:
Tab avanzar
Shift + Tab retroceder
Enter activar
Espacio marcar casillas y pulsar botonesResponde a continuación:
| Pregunta | Página donde falla |
|---|---|
| ¿Puedes alcanzar todas las partes interactivas? | |
| ¿Sabes en todo momento dónde está el foco? | |
| ¿El orden de recorrido tiene sentido? | |
| ¿Puedes enviar el formulario sin tocar el ratón? | |
| ¿Puedes saltar el menú para ir al contenido? |
Corrige lo que encuentres. Casi todo se arregla cambiando un elemento por el que tocaba.
Antes de cerrar · 2 minutos, sin mirar
- Nombra tres cosas de accesibilidad que salen gratis de usar bien HTML.
- ¿Por qué
<div role="button">es peor que<button>? - ¿Cuándo tiene sentido usar ARIA?
Ver respuestas
1 · Por ejemplo: navegación por encabezados, salto entre zonas con los landmarks, botones alcanzables con teclado, campos anunciados por su etiqueta, imágenes sustituidas por su alt. Bastan tres.
2 · Porque hay que reconstruir a mano el foco, la activación con teclado y el estado, y cualquiera de esas piezas se puede olvidar. El button las trae todas.
3 · Cuando construyes un componente para el que HTML no tiene un elemento equivalente. Nunca para sustituir uno que sí existe.