Remediación de accesibilidad sin overlays

Ambos modelos son posibles. Preferimos el acceso directo al repositorio (GitHub, GitLab, Bitbucket) con ramas dedicadas y pull requests revisables, porque nos permite seguir las convenciones del proyecto y facilita la revisión por parte de tu equipo. Si la política de tu empresa no permite dar acceso externo, entregamos patches (git format-patch) o archivos modificados para que aplique vuestro equipo internamente. Firmamos NDA siempre que sea necesario.

Porque no funcionan. Los overlays no resuelven problemas estructurales del HTML y rompen compatibilidad con lectores de pantalla reales. En Estados Unidos hay demandas ADA documentadas contra sitios que solo usaban overlays. Organizaciones de personas con discapacidad los desaconsejan explícitamente. Pagar por un overlay es pagar por una falsa sensación de cumplimiento sin la evidencia verificable que exige la EAA. No ofrecemos el servicio porque iría contra los intereses del cliente.

No estrictamente. Si ya tienes una auditoría reciente (propia o de terceros), la usamos como punto de partida. Si no, incluimos en el proyecto una auditoría técnica de entrada de 2–5 días que identifica los hallazgos y nos permite priorizar correctamente. Ambos enfoques son válidos, pero siempre necesitamos un diagnóstico antes de empezar a corregir.

Trabajamos en ramas separadas que nunca tocan directamente producción. Cada cambio pasa por vuestra code review antes del merge. Si el proyecto tiene tests automatizados, nos aseguramos de que sigan pasando antes de entregar. Si tras el merge se detecta alguna regresión funcional atribuible a la remediación, la corregimos sin coste adicional durante los 30 días posteriores a la entrega.

Nos comprometemos a corregir todos los hallazgos identificados en el alcance acordado y verificar el resultado con WCAG Guard y testing manual. No afirmamos "100% accesible" como garantía legal porque el cumplimiento WCAG depende también del contenido futuro que publique el cliente. Lo que sí podemos asegurar es que, al cierre del proyecto, los criterios del alcance quedan conformes y trazablemente verificados. Esa es la base sobre la que luego se elabora una declaración de accesibilidad verificable.

El precio depende del número de hallazgos, la complejidad técnica y el stack. No damos precios cerrados sin ver primero el sitio porque varían mucho entre proyectos. Lo que sí hacemos es una evaluación gratuita de alcance: tras una llamada inicial y un escaneo automatizado con WCAG Guard, te enviamos un presupuesto cerrado por fases. Puedes contratar solo la primera fase (correcciones críticas) para reducir riesgo y decidir sobre la marcha si seguir adelante.

Sí. Muchos clientes empiezan priorizando los flujos críticos (home, páginas de producto, checkout, formulario de contacto) y dejan el resto para fases posteriores. Es una buena estrategia para reducir el riesgo legal a corto plazo sin asumir un proyecto enorme de golpe. En la propuesta inicial definimos claramente qué está dentro y qué fuera del alcance.

Depende de las limitaciones concretas. En WordPress usamos child themes y hooks/filters para no tocar el tema padre, lo que permite mantener las actualizaciones sin perder las correcciones. En Shopify duplicamos el tema y trabajamos sobre la copia. Para temas propietarios muy cerrados, evaluamos si es técnicamente posible remediar con CSS y JavaScript de capa superior, o si es más rentable migrar a un tema accesible desde el inicio. En la auditoría de entrada te damos una recomendación honesta.