Tu agencia entrega el proyecto. La web tiene buena pinta, carga rápido y en mobile se ve bien. A los seis meses recibes un aviso de un usuario que no puede navegar con teclado. Luego descubres que los formularios de contacto no funcionan con lector de pantalla. Y que los colores del botón principal no superan el contraste mínimo exigido por la WCAG.
La agencia te dice que eso no estaba en el alcance. Y tiene razón: nadie lo incluyó. Nadie lo preguntó. Nadie lo auditó antes de entregar.
Así funciona la accesibilidad web en el 80% de los proyectos digitales: como algo que se añade al final si sobra tiempo y presupuesto. En este post: por qué ese enfoque es un error costoso, qué falla habitualmente en el proceso de las agencias, y cómo debería abordarse desde el primer día en un proyecto de diseño UX/UI serio.
Por qué la accesibilidad web no es un extra — es parte del diseño
Existe una idea extendida en el sector: la accesibilidad es una obligación legal para grandes corporaciones o servicios públicos, y el resto puede ignorarla hasta que alguien se queje. Es una idea cómoda. Y es incorrecta en varios sentidos.
Primero, el alcance real. Según la OMS, más del 15% de la población mundial tiene algún tipo de discapacidad. En España, el Real Decreto 1112/2018 ya obliga a los sitios del sector público a cumplir el nivel AA de la WCAG 2.1, y la Directiva Europea de Accesibilidad amplía ese marco al sector privado de forma progresiva. No es una tendencia futura: es legislación vigente.
Segundo, el argumento de negocio. Las webs accesibles cargan más rápido, tienen mejor estructura semántica (lo que favorece el SEO), funcionan mejor en condiciones adversas (mala conexión, pantalla con mucho sol, un brazo escayolado) y convierten mejor en móvil. La accesibilidad no es UX para una minoría: es UX para todos, en sus peores momentos.
Tercero, el coste. Añadir accesibilidad desde el diseño cuesta entre diez y veinte veces menos que corregirla sobre código entregado. No es una estimación académica: es lo que vemos en los proyectos que auditamos después de pasar por otras agencias.
Error 1 — Diseñar sin especificar los estados de foco
El foco es lo que indica al usuario dónde está cuando navega con teclado, lector de pantalla o cualquier dispositivo de asistencia. Es el equivalente visual del cursor del ratón para quien no puede usar el ratón.
El error más habitual: el diseñador elimina el anillo de foco predeterminado del navegador (outline: none en CSS) porque «se ve feo» y no especifica un estado alternativo. El resultado es una interfaz que parece limpia visualmente y es completamente inutilizable para quien depende del teclado.
La señal de que una agencia no lo gestiona bien: entregan un sistema de diseño o un Figma con estados default, hover y active para los componentes interactivos, pero no hay ningún estado focus documentado. Si no está en el diseño, no va a estar en el desarrollo.
Tip técnico: :focus-visible como alternativa precisa a :focus
La pseudoclase :focus-visible permite mostrar el anillo de foco solo cuando el usuario navega con teclado o dispositivo de asistencia, sin afectar la experiencia visual de quien usa el ratón. Es compatible con todos los navegadores modernos desde 2022. La implementación correcta en CSS es definir un estilo :focus { outline: none } combinado con un :focus-visible { outline: 3px solid [color-de-marca]; outline-offset: 2px } que cumpla el ratio de contraste mínimo de 3:1 contra el fondo. Esto resuelve el conflicto entre limpieza visual y accesibilidad sin sacrificar ninguno de los dos.
Error 2 — Textos alternativos que no alternan nada
El atributo alt en las imágenes no es un requisito técnico que se rellena con el nombre del archivo. Es el texto que describe la imagen a quien no puede verla. Y es, junto con el contraste, el error más frecuente en cualquier auditoría.
Hay dos fallos opuestos igual de comunes. El primero: imágenes sin alt o con alt="" cuando la imagen tiene contenido informativo relevante. El lector de pantalla lo ignora o lee el nombre del archivo («IMG_4821.jpg»). El segundo: imágenes decorativas con alt prolijo que interrumpe la lectura del contenido real. Una imagen de fondo puramente decorativa debe llevar alt="" para que el lector de pantalla la omita.
La distinción no es obvia si nadie la ha explicado. Y la mayoría de las agencias no la explican porque no forman a sus diseñadores ni a sus redactores en este criterio.
Error 3 — Contraste que solo funciona en pantallas de diseñador
Los diseñadores trabajan en monitores calibrados, en entornos controlados, con brillo alto. Sus usuarios abren la web en el metro, con el sol de frente, en un móvil de gama media con el brillo al mínimo para ahorrar batería.
La WCAG 2.1 exige un ratio de contraste mínimo de 4,5:1 para texto normal y 3:1 para texto grande. Esto no es un capricho burocrático: es el umbral por debajo del cual una parte significativa de usuarios con baja visión no puede leer el contenido. Los grises claros sobre blanco, los textos de placeholder en formularios, los botones en tonos pasteles de moda: casi siempre incumplen.
El problema de fondo no es el diseñador: es que nadie en el proceso de revisión pasa un verificador de contraste antes de aprobar el sistema de diseño. Herramientas como Figma Contrast o el plugin Stark detectan estos errores en segundos. Si no están en el flujo de trabajo, los errores llegan a producción.
Error 4 — Formularios sin etiquetas visibles y asociadas
Un formulario sin etiquetas correctamente asociadas a sus campos es uno de los errores más graves desde el punto de vista de accesibilidad. Y uno de los más comunes en webs que visualmente parecen cuidadas.
El diseño suele resolver el problema de forma visual: el placeholder dentro del campo indica qué hay que introducir. El problema es que el placeholder desaparece cuando el usuario empieza a escribir. Para alguien que navega con lector de pantalla, si el campo no tiene un <label> asociado mediante el atributo for o mediante aria-label, el campo simplemente no tiene nombre. El lector anuncia «campo de texto» sin más contexto.
En el proyecto FIHGUV (Fundación de Investigación del Hospital General de Valencia), uno de los requisitos desde el briefing era que la web fuera funcional para profesionales médicos y pacientes con distintos niveles de habilidad digital. Eso nos obligó a construir todos los formularios con etiquetas visibles y semánticamente correctas desde el primer wireframe, no como corrección posterior. El resultado: cero errores de formulario en la auditoría de accesibilidad final. Cuando el requisito está al inicio, el coste es marginal.
Error 5 — La jerarquía de encabezados como decisión estética
Los encabezados (H1, H2, H3…) no son una herramienta de estilo: son la estructura del documento. Son lo que usa un lector de pantalla para navegar por el contenido sin leer todo de arriba a abajo. Son lo que usa Google para entender la arquitectura informativa de una página.
El error habitual: el diseñador decide los tamaños de texto por criterio visual y el desarrollador traduce ese tamaño en un nivel de encabezado. Un texto grande → H2. Un texto mediano → H3. Sin importar si hay un H1 antes, sin importar si el H3 es hijo lógico del H2 anterior. El resultado es una jerarquía rota que desinforma tanto al usuario como al motor de búsqueda.
La corrección es simple pero requiere que diseño y desarrollo hablen el mismo idioma desde el principio: los estilos tipográficos del sistema de diseño deben separar claramente el nivel semántico del estilo visual. Un componente puede tener apariencia de H3 pero renderizar como H2 según el contexto en el que aparezca. Si nadie ha pensado esto en el sistema de diseño, no ocurrirá en el desarrollo.
¿Tu agencia puede mostrarte el informe de Lighthouse de accesibilidad de tu web antes de que lo pidas tú?
Cómo debe abordarse la accesibilidad en un proyecto real
La accesibilidad no se audita al final: se diseña desde el principio. Esto tiene implicaciones concretas en cada fase del proyecto.
En la fase de diseño, el sistema de diseño debe documentar estados de foco, ratios de contraste, etiquetas de componentes y variantes de texto alternativo. No es trabajo extra: es parte de un sistema de diseño bien construido, como explicamos en detalle en el post sobre qué es un sistema de diseño y cuándo necesitas uno de verdad.
En la fase de desarrollo, las revisiones de accesibilidad no son opcionales. Herramientas como axe DevTools o WAVE permiten detectar errores automáticos en segundos. No cubren el 100% de los casos (la evaluación humana sigue siendo necesaria para criterios complejos), pero eliminan los errores más frecuentes antes de que lleguen a producción.
En la entrega, el informe de accesibilidad debería ser parte del handoff estándar, al mismo nivel que el informe de rendimiento o las instrucciones de mantenimiento. Si nadie lo ha pedido, la conversación no ha empezado bien.
Lo que debes pedir a tu agencia antes de firmar
- ¿El sistema de diseño incluye estados de foco documentados para todos los componentes interactivos?
- ¿Pueden mostrarte el informe de Lighthouse Accessibility de algún proyecto reciente?
- ¿Está especificado en el contrato el nivel WCAG que se va a cumplir?
- ¿El equipo de diseño usa verificadores de contraste (Figma Contrast, Stark) en su flujo habitual?
- ¿Los formularios del proyecto incluyen etiquetas
<label>visibles y correctamente asociadas? - ¿Hay pruebas manuales con teclado y lector de pantalla en el proceso de QA?
- ¿El informe de accesibilidad forma parte de la entrega estándar o es un servicio adicional?
Preguntas frecuentes sobre accesibilidad web
¿Qué nivel de la WCAG debe cumplir mi web?
El nivel AA es el estándar razonable para la mayoría de webs comerciales y de servicios. El nivel A solo cubre los requisitos mínimos absolutos — hay barreras significativas que no resuelve. El nivel AAA es muy restrictivo y no es obligatorio ni práctico para webs generales. Si tu web es de un organismo público o presta servicios digitales en la UE, el nivel AA es obligatorio por normativa vigente.
¿La accesibilidad web afecta al SEO?
Directamente, sí. Una jerarquía de encabezados correcta, el texto alternativo en imágenes, la velocidad de carga (relacionada con un código limpio y semántico) y la compatibilidad con cualquier dispositivo son factores que Google valora. Una web accesible tiene, por definición, mejor arquitectura de contenido que una que no lo es.
¿Cuánto cuesta añadir accesibilidad a una web ya construida?
Depende del estado del código y de cuántos errores se detecten. Una auditoría inicial con correcciones de los errores más críticos puede estar entre 800 y 3.000 euros para webs de tamaño medio. Si hay que rehacer componentes completos o la arquitectura semántica está muy degradada, el coste puede multiplicarse. Por eso importa integrarlo desde el inicio: no es lo mismo diseñar accesible que corregir lo que no lo es.
¿Qué herramienta puedo usar para hacer una primera auditoría de mi web?
Lighthouse (integrado en Chrome DevTools) da una puntuación inicial y detecta los errores más comunes de forma gratuita. WAVE y axe DevTools son extensiones de navegador más detalladas. Ninguna cubre el 100% de los criterios WCAG — para eso se necesita evaluación humana — pero permiten identificar los problemas más frecuentes en minutos.
