VPAT explicado para empresas SaaS

VPAT explicado para empresas de SaaS

Las empresas de software se topan una y otra vez con la misma solicitud durante las ventas empresariales: "Envíenos su VPAT".

Para muchos fundadores y equipos de producto, el documento aparece tarde en el ciclo de ventas, generalmente de parte de contrataciones o de una oficina de cumplimiento gubernamental. Puede paralizar acuerdos durante semanas si nadie dentro de la empresa sabe qué es o cómo producir uno.

Un VPAT no es complicado, pero sí muy específico. Es una forma estandarizada de explicar cuán accesible es un producto digital según los estándares federales de accesibilidad. Las grandes empresas, universidades y agencias gubernamentales lo utilizan para evaluar a los proveedores antes de firmar contratos.

Para las empresas de SaaS que venden plataformas de software, el VPAT se ha convertido en una parte rutinaria de la contratación. Algunas organizaciones ni siquiera inician las revisiones de seguridad o las negociaciones de precios hasta que reciben uno.

Este artículo desglosa qué es un VPAT, por qué se lo piden a las empresas SaaS, cómo se relaciona con estándares de accesibilidad como WCAG, y qué implica realmente redactar uno.

Qué es realmente un VPAT

VPAT significa Plantilla Voluntaria de Accesibilidad de Producto (Voluntary Product Accessibility Template).

El documento fue creado por el Consejo de la Industria de Tecnologías de la Información a finales de los años 90 como un formato estandarizado que los proveedores podían usar para describir el cumplimiento de accesibilidad de productos tecnológicos.

La plantilla en sí misma no es el informe final. Es la estructura utilizada para producir algo llamado Informe de Conformidad de Accesibilidad (Accessibility Conformance Report), que suele abreviarse como ACR.

La mayoría de las empresas siguen diciendo "envíe el VPAT", aunque en realidad se refieren al informe completo.

Un documento VPAT típico incluye:

• nombre y versión del producto
• fecha de la evaluación
• estándar de accesibilidad aplicable
• metodología de evaluación
• hallazgos detallados de accesibilidad
• limitaciones conocidas

El núcleo del documento es una tabla larga. Cada fila corresponde a un requisito de un estándar de accesibilidad, más a menudo WCAG 2.1.

Para cada requisito, el proveedor debe declarar uno de varios niveles de conformidad:

• cumple (supports)
• cumple parcialmente (partially supports)
• no cumple (does not support)
• no aplica (not applicable)

Una breve explicación sigue a cada entrada.

Aquí hay un ejemplo simplificado:

Requisito: WCAG 2.1 – 1.1.1 Contenido no textual
Conformidad: Cumple parcialmente
Comentarios: Las imágenes decorativas carecen de texto alternativo en módulos de producto antiguos lanzados antes de marzo de 2022.

Ese formato permite a los equipos de contratación escanear rápidamente la cobertura de accesibilidad.

Por qué las empresas SaaS reciben constantemente solicitudes de VPAT

La solicitud casi siempre proviene de organizaciones que deben cumplir con leyes de accesibilidad.

Tres tipos de compradores comunes requieren documentación VPAT:

• Agencias federales
• Departamentos estatales o locales
• Universidades y colegios públicos

Estas organizaciones deben cumplir con requisitos de accesibilidad vinculados a la ley federal.

Uno de los estándares más citados en las políticas de contratación es la Sección 508 de la Ley de Rehabilitación.

La ley exige que las agencias federales compren tecnología accesible. Si una agencia compra software inaccesible cuando existen alternativas accesibles, la compra puede ser impugnada.

Debido a esa norma, los equipos de contratación piden a los proveedores que envíen documentación VPAT antes de aprobar contratos.

Las empresas privadas a veces siguen el mismo proceso.

Las grandes corporaciones —especialmente bancos, redes de salud y compañías de seguros— a menudo copian los procedimientos de contratación gubernamental para la accesibilidad.

Por eso las empresas SaaS que venden software de RR.HH., herramientas CRM, plataformas de marketing o herramientas de gestión de proyectos reciben regularmente solicitudes de VPAT incluso cuando no venden directamente a agencias gubernamentales.

Cómo se relaciona VPAT con WCAG y la Sección 508

Un VPAT no crea nuevas reglas de accesibilidad.

Simplemente mapea la accesibilidad del producto con estándares existentes.

