Si tienes una empresa, ¿qué hacer?

Si tienes un widget instalado, quítalo

Es el primer paso. Si has leído por qué no protege, la conclusión es directa: quitarlo, no "considerar quitarlo".

• No te protege de denuncias.
• Empeora el rendimiento de tu web.
• Te expone a riesgos de seguridad documentados.
• Es un coste mensual que necesitas para el resto del plan.
• Es identificable a simple vista por la comunidad de personas con discapacidad como una señal de atajo.

Audita el estado real de tu web

Antes de gastar dinero, necesitas saber qué tienes. Tres niveles de auditoría:

Nivel A. Comprobaciones automáticas gratuitas (1 a 2 horas)

Lo puede hacer cualquier persona sin formación técnica con extensiones de navegador:

• WAVE (wave.webaim.org): pinta los problemas detectables sobre tu propia web.
• Lighthouse (en Chrome DevTools, pestaña "Accessibility"): auditoría rápida con puntuación.
• axe DevTools: la herramienta estándar profesional para análisis automático.

Nivel B. Pruebas manuales básicas (1 jornada)

Cualquier persona con paciencia puede hacer estas pruebas:

1. Prueba de teclado. Desconecta el ratón. Recorre toda la web solo con Tab, Shift+Tab, Enter, Espacio y flechas. ¿Llega el foco a todos los elementos interactivos? ¿Se ve el foco en todo momento? ¿Se puede salir de los menús desplegables sin atraparse? SC 2.1.1, 2.1.2, 2.4.3, 2.4.7
2. Prueba de zoom. Amplía el navegador al 200 % (Ctrl + varias veces). ¿Se ve todo? ¿Hay scroll horizontal? ¿Se solapan elementos? SC 1.4.4, 1.4.10
3. Prueba de contraste. Ejecuta WAVE o axe y revisa los avisos de contraste insuficiente. SC 1.4.3, 1.4.11
4. Prueba de lector de pantalla. Activa NVDA en Windows (gratuito, nvaccess.org) o VoiceOver en Mac (Cmd+F5). Navega por las páginas críticas: home, búsqueda, ficha de producto, carrito, checkout. ¿Se anuncian los encabezados? ¿Los formularios tienen etiqueta? ¿Los botones se identifican como tales? SC 1.3.1, 4.1.2

Nivel C. Auditoría profesional (varios cientos a miles de euros)

Para webs de cierta complejidad o cuando hay riesgo regulatorio real, una auditoría externa por un profesional certificado entrega:

• Informe completo de no conformidades con SC concretos.
• Priorización por impacto y esfuerzo.
• Recomendaciones de corrección.
• Si necesitas IRA para Kit Digital: cumplimentación del Excel oficial con muestra real de páginas.

Busca perfiles con certificaciones IAAP (CPACC, WAS, CPABE) o trayectoria documentada. Esta inversión suele ser menor que el coste anual de un widget durante varios años.

Prioriza

No tienes que arreglar todo a la vez. Empieza por:

• Las páginas críticas del recorrido del usuario: home, búsqueda, ficha de producto, carrito, checkout, área de cliente.
• Los problemas que afectan a SC más graves: SC 1.1.1 (alt text), SC 1.3.1 (estructura), SC 2.1.1 (teclado), SC 4.1.2 (nombre, función, valor) son la base. Sin esto, nada más importa.
• Los problemas con más usuarios afectados: un fallo en el formulario de checkout afecta a más gente que un fallo en el footer.

Corregir el código fuente

La accesibilidad real se trabaja en cuatro capas:

HTML semántico

• Usar elementos correctos: <button> para botones, <a href> para enlaces, <h1> a <h6> para encabezados con anidamiento lógico, <nav>, <main>, <footer> como landmarks.
• Etiquetar formularios con <label for> o aria-label correctamente.
• alt significativo en imágenes de contenido, alt="" en decorativas.

CSS accesible

• Contrastes por defecto que cumplan SC 1.4.3 y SC 1.4.11.
• :focus-visible con un indicador claro y persistente.
• prefers-reduced-motion respetado en animaciones.
• Layout que no se rompa al ampliar texto al 200 % ni al reajustar a 320px de ancho.

JavaScript accesible

• Componentes interactivos (modales, menús, autocomplete, tabs) construidos con los patrones de ARIA Authoring Practices o, mejor, basados en componentes nativos cuando exista (<details>, <dialog>).
• Mensajes dinámicos anunciados con aria-live o roles de status. SC 4.1.3

Contenido

• Títulos y enlaces descriptivos. SC 2.4.4
• Lenguaje claro.
• Documentos PDF y multimedia accesibles: alternativas, subtítulos, transcripciones. SC 1.2.1, 1.2.2, 1.2.3

Publica la declaración de accesibilidad

Es obligatorio. La normativa exige publicarla en el sitio. Cómo hacerla, página dedicada.

Una declaración honesta + plan de mejora documentado es la mejor defensa ante una eventual denuncia.

Forma al equipo

Lo más eficaz a medio plazo no es una corrección puntual, sino que la accesibilidad entre en el flujo normal de trabajo:

• Diseñadoras y diseñadores que conozcan los SC clave en fase de diseño.
• Desarrolladoras y desarrolladores que escriban HTML semántico desde el principio.
• QA que incluya pruebas de teclado y contraste en cada release.
• Personas responsables de contenido que sepan escribir alt text y enlaces descriptivos.

Una hora bien dirigida ahorra meses de retrabajo.