Accesibilidad web: qué encontramos en nuestro propio sitio

Quita la mano del ratón. Ahora recorre tu propio sitio: Tab, Tab, Enter. Llega al formulario, rellénalo, envíalo. La mayoría de los dueños lo prueban por primera vez justo cuando alguien se lo propone, y se atascan hacia la tercera pantalla.

Nosotros recorrimos así nuestro sitio la semana pasada. Se rompió una sola cosa, pero se rompió de forma muy instructiva, y de eso va el resto del texto.

Qué es la accesibilidad web y a quién le importa

Circula la idea cómoda de que la accesibilidad en páginas web es cosa de hospitales, bancos y administraciones, y que un negocio corriente puede saltársela. Cómoda y equivocada.

Esta es la gente que choca de verdad contra una interfaz inaccesible:

• Personas ciegas o con baja visión. Un lector de pantalla les dicta la página. Si un botón está escrito en el código como un rectángulo cualquiera, el lector no tiene nada que decir sobre él.
• Quien se ha quedado sin trackpad. Es temporal, pero está pasando ahora mismo. El teclado es lo único que le queda para llegar al botón de pedir.
• Personas con temblor o movilidad reducida. Acertar con el cursor en un enlace pequeño cuesta. Tab es más fiable.
• Quien agranda la letra. A partir de los cuarenta es media audiencia, y muchos sitios se descomponen al 200% de zoom.
• Gente que usa el teclado por costumbre. Programadores, contables, cualquiera para quien el ratón va más lento que sus manos.

Súmale los buscadores. El robot de Google recorre una página parecido a como lo hace un lector de pantalla: estructura, encabezados, descripciones de imágenes. Lo que vuelve una página comprensible para una persona ciega la vuelve comprensible para la indexación. Es uno de esos raros casos en que dos problemas distintos se resuelven con el mismo gesto.

Accesibilidad web: normativa y niveles WCAG

WCAG son las siglas de Web Content Accessibility Guidelines, las pautas de accesibilidad para el contenido web. Las publica el W3C, el mismo consorcio que está detrás de los estándares de la web. En la práctica son una lista de requisitos concretos para una página, desde el contraste del texto hasta el comportamiento de los formularios, agrupados por exigencia. Esa es la respuesta corta a qué es la accesibilidad web en términos técnicos.

Hay tres niveles:

• Nivel A. El suelo, por debajo del cual el sitio sencillamente no funciona para parte de la gente.
• Nivel AA. El objetivo real de trabajo. Es el nivel al que apunta la normativa de accesibilidad web de la mayoría de los países.
• Nivel AAA. El techo. Muy pocos sitios lo cumplen entero, y es normal: parte de sus requisitos choca con ciertos tipos de contenido.

En Europa esto dejó de ser voluntad propia. La European Accessibility Act entró en vigor en el verano de 2025 y alcanza a tiendas online, servicios bancarios, libros electrónicos y plataformas de transporte y reservas. Las empresas pequeñas, por debajo de dos millones de euros de facturación, tienen excepciones, pero el «a nosotros no nos afecta» se sostiene cada vez peor. Varios países ya exigen una página aparte, la declaración de accesibilidad web, donde el titular deja por escrito qué cumple el sitio y qué sigue pendiente. En algunos sectores se pide además un certificado de accesibilidad web emitido tras una auditoría externa.

Qué encontramos en nuestro sitio

Nuestro sitio funciona en tres idiomas y se cambian con una bandera en la cabecera. Se veía bien y con el ratón funcionaba sin un fallo.

El recorrido con teclado contó otra cosa. El botón de la bandera sí era un botón de verdad en el código, así que Tab llegaba a él y la lista se abría. Las tres opciones de dentro seguían siendo bloques de marcado corrientes, sin nada que indicara que se podía pulsar en ellas. Tab no las veía y Enter no hacía nada sobre ellas.

El resultado era una trampa. La persona abría la lista de idiomas desde el teclado y no podía ni elegir idioma ni entender adónde se había ido la navegación: el siguiente Tab la mandaba más abajo en la página, por delante de la lista abierta.

Arreglarlo llevó media hora. Cada opción recibió role="button" y tabindex="0", que es lo que hace que un bloque sea alcanzable con el teclado y tenga sentido para un lector de pantalla. Añadimos el manejo de Enter y la barra espaciadora, una etiqueta con el nombre propio de cada idioma (Українська, English, Español) y aria-current en el activo, para que se anuncie «botón, seleccionado» y no solo «botón».

