Errores técnicos que hacen tu web inaccesible (y cómo evitarlos)

Cuando hablamos de accesibilidad web, mucha gente piensa en colores, tipografías y diseño visual. Pero la verdad es que la accesibilidad empieza (y muchas veces termina) en el desarrollo. Puedes tener una web preciosa, pero si el código está mal hecho, hay una gran parte de tus usuarios que directamente no podrán usarla.

Y ojo: no hablo solo de personas con discapacidad. Una web inaccesible puede ser un problema para cualquiera. Una mala conexión, un dispositivo antiguo, un usuario que navega sin ratón… Todo esto entra en juego.

Hoy quiero contarte los errores técnicos más comunes que me encuentro en webs y cómo evitarlos desde el desarrollo. Porque arreglarlo después cuesta más tiempo, más dinero y más dolores de cabeza.

1. Usar div para todo y olvidarse de la semántica

Uno de los errores más comunes es no usar HTML semántico. Es decir, usar div y span para todo, como si fueran piezas genéricas que puedes colocar sin pensar.

Por ejemplo:

<div class="titulo">Bienvenidos a nuestra web</div>Lenguaje del código: HTML, XML (xml)

En vez de:

<h1>Bienvenidos a nuestra web</h1>
Lenguaje del código: HTML, XML (xml)

Por qué es un problema:

• Los lectores de pantalla no saben qué es importante y qué no.
• Pierdes jerarquía visual y estructural.
• Afecta al SEO, porque los motores de búsqueda no entienden bien tu contenido.

Solución:
Usar siempre etiquetas semánticas (<header>, <main>, <nav>, <section>, <article>, <footer>…) y encabezados (h1 a h6) de forma jerárquica y coherente.

2. Formularios sin etiquetas bien asociadas

Este es un clásico: formularios en los que el campo de texto no está asociado a su etiqueta, o directamente no hay etiqueta. Lo típico:

<input type="text" placeholder="Nombre">
Lenguaje del código: HTML, XML (xml)

Esto es un problema porque un placeholder no sustituye a una etiqueta. El texto desaparece al escribir, y además los lectores de pantalla no lo interpretan igual.

Solución:
Asociar siempre la etiqueta al campo con el atributo for y el id correspondiente:

<label for="nombre">Nombre</label>
<input id="nombre" type="text">
Lenguaje del código: HTML, XML (xml)

Y si quieres usar un placeholder, que sea solo un apoyo, nunca la única referencia.

3. Imágenes sin alt o con texto alternativo mal puesto

El atributo alt no está ahí para poner “imagen bonita” o dejarlo vacío. Su función es describir lo que la imagen transmite para quien no puede verla.

Errores típicos:

• Dejar el alt vacío en imágenes clave.
• Poner texto genérico (“imagen de producto”) en vez de algo descriptivo.
• Usar el alt para meter palabras clave sin sentido (keyword stuffing).

Solución:

• Si la imagen es informativa, describe su contenido o función.
• Si es decorativa, deja el alt vacío (alt="") para que los lectores de pantalla la ignoren.
• No abuses de palabras clave, Google lo detecta y los usuarios lo sufren.

4. Contrastes definidos solo en diseño, no en código

Otro error es que el diseñador defina un buen contraste visual… pero el desarrollador no lo respete al implementarlo. Cambios mínimos en colores, opacidades o fondos pueden hacer que un texto sea ilegible para muchas personas.

Solución:

• Comprobar el contraste con herramientas como WebAIM Contrast Checker.
• Seguir las pautas WCAG: mínimo 4.5:1 para texto normal y 3:1 para texto grande.

5. Navegación imposible sin ratón

¿Has probado a navegar por tu web solo con el teclado? Mucha gente no lo hace, pero es un test rápido que revela muchos problemas:

• Elementos que no reciben foco.
• Menús que no se pueden desplegar con teclado.
• Formularios donde no puedes pasar de un campo a otro.

Solución:

• Usar tabindex correctamente para definir el orden de tabulación.
• Asegurarte de que todos los elementos interactivos son accesibles vía teclado.
• No deshabilitar el foco visual (ese borde azul o resaltado) sin poner una alternativa visible.

6. ARIA mal implementado

Las etiquetas ARIA (aria-label, aria-hidden, etc.) son muy útiles para mejorar accesibilidad, pero mal usadas hacen más daño que bien. El error más común es poner aria-hidden="true" en elementos que son importantes, o usar aria-label para reemplazar contenido que debería estar en HTML semántico.

Solución:

• Usar ARIA solo cuando no hay una etiqueta HTML que cumpla la misma función.
• No ocultar elementos necesarios para la navegación o comprensión del contenido.

7. Elementos interactivos sin rol o sin ser botones/enlaces reales

Si algo parece un botón, debería ser un <button> y no un <div> con un onclick. Lo mismo con los enlaces: un <a> con href, no un span que abre otra página.

Por qué es importante:

• Los lectores de pantalla no reconocen un div como un botón.
• La navegación por teclado deja de funcionar correctamente.
• Pierdes funciones nativas (por ejemplo, pulsar «Enter» en un <button>).

Solución:
Usar siempre el elemento HTML adecuado para la función que cumple.

8. Falta de jerarquía en los encabezados

Otro fallo habitual es usar encabezados por estética, no por estructura. Pasar de un h1 a un h4 sin lógica, o usar h1 en varios sitios sin motivo.

Solución:

• Un solo h1 por página.
• Encabezados descendentes sin saltar niveles.
• Pensar en los encabezados como el índice de un libro.

9. Scripts que bloquean el contenido

A veces el código carga tanto JavaScript antes de mostrar el contenido, que la web es inutilizable para quienes usan lectores de pantalla o conexiones lentas. Esto también penaliza en SEO.

Solución:

• Cargar scripts de forma diferida (defer o async).
• Priorizar el contenido HTML visible antes que scripts secundarios.

10. No probar con usuarios reales

Puedes pasar todas las validaciones automáticas, pero si no pruebas con usuarios que realmente necesiten accesibilidad, te vas a dejar problemas sin detectar.

Solución:

• Usar validadores como WAVE o Lighthouse.
• Pero también hacer pruebas con lectores de pantalla (NVDA, VoiceOver) y navegación por teclado.
• Y, si es posible, involucrar a usuarios reales en las pruebas.

Conclusión

La accesibilidad web no es solo un requisito legal o un gesto de buena voluntad. Es una parte esencial de un desarrollo profesional. Ignorarla significa dejar fuera a personas, perder oportunidades de negocio y arriesgarte a sanciones.

La buena noticia es que hacerlo bien desde el desarrollo es más fácil y barato que tener que rehacer todo después. Y no, no se trata de “hacer algo especial”: se trata de usar bien las herramientas que ya tenemos.

Si quieres que tu web sea accesible desde el código, haz una auditoría técnica. Detecta estos errores, corrígelos y verás cómo no solo mejoras la experiencia de tus usuarios, sino también tu posicionamiento y rendimiento.

💡 En Rights Webs desarrollamos sitios web accesibles desde la base, para que cualquier persona pueda usarlos sin barreras. Si quieres que revisemos tu web, contáctanos y te decimos dónde puedes mejorar.