Privacy & Security

What we collect when we scan and run journeys, what we do with it, and what we protect it with. Stated only as far as we can substantiate it.

Effective date: October 1, 2026

Card details never reach us
Payments run through Stripe Checkout. Card numbers are entered on Stripe’s pages and stored by Stripe; our servers never receive or hold them.
Encrypted in transit and at rest
Every request is served over TLS, and plain-HTTP and www requests are redirected to the canonical secure host. Stored third-party tokens are encrypted with AES-256-GCM before they reach the database.
No credential vault for your site
There is no credential vault in this product. If a journey signs in, the sign-in details you type into its test data are saved with the journey as ordinary text, not separately encrypted, and sent to the AI model that runs it. Use a dedicated test account, never live credentials.
Monitoring collects no page content
The collector reports a route pattern, a barrier fingerprint, and a redacted description of the element — never page text, never a full URL with its query string, and nothing identifying a visitor. Every beacon is redacted again on our side before anything is stored.

Privacy policy

Accessible is operated by L5 Ventures LLC, which is responsible for the personal data described here.

1. Information we collect

We collect information you provide directly to us, and information produced by running the service on your behalf:

Account information. Name, email address, organization name, and a hashed password when you create an account.
Billing information. Handled by Stripe. We store the subscription and customer identifiers Stripe returns, never a card number.
Testing data. The domains and URLs you register, the journeys you define (including any test data you give them), and the results of scans and journey runs — including the page structure and announced output captured during a run.
Communications. Messages you send through support or contact forms.
Real-user monitoring. If you install the monitoring snippet, we receive beacons from a sampled share of sessions: the route patterns visited, whether the session was keyboard-driven, and a fingerprint plus a redacted element description for each barrier encountered. Paths are stripped of query strings and fragments before they are stored. We set no cookie, we do not store IP addresses, and a session identifier is generated per browsing session and is not linked to a person or reused across sessions.
Page checks and assistant connections. When you check a page with our free checker, or ask an assistant you have connected to your account — such as ChatGPT or Claude — to check one, we store the page address and the result: the automated findings and, for assistant checks, a screen-reader transcript, keyboard path and form-field labels of that page. Each result is reachable only by an unguessable link and has no name, account or IP address attached. From a connected assistant we receive only what its tool calls send — the address of the page to check and, if you allowed it access to your sites, site names, issue ids, a framework and page filters — never your conversation. With that access, one tool turns monitoring on for a site you name. We keep the name the assistant registered itself under and the access tokens it holds for your account. To enforce a daily limit we count its checks against your account ID; that count is deleted after two days.
Your organization's industry. Chosen from a fixed list at sign-up and editable in settings. It is used to group de-identified, aggregated barrier statistics for published benchmarks, which are only produced for an industry represented by several organizations.
A per-day rate counter. To bound abuse of the public monitoring endpoint we keep a salted, one-way hash of the requesting address combined with the current date, and a count. The address itself is never stored, the hash changes every day, and the counter is deleted after two days.

2. How we use it

To run the scans and journeys you ask for, and to store their results
To run the page checks you, or an assistant you connected, ask for
To answer an assistant you connected and allowed to see your sites: it receives your sites' monitoring status and open issues, including page addresses and markup, and that information is then handled under that assistant's own terms
To process payments and meter credits
To send technical notices, service updates and security alerts
To answer support requests
To detect and address faults, abuse and fraud

We do not sell your data, and we do not use the content of your sites or your test results to train models for anyone else’s benefit.

3. Cookies

We use essential cookies to hold your session and your interface preferences — including your theme, contrast, motion and text-size settings. You can clear or block them in your browser, at the cost of being signed out and losing those preferences.

We measure how our public pages are used without cookies or any stored identifier: visits are counted from a daily, one-way hash that we cannot reverse and that changes every day. When you are signed in, we record which parts of the product you use on our own servers, against your account's email and name, to decide what to build next. None of it includes your sites' content, the content of your test results or anything our real-user monitoring collects.

