Skip to content
VeriSwarm
About
DocsPricingAgent Skill
LoginRegister
  1. Home
  2. /Accessibility
VeriSwarm
  • ✓ English
  • Español
  • Deutsch
  • Français
  • Italiano
  • Português
  • 日本語
  • 한국어
  • 简体中文

Product

  • Pricing
  • Docs
  • API
  • Agent Skill
  • OATS Spec

Trust

  • Trust Center
  • Security
  • Compliance
  • Status
  • Changelog

Company

  • About
  • Blog
  • Open Source
  • Investors
  • Press

Legal

  • Terms
  • Privacy
  • SLA
  • DPA
  • Accessibility

Accessibility

VeriSwarm's web application is built to, and continuously tested against, the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — the benchmark referenced by the ADA and Section 508. This page states our conformance target plainly, what we've actually verified, and what still needs work. We don't claim full or certified conformance here — we claim what we've tested and list what we haven't finished.

Last reviewed: August 27, 2026.

Conformance target

We target WCAG 2.2 Level AA across veriswarm.ai. That target is enforced in our own delivery pipeline, not just aspired to: automated accessibility checks run on every change before it merges, and representative pages get manual audits and screen-reader verification on top of that. It is not a one-time certification — it's a gate we re-run continuously as the site changes.

Scope

This statement covers the veriswarm.ai web application — the marketing site, docs, blog, pricing, authentication flow, and the authenticated account and admin consoles. It does not cover third-party sites we link to, or content our customers publish through the platform (for example, agent-generated pages).

What's been done

Concrete controls and checks that are actually running today, not a roadmap.

Automated gates in CI

ESLint's jsx-a11y rules run on every commit, and automated axe-core page scans run against representative routes on every change. Both are blocking checks, not advisory warnings.

Manual audits across page types

Beyond automated scanning, we've done manual, code-level audits across representative page archetypes — landing, docs/learn content, pricing, blog, authentication, dashboard, and admin — checking heading structure, landmarks, keyboard reachability, and ARIA correctness by hand.

Semantic structure and skip link

Every page uses a single landmark structure — one header/nav, one main, one footer — with a proper heading hierarchy, and a “Skip to content” link is the first focusable element on every page.

Keyboard operability and visible focus

Interactive controls are reachable and operable by keyboard alone, with a visible focus indicator on every focusable element. Custom widgets like modals implement a proper focus trap, Escape-to-close, and focus return to the trigger.

Reduced-motion support

Animation and motion respect the operating system's reduced-motion preference (prefers-reduced-motion).

AA color contrast

Text and UI colors are checked against the WCAG 1.4.3 contrast ratios (4.5:1 for normal text, 3:1 for large text and UI boundaries), computed with the real relative luminance formula rather than eyeballed.

Text alternatives for data visualizations

Charts and score visualizations expose their underlying data as text (labels, tables, or accessible descriptions) rather than relying on color or shape alone.

Accessible forms

Form fields have programmatically associated labels, and validation errors are exposed with aria-invalid and aria-describedby rather than color alone.

Known limitations — honestly

We don't claim complete or certified conformance. Here's what we know still needs work, and why we haven't shipped a fix yet rather than shipping a fix we couldn't verify.

Authenticated dashboard and admin surfaces — live screen-reader verification in progress

The account dashboard and admin console have had thorough code-level audits (heading structure, landmark usage, ARIA correctness, focus management), but because these surfaces require a live login session, verification with a real screen reader and a keyboard-only walkthrough against actual rendered output is still in progress. We treat a code-level audit as necessary but not sufficient on its own.

Some in-app tabbed sections use plain buttons, not a full tab widget

A few tabbed sections in the account and admin consoles (for example, the account navigation and the Cortex/Governance sub-tabs) currently use standard buttons that switch visible content, rather than the full ARIA tabs pattern (role="tablist"/tab/tabpanel with arrow-key navigation). An earlier attempt to add partial ARIA roles without the full pattern was reverted, because a half-wired tab widget is worse for assistive tech than a plain button set — it announces a tab interaction the page doesn't actually support. Plain buttons remain fully operable by keyboard and mouse in the meantime; a richer, fully-wired tabbed-interface pattern for these sections is planned future work.

Report a barrier

If you run into anything on veriswarm.ai that's hard to use with a keyboard, screen reader, or other assistive technology, tell us. Include the page URL, what you were trying to do, and the assistive technology or browser you were using, if you can.

support@veriswarm.ai