/01
Keyboard navigation
Every interactive element is reachable via Tab/Shift-Tab. Skip-link on every page jumps to the main content. Focus order matches visual order. Focus rings are visible (2px solid rust) on all interactive elements.
/ FILINGS · ACCESSIBILITY
Accessible
by intent.
Scrape is engineered to be usable by everyone. This statement explains what that means in practice, what we've verified, and what we still owe you.
§ I · CONFORMANCE STATUS
Partial conformance to WCAG 2.2 Level AA.
The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA.
The Scrape marketing site, documentation, and dashboard are partially conformant with WCAG 2.2 Level AA. "Partially conformant" means that some parts of the content do not fully meet the accessibility standard. The non-conformant items are catalogued below in the known limitations section. We file a remediation ticket for each one.
For the formal mapping of every applicable WCAG 2.1 AA, Section 508, and EN 301 549 success criterion to its conformance status, see our Voluntary Product Accessibility Template (VPAT).
§ II · SCOPE
What this statement covers.
This statement applies to the entire Scrape web property — the marketing site (scrape.dev), the documentation under /docs, and the authenticated dashboard at /dashboard.
It does not cover content fetched by the scraper itself. Scrape retrieves third-party HTML on your behalf; the accessibility of that HTML is determined by the source site, not by us. When you preview a fetched page in the dashboard we render it inside a sandboxed iframe.
§ III · WHAT WORKS
Verified support.
The list below is what we have manually tested with the assistive technologies named in § VI. We do not list what we hope works.
/02
Color contrast
Body text against page background is 12.5:1 (AAA). Muted secondary text is 7.2:1 (AAA). Rust accent on dark mode is 5.4:1 (AA). Both light and dark modes are tested.
/03
Screen-reader markup
Semantic HTML5 — landmarks (header/main/nav/footer), heading hierarchy without skipped levels, lists for lists. Form fields are associated with labels. Icon-only buttons carry aria-label. Live regions announce job progress.
/04
Resize + zoom
Layout reflows down to 320px width without horizontal scrolling. Text remains readable at 200% browser zoom. No content depends on a specific orientation.
/05
Reduced motion
Long marquees, scroll animations, and pulse indicators respect prefers-reduced-motion: reduce. The dashboard's live-progress UI continues to update with text without motion when that preference is set.
/06
Forms
All inputs have visible labels (no placeholder-only forms). Error messages are programmatically associated via aria-describedby. Required fields are marked both visually and via aria-required.
§ IV · KNOWN LIMITATIONS
What we still owe you.
These are documented gaps. Each carries an internal ticket ID (ACC-NNN) and a target remediation date in our public roadmap.
Code blocks with syntax highlighting
Long horizontal-scrolling code blocks lack a keyboard-accessible scroll affordance — users on a keyboard cannot scroll horizontally without hold-and-drag. Tracking as ACC-014. Mitigation: code is also available in copy-to-clipboard form.
Live job-progress charts
The Recharts-rendered SVG sparklines on the job detail page are decorative — the same data is announced as a live region, but the chart shapes themselves are not keyboard-focusable. ACC-019.
Marketing logo marquee
The auto-scrolling 'field crew' logo strip on the home page does not have a pause control. Reduced-motion users see a static fallback. We have not added an explicit pause button. ACC-002.
Browser-rendered job results
When you preview the rendered HTML of a fetched page in the dashboard, that HTML comes from the source site — Scrape does not (and cannot) modify its accessibility. We render it inside a sandboxed iframe and warn users when navigating to source content.
§ V · OUR APPROACH
How we ship accessibly.
- →Foundation in primitives. The dashboard uses Radix UI primitives, which are built to WAI-ARIA Authoring Practices. We extend rather than rebuild basic interactive widgets.
- →Automated CI checks. Every pull request runs
axe-coreand Lighthouse on representative pages. Builds fail when serious or critical issues regress. - →Manual review per release. Each release branch is keyboard-tested end to end and screen-reader spot-checked on at least one of NVDA + JAWS + VoiceOver.
- →Quarterly external audit. An external accessibility consultancy reviews the dashboard every quarter; remediation tickets are public on the issue tracker.
- →Open source, open issues. Anyone can read the code, file an issue, or send a fix on GitHub.
§ VI · TESTED WITH
Compatible assistive technology.
Technology
Configuration
NVDA
Latest stable on Firefox 135+ (Windows)
JAWS
Latest stable on Chrome 130+ (Windows)
VoiceOver
macOS 14+ on Safari 17+ / iOS 17+ on Safari
TalkBack
Android 14+ on Chrome
Dragon NaturallySpeaking
Latest stable on Windows
Windows Speech Recognition
Latest stable on Edge 130+
The site should also work with most other modern combinations of browser + assistive technology. If you find one that doesn't, please tell us.
§ VII · FEEDBACK
Find a barrier? Tell us.
We treat accessibility regressions as bugs, not feature requests. Three ways to reach us, in order of how fast we can act:
- Email accessibility@scrape.dev — monitored by an engineer; we acknowledge within one business day, target remediation within 30 days.
- File a GitHub issue with the
a11ylabel — public tracker, useful when you want to see progress. - Use the contact form on /contact for general correspondence.
When reporting a barrier, please include: the URL of the page, the browser + version, the assistive technology + version, and the action you were trying to take. Screenshots or short recordings help, but are not required.
§ VIII · ENFORCEMENT
If we don't respond.
If you have submitted feedback through the channels above and are not satisfied with our response, you may escalate through these regulatory routes:
- United States. File a complaint with the Department of Justice under Title III of the Americans with Disabilities Act, or the federal agency that regulates the relevant sector.
- European Union. Contact the supervisory authority for accessibility in your member state under Directive (EU) 2016/2102 (for public-sector bodies) or the European Accessibility Act 2025 transposition in your jurisdiction.
- United Kingdom. The Equality and Human Rights Commission (EHRC) is the enforcement body for the Equality Act 2010.
Last reviewed: .
Review cadence: quarterly, and on every release branch.
Self-evaluation method: automated axe-core CI run + manual keyboard pass + screen-reader spot-check, repeated by an external auditor each quarter.