Accesibilidad web WCAG: qué enviar cuando tu cliente la exige

Ya respondiste el cuestionario de seguridad y adjuntaste el reporte SOC 2. Entonces el área de compras de tu cliente agrega una línea que frena la venta: "Please provide your VPAT", o una cláusula que exige accesibilidad web según WCAG. Si buscas la sigla, es fácil terminar pensando que hay que comprar una "certificación VPAT". No existe.

Un VPAT es una plantilla. Lo que quiere el área de compras es esa plantilla ya completada, un Accessibility Conformance Report (ACR), y vale lo que valen las pruebas que lo respaldan. Detrás del pedido hay cinco preguntas. Aquí va qué enviar para cada una.

¿Qué es un VPAT y qué es un ACR?

VPAT significa Voluntary Product Accessibility Template: plantilla voluntaria de accesibilidad de producto. La publica el Information Technology Industry Council (ITI), una asociación de la industria tecnológica, y la versión vigente es la 2.5Rev, de abril de 2025. Según el ITI, una vez completado con resultados de pruebas documentados, el VPAT pasa a llamarse Accessibility Conformance Report, o ACR: un informe de conformidad de accesibilidad.

El ITI no revisa ni aprueba los VPAT, y no hay un resultado de aprobado o reprobado. Cada criterio recibe una de cuatro respuestas: Supports (cumple), Partially Supports (cumple parcialmente), Does Not Support (no cumple) o Not Applicable (no aplica). Así que no existe una certificación VPAT que puedas comprar. Un ACR es una declaración de tu empresa sobre cómo se comporta tu producto frente a un estándar concreto, y tu cliente lo va a leer como cualquier otra declaración del contrato.

¿Qué estándar de accesibilidad web te están pidiendo?

Casi siempre WCAG, las Pautas de Accesibilidad para el Contenido Web del W3C. La versión vigente, WCAG 2.2, es una Recomendación del W3C (actualizada por última vez en diciembre de 2024) y desde octubre de 2025 también es la norma ISO/IEC 40500:2025. Agrega nueve criterios de conformidad a WCAG 2.1, seis de ellos de nivel A o AA, y elimina uno, el 4.1.1 Parsing (análisis sintáctico).

Las leyes que están detrás del pedido cambian según el mercado, y muchas citan versiones anteriores:

• European Accessibility Act. Es la Directiva (UE) 2019/882 sobre los requisitos de accesibilidad de los productos y servicios, que en español muchos llaman Ley Europea de Accesibilidad. Se aplica desde el 28 de junio de 2025 a una lista de productos y de servicios prestados a consumidores, entre ellos el comercio electrónico y la banca de consumo. Las microempresas que prestan servicios (menos de 10 personas y facturación o balance de hasta 2 millones de euros) están exentas, y cada Estado miembro la incorpora a su legislación nacional. Los servicios de la lista son de cara al consumidor, así que un software que solo se vende a empresas por lo general no queda cubierto de forma directa, pero tus clientes pueden estarlo: si la app de un banco para sus clientes o el checkout de una tienda en línea funcionan sobre tu software, espera ver el requisito en tu contrato, igual que pasa con el cumplimiento en fintech y healthtech.
• EN 301 549. Es el estándar europeo detrás de esa directiva y de la Directiva de Accesibilidad Web del sector público. La versión 4.1.1, publicada en línea el 2 de septiembre de 2026, lleva el mínimo para contenido web a WCAG 2.2 nivel AA. Según la National Disability Authority de Irlanda, se espera que el Diario Oficial de la UE la cite el 16 de diciembre de 2026, y solo esa cita le da presunción de conformidad con las dos directivas. Mientras tanto, sigue vigente la versión 3.2.1 de 2021, basada en WCAG 2.1.
• Estados Unidos. Los compradores federales se rigen por la Sección 508. Para gobiernos estatales y locales, la norma del Departamento de Justicia sobre el Título II de la ADA exige WCAG 2.1 nivel AA en el contenido web que ofrecen, ya sea directamente o mediante contratos, licencias u otros acuerdos. Una norma final provisional publicada en abril de 2026 movió la fecha de cumplimiento al 26 de abril de 2027 para entidades públicas con una población total de 50,000 personas o más, y al 26 de abril de 2028 para las más pequeñas. Si vendes edtech a universidades públicas, esa cláusula explica por qué la pregunta aparece en tu RFP.

Nuestra recomendación: haz tus pruebas con WCAG 2.2 nivel AA como referencia desde ya. El W3C dice que el contenido conforme con 2.2 también es conforme con 2.0 y 2.1 (aunque una política que cite esas versiones puede seguir pidiendo que pruebes y reportes el 4.1.1), y su grupo de trabajo recomienda 2.2 como objetivo aunque las obligaciones citen versiones anteriores. Esto no es asesoría legal: consulta con tu asesor legal qué ley obliga a tu cliente.

