Hemos revisado decenas de páginas web de los sectores público y privado. Y hay algo que llama la atención: los errores de accesibilidad son muy comunes. Se repiten. Una y otra vez. En organizaciones grandes y pequeñas, con presupuestos altos y bajos, con equipos de tecnología experimentados y novatos.

Aquí van los diez que aparecen con más frecuencia, explicados sin tecnicismos y con lo que necesitas para entender por qué importan.

Imágenes sin texto alternativo

Este es el error número uno en casi todas las auditorías de accesibilidad del mundo. Una imagen en una página web puede tener un atributo llamado alt que describe lo que muestra. Si ese atributo está vacío o ausente, alguien que use un lector de pantalla no sabrá qué hay en esa imagen.

El impacto varía. Una imagen decorativa sin alt es una molestia menor: el lector de pantalla anuncia “imagen_5968” y sigue adelante. Una imagen que contiene información importante (un gráfico, una infografía, un organigrama, un formulario en imagen) sin alt es completamente inaccesible.

Lo que pasa en la práctica: el equipo de comunicación sube una infografía con los datos del informe anual. No añade texto alternativo porque “se ve bien”. Para un usuario con discapacidad visual, esa información no existe.

La corrección: texto alternativo que describe el contenido y la función de cada imagen informativa. Si la imagen muestra a una niña leyendo un libro, el texto alternativo deberá decir “niña leyendo un libro”.

Contraste insuficiente entre texto y fondo

Los diseños modernos adoran los colores suaves, los grises claros, los textos en blanco sobre fotografías. El problema es que el ojo humano necesita suficiente diferencia de luminosidad entre el texto y el fondo para leer con comodidad. Cuando esa diferencia es baja, las personas con baja visión, daltonismo o simplemente con la pantalla al sol no pueden leer el contenido.

WCAG 2.1 exige una relación de contraste mínima de 4.5:1 para el texto normal y de 3:1 para el texto grande.

Lo que pasa en la práctica: el texto de los botones de llamada a la acción es blanco sobre un azul claro que “queda más moderno”. La relación de contraste es de 2.8:1, en incumplimiento directo de las regulaciones de accesibilidad del gobierno federal.

La corrección: revisar la paleta de colores con una herramienta de contraste antes de aprobar cualquier diseño. Ajustar los colores que no cumplan, sin cambiar necesariamente la identidad visual.

Formularios sin etiquetas visibles

Hay formularios que usan el placeholder (el texto de ejemplo dentro del campo) como única indicación de qué escribir en cada campo. Cuando el usuario empieza a escribir, el placeholder desaparece. Si pierde el hilo o comete un error, ya no sabe qué se le pedía.

Peor aún: muchos lectores de pantalla no anuncian el placeholder como etiqueta. El usuario llega a un campo y no sabe para qué sirve.

Lo que pasa en la práctica: el formulario de contacto tiene cuatro campos vacíos con texto de ejemplo. Sin etiquetas reales. Sin label asociado a cada input. Para un usuario de lector de pantalla, es un formulario de cuatro campos sin nombre.

La corrección: etiquetas visibles y permanentes para cada campo del formulario. Las etiquetas en el HTML deben estar correctamente asociadas a su input correspondiente.

Errores de formulario sin indicación clara

Cuando un formulario rechaza el envío por errores, ¿cómo lo comunicas? Si la única indicación es que los campos incorrectos se ponen en rojo, alguien que no percibe el color rojo no sabe qué ha fallado. Si el mensaje de error solo aparece arriba de la página, pero el foco del teclado no se mueve ahí, alguien que navega con el teclado puede no verlo.

Lo que pasa en la práctica: el usuario rellena un formulario largo, pulsa “Enviar”, y nada parece pasar. En realidad, hay tres errores de validación indicados solo con un borde rojo en los campos incorrectos. No hay mensaje de texto, descripción del error ni indicación de cómo corregirlo.

La corrección: mensajes de error en texto (no solo en color), descriptivos (“El formato del correo electrónico no es válido”, no solo “Error”), asociados específicamente al campo que los genera, y con foco automático en el primer error.

Navegación imposible con teclado

Todo lo que se puede hacer con el ratón o “mouse” debe poder hacerse con el teclado. Esta es una regla básica de accesibilidad. Los usuarios con discapacidad motriz que no pueden usar el ratón, los usuarios ciegos que navegan con lectores de pantalla y los usuarios avanzados que prefieren el teclado dependen de esto.

El error más común: menús desplegables, modales y carruseles que solo responden al pasar el ratón por encima y son completamente inoperables desde el teclado.

Lo que pasa en la práctica: el menú principal tiene submenús que aparecen al pasar el ratón por encima. Con el teclado, esos submenús no se pueden abrir. Las secciones del segundo nivel del sitio son inaccesibles para cualquier usuario sin ratón.