4. Processors we rely on

Running this service means handing some data to other companies. The ones that touch your data are:

Stripe — payments and subscriptions
MongoDB Atlas — the database holding your account, domains and results
Google Cloud — hosting for the application and scanning services (Cloud Run), and the queues and schedules that carry monitoring data and background work (Cloud Tasks, Cloud Scheduler)
Resend — transactional email
Upstash — temporary working state for journey runs while they execute
OpenRouter — routes the AI models that run journeys and suggest them to the model providers it uses; the pages a journey visits, and the journey's test data, pass through it
PostHog — product analytics (United States)
Sentry — error reports from our servers and your browser, sent without cookies, request contents, email addresses or IP addresses

5. Retention

We keep your data for as long as your account is active, and you can ask us to delete scan and journey results sooner. Page checks from the free checker and from connected assistants are deleted after 15 days. An assistant's access token expires after an hour, and its connection lapses after 30 days without use; to end it sooner, disconnect it in the assistant and ask us to revoke it at privacy@accessible.so. You can delete your account yourself in Settings: it removes your account and, for an organization you own alone, every domain and all of its history at once, and cancels its plans. Our payment processor keeps the invoices and payment records the law requires, and error reports that carry only an opaque account number expire on their own within 90 days.

6. Your rights

Depending on where you live, you may be entitled to request access to your personal data, correction of it, deletion of it, a machine-readable export of it, or to object to particular processing. Ask at privacy@accessible.so and we will act on it.

Reports and issue lists can be exported from the product at any time, and you can delete your account in Settings. A full export of everything we hold is by request. We are not claiming a completed GDPR or CCPA audit; see “What we are not, yet” below.

Security practices

Everything below is a property of how the product is built, and can be checked against its behaviour.

Encryption

All traffic is served over TLS, and http and www requests are redirected to the canonical secure host.
Third-party tokens we store on your behalf, such as deploy webhooks, are encrypted with AES-256-GCM before they are written to the database.
We store no GitHub token. The GitHub integration is a GitHub App that can create issues in the repository you choose and cannot read or change your code; each request uses a short-lived token GitHub issues for that one repository. Disconnecting removes the app from your GitHub account unless another of your domains still uses it.
Passwords are stored as hashes by our authentication layer, never in plain text.
Our database provider encrypts stored data at rest.

What we deliberately do not hold

Card numbers. Stripe holds them; we hold identifiers that point at Stripe records.
A credential vault for the sites you test. There isn't one. Sign-in details you put in a journey's test data are stored with that journey as ordinary text, so use a dedicated test account.
Our Stripe price identifiers are kept server-side and are never shipped to the browser, so a build artefact cannot leak which billing environment it belongs to.

Access and integrity

Access to a domain’s data is scoped to its organization, with owner, admin and member roles.
Sessions are database-backed and can be revoked server-side.
Stripe webhooks are signature-verified before they are acted on.
Scan results posted back by the scanning service are authenticated with a shared secret, and the endpoint fails closed: with no secret configured it rejects every callback rather than accepting anyone’s. Fabricated results would end up in a customer’s conformance evidence, so refusing is the safe direction.

If something goes wrong

Report a vulnerability to privacy@accessible.so. We will confirm receipt, and we will notify affected customers within 72 hours of confirming a breach of their data.

What we are not, yet

We do not hold a SOC 2 Type II report, and we are not claiming a completed GDPR or CCPA audit. We are not going to imply otherwise on a page whose whole purpose is to be trusted — this is the same rule we hold our own scan results to. If your procurement process needs one of those, tell us where you are in it and we will tell you honestly where we are in ours.

Questions about any of this

Privacy, security and legal questions all go to privacy@accessible.so. Anything else reaches us through the contact form.

Email: privacy@accessible.so