En una web pequeña es fácil aplazar la accesibilidad. El diseño va tomando forma, el responsive funciona y queda la sensación de que solo falta pulir detalles.
Pero hay decisiones que se vuelven caras cuando ya está todo montado. Una navegación hecha con div, títulos elegidos por tamaño de letra, un formulario sin etiquetas o un foco invisible obligan a tocar la estructura, no solo los estilos.
Es algo que tengo más presente desde que empecé a organizar proyectos con varias páginas y bastante contenido. En el portfolio, por ejemplo, la estructura sirve para que Google encuentre las páginas, pero también para que alguien llegue a un artículo, entienda en qué parte está y pueda moverse sin usar el ratón.
No soy especialista en accesibilidad. La trato como una parte del frontend que necesito seguir aprendiendo, igual que seguridad o rendimiento. Este artículo recoge el punto de partida que quiero tener resuelto antes de dar una web por terminada.
Cuando llegas tarde, toca rehacer
La accesibilidad aparece en decisiones bastante básicas: el HTML que eliges, el orden del contenido, la navegación por teclado, los mensajes de un formulario y el papel que tiene cada imagen.
No hace falta esperar a una auditoría para mirar esas cosas. Mientras construyes una página, ya puedes comprobar si se entiende sin el diseño, si el orden del HTML es lógico y si los controles responden como esperas.
También hay casos que no tienen que ver con un lector de pantalla: una persona con el móvil bajo el sol, alguien que ha ampliado el texto, quien usa teclado por una lesión temporal o quien llega por primera vez a una interfaz.
El HTML ya resuelve más de lo que parece
Cuando empecé a hacer interfaces, era fácil elegir elementos por cómo quedaban en pantalla. Un div para todo, un span con estilos de botón o un título elegido por el tamaño de fuente.
El navegador no interpreta eso como lo interpreta una persona. Necesita que el código explique qué es cada cosa.
Un botón debería ser un <button> cuando dispara una acción. Un enlace debería ser un <a> cuando lleva a otro lugar. Una navegación debería vivir dentro de <nav>. El contenido principal, dentro de <main>. Y los encabezados deberían marcar la jerarquía real de la página.
<button type="button">Abrir filtros</button>
<a href="/proyectos/">Ver proyectos</a>Con esos elementos ganas comportamiento sin tener que reconstruirlo: se pueden enfocar, responden a teclado y las tecnologías de apoyo saben qué son.
ARIA puede aportar información cuando una interfaz lo necesita. Aun así, antes de añadir atributos, conviene mirar si HTML ya tiene un elemento que describe esa intención.
Probar con teclado cambia lo que ves
Una prueba sencilla que intento no saltarme es recorrer una página con Tab, Shift + Tab, Enter y Espacio.
Parece poca cosa, pero enseguida aparecen fallos que no se ven usando ratón:
- El foco no se aprecia porque se ha eliminado con CSS.
- El orden de los elementos no tiene sentido.
- Un menú se abre, pero no se puede cerrar bien.
- Un desplegable deja el foco perdido en alguna parte de la página.
- Hay enlaces vacíos o elementos interactivos imposibles de alcanzar.
- Un modal se abre y el teclado sigue recorriendo el contenido de fondo.
Quitar el foco para que el diseño quede más limpio suele ser una mala decisión. Es la referencia de quien navega con teclado. Si el estilo por defecto no encaja con la web, toca diseñar otro que se vea con claridad.
En una web de contenido también compensa añadir un enlace para saltar al contenido principal. Evita recorrer el menú entero cada vez que se abre una página con teclado.
La estructura de una página también guía
Los encabezados no están solo para dar ritmo visual al texto. Permiten entender la jerarquía y navegar por bloques de contenido.
En un artículo, el título principal debería ser un h1 y los apartados posteriores deberían usar h2, h3 y así sucesivamente con un orden que refleje lo que estás explicando.
Esto encaja mucho con cómo estoy planteando el blog: artículos con una idea clara, secciones que responden a una duda concreta y enlaces que dicen a dónde llevan. Si un enlace pone “aquí” o “leer más” sin contexto, es más difícil entender su destino fuera del párrafo.
La misma lógica sirve para el layout general. Cabecera, navegación, contenido principal, contenido complementario y pie son partes distintas de una página; el HTML puede expresarlo.
Un formulario no se explica solo
Los formularios son uno de los sitios donde más se nota la diferencia entre una interfaz que parece correcta y una que se puede completar de verdad.
Un placeholder no sustituye a un label. El texto desaparece en cuanto empiezas a escribir y no deja una referencia estable para la persona ni para un lector de pantalla.
<label for="email">Tu email</label>
<input id="email" name="email" type="email" autocomplete="email" />También importa qué ocurre cuando algo falla. Decir solo “campo incorrecto” no ayuda mucho. Es mejor explicar qué dato tiene un problema, por qué y, si se puede, cómo corregirlo. El color rojo puede reforzar el mensaje, pero no debería ser la única señal.
En el artículo sobre errores de seguridad comunes en formularios web hablaba de validar tanto en frontend como en backend. Aquí hay otro motivo para cuidar el frontend: si la validación está bien planteada, la persona recibe feedback rápido y comprensible antes de reenviar el formulario a ciegas.
El texto alternativo depende del contexto
No todas las imágenes necesitan una descripción larga, y escribir “imagen de…” en cada alt tampoco aporta nada.
La pregunta útil es: si esta imagen desapareciera, ¿qué información perdería alguien?
Si una captura muestra una parte importante de un proyecto, el texto alternativo debería explicar qué se ve o por qué es relevante. Si una imagen solo decora y el contenido ya se entiende sin ella, puede llevar alt="" para que no añada ruido.
<img
src="/proyecto-apuntes-ico.webp"
alt="Vista del buscador de Apuntes ICO con resultados por módulo"
/>El alt no es un sitio para repetir keywords. Es contenido para quien no puede ver la imagen, y eso obliga a pensar qué función tiene de verdad dentro de la página.
Leer cómodo también forma parte de la interfaz
El contraste, el tamaño de texto, el espaciado y el ancho de lectura afectan directamente a la experiencia.
Un gris muy suave sobre fondo blanco puede quedar bien en una captura y ser incómodo de leer durante varios minutos. Un botón pequeño puede funcionar con ratón y ser difícil de pulsar en móvil. Un layout demasiado rígido puede romperse cuando alguien amplía el texto.
Mirar la interfaz solo desde una pantalla grande y en condiciones perfectas deja fuera demasiados casos. Ampliar la página al 200 %, comprobar que el texto sigue teniendo sentido y probarla en móvil descubre problemas bastante rápido. Si hay animaciones, también merece la pena respetar la preferencia de reducir movimiento cuando sea posible.
Una puntuación no cierra el tema
Lighthouse, axe y otras herramientas son muy útiles para detectar problemas repetidos: imágenes sin alt, contraste insuficiente, nombres ausentes en controles o atributos mal usados.
Sirven para encontrar una pista, no para cerrar el tema. Una herramienta no sabe si un texto alternativo describe bien una imagen, si el orden de un formulario tiene sentido, si un error se entiende o si un menú resulta cómodo.
Antes de publicar, empezaría por esto:
- Recorrer las páginas importantes solo con teclado.
- Revisar los encabezados y las regiones principales en el HTML.
- Comprobar que los formularios tienen etiquetas, instrucciones y errores claros.
- Mirar las imágenes y decidir qué información deben transmitir sin verse.
- Ampliar el texto y probar en móvil antes del deploy.
Con eso no puedes afirmar que una web sea accesible en todos los casos. Evita, al menos, publicar sin haber mirado lo más básico.
El tipo de detalle que quiero cuidar
Cuando empecé a transformar apuntes en una aplicación de consulta y a organizar contenido en proyectos con varias páginas, el problema no era solo escribir código. La información tenía que encontrarse y entenderse sin saber de antemano dónde hacer clic.
La accesibilidad me interesa por eso. Obliga a mirar partes de una web que no salen en una captura: el orden del contenido, el foco, los mensajes y cómo responde la interfaz cuando no se usa como el desarrollador esperaba.