WCAG 2.2 en entregas white label: el checklist que evita auditorías sorpresa
Qué se publicó y qué todavía no es obligatorio
En septiembre de 2026 se publicó la nueva versión de la norma europea de accesibilidad, EN 301 549 v4.1.1. El cambio de fondo es que adopta las WCAG 2.2 como referencia para sitios web, software y documentos, en reemplazo de las WCAG 2.1, según el centro AccessibleEU de la Comisión Europea.
Hay un matiz que muchas coberturas periodísticas omiten: la versión nueva todavía no es la referencia legal armonizada. Hasta que la Comisión Europea la cite en el Diario Oficial, la norma que se usa para demostrar cumplimiento sigue siendo la v3.2.1 de 2021, basada en WCAG 2.1 nivel AA. La citación está prevista para diciembre de 2026.
Para una agencia que entrega sitios en white label, la lectura práctica es simple: el objetivo técnico ya está definido y cambió. Si tus entregas se miden contra WCAG 2.1, vas a quedar un paso atrás cuando el cliente reciba su primera auditoría con la norma nueva.
Los seis criterios que entran
La actualización incorpora los criterios de nivel A y AA que WCAG 2.2 sumó, y retira el 4.1.1 de procesamiento porque quedó obsoleto. En trabajo de implementación, esto es lo que cambia:
- 2.4.11 Enfoque no oscurecido (AA): el header pegajoso o el banner de cookies no pueden tapar el elemento que tiene el foco al navegar con teclado.
- 2.5.7 Movimientos de arrastre (AA): si un control solo funciona arrastrando (slider de precio, carrusel, ordenar tarjetas), necesita alternativa con un puntero simple.
- 2.5.8 Tamaño del objetivo (AA): los controles táctiles del checkout no pueden quedar por debajo de 24 por 24 píxeles útiles.
- 3.2.6 Ayuda coherente (A): el acceso a ayuda tiene que estar en el mismo lugar relativo en todas las plantillas.
- 3.3.7 Entrada redundante (A): no se puede pedir dos veces el mismo dato dentro de un proceso de compra.
- 3.3.8 Autenticación accesible (AA): no se puede bloquear el pegado de un código, ni exigir memoria o resolución de acertijos como única forma de identificarse.
El texto de referencia está en las WCAG 2.2 del W3C.
El requisito que no existe en WCAG
La EN 301 549 agrega una cláusula propia, la 9.7, sobre preferencias del usuario: una página no debe impedir que el navegador aplique la configuración de accesibilidad de la persona. En la práctica, eso significa no anular el tamaño de texto, el contraste forzado ni el tamaño del cursor.
El detalle técnico que suele romper esto es el uso de forced-color-adjust para forzar colores en modo de alto contraste, o tamaños de fuente definidos en píxeles absolutos que impiden el escalado. Para un equipo de frontend es una revisión de una tarde; para una auditoría es un hallazgo.
También hay una definición relevante para agencias: si el sitio incluye un overlay de accesibilidad, ese overlay pasa a formar parte del producto. La conformidad se evalúa sobre el conjunto, no sobre la web original y el widget por separado. La solución mágica de terceros no exime de nada.
Por qué esto impacta en una entrega white label
Cuando una agencia terceriza ingeniería, el riesgo no está en el diseño: está en el traspaso. Si el criterio de aceptación es "se ve igual al Figma", la accesibilidad no entra nunca. Si el criterio incluye estados de foco, tamaño de objetivos y orden de tabulación, entra desde el primer sprint.
Tres decisiones que cambian el resultado:
- El componente se entrega con sus estados. Foco visible, hover, disabled, error y loading documentados, no solo el estado feliz.
- El handoff incluye semántica. Qué elemento HTML corresponde a cada bloque, qué etiquetas ARIA son necesarias y cuáles son ruido. En Figma a código: handoff de diseño está el detalle del proceso.
- El design system tiene tokens de foco y contraste. Si el sistema no define cómo se ve el foco, cada desarrollador lo inventa. En design system para agencias tratamos el modelo de entrega.
Checklist de QA accesible para cada entrega
- Recorrido completo con teclado, en desktop y mobile, por los flujos críticos: home, categoría, ficha, carrito, checkout y confirmación.
- Verificación de que el foco no queda oculto detrás de elementos fijos.
- Contraste de texto y de componentes de interfaz medido, no estimado a ojo.
- Formularios con etiquetas asociadas, mensajes de error descriptivos y sin pedir datos repetidos.
- Controles táctiles con área mínima y separación suficiente.
- Autenticación con alternativa al código por SMS o al captcha cognitivo.
- Prueba con zoom al 200 por ciento y con modo de alto contraste activo.
- Prueba con lector de pantalla en el flujo de compra, aunque sea una pasada rápida.
Ninguno de estos puntos requiere un experto certificado. Requieren un checklist y alguien con autoridad para rechazar una entrega.
Impacto comercial, no solo legal
La accesibilidad tiene una consecuencia lateral que las agencias suelen subestimar: mejora la conversión. Foco visible, objetivos táctiles más grandes, formularios sin datos redundantes y autenticación que permite pegar el código reducen fricción para todas las personas, no solo para quienes usan tecnologías de asistencia.
También ordena las licitaciones. En compras públicas y en procesos corporativos grandes, la declaración de conformidad es un requisito de admisión. Llegar con un producto auditado ahorra semanas de ida y vuelta.
Cómo incorporarlo sin frenar el roadmap
Un plan de adopción en tres movimientos:
- Ahora: agregar el checklist de QA accesible al proceso de aceptación de cada entrega.
- Próximos 60 días: corregir los seis criterios nuevos en las plantillas base del design system, que son las que se replican en todos los proyectos.
- Próximos 6 meses: auditoría formal de los productos activos y plan de remediación por impacto.
Cierre
Si entregás sitios para clientes y querés que la accesibilidad sea parte del estándar y no un pedido de último momento, en Codit Digital trabajamos como equipo de ingeniería white label para agencias: desarrollo Figma a código, design systems auditados y QA accesible documentado. Mirá el servicio de desarrollo white label para agencias o escribinos por contacto para armar el checklist de aceptación juntos.
