¿Qué es un Accessibility Conformance Report (ACR)?

¿Qué es un Accessibility Conformance Report (ACR)?

Un Accessibility Conformance Report (ACR) es un documento que declara hasta qué punto un producto digital (sitio web, web app, app móvil, software, hardware) cumple los estándares de accesibilidad — principalmente WCAG (Web Content Accessibility Guidelines) y Section 508 del US Rehabilitation Act. Los ACRs se redactan típicamente usando la VPAT (Voluntary Product Accessibility Template) publicada por el Information Technology Industry Council (ITI), que proporciona un formato estandarizado para reportar contra cada criterio de éxito de WCAG.

Un ACR no es una certificación o auditoría — es una autoatestación del proveedor. El proveedor lista cada criterio WCAG aplicable y reporta si el producto Supports, Partially Supports, Does Not Support o Not Applicable. Los ACRs honestos incluyen notas explicativas sobre casos límite y problemas conocidos. Los ACRs guiados por marketing reclaman soporte completo sin evidencia — y normalmente se desmoronan bajo auditorías reales.

Por qué existen los ACRs

Tres impulsores:

• Adquisición federal de EE.UU. Section 508 requiere que las agencias federales compren tecnología accesible. Los ACRs son la forma estándar en que los proveedores demuestran conformidad durante la adquisición — requeridos por GSA Schedule 70 y la mayoría de RFPs de agencias.
• Adquisición de educación superior y grandes empresas. Universidades y compradores Fortune 500 cada vez más requieren ACRs como parte de sus respuestas a RFP. Los equipos de adquisición los usan como filtro.
• EU EAA (European Accessibility Act). Vigente desde junio de 2025, el EAA requiere declaraciones de accesibilidad para muchos productos digitales vendidos en la UE. Los proveedores con ACRs están preposicionados para cumplir los requisitos del EAA con esfuerzo extra mínimo.

Qué contiene un ACR (formato VPAT 2.x)

El formato actual VPAT 2.5 (último a 2026) cubre cuatro estándares en un documento:

• WCAG 2.1 (Niveles A y AA). 50+ criterios de éxito a través de los cuatro principios POUR (Perceivable, Operable, Understandable, Robust).
• Section 508 revisada. Estándar federal de adquisición de EE.UU., armonizado con WCAG 2.0 desde 2018.
• EN 301 549. Estándar europeo para accesibilidad ICT, obligatorio bajo el EAA.
• WCAG 2.2 (en VPAT 2.5+). Criterios de éxito más nuevos (tamaño de objetivo, apariencia de foco, etc.).

Para cada criterio, el ACR lista:

1. Nivel de conformidad (Supports / Partially Supports / Does Not Support / Not Applicable).
2. Observaciones y explicaciones — detalles concretos sobre qué se probó, problemas conocidos, soluciones provisionales y roadmap para criterios no soportados.

Cómo escribir un ACR creíble

Prueba antes de escribir

El mayor error: escribir el ACR desde la documentación de features sin probar realmente. Antes de que cualquier criterio reciba "Supports", ejecuta scanners automatizados (axe, WAVE) Y pruebas manuales con lectores de pantalla (NVDA en Windows, VoiceOver en Mac/iOS, TalkBack en Android). Documenta qué probaste, en qué plataformas, con qué tecnologías de asistencia.

Sé honesto sobre "Partially Supports"

Casi todo producto real soporta parcialmente muchos criterios. Escenarios honestos comunes de soporte parcial: "la navegación por teclado funciona para los flujos principales pero el widget desplegable en la página de configuración atrapa el foco", o "el texto alt se proporciona para imágenes de productos pero los gráficos auto-generados no tienen alternativas de texto descriptivas". Documentar esto honestamente construye confianza con el comprador; ocultarlo aparece en la propia auditoría del comprador y mata el trato.

Actualiza con cada lanzamiento mayor