Los estándares más comunes referenciados dentro de los informes VPAT son:

• WCAG 2.1
• Estándares revisados de la Sección 508
• EN 301 549 (normativa europea de contratación)

WCAG es el más familiar para los desarrolladores.

WCAG 2.1 contiene 78 criterios de éxito comprobables que cubren temas como:

• navegación por teclado
• contraste de color
• alternativas textuales para imágenes
• etiquetas de formularios
• compatibilidad con lectores de pantalla
• mensajes de error

Cuando se prepara un VPAT para software web, cada uno de esos criterios aparece como filas dentro de la tabla de accesibilidad.

La Sección 508 hace referencia a muchos de los mismos criterios WCAG.

Los estándares federales actuales se actualizaron en 2017 para alinearse con WCAG 2.0 Nivel AA. Muchas organizaciones ahora solicitan cobertura WCAG 2.1 porque incluye requisitos adicionales para accesibilidad móvil y para usuarios con baja visión.

Para los productos SaaS a los que se accede a través de un navegador, los criterios WCAG suelen representar la mayor parte del documento VPAT.

Las cuatro versiones de VPAT que encuentran los proveedores

La plantilla ha evolucionado con el tiempo. Los proveedores ahora eligen entre cuatro versiones según el mercado al que sirven.

• VPAT 2.4 Rev 508: Utilizado para contrataciones federales de EE.UU. Mapea la accesibilidad con los estándares de la Sección 508.
• VPAT 2.4 WCAG: Centrado completamente en los criterios WCAG 2.x.
• VPAT 2.4 EU: Utilizado para productos vendidos a gobiernos europeos que siguen EN 301 549.
• VPAT 2.4 INT: Una versión internacional combinada que mapea los requisitos a través de los tres estándares.

La mayoría de las empresas SaaS que preparan su primer VPAT eligen la versión WCAG o la versión internacional.

La plantilla internacional produce informes más largos pero reduce la necesidad de crear documentos separados para diferentes regiones.

Cómo es realmente un informe VPAT

Un Informe de Conformidad de Accesibilidad terminado suele tener de 30 a 70 páginas, dependiendo de la complejidad del producto.

Las grandes plataformas SaaS con múltiples módulos a veces superan las 100 páginas.

El documento suele incluir las siguientes secciones.

Métodos de evaluación utilizados

Los proveedores explican cómo se realizaron las pruebas de accesibilidad. Los informes más creíbles describen tanto pruebas automatizadas como evaluaciones manuales con tecnología de asistencia.

Los métodos típicos incluyen:

• pruebas con lectores de pantalla
• pruebas de navegación por teclado
• evaluación de contraste
• herramientas de escaneo automatizadas

Productos evaluados

Muchas herramientas SaaS funcionan en múltiples navegadores y dispositivos. El VPAT enumera los entornos utilizados durante la evaluación.

Ejemplo:

• Chrome versión 120
• Firefox versión 121
• Safari versión 17
• Windows 11
• macOS Sonoma

Tecnologías de asistencia evaluadas

La evaluación de accesibilidad a menudo incluye software de lector de pantalla real.

Ejemplos comunes:

• NVDA
• JAWS
• VoiceOver

El informe explica qué herramientas se utilizaron y qué funcionalidad se verificó.

Tablas de conformidad de accesibilidad

Esta es la sección más grande. Cada requisito de WCAG o la Sección 508 aparece como una fila de tabla con la declaración de conformidad del proveedor.

Comentarios y explicaciones

Los proveedores deben describir las limitaciones de accesibilidad conocidas y proporcionar contexto.

Esta sección suele incluir la información más útil para los compradores.

Qué significa realmente "cumple" en un VPAT

Las etiquetas de conformidad dentro de los informes VPAT a veces se malinterpretan.

"Cumple" no significa que un producto sea perfectamente accesible. Significa que el proveedor cree que la característica cumple con el requisito de accesibilidad en condiciones normales de uso.

"Cumple parcialmente" es común.

Las aplicaciones SaaS son complejas. Una página de inicio de sesión puede cumplir completamente con los estándares de accesibilidad mientras que un módulo de informes más antiguo aún tiene problemas con la navegación por lector de pantalla.

La guía de VPAT anima a los proveedores a documentar esas brechas con honestidad.

El objetivo no es la perfección. Es la transparencia.

