¿Sabías que una de cada siete personas tiene alguna discapacidad y muchas abandonan compras por barreras digitales? La web obsoleta roba conversiones, complica ventas móviles y añade riesgos legales. Una intervención práctica y económica puede modernizar la tienda sin quebrar el presupuesto; sus pasos son replicables por un equipo pequeño o por un desarrollador externo.
Un diseño web accesible adapta tu sitio para que personas con discapacidades (visuales, auditivas, cognitivas o motoras) lo usen sin barreras; mejora la experiencia, el SEO y la conversión. Aquí verás qué normas seguir (WCAG/EN), prioridades prácticas, ejemplos de código y un plan paso a paso para hacerlo en una pyme sin complejidad técnica.
Este artículo ofrece metodologías, ejemplos y un checklist básico en texto dentro del cuerpo del contenido; los patrones de código ejemplares aparecen en secciones prácticas. Para obtener plantillas o repositorios completos, debe facilitarse un enlace al repositorio de recursos asociado.
Resumen del proceso
Este bloque resume los pasos prácticos para llevar una pyme de una web obsoleta a una tienda accesible. Cada paso es replicable por un equipo pequeño o por un desarrollador externo.
- Auditoría rápida (0–7 días): combinar herramientas automáticas y revisión manual.
- Arreglos de alto impacto (7–30 días): contraste, alt text, navegación por teclado.
- Pruebas con usuarios (30–60 días): escenarios de compra en móvil y escritorio.
- Integración continua (60+ días): checklist en tareas y formación básica.
- Medición y ajuste: comparar métricas antes/después y priorizar según impacto.
Un checklist práctico y un plan de implementación paso a paso aceleran el trabajo en pymes:
- Inventario rápido (2–6 h): catálogo CSV de URLs clave y componentes; criterio: lista completa de páginas de producto, carrito y checkout
- Arreglos de alto impacto (8–40 h): contraste (4.5:1), alt text en imágenes prioritarias, navegación por teclado en flujos de compra; criterio: pruebas automatizadas limpias y verificación manual en 3 rutas críticas
- Pruebas con usuarios (8–24 h): 3–5 sesiones moderadas en móvil y escritorio; criterio: tasa de éxito >80% en el checkout
- Integración continua (4–12 h): checklist en PRs y revisión básica en cada sprint; criterio: 0 regresiones en controles críticos
Paso 1: diagnóstico rápido
La auditoría inicial detecta problemas visibles y define prioridades en horas de trabajo. El resultado es una lista priorizada con acciones de alto impacto.
Herramientas automáticas
Ejecutar Lighthouse y axe para obtener un primer mapa de fallos. Estos analizadores detectan problemas de contraste, metadatos y estructura.
Revisión manual esencial
Comprobar navegación por teclado y foco visible con navegador y lector de pantalla. Esta revisión encuentra problemas que las herramientas automáticas no ven.
Entregable y priorización
Generar una lista con prioridad alta/media/baja y estimación de horas. La lista sirve para planificar las tareas del sprint.
Paso 2: arreglos de alto impacto
Priorizar lo que da resultado rápido: contraste, etiquetas, foco y texto alternativo. Estas acciones suelen reducir fricciones en el checkout.
Contraste y tipografía
Asegurar contraste mínimo AA según WCAG 2.1: al menos 4.5:1 para texto normal y 3:1 para texto grande, comprobando los cambios con herramientas automáticas y pruebas manuales en escenarios reales. Cambiar colores lleva pocas horas y mejora la lectura.
Usar
Botones y controles táctiles
Tamaño mínimo de botón y texto descriptivo en el elemento. Evitar usar solo iconos sin texto visible.
Plazo legal: la Directiva (UE) sobre accesibilidad obliga a que las webs públicas sean accesibles desde su entrada en vigor.
El Real Decreto 1112/2018 adaptó requisitos en España.
| Acción |
Coste estimado (h) |
Impacto |
| Contraste y colores |
2–8 |
Alto |
| Alt text de imágenes |
5–12 |
Alto |
| Navegación por teclado |
4–16 |
Alto |
Para facilitar la implementación inmediata, aquí hay patrones HTML/CSS/ARIA listos para usar que resuelven problemas habituales: un enlace de salto, imagen con texto alternativo descriptivo y un control de formulario con etiqueta y mensaje de error accesible. Ejemplos:
Saltar al contenido
Introduce un correo válido
Estos fragmentos usan HTML semántico y ARIA mínimo (aria-describedby, role="alert") para que lectores de pantalla anuncien errores y la navegación por teclado mantenga foco lógico; se integran sin dependencias complejas y sirven como plantilla para listas de producto, tarjetas y formularios del checkout.
Infografía del flujo
Auditoría 0–7 días
→
Arreglos 7–30 días
→
Pruebas 30–60 días
Paso 3: pruebas, usuarios y control
Combinar pruebas automáticas con manuales y con usuarios reales detecta la mayoría de problemas. Los analizadores automáticos detectan cerca del 30% de los fallos reales.
Ejecutar pruebas automáticas
Correr axe-core en desarrollo y Lighthouse en Chrome. Guardar los resultados y enlazar cada fallo a un criterio WCAG.
Pruebas manuales recomendadas
Vigilar teclado, modales, focus trap y navegación con pantalla pequeña. Estas pruebas suelen revelar bloqueos en el checkout.
Pruebas con usuarios reales
Reclutar 3–5 usuarios con discapacidad para tareas clave. Medir tasa de éxito y puntos de bloqueo.
El error más frecuente en este punto es confiar solo en la puntuación de una herramienta automática. Muchos problemas de usabilidad requieren observación humana.
La accesibilidad cognitiva requiere medidas específicas además de las técnicas visuales y de teclado: usar lenguaje claro y conciso, dividir contenido en bloques cortos y encabezados consistentes, evitar justificado y ofrecer interlineado amplio (recomendable line-height ≥1.5 y tamaño base ≥16px), incluir ayudas visuales con texto (no solo iconos) y permitir ajustar espaciado y tamaño de fuente. Para formularios, reducir campos, ofrecer ejemplos y sugerencias de formato en el placeholder y mostrar mensajes de error claros con instrucciones paso a paso.
Estas adaptaciones mejoran la comprensión para personas con dislexia, TDAH o deterioro cognitivo y suelen aumentar la tasa de completado de tareas críticas como el pago.
Accesibilidad en e‑commerce y móvil
Los problemas más dañinos aparecen en filtros, carrito y pago en móvil. Corregir estas áreas mejora conversiones de forma directa.
Filtros y listas de producto
Usar controles nativos cuando sea posible, con etiquetas claras y estados anunciados. Si se usa JavaScript, mantener roles ARIA correctos.
Carrito y checkout mobile
Reducir campos, usar autocompletado y mostrar errores cerca del campo. Asegurar que el foco no se pierda al abrir modales.
Rendimiento y accesibilidad móvil
Optimizar imágenes y evitar cambios de layout que rompan el foco. Lighthouse ofrece métricas conjuntas de rendimiento y accesibilidad.
Un caso habitual: una tienda añade filtros complejos que no funcionan por teclado. Resultado: muchos usuarios no terminan la compra y la tasa de abandono sube.
Errores que arruinan el resultado
Algunos fallos comunes invalidan el trabajo de accesibilidad y generan más problemas que soluciones. Evitar atajos reduce riesgo legal y de negocio.
Confiar solo en herramientas
Las herramientas automáticas ayudan, pero no sustituyen las pruebas manuales. Muchas recomendaciones requieren juicio humano.
Usar ARIA sin semántica HTML
Colocar roles ARIA encima de HTML incorrecto complica el mantenimiento. Preferir HTML semántico y añadir ARIA solo donde haga falta.
Hacer un cambio único en vez de proceso
Tratar la accesibilidad como tarea puntual lleva a recidiva. Habrá fallos cada vez que se añada contenido o funcionalidad.
Si se desea un diagnóstico rápido y una estimación detallada, se puede pedir un informe de vulnerabilidades con plan de trabajo en 5–7 días hábiles, que incluya horas estimadas y prioridad.
Este enfoque no aporta valor si la web es una maqueta local no pública o si la acción urgente es una campaña temporal sin tráfico real. En esos casos, priorizar ventas inmediatas y aplicar accesibilidad cuando el sitio vaya a público.
Preguntas frecuentes
¿Qué es accesibilidad web para personas con discapacidad?
La accesibilidad web permite usar un sitio sin barreras a personas con discapacidades. Incluye visual, auditiva, motora y cognitiva.
Implica HTML semántico, texto alternativo, subtítulos, navegación por teclado y textos claros. La meta práctica es cumplir criterios WCAG y mejorar conversión.
¿Cuánto cuesta adaptar una web accesible?
Estimación rápida: acciones iniciales entre 200 y 2.500 euros según tamaño. El coste depende del número de páginas y complejidad técnica.
Una tienda pequeña suele requerir 10–40 horas para arreglos de alto impacto. Un rediseño completo sube el coste.
¿Qué normas aplicar en España y la UE?
Aplicar WCAG 2.1 AA y seguir Directiva (UE) 2016/2102 y Real Decreto 1112/2018. Es la referencia práctica para cumplimiento.
La UNE-EN 301 549 también ofrece requisitos técnicos y la Fundación ONCE publica guías útiles para adaptaciones.
¿Cómo comprobar enlaces inaccesibles según WCAG?
Comprobar que cada enlace tiene texto claro y destino único. Usar una herramienta automática para localizar enlaces vacíos y revisar manualmente los enlaces con texto ambiguo o que anuncian la misma acción.
¿Qué diferencia hay entre diseño accesible y diseño adaptativo?
El diseño accesible busca eliminar barreras; el diseño adaptativo cambia la presentación según el dispositivo. Un sitio adaptativo se ajusta a pantallas, pero puede seguir siendo inaccesible si no gestiona foco o lectores de pantalla.
¿Qué herramientas son mejores para probar accesibilidad?
Combinar Lighthouse, axe y Wave cubre gran parte de los fallos técnicos. Añadir pruebas con NVDA y VoiceOver para casos reales. Google y W3C recomiendan esta mezcla para evaluación práctica.
¿Cómo saber si mi web cumple WCAG al 100%?
Ninguna herramienta garantiza cumplimiento total; se necesita auditoría humana. Un auditor combina herramientas, pruebas manuales y tests con usuarios. La conformidad A/AA/AAA se documenta en la declaración de accesibilidad.
Síntesis y siguiente paso
La ruta práctica para una pyme es clara: diagnóstico rápido, arreglos prioritarios, pruebas con usuarios y mantenimiento. Esta secuencia reduce abandonos y mejora conversión móvil.
La evidencia aporta valor: W3C ha publicado guías prácticas y Fundación ONCE y CERMI han impulsado iniciativas de accesibilidad en España. Medir antes/después suele mostrar mejoras en tasas de éxito y conversión.
Recomendación final: comenzar por contraste, alt text y navegación por teclado. Luego, planificar pruebas con al menos tres usuarios con discapacidad para verificar el checkout.
Guía WAI del W3C
