Un VPAT, o Plantilla Voluntaria de Accesibilidad de Producto, es un documento estandarizado que un proveedor completa para describir en qué medida un producto o servicio concreto cumple estándares de accesibilidad como la WCAG, la Sección 508 y la EN 301 549, evaluados criterio por criterio. Los compradores empresariales, gubernamentales y de educación superior suelen solicitar uno durante el proceso de compra antes de adquirir software o servicios digitales. Una vez rellenado para un producto concreto, el documento terminado se llama técnicamente Informe de Conformidad de Accesibilidad (ACR), aunque la mayoría de la gente llama VPAT a todo el conjunto.
Qué contiene realmente un VPAT
Un VPAT es una tabla larga y estructurada, no un resumen breve. Lo publica y mantiene el Information Technology Industry Council (ITI), con ediciones que cubren distintos estándares: una edición exclusiva de WCAG, una edición de la Sección 508, una edición de la EN 301 549 (para la UE) y una edición combinada “INT” que cubre las tres a la vez. Para cada criterio de éxito individual, el proveedor marca el producto como Cumple, Cumple parcialmente, No cumple o No aplicable, y se espera que añada observaciones específicas que expliquen esa valoración, idealmente señalando qué se probó realmente en lugar de dejar una casilla sin explicación.
Por qué los compradores lo solicitan
Los equipos de compras empresariales y gubernamentales necesitan documentar que el software que adquieren cumple los requisitos legales de accesibilidad, en particular bajo la Sección 508 para las compras federales de Estados Unidos, normas de compras estatales similares y la EN 301 549 para las compras del sector público de la UE relacionadas con la EAA. Un VPAT les da esa documentación sin necesidad de realizar su propia auditoría independiente completa de cada proveedor que evalúan. También crea un rastro documental: si un producto adquirido resulta tener carencias de accesibilidad importantes que el VPAT no declaraba, la organización compradora cuenta con un registro de lo que afirmó el proveedor en el momento de la compra.
Los VPAT y los estándares que hay detrás
Un VPAT vale tanto como el estándar frente al que se probó y con qué rigor se hizo realmente esa prueba. La edición de la Sección 508 se mapea con la WCAG 2.0 A y AA, ya que eso es lo que incorporó por referencia la actualización de la Sección 508 de 2017. La edición de la EN 301 549 se mapea con los requisitos de ese estándar, que a partir de la versión 3.2.1 incorporan por completo la WCAG 2.1 AA. Gracias a esa base compartida en la WCAG, un proveedor que ha hecho pruebas genuinas de WCAG 2.1 AA generalmente está bien posicionado para completar un VPAT preciso en las tres ediciones sin partir de cero en cada una.
Quién elabora los VPAT
| Función | Deque Systems | Allyant | UserWay |
|---|---|---|---|
| Enfoque | Enterprise accessibility testing and remediation company built around the open-source axe-core engine, sold as developer tooling (axe DevTools, axe Monitor, axe Auditor) plus expert manual audits and training, not a consumer widget. | Formed in 2022 by Thompson Street Capital Partners combining Accessible360, ReadSpeaker's document services and other accessibility businesses; focuses on enterprise document, PDF and publishing remediation alongside broader digital accessibility consulting, with an AI-assisted PDF remediation product launched in 2025. | AI-driven accessibility widget with an in-house automated remediation engine, sold mainly as a self-serve script install with tiered plans and a separate professional audit add-on. |
| Precios | Enterprise quoted pricing by seats and scan volume; axe-core itself is free and open source. | Enterprise quoted engagements, typically scoped per document volume or project. | Freemium widget with paid tiers that unlock more automated checks; enterprise and professional audit services quoted separately. |
| Normas compatibles | WCAG 2.0, WCAG 2.1, WCAG 2.2, Section 508, EN 301 549 | WCAG 2.1, Section 508, PDF/UA, EN 301 549 | WCAG 2.1, ADA, Section 508, EN 301 549 |
| Ideal para | Engineering teams that want to test and fix code directly; Large enterprises needing audits, training and VPAT documentation | Enterprises and government agencies with large volumes of PDFs and documents to remediate | Very small sites wanting a no-cost starting point; Teams that want a widely recognized brand name |
Elaborar un VPAT creíble depende de las pruebas reales que haya detrás, por lo que a menudo se encarga a proveedores con experiencia dedicada en auditorías, en lugar de hacerse como un ejercicio interno rápido. Deque Systems realiza auditorías manuales dirigidas por expertos y elabora VPAT como parte central de su trabajo de consultoría empresarial, apoyándose en el motor de pruebas axe-core que también mantiene. Allyant trabaja ampliamente con clientes empresariales y gubernamentales en accesibilidad de documentos y accesibilidad digital en general, incluido el tipo de documentación de conformidad detallada que exigen los VPAT. UserWay ofrece un servicio profesional de auditoría manual y VPAT como complemento junto a su producto de widget, algo que vale la pena saber si ya usa UserWay y necesita documentación para una venta empresarial concreta.
Errores habituales al crear uno
El error más perjudicial es elaborar un VPAT basado solo en un escaneo automatizado en lugar de en pruebas manuales genuinas; las herramientas automatizadas detectan un subconjunto relevante de los criterios de éxito de la WCAG, pero no pueden evaluar de forma fiable todo lo que un VPAT debe certificar, así que un VPAT basado solo en un escaneo corre el riesgo de exagerar la conformidad de formas que pueden aflorar más tarde como un problema real, tanto reputacional como, en algunas circunstancias, legal. Un segundo error común es dejar que un VPAT se quede desactualizado: describe la accesibilidad de un producto en un momento concreto, y un rediseño importante o una nueva función sin la actualización correspondiente del VPAT deja a los compradores confiando en información obsoleta. Por último, las columnas de observaciones vagas (“cumple el requisito” sin más detalle) socavan la credibilidad del documento; el equipo de compras o de accesibilidad de un comprador generalmente confiará más en un VPAT cuando las observaciones sean específicas sobre qué se probó y cómo.
Leer el VPAT de otro proveedor como comprador
Si está en el lado comprador, evaluar un VPAT es una habilidad distinta a elaborar uno. Mire más allá del resumen general y revise la columna de observaciones en busca de criterios concretos que importen para su caso de uso; una valoración de “Cumple parcialmente” en la operabilidad por teclado o el etiquetado de formularios merece más atención que la misma valoración en algo menos central para cómo van a interactuar realmente sus usuarios con el producto. Compruebe la fecha en que se completó el VPAT y, si tiene más de uno o dos años, pregunte si el producto ha cambiado de forma significativa desde entonces. Y trate un VPAT sin observaciones en absoluto, solo casillas marcadas sin explicación, como una señal para hacer preguntas de seguimiento antes de basarse en él para una decisión de compra, ya que las observaciones suelen ser donde vive el verdadero contenido de la evaluación.
Cómo encajan los VPAT en un panorama de cumplimiento más amplio
Un VPAT documenta la conformidad de un único producto; no es lo mismo que el cumplimiento general de accesibilidad de su organización, y tener uno para un software adquirido no hace que todo lo que construya sobre él sea automáticamente accesible. Una empresa que compra una plataforma bien documentada y respaldada por un VPAT todavía puede construir sobre ella una interfaz personalizada inaccesible, así que lo mejor es tratar un VPAT como un elemento más dentro de las decisiones de compra y la evaluación de riesgo de proveedores, no como un sustituto de probar su propio producto, sitio web o aplicación final una vez que todo está ensamblado y configurado para su uso específico.
Cuánto suele tardar un proceso de VPAT
Para un producto pequeño o mediano, las pruebas de conformidad reales seguidas de la elaboración de un VPAT bien documentado no son algo que se entregue en la misma semana; espere que lleve varias semanas una vez que tenga en cuenta programar las pruebas manuales en los criterios de éxito relevantes, volver a probar cualquier cosa que falle y redactar observaciones específicas en lugar de marcas genéricas de aprobado o reprobado. Los productos más grandes y complejos, con muchos componentes interactivos o una superficie de funciones amplia, tardan todavía más. Incorporar ese calendario a un ciclo de ventas o a un plazo de compras con antelación evita la trampa habitual de intentar producir un VPAT apresurado y superficial bajo presión de plazo solo para satisfacer la solicitud de un comprador, lo cual suele producir exactamente el tipo de documentación poco fiable y vaga que socava la confianza del comprador en lugar de ganársela.
Planifique el calendario dentro de su hoja de ruta de producto junto con los lanzamientos principales, no como reacción a un único acuerdo de compra que de pronto lo exige. Un VPAT elaborado con calma, en su propio calendario, sobre un producto que ya ha probado a fondo, es un documento fundamentalmente distinto (y más fiable) que uno ensamblado a las prisas para cerrar un trato, y los compradores que revisan VPAT con regularidad a menudo notan la diferencia solo con la calidad de las observaciones.
Si necesita uno para su producto
Empiece por confirmar qué edición necesita realmente (solo WCAG, Sección 508, EN 301 549 o la edición combinada INT) según quién lo esté pidiendo y en qué mercado esté vendiendo. Luego encargue pruebas reales frente a los criterios de éxito relevantes, ya sea a través de un especialista de accesibilidad interno o de un proveedor externo de pruebas y auditorías, antes de rellenar el documento en sí. Trate el VPAT terminado como un documento vivo que tendrá que revisar tras cambios importantes del producto, no como una entrega puntual que archiva en cuanto se cierra la venta inicial.