Privacy Policy

1. Information We Collect

A. Account Data

When you sign in to Accesserty Console or CRM through Google OAuth, we receive your email address, display name, avatar, and the user identifier issued by Google. We use this information to authenticate you, create your user profile, generate your Pulse view_key, and determine which domain data you may access.

We do not receive your Google password, nor do we access Gmail, Google Drive, or other Google service content.

B. Subscription and Billing Data

When you subscribe to Pulse Pro, Lemon Squeezy handles checkout, payment methods, taxes, and invoices. Accesserty may store Lemon Squeezy customer and subscription identifiers, plan status, subscription start and end times, and information needed to open the customer portal. We do not directly store full payment-card numbers or security codes.

C. Contact Form and CRM Data

When you submit our website contact form, we collect your name (optional), email, referral sources, message body, UTM source information, and User-Agent. We use this information to respond to inquiries, keep service records, and improve our website communication flow. To prevent abuse, the submission service also keeps a short-lived HMAC-derived request identifier; it does not store the raw IP address.

D. Accesserty Pulse Behavior Events

When a website administrator installs pulse.js on their website, Pulse records interaction events that may indicate usability or accessibility difficulties, such as repeated clicks, possible keyboard dead interactions, focus reversals, Escape close difficulties, possible keyboard traps, focus being pulled back, and repeated form attempts.

Pulse event data may include the view_key, domain, page URL, event type, CSS selector of the affected element, a short event note, and a random page-view ID. That ID is created for each page view, kept only in that page's memory, and not linked across pages or visits. Since October 6, 2026 (pulse.js v5.6), Pulse does not send the User-Agent; events recorded earlier may include a random session ID and the User-Agent until they are removed under the retention rules below.

Before sending, and again before storage, Pulse replaces page-path segments and selector values whose format suggests personal data or a secret, such as an email address, a UUID, a number of six or more digits, or a long token, with placeholders such as :email or :id. Scan summaries are treated the same way. This is a pattern-based safeguard, not a guarantee that no personal data can appear in a page address or selector.

Pulse does not collect form field contents, actual keystrokes, full DOM, page text, screenshots, mouse-movement trails, or cross-site browsing history.

When you register a Pulse domain, we store the normalized domain and account identifier. Access to that website's Pulse data and Signal reports begins only after our verification service finds your account's static Pulse script in the server-returned homepage HTML. We then store the registration status, verification checks, domain access identifier, and timestamps for establishing or ending access. This confirms control of the website installation for Accesserty access control; it is not proof of legal ownership. Removing the domain ends that access. If the domain is registered and verified again after its access has ended, it receives a new access identifier and does not restore the Pulse history or Signal reports associated with the previous access.

E. Accesserty Pulse Page Scan Summaries and Weekly Reports

Pulse may also run low-frequency axe-core summary scans in the browser after an end user opens a page. These scans provide a machine-detectable overview of WCAG A/AA and best-practice risks. To avoid repeated scans, the same view_key, URL, and scan version are usually not scanned again within a short period.

Scan summaries may include the view_key, domain, scan time, URL, scan version, rule IDs, impact levels, issue counts, axe-core help text, help URLs, and a small number of sample selectors. Since October 6, 2026, scan summaries carry no visitor ID or User-Agent; earlier summaries may include a random session ID and the User-Agent until they are removed under the retention rules below. They are not a full manual accessibility audit and do not mean that a website conforms to WCAG 2.2 AA or any legal requirement.

Pro users may opt in to a weekly email report. The report aggregates Pulse events, scan summaries, and Signal reports for their currently registered domains with active verified access and is delivered to the account email through Resend as semantic HTML with a complete plain-text fallback. The same report can also be viewed in Console. Administrators may preview or manually send the same type of report when needed for service support.

F. Accesserty Signal Reports and Search-Result Labels

Accesserty Signal is a browser extension that mainly runs on Google and Bing search-result pages. It may display public accessibility certification, recognition, award, or badge records from supported sources, accessibility-statement links, and Accesserty ALLY active-maintenance information.

When you actively submit a report through Signal, we collect issue types, the reported page URL, domain, User-Agent, and email address if you choose to provide one. The report may also include a snapshot of publicly visible accessibility signals for that page, such as whether the site is an Accesserty ALLY, whether it has a supported public signal record, source and level, report date, validity date, and known accessibility-statement URL. Signal does not send your full browsing history to us in the background. An email address you choose to provide is visible only to Accesserty and used to contact you when needed; we do not share it with the maintainers of the reported website, who see only the report content.