La corrección: todos los componentes interactivos deben funcionar con el teclado. La tecla Tab navega entre elementos. Enter o Espacio activan acciones. Escape cierra modales. Los menús desplegables se abren y cierran con las flechas de navegación.

Indicador de foco invisible

Cuando navegas con el teclado, el navegador muestra qué elemento está seleccionado mediante un indicador visual (normalmente un borde o resaltado). Muchos diseñadores lo eliminan porque “queda feo”. El resultado es que los usuarios de teclado no saben dónde están en la página.

Lo que pasa en la práctica: el CSS del sitio incluye outline: none o outline: 0 de forma global, eliminando el indicador de foco en todos los elementos. El usuario que navega con el teclado ve los elementos resaltarse y no resaltarse sin ninguna indicación visual de cuál está activo.

La corrección: nunca eliminar el indicador de foco sin sustituirlo por uno mejor. WCAG 2.1 incluso añadió criterios específicos para garantizar que el foco sea visible y no quede oculto por otros elementos.

Vídeos sin subtítulos

El contenido audiovisual sin subtítulos es inaccesible para personas con discapacidad auditiva. Pero también para personas que están en un entorno ruidoso, que están aprendiendo el idioma o que simplemente prefieren leer.

Lo que pasa en la práctica: el portal publica vídeos informativos sobre sus servicios, con subtítulos generados automáticamente que no han sido revisados. Los subtítulos automáticos sin revisión humana suelen tener una tasa de error que los hace difícilmente comprensibles para contenido técnico o formal.

La corrección: subtítulos sincronizados y revisados para todo el contenido audiovisual. Para contenido en directo, subtítulos en tiempo real si se trata de un servicio público esencial.

PDFs inaccesibles

Los portales corporativos y públicos publican enormes cantidades de contenido en PDF: informes, formularios, normativa, convocatorias. Una gran parte de estos archivos son inaccesibles.

Los problemas más frecuentes: PDFs que son imágenes escaneadas sin texto seleccionable (sin OCR), PDFs sin estructura de etiquetas (sin heading, sin listas, sin orden de lectura definido), tablas sin encabezados, formularios PDF que no se pueden rellenar con el teclado.

Lo que pasa en la práctica: las empresas escanean documentos físicos y los suben como PDF. Los lectores de pantalla ven un documento vacío. La información, sencillamente, no existe para estos usuarios.

La corrección: PDFs con texto real (no imágenes). Estructura de etiquetas correcta. Para formularios, optar por formularios web accesibles sobre formularios PDF siempre que sea posible.

Estructura de encabezados inconsistente o ausente

Los encabezados (H1, H2, H3…) no son solo elementos visuales para hacer el texto más grande. Es la estructura del documento, el índice que los lectores de pantalla usan para navegar. Un usuario ciego puede saltar entre encabezados para hacerse una idea del contenido de una página larga sin tener que escucharla completa.

Lo que pasa en la práctica: los redactores usan encabezados según el tamaño visual que quieren conseguir, no según la jerarquía semántica. Una página tiene un H1, luego varios H3 que son realmente H2, luego un H2 que es realmente un H3. La estructura es incoherente. Los saltos de nivel (de H1 a H4 sin H2 ni H3) son especialmente problemáticos.

La corrección: la jerarquía de encabezados debe reflejar la estructura real del contenido. Un único H1 por página (el título principal). H2 para las secciones principales. H3 para subsecciones dentro de cada H2. Sin saltos de nivel.

Idioma de la página no declarado

El idioma del documento HTML debe declararse en el código de la página. Parece un detalle técnico menor, pero tiene un impacto directo: los lectores de pantalla usan esa información para pronunciar el contenido correctamente. Si la página está en español pero el código indica que está en inglés (o no dice nada), el lector de pantalla intentará pronunciar el texto en español con la fonética inglesa. El resultado es incomprensible.

Lo que pasa en la práctica: la plantilla HTML fue desarrollada en inglés y el atributo lang=”en” nunca fue cambiado al adaptar el sitio para el mercado hispanohablante.

La corrección: (o el código del idioma correspondiente) en todas las páginas. Si una página contiene fragmentos en otro idioma, etiquetar esos fragmentos con el atributo lang correcto.

El patrón que hay detrás de todos estos errores

Si observas la lista, verás que muy pocos de estos errores son errores técnicos complejos. La mayoría son errores de omisión: no se pensó en ello, no había un proceso que lo revisara, nadie era responsable de comprobarlo.

La accesibilidad no falla porque los equipos no sepan cómo hacerlo. Falla porque no hay un proceso que la incluya como criterio de aceptación en cada iteración, en cada nueva funcionalidad, en cada actualización de contenido.

Si deseas un equipo experto que evalúe la accesibilidad de tu página web, agenda una consulta gratuita con nosotros hoy, visitando invidgroup.com o haciendo clic aquí.