Una entrada típica podría ser:

WCAG 2.1 – 2.4.3 Orden del foco
Conformidad: Cumple parcialmente
Comentarios: El orden del foco funciona correctamente en la navegación principal y en las páginas de gestión de cuentas. Algunos diálogos modales en el panel de análisis saltan el foco de vuelta al cuerpo de la página.

Los equipos de contratación a menudo aceptan el cumplimiento parcial siempre que el proveedor documente el problema y muestre progreso hacia su solución.

Por qué muchos informes VPAT tempranos son inexactos

Muchos VPAT realizados por primera vez son creados rápidamente por equipos de marketing que intentan cerrar un trato.

Ese enfoque produce informes poco fiables.

Las pruebas de accesibilidad requieren una interacción real con tecnología de asistencia y navegación por teclado. Los escáneres automatizados por sí solos no pueden verificar muchos requisitos de WCAG.

Los errores comunes en los informes VPAT apresurados incluyen:

• marcar cada requisito como "cumple"
• confiar exclusivamente en herramientas de escaneo automatizadas
• probar solo la página de inicio de un producto
• ignorar las interfaces móviles
• copiar resultados de productos no relacionados

Algunos equipos de contratación ahora rechazan los documentos VPAT que carecen de comentarios detallados o metodología de prueba.

Un campo de explicación en blanco junto a docenas de entradas "cumple" es una señal de alerta.

El costo de producir un VPAT real

El precio varía ampliamente según el tamaño del producto.

Un producto SaaS pequeño con menos de 20 pantallas puede costar entre $3,000 y $8,000 por una auditoría de accesibilidad profesional y un informe VPAT.

Las plataformas empresariales más grandes a menudo cuestan entre $15,000 y $40,000 porque las pruebas deben cubrir múltiples módulos y flujos de trabajo.

El tiempo de preparación interna añade más costo.

Los equipos de ingeniería a menudo pasan semanas corrigiendo problemas de accesibilidad descubiertos durante la auditoría antes de que se publique el VPAT final.

Algunas empresas omiten ese paso y publican un VPAT que describe las limitaciones actuales. Otras esperan hasta que se complete el trabajo de remediación.

Ambos enfoques aparecen en los procesos de contratación.

Un ejemplo real de contratación

En 2023, una empresa de análisis de SaaS de tamaño medio intentó vender su plataforma a un sistema universitario estatal.

La plataforma tenía unas 70 pantallas de interfaz de usuario y nunca había sido sometida a pruebas de accesibilidad.

La contratación solicitó tres documentos:

• cuestionario de seguridad
• acuerdo de procesamiento de datos
• informe VPAT de accesibilidad

La documentación de seguridad estaba disponible. El VPAT no.

El equipo de ventas intentó armar uno internamente utilizando herramientas de escaneo automatizadas.

Durante la revisión, la oficina de accesibilidad de la universidad rechazó el documento. Las secciones de comentarios estaban en blanco y los métodos de prueba no eran claros.

El acuerdo se detuvo durante seis semanas mientras el proveedor contrataba a un consultor de accesibilidad.

El informe final identificó varios problemas:

• falta de etiquetas en formularios
• texto de bajo contraste en las leyendas de los gráficos
• trampas de teclado dentro de los modales

Esos problemas no mataron el acuerdo. La universidad aceptó el VPAT una vez que los problemas fueron documentados y se proporcionaron plazos de remediación.

El retraso le costó al proveedor un trimestre completo de su cartera de ventas.

Limitaciones de los documentos VPAT

Los informes VPAT tienen valor, pero también tienen claras limitaciones.

El documento depende en gran medida de la autodeclaración del proveedor.

Los equipos de contratación raramente repiten toda la evaluación de accesibilidad ellos mismos. Dependen de la precisión del informe del proveedor.

Debido a esa estructura, la calidad del VPAT varía ampliamente.

Algunos informes son detallados y creíbles. Otros se leen como documentos de marketing.

Otra limitación: el informe solo refleja la versión del producto evaluada.

Los productos SaaS cambian constantemente. Un VPAT creado en enero puede estar desactualizado en junio si nuevos componentes de interfaz introducen problemas de accesibilidad.

Algunas empresas ahora actualizan los informes VPAT anualmente o después de lanzamientos importantes.