A report can suggest how you use the web, for example with assistive technology, which may count as health information in some jurisdictions. Signal 1.6.7 and later therefore ask you to tick an explicit consent statement before a report is sent, and we record which statement you accepted. Please do not include health details. You can withdraw consent and ask us to delete a report at any time through the contact details below.

Signal reports are received by Accesserty. Maintainers may review reports associated with their current active verified domain access in Console. Ending verified domain access ends maintainer access to those reports. Reports for domains without active verified maintainer access may remain with Accesserty and may not be made available to or resolved by the website maintainer.

To limit repeated submissions, the reporting service derives an identifier from the request’s IP address using a server-side secret key (HMAC), and stores request counts and timestamps separately from report content. It does not store the raw IP address in these rate-limit records, share them with website maintainers, or use them for advertising tracking. An unsuccessful submission may still leave a rate-limit record; that does not mean its report content was saved. Infrastructure providers may separately retain network or security logs under their own policies.

G. Accesserty ALLY Applications and Maintenance

When a maintainer with active verified domain access applies for ALLY, we process the account, application status, domains with active verified access, review outcome, and relevant timestamps. To maintain the program, we may also store revocation time and reason, the date after which reapplication is allowed, Signal report-resolution status, owner-reminder timestamps, and administrator-created spot-check records such as the domain, finding, optional evidence URL, status, and action timestamps.

We use this information to review applications, make reports available to maintainers with current verified access for their domains, support reasonable report follow-up, send service reminders or administrator digests through Resend, record spot-check follow-up, and make administrator decisions about whether ALLY remains active. Verified domains present at application and review time are retained as audit snapshots. After approval, ALLY is an account-level maintainer status: domains that account verifies later may display it while access remains active. Domains with pending, suspended or ended access, or domains subsequently verified by another account, do not display or inherit a former maintainer's status. Changing the registered domain set does not automatically revoke ALLY, and other maintenance findings do not cause automatic revocation.

H. Accesserty DevCheck

Accesserty DevCheck's simulations, manual review aids, axe-core scans, and PDF structure checks primarily run locally in your browser or extension. DevCheck does not automatically upload scanned page content, PDF files, manual-review results, or scan results to Accesserty.

If you actively run DevCheck's AI Check, the extension extracts a bounded sample of the current page's visible text, link names, and selected images that the page itself permits the extension to read, then sends that content to Google Gemini for analysis. Cross-origin images that the page does not permit the extension to read are skipped. If you provide your own Gemini API key, the request is sent directly to Google. If you use Accesserty's free quota, the request is sent to Accesserty's Supabase Edge Function first, then forwarded to Google Gemini. A random extension-instance identifier and an IP hash are recorded to enforce usage limits.

The sample can include link context, alt text, ARIA naming fields, explicitly referenced accessible-name text, and SVG titles, even when those names are visually hidden. Editable content and some CSS-hidden text are excluded. Clipped or off-screen text may still be sampled; the extractor is not a sensitive-data detector.

The AI Check omits dedicated page/destination/image-source URL fields and does not send the full DOM, browsing history, form input or PDF files to the AI service. URLs appearing in sampled text, names or images may still be transmitted. Google may use inputs and generated responses under its unpaid-service terms to improve products and models, and human reviewers may process them. With your own key, Google's data-use terms depend on that project's billing status and applicable regional terms; supplying a key does not itself guarantee exclusion from model improvement. See the Gemini API Additional Terms of Service. Do not submit confidential, unauthorized, or personal information to unpaid AI services.

Your optional Gemini API key is stored locally in your browser and sent to Google for authentication, not to Accesserty. If you choose to copy or download a report, it can include the current page URL, sampled text, and AI suggestions. This export is created locally; review it before sharing.

I. Accesserty UI Kit

Accesserty UI Kit is an open-source Web Components library. Merely using or downloading UI Kit does not cause us to automatically collect your personal data. If you obtain the package through GitHub, npm, or another third-party platform, that platform may process data under its own policy.

J. Cookies and Local Storage

• Supabase Auth: Used to maintain your Console sign-in session.
• i18n_redirected: Used to remember language preference.
• UTM cookies: After you accept analytics and diagnostics, used to remember first-touch website source information for up to 30 days and last-touch source information for up to 14 days.
• Accesserty Pulse: Since October 6, 2026 (pulse.js v5.6), Pulse stores nothing in cookies or browser storage on the end user's device. Earlier versions kept pulse_sid and a scan cache in the tab's sessionStorage. On accesserty.com, Pulse runs only after you accept analytics and diagnostics.
• Extension storage: Signal and DevCheck may use browser extension storage for settings, cache, or temporary state.
• Daily city preference: The name, display name and coordinates of a city you select manually are saved as accessertyDailyCity in this device's localStorage for your next visit. Use “Forget saved city” on Daily or clear this site's browser data to remove it. Using your device location does not replace that preference.

