La aplicación web de VeriSwarm está construida y se prueba de forma continua conforme a las Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — el estándar de referencia citado por la ADA y la Section 508. Esta página expone con claridad nuestro objetivo de conformidad, lo que realmente hemos verificado y lo que todavía falta por hacer. Aquí no afirmamos una conformidad total ni certificada: afirmamos lo que hemos probado y enumeramos lo que aún no hemos terminado.
Última revisión: 27 de agosto de 2026.
Nuestro objetivo es WCAG 2.2 Level AA en todo veriswarm.ai. Ese objetivo se aplica en nuestro propio proceso de entrega, no es solo una aspiración: en cada cambio, antes de fusionarse, se ejecutan comprobaciones de accesibilidad automatizadas, y las páginas representativas reciben además auditorías manuales y verificación con lector de pantalla. No es una certificación puntual: es una comprobación que volvemos a ejecutar continuamente a medida que el sitio cambia.
Esta declaración cubre la aplicación web veriswarm.ai: el sitio de marketing, la documentación, el blog, los precios, el flujo de autenticación y las consolas autenticadas de cuenta y administración. No cubre sitios de terceros a los que enlazamos, ni el contenido que nuestros clientes publican a través de la plataforma (por ejemplo, páginas generadas por agentes).
Controles y comprobaciones concretos que están funcionando hoy, no una hoja de ruta.
Las reglas jsx-a11y de ESLint se ejecutan en cada commit, y los escaneos automatizados de páginas con axe-core se ejecutan en rutas representativas en cada cambio. Ambas son comprobaciones bloqueantes, no advertencias informativas.
Además del análisis automatizado, hemos realizado auditorías manuales a nivel de código en arquetipos de página representativos — landing, contenido de documentación/aprendizaje, precios, blog, autenticación, panel de control y administración — revisando a mano la estructura de encabezados, los landmarks, la accesibilidad por teclado y la corrección de ARIA.
Cada página utiliza una única estructura de landmarks — un header/nav, un main y un footer — con una jerarquía de encabezados adecuada, y un enlace “Skip to content” es el primer elemento que recibe el foco en cada página.
Los controles interactivos son alcanzables y operables solo con el teclado, con un indicador de foco visible en cada elemento enfocable. Los widgets personalizados, como los modales, implementan una trampa de foco adecuada, cierre con Escape y devuelven el foco al elemento que los activó.
La animación y el movimiento respetan la preferencia de movimiento reducido del sistema operativo (prefers-reduced-motion).
Los colores del texto y de la interfaz se verifican contra los ratios de contraste de WCAG 1.4.3 (4.5:1 para texto normal, 3:1 para texto grande y límites de interfaz), calculados con la fórmula real de luminancia relativa en lugar de a simple vista.
Los gráficos y las visualizaciones de puntuación exponen sus datos subyacentes como texto (etiquetas, tablas o descripciones accesibles) en lugar de depender solo del color o la forma.
Los campos de formulario tienen etiquetas asociadas programáticamente, y los errores de validación se exponen con aria-invalid y aria-describedby en lugar de solo con el color.
No afirmamos una conformidad completa ni certificada. Esto es lo que sabemos que todavía necesita trabajo, y por qué no hemos publicado una solución que no pudiéramos verificar.
El panel de cuenta y la consola de administración han pasado por auditorías exhaustivas a nivel de código (estructura de encabezados, uso de landmarks, corrección de ARIA, gestión del foco), pero como estas superficies requieren una sesión de inicio de sesión activa, la verificación con un lector de pantalla real y un recorrido solo con teclado sobre la salida realmente renderizada todavía está en curso. Consideramos que una auditoría a nivel de código es necesaria, pero no suficiente por sí sola.
Algunas secciones con pestañas en las consolas de cuenta y administración (por ejemplo, la navegación de la cuenta y las subpestañas de Cortex/Governance) usan actualmente botones estándar que cambian el contenido visible, en lugar del patrón completo de pestañas ARIA (role="tablist"/tab/tabpanel con navegación por teclas de flecha). Un intento anterior de añadir roles ARIA parciales sin el patrón completo se revirtió, porque un widget de pestañas medio implementado es peor para la tecnología de asistencia que un simple conjunto de botones — anuncia una interacción de pestañas que la página en realidad no admite. Mientras tanto, los botones simples siguen siendo totalmente operables con teclado y ratón; un patrón de interfaz con pestañas más completo y correctamente implementado para estas secciones es trabajo futuro planificado.
Si te encuentras con algo en veriswarm.ai que sea difícil de usar con teclado, lector de pantalla u otra tecnología de asistencia, cuéntanoslo. Incluye la URL de la página, qué intentabas hacer y, si puedes, la tecnología de asistencia o el navegador que estabas usando.
support@veriswarm.ai