Actualizado en March 2026
¿Te preocupa que la web del negocio no cumpla la ley y pierda clientes con discapacidad? ¿Se teme una sanción o una queja que dañe la reputación? Esta guía ofrece una ruta práctica y localizada para obtener cumplimiento en España, con pasos claros, checklist, herramientas para principiantes y estimaciones de coste.
Puntos clave: Lo que debes saber en 1 minuto
- Obligatorio para ciertos sectores: Las obligaciones legales (EAA y normativa española) afectan sobre todo a administraciones públicas y servicios de interés general; cada empresa debe verificar su caso concreto.
- Cumplimiento técnico vs. usabilidad real: Pasar un test automático no garantiza accesibilidad real; pruebas con usuarios y revisión manual son imprescindibles.
- Proceso claro y escalable: Auditoría → plan de adaptación → implementación → pruebas con usuarios → declaración de accesibilidad.
- Coste y tiempo variables: Una web pequeña puede necesitar desde 1.000–3.000 €; proyectos complejos suben a 8.000–30.000 € según alcance.
- Documentación obligatoria: Un certificado formal no siempre existe; sí es obligatorio publicar una declaración de accesibilidad y plan de mejoras según la normativa española.
Por qué se necesita certificado de accesibilidad en España
La normativa europea (EAA/European Accessibility Act) y las leyes nacionales establecen obligaciones para ciertos tipos de servicios y productos digitales. En España, el Real Decreto 1112 regula la accesibilidad de los sitios web y las aplicaciones móviles del sector público. Además, la EAA exige que productos y servicios clave cumplan criterios de accesibilidad.
Para empresas privadas, la obligación concreta depende del sector y de si el servicio se considera de interés general. Aun cuando no exista una multa inmediata, disponer de una declaración de accesibilidad y de un plan de mejoras demuestra diligencia y reduce riesgos legales y reputacionales.
Fuentes técnicas: WCAG (W3C) define criterios testables; ver WCAG. Para contexto legal, consultar EAA (EU) y el BOE español.
Señales de incumplimiento de accesibilidad web
Detectar señales tempranas permite priorizar intervenciones. Señales comunes:
- Ausencia de texto alternativo en imágenes importantes (logo, botones, productos).
- Estructura de encabezados errática (saltos H1→H3, uso de divs en lugar de h2/h3).
- Contraste insuficiente entre texto y fondo (especialmente en CTAs).
- Formularios inaccesibles: etiquetas ausentes, campos sin aria-label, errores no anunciados.
- Navegación por teclado rota: elementos no focables o foco invisible.
- Contenidos que parpadean o se mueven sin control.
- Falta de subtítulos en vídeos o transcripciones.
Si se detectan varias de estas señales, la web puede no solo fracasar en tests, sino excluir usuarios reales.
Diferencia entre accesibilidad y diseño responsive
Ambos términos mejoran la experiencia, pero son conceptos distintos:
- Accesibilidad: se centra en permitir que personas con diferentes discapacidades (visuales, auditivas, cognitivas, motoras) accedan a la información y funciones. Se basa en criterios técnicos (WCAG) y en pruebas con usuarios reales.
- Diseño responsive: garantiza que la interfaz se adapte a distintos tamaños de pantalla y dispositivos (móvil, tablet, desktop). Es necesario pero no suficiente para la accesibilidad.
un menú responsive que solo aparezca tocando un icono sin alternativa para teclado o lector de pantalla cumple responsive pero no accesible.
Cómo comprobar cumplimiento: auditoría práctica combinada
Una auditoría robusta mezcla pruebas automáticas, revisión manual y pruebas con usuarios. Pasos mínimos:
- Ejecutar un escaneo automático con herramientas (axe, WAVE, Lighthouse) para identificar errores evidentes.
- Revisar manualmente puntos críticos: encabezados, botones, formularios, roles ARIA, orden de foco.
- Validar contraste con herramientas como Colour Contrast Analyzer.
- Realizar 3–5 pruebas con usuarios reales que tengan discapacidad (lectores de pantalla, baja visión, movilidad reducida).
- Generar informe con prioridades (crítico, alto, medio, bajo).
Herramientas recomendadas: axe, WAVE, Lighthouse.
Adaptar sitio web accesible paso a paso
Paso 1: auditoría inicial y priorización
Realizar un escaneo técnico y una revisión manual. Identificar las pantallas con más tráfico (home, ficha producto, formulario de contacto) y priorizarlas. Documentar errores y asignar gravedad.
Paso 2: elaborar plan de adaptación (roadmap)
Definir acciones por sprint: arreglos críticos (contraste, texto alternativo), correcciones de foco y etiquetas, mejoras en formularios, subtítulos y transcripciones. Incluir responsable, coste estimado y plazo.
Paso 3: implementar correcciones técnicas
Corregir HTML semántico, añadir roles ARIA cuando proceda, asegurar foco visible, implementar skip links, y mejorar contraste. Incluir pequeños fragmentos de código con buenas prácticas:
<!-- Botón accesible con aria-label y foco visible -->
<button aria-label="Cerrar ventana" class="btn-close">✕</button>
<!-- Imagen con alt descriptivo -->
<img src="/producto.jpg" alt="Chaqueta impermeable azul hombre talla M">
<!-- Campo de formulario con label asociado -->
<label for="email">Correo electrónico</label>
<input id="email" name="email" type="email" required aria-required="true">
Paso 4: pruebas con usuarios y ajustes
Realizar sesiones moderadas con personas con discapacidad y recoger observaciones de uso real. Priorizar correcciones que influyan en conversión (checkout, contacto).
Paso 5: documentación y declaración de accesibilidad
Publicar la declaración de accesibilidad con el nivel de conformidad, las páginas probadas, las limitaciones conocidas y el plan de mejoras.
Paso 6: mantenimiento continuo
Incluir accesibilidad en el control de calidad de cada release: checklist en pull requests, pruebas automáticas en CI, comprobaciones mensuales y pruebas de usabilidad trimestrales.
Herramientas de accesibilidad web para principiantes
Lista para empezar con poco conocimiento técnico:
- axe DevTools (extensión): fácil y ofrece explicaciones de cada fallo. Visitar axe
- WAVE (web): visualiza problemas en la página. Ver WAVE
- Lighthouse (Chrome): incluye auditoría de accesibilidad integrada.
- Colour Contrast Analyzer: para comprobar contraste de color.
- NVDA (lector de pantalla gratuito para Windows): permite escuchar cómo navega un lector de pantalla.
- VoiceOver (mac/iOS) y TalkBack (Android): probar en dispositivos móviles.
Para plantillas y checklist listos para usar, adaptar una lista básica: etiquetas en inputs, roles en botones, texto alternativo, orden lógico de foco, subtítulos en vídeos, evitar texto en imágenes sin alternativa.
Guía simple de coste para adaptar la accesibilidad
A continuación una tabla comparativa con estimaciones orientativas. Los costes son aproximados y dependen de la tecnología y del grado de incumplimiento.
| Tipo de sitio |
Intervención mínima |
Rango de coste (€) |
Tiempo estimado |
| Micro web (1–10 páginas) |
Correcciones básicas, declaración |
1.000–3.000 |
1–3 semanas |
| Tienda online mediana (100–500 págs) |
Revisión de UX, formularios, checkout |
4.000–12.000 |
4–8 semanas |
| Plataforma compleja / app |
Rearquitectura accesible, testing con usuarios |
8.000–30.000+ |
2–4 meses |
Estas cifras incluyen auditoría, correcciones front-end y pruebas con usuarios. No incluyen migraciones de tecnología ni reescrituras completas. Para presupuestos precisos, solicitar un alcance detallado.
Cómo funciona realmente la adaptación para ecommerce y fichas de producto
Priorizar las páginas que generan conversión. Acciones concretas:
- Fichas de producto: alt en imágenes, descripciones textuales completas, atributos accesibles en selectores, posibilidad de aumentar tamaño de fuente.
- Carrito/checkout: etiquetas en campos, mensajes de error claros y visibles, teclado totalmente funcional.
- Imágenes de producto con zoom: añadir control accesible y texto alternativo detallado.
Para tiendas grandes, automatizar la incorporación de alt text mediante CMS o procesos editorial puede ahorrar tiempo.
Ejemplos de código y patrones UI reutilizables
Patrón: skip link para saltar a contenido principal (útil para usuarios de teclado):
<a href="#main-content" class="skip-link">Saltar al contenido principal</a>
<main id="main-content"> ... </main>
Patrón: anuncio de error accesible en formularios:
<div aria-live="assertive" class="form-errors" role="status"></div>
Evitar patrones problemáticos: menús que dependen exclusivamente de hover o gestos táctiles sin alternativa.
Proceso de adaptación accesible
🕵️♂️
Paso 1
Auditoría técnica
➡️
🗂️
Paso 2
Planificación y prioridades
➡️
🛠️
Paso 3
Implementación técnica
➡️
👥
Paso 4
Pruebas con usuarios
➡️
📄
Resultado
Declaración pública y mantenimiento
Ventajas, riesgos y errores comunes
Beneficios / Cuándo aplicar ✅
- Mejora del alcance de mercado y de la imagen de marca.
- Reducción de riesgo legal y reputacional.
- Aumento potencial de conversiones al mejorar la usabilidad para todos.
Errores que debes evitar / Riesgos ⚠️
- Confiar únicamente en escáneres automáticos.
- No probar con usuarios reales.
- Implementar soluciones parche que rompen SEO o rendimiento.
Preguntas frecuentes
¿Qué es la declaración de accesibilidad y cómo hacerla?
La declaración de accesibilidad es un documento público que indica el nivel de conformidad, las páginas evaluadas, las limitaciones y el plan de mejoras. Debe incluir datos de contacto para reclamaciones.
¿La accesibilidad mejora el SEO?
Sí. Mejor estructura semántica, texto alternativo y contenido legible suelen mejorar rastreo y posicionamiento.
No siempre; la obligación depende del sector. Sin embargo, la mayoría de sitios se benefician de publicar una declaración y un plan de acción.
Depende del alcance, pero normalmente entre 4 y 8 semanas si se priorizan pantallas críticas.
¿Las herramientas automáticas son suficientes?
No. Detectan muchos problemas, pero no sustituyen pruebas manuales ni con usuarios reales.
¿Qué normativa seguir: WCAG 2.1 o 2.2?
Se recomienda aplicar el nivel AA de la versión más actual aceptada en el marco legal. Consultar W3C para la versión vigente.
¿Qué hacer si un tercero (CMS, plugin) genera inaccesibilidad?
Documentar el problema, buscar alternativas accesibles o solicitar soporte al proveedor. En casos críticos, desarrollar solución a medida.
Siguientes acciones
- Realizar una auditoría rápida (automática + revisión manual) en las páginas críticas.
- Publicar inmediatamente una declaración de accesibilidad provisional indicando plan de mejoras.
- Planificar pruebas con 3 usuarios reales y corregir los fallos críticos en el siguiente sprint.