Only after you accept analytics and diagnostics does our website run Accesserty Pulse and may it load analytics or diagnostic tools through Google Tag Manager, such as Microsoft Clarity when enabled. These tools may process usage data under their own policies. When we add a purpose to this choice, we ask again; an earlier refusal stays in place. To withdraw, choose “Manage analytics and diagnostics” in the footer: the page reloads without these tools. Withdrawing stops further collection; it does not delete data already sent.

K. Website Security Policy Reports

When a browser detects that a resource on accesserty.com conflicts with our Content Security Policy (CSP), it may send a minimized security report so we can safely review the policy. We retain only the Accesserty page path, the policy directive involved, a category or origin for the blocked resource, an HTTP status when supplied, and aggregate occurrence timestamps. We do not retain the raw report, IP address, complete page URL or query string, referrer, source-file path, or script sample.

L. Daily Weather Lookups

City search terms and weather lookup coordinates pass through Accesserty's weather service on Cloudflare to WeatherAPI. Coordinates are rounded to two decimal places in your browser before sending, but still indicate an approximate location. Browser geolocation is requested only after you choose “Use my location”. This site does not write device-location coordinates to cookies or local storage, or reuse them on your next visit. On page load, it attempts to clear previously saved device-location records; if your browser prevents clearing them, they are still not used for lookups.

The weather service does not write search or location data to Accesserty's database, or log request contents or IP addresses in application code. Normalized weather responses are cached on Cloudflare by approximate coordinates for up to 10 minutes; city searches are not cached. Cloudflare and WeatherAPI may still process network and request logs under their own policies; this does not mean providers keep no records. Clearing this site's saved city does not delete data already received by those providers. See WeatherAPI's privacy notice and Cloudflare's privacy notice.

2. How We Use Information

• Provide sign-in, Console, Pulse, Signal reports, CRM, and related services.
• Manage Pulse Pro plans, subscription status, feature access, and optional weekly reports.
• Help website administrators view Pulse events and scan summaries for their registered domains.
• Process user reports, contact requests, and service support.
• Review ALLY applications, follow up on reports and spot checks, send maintenance reminders, and record administrator decisions.
• Improve product detection logic, interfaces, and documentation.
• Prevent abuse, forged origins, unauthorized domain use, and security risks.
• Where necessary, use de-identified or aggregated data to understand accessibility and usability trends.

3. Pulse Website Maintainer Responsibilities

Pulse is provided to website owners and maintainers as a maintenance tool. If you install Pulse on a website, you are responsible for deciding whether your own privacy notice, consent flow, accessibility statement, or internal data-processing documentation needs to mention Pulse or similar monitoring tools.

Pulse is designed to collect limited maintenance signals for an account that is authorized to maintain the site and holds the current active verified domain access. It does not provide session replay, heatmaps, screen recordings, full page text collection, form-value capture, or advertising tracking. Pulse data is shown to authorized maintainers for their registered domains. Accesserty uses it only to provide, secure, and troubleshoot the service, as set out in the Data Processing Agreement that applies to websites using Pulse.

Maintainers may remove a registered domain to end its active domain access and may ask Accesserty to remove related Pulse records where deletion is technically and operationally reasonable. End users of a website where Pulse is installed should normally contact that website administrator about the site’s disclosure, consent, and data-processing practices; they may also contact Accesserty if they need help identifying the relevant maintainer, disputing unauthorized domain access, or reporting a concern.

4. Third-Party Services

We use third-party services to provide infrastructure and functionality, including Supabase (database, Auth, Edge Functions), Google OAuth, Google Gemini (DevCheck AI Check and image alternative-text suggestions), Lemon Squeezy (subscriptions, payments, and taxes), Resend (weekly reports and service email), Cloudflare Pages / CDN / Functions, WeatherAPI (Daily city searches and weather lookups), Google Tag Manager, and analytics or diagnostic tools that may be enabled through GTM.

We do not sell your personal data. We may disclose necessary information where required by law, to protect rights, investigate security matters, or in connection with a business transfer.

5. Data Retention