Lo incómodo es cuánto sobrevivió el fallo. El sitio pasaba revisiones y puntuaba bien en las herramientas automáticas, y ninguna lo sacó a la luz. Una trampa de teclado solo la ve una persona real pulsando Tab.

Cómo revisar tu sitio en diez minutos

No hay que instalar nada, basta con el navegador.

1. El recorrido con Tab. Abre la portada y pulsa Tab hasta dar la vuelta a la página. Dos preguntas por el camino: ¿se ve dónde está el foco? ¿te has quedado atascado en algún punto? Lo que las herramientas etiquetan como wcag focus se reduce justo a eso, un contorno visible sobre el elemento activo. Si en los estilos hay un outline: none sin nada que lo sustituya, ese contorno no existe y la persona avanza a ciegas.
2. Menús y ventanas emergentes. Abre cada una desde el teclado e intenta cerrarla con Escape. Los formularios de contacto, los pop-ups promocionales y el menú móvil fallan mucho más que los enlaces normales.
3. Zoom al 200%. Ctrl y más, cuatro veces. El texto debe seguir leyéndose y los botones no deben montarse unos sobre otros.
4. Contraste. El gris claro sobre blanco queda elegante en la maqueta y desaparece en el móvil a pleno sol. El mínimo para el texto corriente es una relación de 4,5 a 1, y cualquier calculadora de contraste online te dice dónde estás.
5. Descripciones de las imágenes. Cada imagen con contenido necesita un atributo alt que cuente qué se ve. Las decorativas llevan alt vacío para que el lector de pantalla las salte en lugar de leer el nombre del archivo.
6. Encabezados en orden. Un H1 por página, luego H2 y dentro H3. Saltarse niveles rompe la lectura: el lector de pantalla construye con ellos su índice, y ese índice es la forma en que se mueve por el sitio quien no ve.

Después puedes pasar Lighthouse, que viene dentro de Chrome, en las herramientas de desarrollo. Te da una nota y una lista de avisos. Ten presente una corrección: lo automático detecta alrededor de un tercio de los problemas reales. El nuestro no detectó el selector de idiomas.

Lo que solo se ve en el código

Hay cosas que no salen ni con Tab ni con una herramienta automática.

• El foco que se escapó de la ventana modal. El diálogo está abierto y Tab pasea por la página de detrás. A la vista no se nota nada, porque el diálogo tapa el fondo.
• Orden de lectura que no coincide con el visual. Las columnas se reordenaron con estilos y en el código quedaron como estaban. El ojo ve una cosa y el lector de pantalla lee otra.
• Confirmaciones mudas. El formulario se envió, apareció el mensaje verde, el lector de pantalla no dijo nada. Se cura con un atributo que marca esa zona como viva.
• Etiquetas de los campos. La pista dentro del campo desaparece en cuanto la persona empieza a escribir, y deja de estar claro qué va ahí.

Cuánto cuesta corregirlo

Durante el desarrollo, nada. Nada de lo anterior es trabajo extra, es cuidado corriente: llamar botón a un botón, dejar el contorno de foco donde está, describir la imagen. Quien lo hace así desde el principio invierte exactamente el mismo tiempo.

En un sitio terminado el precio depende de con qué esté construido. Los arreglos puntuales como el nuestro son cuestión de horas. Si el sitio vive en un constructor donde el marcado se genera solo y la mitad no es tuya, el techo lo pone la plataforma.

Un apunte sobre los widgets superpuestos que prometen accesibilidad de sitios web en una línea de código. Colocan sobre la página un panel con botones de letra grande y tema de alto contraste. Eso no resuelve nada, porque el código de debajo sigue igual, y hay lectores de pantalla que se lían más con la superposición que sin ella. En Estados Unidos, cientos de demandas de los últimos años señalan a sitios que tenían instalado justo ese panel.

Por dónde empezar

Si todo esto es nuevo, empieza por el recorrido con Tab. Diez minutos, sin herramientas, y sabrás enseguida si tienes un problema.

Si aparecen fallos y no está claro de dónde vienen, eso ya es una auditoría web, donde contamos cómo revisar de forma sistemática y en qué orden corregir. El mismo tipo de desmontaje lo hicimos antes con la velocidad de carga de nuestro propio sitio, y la causa tampoco resultó ser la que esperábamos. Y si hay que meter accesibilidad en un sitio hecho con plantilla, mira primero dónde están los límites reales de un constructor: no todo lo de esta lista se puede arreglar allí.

← Volver al blog