Accessibility statement

Scrapeland is committed to making scrape.land usable by everyone, including people who browse with a screen reader, a keyboard only, magnification, or reduced motion. This statement describes how far we have got and what we know is still wrong.

1. Conformance target

We target Web Content Accessibility Guidelines (WCAG) 2.1 level AA, which is the standard referenced by EN 301 549 and the European Accessibility Act. We are partially conformant: most of the site meets that bar, and the exceptions below do not.

2. What we have done

• Every page has a skip link and a single main landmark, so a keyboard user can reach the content without tabbing through the header.
• Colours are declared explicitly in both the dark and light themes rather than inherited from the browser, and body text meets the 4.5:1 contrast minimum.
• Links inside sentences are underlined, so they are not distinguished by colour alone.
• Code samples and wide tables that scroll sideways can be reached and scrolled with the keyboard.
• The mobile menu moves focus into itself, keeps focus inside while open, closes on Escape, and returns focus to the button that opened it.
• Status messages, including copy confirmations and errors, are announced to screen readers.
• Animation on the landing page and the documentation stops for visitors whose system asks for reduced motion.
• Data tables identify their column headers, and the site is published in English, Romanian and Italian.
• Every chart and map in the dashboard is accompanied by a table of the same figures, so no value is conveyed only by colour or by a tooltip you need a mouse to reach.
• Notifications can be dismissed by hand, stop disappearing while you are reading them, and error messages do not vanish on their own.
• Form errors are attached to the field that caused them and move the cursor there, and every confirmation uses the same in-page dialog, which keeps focus inside it and closes on Escape.

3. Known problems

These are the barriers we are aware of. They are real, and this list is not a summary of an automated scan — automated tools find roughly a third of accessibility problems, and the rest of this list came from testing by hand.

• We have not tested the site with the screen readers themselves. Our checks run automated rules, read the browser's own accessibility tree, and operate every page from the keyboard — all of it in Chrome. NVDA, JAWS, VoiceOver and browsers other than Chrome have not been through it end to end, so problems specific to one pairing may remain.

4. How this was assessed

We assessed the site ourselves. Automated testing used axe-core against every public page and against every screen of the signed-in dashboard, including the administrative area, in both the dark and the light theme and down to a 320-pixel-wide window. The rest was manual keyboard testing, inspection of the accessibility tree, and review of colour contrast against the WCAG formula. We have not commissioned an independent third-party audit, and we do not describe this statement as one.

5. The API itself

The API returns machine-readable JSON, and every error carries a message in plain text that says what went wrong and what to change. No error depends on colour, position, or an image to be understood. Our client libraries and documentation are the human surface of the API, and the statement above applies to them.

6. Reporting a problem

If something on this site does not work for you, please tell us. Describe the page and what you were trying to do, and include your assistive technology and browser if you can. We aim to reply within five working days, and we will tell you either when it is fixed or why it is not. support@scrape.land.

If you are not satisfied with our response, you can raise the matter with the market surveillance authority for accessibility in your EU member state.