• Account Data: Retained while you use the Service. You may request deletion of your account and related personal data.
• Subscription and Billing Records: Retained during the subscription and for periods required for plan access, accounting, tax, refund, and dispute handling. Payment-card data is handled by Lemon Squeezy under its policies.
• Weekly Reports: Report content is generated from existing Pulse and Signal records. Delivery records may be retained for service support and troubleshooting.
• Contact Form: Retained for response and service records, then deleted automatically 24 months after submission. You may also request deletion before that. Short-lived HMAC-derived abuse-control identifiers are scheduled for deletion 24 hours after their last use, no later than the following daily scheduled deletion run while that job is operating.
• Signal Reports: Retained to support report review, current verified domain access where available (excluding any email address you provided), service records, and abuse prevention. Ending domain access removes maintainer access but does not necessarily delete the report from Accesserty. The report itself is kept, but an email address you chose to provide is cleared automatically after 12 months — the report is a record in an accessibility dispute, while the contact detail is only needed for follow-up.
• Signal Submission Rate-Limit Records: Identifiers, request counts and timestamps used to limit repeated submissions become eligible for deletion after more than 24 hours without use. They are removed on the next daily cleanup run while that job is operating. This is not a fixed period from the first submission, nor the retention period for report content.
• Domain Access Audit: Domain access identifiers, normalized domains, account identifiers, and timestamps for establishing or ending access may be retained for abuse prevention, dispute handling, and operational audit. Account identifiers are cleared from this audit when the account is deleted where implemented by the database lifecycle.
• ALLY Applications and Maintenance Records: Application decisions, reminder and resolution state, spot-check findings, and revocation records may be retained for program operation, abuse prevention, and audit history. Active domain access remains separate from ALLY status.
• Pulse Events: Retained for Console display, the weekly report, and diagnostics. Events are deleted by the scheduled job only when they are both older than 30 days and outside the latest 1,000 associated with the same current domain access. Historical events no longer associated with domain access share one combined 1,000-event allowance, rather than a separate allowance per original domain. This retention threshold is separate from Free/Pro viewing limits; an event that does not meet both conditions is not deleted merely because it is older than 30 days.
• Pulse Scan Summaries: Console and the weekly report read the latest summary per page. An older summary is deleted by the scheduled job when a newer summary exists for the same current access and page URL, and its scan date is more than 30 days old. The latest summary is not subject to this 30-day deletion condition. Summaries no longer associated with domain access are compared by URL.
• Operational Alerts: System failure alerts may include technical detail used for troubleshooting. Resolved alerts are deleted automatically after 6 months; unresolved alerts are kept until they are resolved.
• CSP Security Reports: Minimized, aggregated website-security reports are kept only to review and safely enforce our resource policy. They are deleted automatically 30 days after they were last seen.
• DevCheck AI Quota Records: The device instance identifier and IP hash used to enforce the daily quota are deleted automatically after 7 days. Before deletion, only weekly totals are kept: the number of checks and the number of distinct extension instances, with no identifier or IP hash.
• Local Data: DevCheck and browser-extension local data can be cleared through your browser or extension settings. A manually selected Daily city is retained until you clear it on the page, replace it with another city, or clear this site's browser data.
• About Backups: The automatic deletion described above runs against the live database and does not rewrite existing backups. Supabase backup availability and retention depend on the applicable plan and provider policy; we do not treat the Free plan as having accessible daily backups. Backups are used only for disaster recovery and recovery testing, never for routine queries, analysis, marketing, or support work. Access on Accesserty's side is limited to authorized operations staff; provider-managed backups are also subject to the provider's access rules. If a backup is restored to the live service, the deletion rules above are applied again on the next normally operating daily scheduled run.
• Short-Term Local Recovery Testing: If we create a manual backup to test restoration, database contents, necessary authentication data, and stored files are saved directly to an encrypted local location controlled by Accesserty operations staff. They are kept for no more than 7 days from the first data collected for that backup and may be deleted earlier when testing is complete. Restored test copies and temporary files have the same deadline. Operations staff remove these files; the live database's daily cleanup does not delete them. This is not a long-term backup service.

6. Your Rights

You may request access to, correction of, or deletion of personal data we hold about you, and you may ask us to stop unnecessary communications. If you are an end user of a website where Pulse is installed, you may also contact that website administrator about their disclosure, consent, and data-processing practices.

7. International Transfers

Because we use international cloud providers such as Supabase, Google, and Cloudflare, data may be transferred to and stored on servers outside your location or region.

8. Children's Privacy

The Service is not directed to children under 13. We do not knowingly collect children's personal information. If you believe children's data has been improperly provided to us, please contact us.

9. Policy Updates

We may update this policy when our products, legal obligations, or data-processing practices change. Updates will be posted on this page with a revised effective date.

10. Contact Us

Operator: Neil Lin, an individual based in Taiwan.

If you have questions about this Privacy Policy or wish to exercise your rights, please contact us: [email protected]