Una instantánea de ACR de hace 18 meses es peor que ningún ACR — engaña activamente a los compradores sobre el estado actual. Re-prueba y republica con cada lanzamiento mayor de UI.

Consigue una auditoría externa para tratos de alto nivel

Para grandes contratos gubernamentales o de educación superior, los compradores pueden requerir ACRs auditados por terceros. Empresas especialistas (Deque, Level Access, TPGi) auditan tu producto contra WCAG y producen un ACR auditado. Más caro pero más creíble.

Errores comunes de ACR

• Reclamar "Supports" sin probar. ACRs guiados por ventas que dicen que todo funciona fallan auditorías de comprador y dañan la reputación.
• Versión VPAT obsoleta. Los compradores esperan VPAT 2.4 o 2.5; enviar uno 2.0 de 2018 parece descuidado.
• Sin observaciones. Solo listar "Supports" sin explicación no proporciona información útil. Los compradores quieren saber qué se probó y cómo.
• Tratar el ACR como marketing. Un ACR es documentación de adquisición, no una hoja de ventas. Honesto, técnico, basado en evidencia.
• Olvidar actualizar. Los ACRs obsoletos son peores que los ACRs faltantes — representan activamente mal el estado actual.
• Mezclar plataformas. Si tu producto tiene una web app + app iOS + app Android + app desktop, cada una puede necesitar su propio ACR (o uno combinado claramente segmentado).

FAQ: Accessibility Conformance Reports

¿Es un ACR lo mismo que un VPAT?

Estrechamente relacionados pero técnicamente distintos. El VPAT es la plantilla (un formulario en blanco). El ACR es el documento rellenado (un VPAT completado para un producto específico). En la práctica los términos se usan a menudo de forma intercambiable — "envíame tu VPAT" normalmente significa "envíame tu ACR".

¿Quién escribe el ACR?

Típicamente: un líder interno de accesibilidad o product manager + ingenieros que probaron features específicas + a veces un auditor externo para verificación. Las empresas más grandes tienen programas dedicados de accesibilidad; las empresas más pequeñas a menudo contratan especialistas para los engagements VPAT.

¿Cuánto tarda escribir un ACR?

Para un producto pequeño: 2-4 semanas de esfuerzo enfocado, principalmente tiempo de prueba. Para una gran app empresarial: 2-3 meses incluyendo coordinación con equipos de producto, diseño e ingeniería. Los ACRs auditados tardan más.

¿Cuánto cuesta una auditoría externa?

10.000-50.000+ $ dependiendo de la complejidad del producto. Vale la pena para contratos de alto valor donde los compradores requieren verificación independiente o donde la reputación importa.

¿Pueden las herramientas automatizadas generar el ACR?

No — las herramientas automatizadas (axe, WAVE, Pa11y) atrapan quizás el 30-40% de los problemas de accesibilidad. Son útiles para escanear a escala pero la credibilidad del ACR proviene de pruebas manuales con tecnologías de asistencia. Las herramientas aumentan las pruebas humanas; no las reemplazan.

¿Necesita mi SaaS un ACR si no vendemos al gobierno?

Recomendado incluso sin clientes gubernamentales. Educación superior, empresas Fortune 500 y clientes UE (bajo el EAA desde junio de 2025) cada vez más solicitan ACRs. Tener uno publicado en tu sitio señala disposición de adquisición y acelera tratos empresariales.

Cómo LoadFocus se relaciona con auditorías de accesibilidad

Mientras LoadFocus se enfoca en rendimiento no en accesibilidad, las auditorías de accesibilidad a menudo necesitan también verificación de rendimiento — páginas que fallan Core Web Vitals crean problemas de accesibilidad para usuarios en redes lentas o dispositivos de gama baja. Combina tu trabajo VPAT/ACR con auditorías de velocidad LoadFocus a través de regiones para validar líneas base de rendimiento que apoyen accesibilidad (ej. asegurar que usuarios de lectores de pantalla en conexiones 3G todavía obtengan tiempos razonables de carga de página).