El equipo publica un rediseño "compatible con RGAA". Dos semanas después, las quejas están llegando: usuarios con discapacidad visual que esperan ocho segundos antes de mostrar el menú, CDN que muestra una página de error almacenada en caché desde el día anterior, firewall de aplicaciones que bloquea el validador automático. El código HTML está limpio; infraestructura no lo es.
La accesibilidad digital (RGAA, WCAG, directiva europea sobre accesibilidad) se basa principalmente en el contenido, el diseño y el desarrollo. Pero un hosting inadecuado puede impedir que un sitio compatible sea utilizable: latencia, indisponibilidad, mala configuración de TLS o CDN, reglas de seguridad demasiado agresivas. Ignorar esta capa significa liberar el frágil cumplimiento del primer pico de carga.
Qué infraestructura controla y qué no controla
Tres ámbitos se superponen y las responsabilidades deben quedar claras antes de cualquier auditoría.
Fuera del ámbito del hosting — tu responsabilidad: contrastes, alternativas textuales, estructura semántica, navegación por teclado, formularios correctamente etiquetados, gestión de enfoque. Ningún contrato de hosting firma por usted su declaración de accesibilidad.
Alcance compartido: rendimiento percibido, estabilidad, compatibilidad HTTPS, encabezados HTTP (Cache-Control, Content-Type, Content-Language), ausencia de scripts inyectados por la plataforma o el panel de administración. Tú configuras; el anfitrión proporciona la capa que los transmite.
Alcance de hosting puro: disponibilidad, capacidad compartida o VPS, ubicación de puntos de presencia CDN, reglas de firewall de aplicaciones, limitación de rendimiento. Se trata de palancas que a menudo se olvidan en los planes de pruebas de accesibilidad.
| Síntoma del usuario | Posible causa de infraestructura | Ruta de diagnóstico |
|---|---|---|
| Página en blanco intermitente | Saturación del procesador o de la memoria | Supervisar la carga, actualizar |
| Fecha límite de envío del formulario | Tiempo de respuesta al primer byte > 3 s | Caché, PHP-FPM, base de datos |
| Validador bloqueado | Cortafuegos de aplicaciones/anti-bot | Auditar la lista blanca de IP |
| Medios no cargados | Protección de enlaces antidirectos | CDN o regla de host |
Una puntuación perfecta de Lighthouse local no sirve de nada si la puntuación compartida cae con cada pico de tráfico del boletín.
Rendimiento percibido: un criterio de accesibilidad olvidado
Los puntos de referencia de accesibilidad no se limitan al marcado. Un sitio que tarda diez segundos en responder excluye de facto a los usuarios con una conexión móvil limitada, a las personas con fatiga cognitiva o a aquellos que tienen que memorizar una interfaz lenta entre dos interacciones.
Mida el tiempo de respuesta del primer byte y la pintura con contenido más grande en producción, no solo en la preparación local. Una plataforma compartida saturada, una base de datos de tamaño deficiente o una CDN mal configurada degradan la experiencia de asistencia tanto como una imagen sin un atributo "alt".
Los criterios RGAA vinculados al tiempo de actividad de los servicios esenciales se cruzan directamente con el SLA del host y la página de estado. Si su sitio se considera un servicio público o un servicio esencial, la indisponibilidad no es sólo una incidencia técnica: es una barrera de acceso.
CDN, compresión y firewall: las trampas silenciosas
Una CDN acelera la entrega, pero también puede transformar HTML, comprimir agresivamente recursos, almacenar en caché páginas de error o inyectar scripts de administración de bots. Cada transformación es un riesgo para los lectores de pantalla y los navegadores asistidos.
Las optimizaciones de “minificación automática” en páginas dinámicas son particularmente peligrosas: pueden eliminar atributos ARIA, romper el orden de tabulación o alterar la estructura semántica. Pruebe después de cada cambio de configuración de CDN, con y sin lector de pantalla.
El firewall de la aplicación a veces bloquea los robots de auditoría (validadores pa11y, WAVE, RGAA) que se confunden con tráfico malicioso. Proporcione una lista blanca temporal para las IP de prueba o un espejo de prueba sin filtrar. Sin esto, la fecha de su última auditoría puede ser de un entorno que nadie está mirando.
Mejores prácticas en el lado del hosting
Entorno de preproducción: ejecute pa11y, axe-core o sus pruebas RGAA en una URL estable, idéntica a la de producción en términos de configuración del servidor, antes de cada lanzamiento importante.
CDN configurado sin romper HTML: evite optimizaciones automáticas ciegas en páginas dinámicas; documentar cada regla de transformación.
Disponibilidad documentada: cruzar el SLA contractual, la página de estado y el seguimiento externo durante un mínimo de treinta días.
Acceso a herramientas de auditoría: permita temporalmente las IP de prueba o proporcione un espejo provisional accesible para los validadores automáticos.
Compare ofertas a través del directorio observando el rendimiento documentado y la calidad del soporte, no solo el precio del servicio compartido.
La cumbre
Decide y avanza sin puntos ciegos
Comience midiendo el tiempo de respuesta del primer byte y la disponibilidad de treinta días en producción, de múltiples regiones si su audiencia es europea. Luego pruebe con un lector de pantalla en la URL real, no solo en su máquina local. Ajuste la configuración de CDN y firewall de aplicaciones, documentando cada cambio. Por último, compare los alojamientos orientados al rendimiento a través del comparador y las guías para elegir una oferta adaptada a sus necesidades.
Preguntas frecuentes
¿Es el anfitrión responsable de la accesibilidad del sitio?
No para el contenido y el código de aplicación: es el responsable de la publicación quien firma la declaración. Sin embargo, el host influye en la disponibilidad, el rendimiento percibido, los encabezados TLS y HTTP, todo lo cual puede degradar la experiencia de la tecnología de asistencia. Una auditoría local exitosa no garantiza nada si la producción es lenta o inestable.
¿Un sitio lento es un problema de accesibilidad?
Sí, para usuarios con conexión limitada, en dispositivos antiguos o en situación de fatiga cognitiva. Los tiempos de respuesta elevados o un grupo saturado inutilizan la interfaz antes de que se detecte un error WCAG en el HTML. El rendimiento percibido es parte de la experiencia accesible.
¿Puede la CDN alterar la accesibilidad?
Sí: compresión agresiva, transformación HTML, páginas de error almacenadas en caché, bloqueo geográfico o scripts de terceros inyectados sin control. Cada activación o modificación de CDN debe ir seguida de una prueba de lector de pantalla y validadores automáticos.
¿Qué puedes pedirle exactamente al anfitrión?
HTTP/2 o HTTP/3, certificados integrados, sin bloqueo arbitrario de robots de auditoría, registros para diagnosticar errores 403 y 503, un SLA de tiempo de actividad documentado y un entorno de prueba para pruebas automatizadas.
La accesibilidad se verifica donde los usuarios sufren: a menudo en un sitio compartido saturado, no en un informe HTML estático.