Incluso esa cadencia puede pasar por alto cambios más pequeños introducidos durante ciclos de despliegue frecuentes.

Problemas de accesibilidad comunes encontrados en productos SaaS

Las auditorías de accesibilidad para herramientas SaaS tienden a sacar a la luz problemas similares en todos los productos.

Los fallos de navegación por teclado son comunes.

Los elementos interactivos a veces requieren entrada de ratón. Los menús desplegables, selectores de fecha o interfaces de arrastrar y soltar a menudo fallan cuando se accede solo con teclado.

Los fallos de contraste de color también aparecen con frecuencia.

Los equipos de diseño a menudo eligen paletas de colores sutiles que se ven limpias pero no cumplen con las relaciones de contraste de WCAG.

Los errores de etiquetado para lectores de pantalla aparecen en formularios y paneles complejos.

Los desarrolladores pueden construir componentes personalizados que parecen elementos de formulario estándar pero carecen de los atributos HTML semánticos en los que confían los lectores de pantalla.

El contenido dinámico es otro problema frecuente.

Las aplicaciones de una sola página construidas con frameworks modernos a veces actualizan el contenido de la interfaz sin notificar a la tecnología de asistencia. Los lectores de pantalla pueden no detectar esas actualizaciones.

Estos problemas aparecen repetidamente en informes VPAT de sistemas CRM, paneles de análisis, plataformas de gestión de proyectos y software de RR.HH.

Cuándo deberían las empresas SaaS crear su primer VPAT

Algunas empresas esperan hasta que llega la primera solicitud de contratación.

Ese enfoque retrasa los acuerdos.

Una estrategia más común es producir un VPAT antes de vender a grandes organizaciones.

El momento típico ocurre cuando una empresa SaaS comienza a apuntar a:

• universidades
• agencias gubernamentales
• redes de salud
• grandes departamentos de contratación corporativa

Los equipos de ventas que trabajan en esos mercados esperan documentación de accesibilidad durante la incorporación del proveedor.

Sin ella, los acuerdos se estancan temprano.

Otro factor es el riesgo legal.

Las demandas por accesibilidad contra sitios web y servicios digitales aumentaron en los últimos años. Muchas demandas hacen referencia a los estándares de accesibilidad WCAG.

Si bien un VPAT no previene demandas, demuestra que una empresa ha evaluado la accesibilidad y ha documentado los problemas conocidos.

Algunos equipos legales prefieren tener ese registro disponible.

Quién suele redactar el VPAT

Varios roles pueden contribuir al documento final.

• Consultores de accesibilidad: Firmas especializadas a menudo realizan auditorías y preparan el informe.
• Equipos de ingeniería internos: Los desarrolladores a veces documentan los hallazgos de accesibilidad después de pruebas internas.
• Equipos de cumplimiento o legales: Estos grupos revisan la redacción para evitar afirmaciones inexactas.
• Gerentes de producto: A menudo proporcionan contexto sobre las características del producto y las correcciones planificadas.

Los equipos de marketing a veces intentan crear informes VPAT solos. Eso rara vez funciona bien porque las pruebas de accesibilidad requieren una evaluación técnica de las interfaces de usuario.

La mayoría de los informes creíbles combinan el conocimiento de ingeniería con la experiencia en accesibilidad.

Cómo afectan las revisiones de VPAT a los ciclos de ventas de SaaS

La documentación de accesibilidad a menudo aparece cerca del final de los procesos de ventas empresariales.

Los equipos de contratación revisan los informes VPAT junto con los cuestionarios de seguridad y la documentación de privacidad.

Si el informe revela barreras de accesibilidad graves, los compradores pueden pedir a los proveedores plazos de remediación antes de aprobar la compra.

Los problemas menores generalmente no detienen los contratos.

Las universidades y agencias gubernamentales entienden que la mayoría del software contiene algunas limitaciones de accesibilidad.

Lo que quieren es visibilidad.

Un VPAT detallado ayuda a los equipos de contratación a decidir si los riesgos de accesibilidad son aceptables para un producto específico.

Los acuerdos se ralentizan cuando la documentación falta o es vaga.

Críticas al sistema VPAT

Los profesionales de la accesibilidad han planteado varias críticas al modelo VPAT.

La mayor preocupación es la calidad inconsistente.

