How It Works
A high-level overview of how AllyProof scans your sites, processes results, and keeps your data secure.
Scan Pipeline
When you trigger a scan — manually, via the CI/CD API, or on a schedule — AllyProof runs through this pipeline for each page:
- Page discovery— Pages are found via your sitemap (preferred) or by crawling links from the homepage. The number of pages scanned depends on your plan's page limit.
- Multi-engine scanning— Each page is loaded in a real Chromium browser and tested by three engines simultaneously:
- axe-core — 91 rules, zero false-positive policy (primary engine)
- HTML_CodeSniffer — ~200 additional rules for broader coverage
- APCA — Advanced contrast analysis (WCAG 3.0 preview)
- Scoring & analysis— An accessibility score (0–100) is calculated based on violation count and severity. Litigation risk is assessed by matching violations to those commonly cited in ADA lawsuits.
- Element screenshots— Visual screenshots of affected elements are captured as evidence, displayed as clickable thumbnails on the issue detail page.
- Scan comparison— Results are compared against the previous scan to identify new issues, verified fixes, and regressions. Previously resolved violations that reappear are automatically reopened.
- AI fix suggestions— For each detected violation, AI generates a before/after code fix with a WCAG technique reference. These are generated asynchronously and appear on the violation detail page.
- Notifications & webhooks— Team members are notified based on their individual preferences. Webhook events are emitted for external integrations.
Data Security
| Measure | Detail |
|---|---|
| Encryption in transit | All connections use TLS (HTTPS). No data is transmitted in plaintext. |
| Tenant isolation | Every database query is filtered by your organization. Row Level Security (RLS) policies enforce this at the database level — even if application code has a bug, cross-tenant access is blocked. |
| API key security | API keys are stored as SHA-256 hashes. The plaintext key is shown only once at creation time and is never stored. |
| Role-based access | Five roles with a server-enforced 11-action permission matrix: Owner (full control including billing and org deletion), Admin (sites, team, API keys, webhooks, audit log — but not billing), Member (run scans, manage issues, draft VPATs), Billing (subscription and invoices only, no site or issue visibility), and Client guest on Agency and Enterprise (site-scoped read-only). See Team & Permissions for the full matrix. |
| Audit log | All organization actions are recorded in an immutable audit log. Admin and owner users can review the full history in Settings. |
| Data hosting | Primary database hosted in the EU (Germany). Compliant with GDPR requirements. |
| Authentication | Email/password, Google OAuth, and GitHub OAuth. Sessions use HttpOnly cookies with PKCE flow. |
Scheduled Scans
Depending on your plan, scans run automatically on a weekly or daily schedule. You configure the frequency per site in Settings. Scheduled scans follow the same pipeline as manual scans and trigger the same notifications.
AI-Powered Features
AllyProof uses AI for three features:
- Fix suggestions— Generated for each detected violation. Shows the problematic code and a corrected version with the relevant WCAG technique. These are suggestions, not automated fixes — a developer should review before implementing.
- VPAT executive summaries— AI writes the conformance summary section of VPAT documents based on scan results. Always labeled DRAFT.
- Fix instructions export— Download a Markdown file containing all open violations with AI-generated fix patterns, organized by severity. The file is framework-agnostic and compatible with coding tools like Claude Code, Cursor, and GitHub Copilot.
AI-generated content may contain inaccuracies. All suggestions should be reviewed by qualified personnel before use. The AI provider is shown on each suggestion via a "Powered by" label.
Integrations
| Integration | Purpose |
|---|---|
| CI/CD API | Trigger scans from GitHub Actions, GitLab CI, or any pipeline |
| Email notifications | Per-user preferences for scan results, critical alerts, and weekly digests |
| Webhooks | Receive events (scan.completed, violation.new, violation.resolved) with HMAC-SHA256 signed payloads |
| Shared reports | Token-based public read-only report links with 30-day expiry |
| Embeddable badge | SVG accessibility badge for your site (light/dark themes) |
| Public statements | One-click publish of accessibility statements with a permanent URL |
Coverage Limitations
Automated scanning covers approximately 57–70% of WCAG 2.2 AA criteria. The remaining criteria require human judgment (e.g., whether alt text is meaningful, whether content is logically ordered). AllyProof clearly marks untestable criteria as "Not Evaluated" in VPAT documents and recommends manual expert review for full conformance.