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)
Results are deduplicated across engines so no violation is counted twice.
-
Scoring & analysis — An accessibility score (0–100) summarizes counted findings by severity. A separate card highlights selected accessibility barriers; it does not estimate litigation probability.
-
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 — Eligible plans provide suggested code changes for automated findings. Saved suggestions appear immediately on the issue page. If one is missing, an authorized member opening that page requests a suggestion for that issue only. Re-renders do not trigger a site-wide batch. Retry and regeneration are explicit actions; all suggested changes require review and testing.
-
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, generate VPAT-based evidence drafts), Billing (subscription and invoices only, no site or issue visibility), and Client guest on 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-based evidence summaries — A deterministic summary records which automated failure patterns were detected, which were not detected, and which criteria have no automated rule. It does not assign an official conformance level. 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 detects common WCAG 2.2 AA failure patterns; it cannot establish conformance, and a scan without findings has only ruled out the failure patterns its rules cover. Thirty of the 55 active A/AA criteria have no automated rule at all and require human judgment (e.g., whether alt text is meaningful, whether content is logically ordered). In a draft Accessibility Conformance Report, AllyProof records what the scan observed and leaves the conformance level for a qualified evaluator wherever automation cannot support one. See WCAG Coverage.