Dos proveedores pueden enviar informes VPAT afirmando "cumple" en la mayoría de los criterios mientras que los productos reales se comportan de manera muy diferente para los usuarios de lectores de pantalla.

Otra crítica involucra la legibilidad.

Algunos informes VPAT tienen decenas de páginas con explicaciones técnicas que el personal de contratación tiene dificultades para interpretar.

Las oficinas de accesibilidad dentro de las universidades a menudo revisan los informes en lugar de los equipos de contratación porque los detalles técnicos requieren conocimiento especializado.

También hay debate sobre si los informes estáticos coinciden con el ritmo del desarrollo SaaS.

El software moderno lanza actualizaciones semanal o diariamente. Un informe PDF creado meses atrás puede no reflejar las condiciones de accesibilidad actuales.

A pesar de estas críticas, la plantilla sigue siendo el formato de contratación dominante para la presentación de informes de accesibilidad.

No ha surgido un reemplazo ampliamente adoptado.

Cómo mantienen las empresas los informes VPAT a lo largo del tiempo

Las organizaciones que venden ampliamente a compradores empresariales suelen tratar las actualizaciones de VPAT como una tarea recurrente de cumplimiento.

Las prácticas de mantenimiento comunes incluyen:

• auditorías de accesibilidad anuales
• actualización de documentos VPAT después de rediseños importantes del producto
• documentación de mejoras de accesibilidad entre versiones
• publicación de informes actualizados en las páginas de confianza o cumplimiento de la empresa

Algunos proveedores de SaaS también publican hojas de ruta de accesibilidad que describen correcciones o mejoras próximas.

Esas hojas de ruta a veces aparecen como enlaces dentro de la sección de comentarios del VPAT.

El objetivo es simple: reducir la fricción en la contratación durante las ventas futuras.

Qué buscan realmente los equipos de contratación

Los revisores de accesibilidad rara vez leen los informes VPAT línea por línea de principio a fin.

En su lugar, buscan varias señales.

Metodología de prueba clara: Si el documento describe pruebas con tecnología de asistencia y evaluación manual, los revisores consideran el informe más creíble.

Comentarios honestos: Las entradas que reconocen limitaciones de accesibilidad suelen ser vistas como más confiables que los documentos que afirman cumplimiento total en todas partes.

Fechas de evaluación recientes: Los informes con más de dos años a veces provocan solicitudes de documentación actualizada.

Cobertura de los flujos de trabajo principales del producto: Las pruebas deben incluir inicio de sesión, navegación, entrada de datos e informes, no solo páginas estáticas.

El VPAT funciona más como un documento de divulgación técnica que como un activo de marketing.

Los compradores quieren información que puedan evaluar.

Una comparación rápida con las declaraciones de accesibilidad

Muchas empresas SaaS ya publican declaraciones de accesibilidad en sus sitios web.

Esas declaraciones son resúmenes breves que describen objetivos y estándares de accesibilidad.

Un VPAT es muy diferente.

Los equipos de contratación casi siempre requieren el VPAT cuando se solicita documentación de accesibilidad.

Las declaraciones por sí solas rara vez satisfacen los requisitos de contratación.

Por qué los VPAT se están volviendo rutinarios para los proveedores de SaaS

Hace diez años, la mayoría de las startups de SaaS nunca encontraban requisitos de accesibilidad en las contrataciones.

Eso cambió a medida que las leyes de accesibilidad digital se expandieron y las instituciones públicas trasladaron más operaciones al software en la nube.

Las universidades ahora dependen de plataformas SaaS para sistemas de admisiones, portales de estudiantes, herramientas de aprendizaje y análisis internos.

Las agencias gubernamentales utilizan productos SaaS para sistemas de licencias, portales de servicios y colaboración interna.

Esas organizaciones deben documentar el cumplimiento de accesibilidad para las compras de tecnología.

Como resultado, los proveedores que entran en esos mercados ahora esperan solicitudes de VPAT como parte de la incorporación normal de proveedores.

Para las empresas SaaS que venden en entornos empresariales o del sector público, la documentación de accesibilidad se ha convertido en otro artefacto de cumplimiento estándar junto con la documentación de seguridad y privacidad.

La plantilla puede parecer burocrática, pero los equipos de contratación confían en ella porque crea un formato consistente para comparar proveedores.

Sin ella, las afirmaciones de accesibilidad serían imposibles de evaluar entre docenas de productos de software competidores.