/ FILINGS · VPAT 2.5
Voluntary Product
Accessibility Template.
A formal conformance report following the ITI VPAT 2.5 format. For the friendlier consumer-facing version see our accessibility statement.
Product name
Scrape
Product version
v0.5
Report date
2026-04-29
Contact
accessibility@scrape.dev
Product description
Open-source web scraping platform with tiered HTTP/browser/CAPTCHA/unblock escalation, residential proxy rotation, and Claude-based AI extraction. Includes a Next.js 15 dashboard, FastAPI REST API, and CLI.
Notes on the report
This VPAT covers the marketing site (scrape.dev), the documentation, and the authenticated dashboard at /dashboard. It does not cover content fetched by the scraper on a customer's behalf — the accessibility of fetched HTML is determined by the source site.
§ I · APPLICABLE STANDARDS
Standards covered.
- ·Web Content Accessibility Guidelines (WCAG) 2.1 — Level A and Level AA
- ·WCAG 2.2 — Level AA (the four 2.2-only criteria are evaluated separately below)
- ·Revised Section 508 standards (US 36 CFR Part 1194) — incorporates WCAG 2.0 by reference
- ·EN 301 549 v3.2.1 (EU) — incorporates WCAG 2.1 AA
§ II · TERMS USED
How to read this report.
Each WCAG success criterion below is mapped to one of four conformance levels per the ITI VPAT 2.5 vocabulary:
- Supports
- The functionality of the product has at least one method that meets the criterion without known defects, or meets with equivalent facilitation.
- Partially Supports
- Some functionality of the product does not meet the criterion. The remarks call out which parts and why.
- Does Not Support
- The majority of the product functionality does not meet the criterion.
- Not Applicable
- The criterion is not relevant to the product.
§ III · EVALUATION METHODS
How conformance was determined.
- →Automated axe-core scans on every CI build (representative pages: home, pricing, docs landing, dashboard, job detail).
- →Manual keyboard-only traversal of every public page and the most-used dashboard flows (sign in, create job, view results, settings).
- →Screen-reader spot checks each release on at least one of NVDA + JAWS + VoiceOver.
- →Quarterly external review by an independent accessibility consultancy (results filed in the public ACC-NNN issue tracker).
§ IV · CONFORMANCE SUMMARY
By the numbers.
Across the 50 applicable WCAG 2.1 Level A and AA success criteria:
37
Supports
3
Partially supports
0
Does not support
10
Not applicable
§ V · WCAG 2.1 REPORT
Chapter 1 — Perceivable.
| § | Criterion | Level | Conformance | Remarks & explanations |
|---|---|---|---|---|
| 1.1.1 | Non-text Content | Level A | Supports | All informative images carry alt text; decorative images are alt="" or aria-hidden. Icon-only buttons (e.g. theme toggle, close icons) carry aria-label. SVG-only logos have role=img and an accessible name. |
| 1.2.1 | Audio-only and Video-only (Prerecorded) | Level A | Not Applicable | The product ships no prerecorded audio or video content. |
| 1.2.2 | Captions (Prerecorded) | Level A | Not Applicable | No prerecorded video content. |
| 1.2.3 | Audio Description or Media Alternative (Prerecorded) | Level A | Not Applicable | No prerecorded video content. |
| 1.2.4 | Captions (Live) | Level AA | Not Applicable | No live audio or video content. |
| 1.2.5 | Audio Description (Prerecorded) | Level AA | Not Applicable | No prerecorded video content. |
| 1.3.1 | Info and Relationships | Level A | Supports | Document structure uses HTML5 landmarks (header, main, nav, footer, aside). Headings follow logical hierarchy without skipped levels. Lists use <ul>/<ol>/<dl>. Form controls are explicitly associated with <label>. Tables use <th scope> for headers. |
| 1.3.2 | Meaningful Sequence | Level A | Supports | Source order matches visual reading order. Multi-column layouts use CSS grid/flex without breaking the underlying tab-and-screen-reader order. |
| 1.3.3 | Sensory Characteristics | Level A | Supports | Instructions never rely on color, shape, position, or sound alone. Tier-escalation status uses both an icon and a textual label; success/error states pair color with a glyph and copy. |
| 1.3.4 | Orientation | Level AA | Supports | No content is locked to a specific orientation. The mobile dashboard works in both portrait and landscape. |
| 1.3.5 | Identify Input Purpose | Level AA | Supports | Account-related inputs use the WCAG-listed autocomplete tokens — autocomplete="email", "new-password", "current-password", "name", etc. |
| 1.4.1 | Use of Color | Level A | Supports | Color is never the sole means of conveying information. Form errors carry both a red border and an explicit error-text element. Tier badges include the tier number text in addition to the color. |
| 1.4.2 | Audio Control | Level A | Not Applicable | No auto-playing audio. |
| 1.4.3 | Contrast (Minimum) | Level AA | Supports | Tested with pair-axe. Body text against page background: 12.5:1 (AAA). Muted secondary text: 7.2:1 (AAA). Rust accent on dark: 5.4:1 (AA). Validated in both light and dark modes. |
| 1.4.4 | Resize text | Level AA | Supports | Text scales to 200% without loss of content or functionality. No fixed-pixel font sizes on body copy; all layout uses rem-based spacing. |
| 1.4.5 | Images of Text | Level AA | Partially Supports | Marketing pages and the dashboard use real text exclusively. The Open Graph image (/opengraph-image) is a rendered PNG containing the brand wordmark — this is acceptable per WCAG because the OG image is metadata, not on-page content. The single exception within the page is the Fraunces wordmark in the footer pull-quote, which is rendered as live SVG text and carries an accessible name. |
| 1.4.10 | Reflow | Level AA | Supports | Layout reflows down to 320 CSS pixels wide without horizontal scrolling, except for content that genuinely requires 2D presentation (data tables in the dashboard's job results — these allow horizontal scroll within their container). |
| 1.4.11 | Non-text Contrast | Level AA | Supports | Form input borders, button outlines, focus indicators, and icon strokes all meet or exceed the 3:1 minimum against their adjacent backgrounds. |
| 1.4.12 | Text Spacing | Level AA | Supports | Tested with the WCAG Text Spacing user-stylesheet — line-height 1.5×, paragraph spacing 2×, letter spacing 0.12×, word spacing 0.16×. No content clipped or overlapping. |
| 1.4.13 | Content on Hover or Focus | Level AA | Partially Supports | Tooltip and popover primitives from Radix UI are dismissible (Esc), hoverable, and persistent — they meet the criterion. Two custom hover-only effects in the marketing site (the dotted-leader sitemap rows in the footer) reveal additional information that is also exposed via focus, but the hover state is not user-dismissible without leaving focus. Tracked as ACC-021. |
Chapter 2 — Operable.
| § | Criterion | Level | Conformance | Remarks & explanations |
|---|---|---|---|---|
| 2.1.1 | Keyboard | Level A | Supports | All interactive elements (links, buttons, form fields, tabs, dialogs, dropdown menus) are reachable and operable via keyboard alone. Custom widgets sit on top of Radix primitives, which are tested against this criterion upstream. |
| 2.1.2 | No Keyboard Trap | Level A | Supports | Modal dialogs trap focus only within the dialog while open and release it on close. No widget retains keyboard focus indefinitely. |
| 2.1.4 | Character Key Shortcuts | Level A | Supports | The command palette (Ctrl/Cmd+K) and theme toggle use modifier keys. We do not bind any single-character shortcuts that would conflict with assistive technology. |
| 2.2.1 | Timing Adjustable | Level A | Not Applicable | No time-limited content. Auth tokens expire silently at 7 days; the user is never forced to act within a visible time window. |
| 2.2.2 | Pause, Stop, Hide | Level A | Partially Supports | The home-page logo marquee (auto-scrolling field-crew strip) does not have an explicit pause control. It does respect prefers-reduced-motion: reduce, displaying a static fallback. Adding an explicit pause button is tracked as ACC-002. |
| 2.3.1 | Three Flashes or Below Threshold | Level A | Supports | No animations exceed three flashes per second. The status-strip pulse-dot animates at ~1 Hz (well under the threshold). |
| 2.4.1 | Bypass Blocks | Level A | Supports | Every page provides a 'Skip to main content' link as the first focusable element. Landmark regions (banner, navigation, main, contentinfo) allow screen-reader users to jump. |
| 2.4.2 | Page Titled | Level A | Supports | Every page has a unique, descriptive <title> via Next.js metadata API; titles follow the pattern '<Page name> · Scrape'. |
| 2.4.3 | Focus Order | Level A | Supports | Focus order follows the visual reading order on every audited page. No tabindex > 0 is used. |
| 2.4.4 | Link Purpose (In Context) | Level A | Supports | Link text is descriptive in itself or in conjunction with the surrounding sentence. We avoid 'click here'-style links. External links carry an aria-label expansion (e.g. 'Source code, opens in new tab'). |
| 2.4.5 | Multiple Ways | Level AA | Supports | Pages can be reached via persistent navigation, footer sitemap, search (command palette), and breadcrumbs (on docs). |
| 2.4.6 | Headings and Labels | Level AA | Supports | Headings describe the topic of their section. Form labels describe the field's purpose. No empty headings or label-text mismatches. |
| 2.4.7 | Focus Visible | Level AA | Supports | All interactive elements show a visible focus indicator (2px solid rust outline, 2px offset). Default browser outline is overridden but not removed; a custom outline replaces it everywhere. |
| 2.5.1 | Pointer Gestures | Level A | Supports | All multi-point and path-based gestures (e.g. drag-to-reorder in the dashboard) have a single-pointer alternative. |
| 2.5.2 | Pointer Cancellation | Level A | Supports | Activation of buttons fires on the up-event, not the down-event. Drag handles support escape-to-cancel. |
| 2.5.3 | Label in Name | Level A | Supports | Visible label text appears at the start of accessible names for all controls — important for voice-control software (Dragon, Voice Access). |
| 2.5.4 | Motion Actuation | Level A | Not Applicable | The product does not respond to device motion or user motion (no shake-to-undo, etc.). |
Chapter 3 — Understandable.
| § | Criterion | Level | Conformance | Remarks & explanations |
|---|---|---|---|---|
| 3.1.1 | Language of Page | Level A | Supports | Every page sets <html lang="en">. |
| 3.1.2 | Language of Parts | Level AA | Not Applicable | Page content is currently English-only. When non-English passages are introduced (e.g. localized testimonials), they will carry lang attributes. |
| 3.2.1 | On Focus | Level A | Supports | Focusing an element does not trigger an unexpected context change. |
| 3.2.2 | On Input | Level A | Supports | Changing a form field does not auto-submit or navigate the page. The user always confirms via an explicit submit. |
| 3.2.3 | Consistent Navigation | Level AA | Supports | Marketing header, dashboard sidebar, and docs sidebar maintain identical relative ordering across pages. |
| 3.2.4 | Consistent Identification | Level AA | Supports | Components with the same function (e.g. 'New job' button, 'Sign out' link) carry identical labels and icons across the dashboard. |
| 3.3.1 | Error Identification | Level A | Supports | Form validation errors are announced via aria-describedby links from the input to the error message; messages are color- and text-coded ('Email is required'). |
| 3.3.2 | Labels or Instructions | Level A | Supports | All form controls have visible labels (no placeholder-only inputs). Required fields are marked both visually and with aria-required. |
| 3.3.3 | Error Suggestion | Level AA | Supports | When validation fails, the inline message includes a suggested correction where the system can infer one (e.g. 'Email must contain @'). |
| 3.3.4 | Error Prevention (Legal, Financial, Data) | Level AA | Supports | Account deletion, plan downgrade, and webhook deletion all require an explicit confirmation step. API key revocation is reversible until the user signs out. |
Chapter 4 — Robust.
| § | Criterion | Level | Conformance | Remarks & explanations |
|---|---|---|---|---|
| 4.1.1 | Parsing | Level A | Not Applicable | WCAG 2.2 deprecates this criterion as obsolete. We continue to ship valid HTML5 (validated as part of CI builds via Next.js's React 19 strict-mode emission). |
| 4.1.2 | Name, Role, Value | Level A | Supports | All custom widgets expose accessible name, role, and state via Radix UI primitives. Programmatic state changes (e.g. dropdown open/closed) are announced. |
| 4.1.3 | Status Messages | Level AA | Supports | Job-progress updates, save-success toasts, and form-validation errors are all announced via role="status" or role="alert" without moving keyboard focus. |
§ VI · WCAG 2.2 ADDITIONS
Criteria new in WCAG 2.2.
These four AA criteria are present in WCAG 2.2 but not in 2.1. Customers operating under a WCAG-2.1-only procurement may disregard this section.
| § | Criterion | Level | Conformance | Remarks & explanations |
|---|---|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | Level AA | Supports | Sticky headers and footers are sized so that no focused element is fully hidden behind them; the marketing header (~64px) and dashboard sidebar leave the focused content visible. |
| 2.5.7 | Dragging Movements | Level AA | Supports | Every drag interaction in the dashboard (e.g. reordering API keys) has a single-pointer alternative — keyboard arrow-key reorder, or a context menu with 'Move up' / 'Move down'. |
| 2.5.8 | Target Size (Minimum) | Level AA | Supports | All interactive targets are at least 24×24 CSS pixels. Buttons in the dashboard are 36px+; icon buttons are 32px+. Inline links are exempt per the criterion. |
| 3.3.8 | Accessible Authentication (Minimum) | Level AA | Supports | Sign-in does not require a cognitive function test. Password fields support paste; we do not impose puzzle-CAPTCHAs on customer authentication. Account recovery uses one-click email links. |
§ VII · SECTION 508
Revised Section 508 — chapters 4 and 5.
The US Revised Section 508 standards incorporate WCAG 2.0 Level A and AA by reference (36 CFR Part 1194 § 504.2). All applicable WCAG criteria above therefore apply to Section 508 conformance. The product is purely web-based; chapters 4 (Hardware) and 5 (Software) are Not Applicable except for the following two software-platform criteria that cover the keyboard interface in the dashboard:
502.3.1
Object Information
Supports
Object information (name, role, state, value) is exposed via standard ARIA attributes; the dashboard relies on Radix primitives that are tested against this criterion.
503.2
User Preferences
Supports
User-set preferences for color, contrast, and font are honored via prefers-color-scheme, prefers-contrast, and OS-level font scaling.
§ VIII · EN 301 549
EN 301 549 v3.2.1 — relevant clauses.
EN 301 549 incorporates WCAG 2.1 AA by reference (clause 9). The applicable criteria are therefore those listed in §V above. Clause 11 (Software) covers the dashboard's desktop-style widgets via the same Radix-primitives evaluation already noted. Clauses 6 (Two-way Voice), 7 (Video), 8 (Hardware), and 13 (ICT providing real-time text) are Not Applicable — the product does not provide voice, video, hardware, or real-time text functionality.
Report version: 1.0
Report author: Scrape Bureau accessibility working group
Contact: accessibility@scrape.dev
Next scheduled review: on the next minor release branch (quarterly).
The VPAT format is owned by the Information Technology Industry Council (ITI) and is freely usable. The conformance evaluations in this document represent Scrape's own honest review of its product against the applicable standards.