¿Qué edición del VPAT debes llenar?

El ITI publica cuatro ediciones: 508 para el estándar federal de EE. UU., EU para EN 301 549, WCAG para las pautas del W3C (incluida la 2.2) e INT, que cubre las tres. ¿Vendes solo a empresas privadas en EE. UU.? La edición WCAG suele bastar. ¿Vendes en EE. UU. y Europa? Llena la INT una vez y deja de rehacer el documento en cada venta.

¿Quién hizo las pruebas y cómo?

Aquí es donde la mayoría de los ACR pierde credibilidad. Indica la versión del producto, la fecha de evaluación, quién hizo las pruebas y cómo: revisión automatizada, un recorrido solo con teclado por los flujos principales y pruebas con lector de pantalla.

El análisis de WebAIM de 2026 sobre el millón de páginas de inicio más populares detectó fallas de WCAG 2 en el 95.9% de ellas, con un promedio de 56.1 errores por página y texto con bajo contraste en el 83.9%. Son páginas de inicio populares, no interfaces de producto B2B, y el propio WebAIM advierte que no todas las fallas de conformidad se pueden detectar de forma automática. Tómalo como una medida de qué tan comunes son las fallas básicas, no como un punto de comparación.

Un widget de overlay tampoco arregla el producto que está debajo. En abril de 2025, la Comisión Federal de Comercio de EE. UU. (FTC) aprobó una orden final que obliga a un proveedor de overlays a pagar $1 millón. La FTC había alegado que era falsa, engañosa o sin sustento la afirmación del proveedor de que su plug-in podía hacer que cualquier sitio web cumpliera con WCAG.

¿Qué falla y cuándo se corrige?

Todo producto real tiene brechas, y si tu cliente ve "Supports" en todas las filas va a suponer que nadie probó nada. Marca lo parcial como Partially Supports, explícalo en las observaciones y adjunta un roadmap de corrección: cada brecha, a quién afecta, la solución y una fecha objetivo. Nunca escribas "cumplimiento total" en una respuesta a un RFP. Basta con que el evaluador de tu cliente encuentre una falla de contraste para que relea con lupa todas tus demás respuestas.

Nuestra propia declaración de accesibilidad sigue esa regla: dice que el sitio es "parcialmente conforme" y lista cada problema conocido con su plan.

¿De dónde sale de verdad la conformidad con WCAG 2.2?

Sobre todo del design system. Las fallas comunes son decisiones que se toman una vez y se copian en todas partes: un color de texto, un estilo de foco, el tamaño de un botón. Corrígelas en tokens y componentes que tus desarrolladores sí usen y cada pantalla hereda la corrección.

• Contraste. El texto normal necesita un contraste de al menos 4.5:1 con su fondo (1.4.3). Empareja cada token de texto con su fondo, en modo claro y oscuro.
• Foco. El foco del teclado tiene que ser visible (2.4.7), y, como novedad de la 2.2, tu propio encabezado fijo o tu banner de cookies no puede ocultar por completo el elemento enfocado (2.4.11).
• Tamaño de los controles. Los elementos que se activan con puntero deben medir al menos 24 por 24 píxeles CSS, con algunas excepciones (2.5.8). Los botones de ícono en tablas densas son los primeros en fallar.
• Inicio de sesión. Ningún paso puede exigir una prueba de función cognitiva, como recordar una contraseña o resolver un acertijo, sin ofrecer una alternativa o un mecanismo de ayuda, por ejemplo permitir pegar texto y usar gestores de contraseñas (3.3.8, con excepciones puntuales).

También incluiríamos una variante de movimiento reducido en cada animación: cuesta poco al diseñar y mucho al corregir después. Luego Build evita que las correcciones se pierdan, con HTML semántico y revisiones automatizadas como axe-core en cada pull request.

El paquete que debes tener listo

Un ACR en la edición que piden tus mercados, con versión, fecha y métodos de prueba; un roadmap de corrección con fechas; y una declaración pública de accesibilidad. Guárdalos junto a tu reporte SOC 2, porque el área de compras los pide en el mismo paquete.

Este trabajo toca cuatro prácticas. Studio se encarga del design system que hace repetible la conformidad, Build del HTML y de las revisiones en CI, y Secure del cuestionario de seguridad que acompaña al ACR. Sales necesita todo esto antes del RFP, no después. Por eso lo abordaríamos como un solo trabajo multipráctica.

Relacionados: Design systems que sí se usan → · SOC 2 o ISO 27001: cuál necesitas → · Productos B2B para industrias reguladas →