Skip to content
The End Effector
Sign inJoin

Legal

Accessibility Statement

Last reviewed: 2026-05-16 — reviewed at least annually. Conformance target: WCAG 2.2 Level AA.

Our commitment

The End Effector is committed to making our public surfaces usable by everyone, including people with disabilities. We design, build, and audit our sites against the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.

WCAG 2.2 AA satisfies the technical requirements of the US Americans with Disabilities Act (Titles II and III), the European Accessibility Act (Directive (EU) 2019/882), the UK Public Sector Bodies Accessibility Regulations 2018, the Accessible Canada Act, and the majority of national accessibility regulations. Compliance is a legal question that varies by jurisdiction; the technical floor we apply does not.

Our full internal standard, including the pre-flight checklist every change is held to, the testing requirements, and the CI checks that enforce them, is published in ACCESSIBILITY.md in our source repository. The exemption log is in ACCESSIBILITY-EXEMPTIONS.md.

Scope

This statement covers the following public-facing surfaces operated by The End Effector:

  • endeff.com — the main site (research, stories, Cores, Thrusts, Downrange, Telemetry, memberships)
  • id.endeff.com — Effector ID (credentials, identity, public verification)
  • sig.endeff.com — Sigline (email signature management)
  • store.endeff.com — Cross & Check (TEE merch, currently a Shopify-hosted storefront)
  • conduit.endeff.com — the SMS subscribe page for our community SMS platform

Microsites we publish at their own canonical hostnames — including n1ba.com and spaceforearthlings.com — share the same code and are held to the same baseline.

Conformance status

All public surfaces listed above target WCAG 2.2 Level AA. We do not claim full conformance: WCAG 2.2 includes criteria that automated testing cannot verify (alt-text accuracy, reading order under a screen reader, cognitive accessibility), and we are honest about the limits of any technical floor. We treat unresolved findings the same way we treat any other defect — logged, owned, and dated.

If you find a barrier we have missed, please use the feedback channel below. Reports from people who actually use assistive technology are the most reliable input we get.

Known limitations

The authoritative log of known issues lives in ACCESSIBILITY-EXEMPTIONS.md, which records the surface, the WCAG criterion involved, severity, owner, and remediation target for every accepted exemption.

At the time of last review there were no active exemptions on file. If you encounter an issue not listed in that file, treat it as an unknown limitation and report it using the feedback channel — that is how it gets added to the queue.

Third-party content

Parts of the experience are provided by third-party vendors. We select vendors with accessibility in mind but cannot guarantee their conformance to WCAG 2.2 AA at every moment. Third-party surfaces currently embedded in our sites include:

  • Clerk — authentication and member account UI (sign-in, sign-up, account settings)
  • Stripe — billing portal and checkout
  • Sanity Studio — the embedded CMS at /studio (admin-only; not part of the public surface)
  • Beehiiv — newsletter archive and subscription forms used by Telemetry
  • Cloudflare Turnstile — bot-protection challenge on sign-up
  • YouTube and Vimeo — embedded video players inside long-form articles
  • Shopify — checkout and storefront chrome at store.endeff.com

Where a third-party surface blocks a task that has no other path, we will provide an alternative — see Alternative access below.

Feedback

If you encounter an accessibility barrier on any of our sites, or if you have a suggestion for improvement, please contact us. We read every report.

We aim to acknowledge every report within 2 business days and to respond with a remediation plan or explanation within 10 business days. When a fix requires more time than that — for example, because it depends on a vendor — we will say so in the acknowledgement and keep you posted on progress.

Alternative access

If a specific piece of content on any of our sites is not accessible to you, request an alternative format using the email above. We will provide the alternative — HTML, plain text, large print, transcript, audio description, or a direct conversation with a human — at no cost and without requiring you to justify the request.

Technical specifications

Our sites rely on HTML, CSS, JavaScript, and WAI-ARIA. These technologies are relied upon for conformance with the standard. We test against the following assistive-technology and browser combinations as a minimum:

  • NVDA (latest stable) on the latest Firefox (Windows)
  • VoiceOver (macOS latest) on the latest Safari
  • VoiceOver on iOS Safari (current major version)
  • TalkBack on Android Chrome (current major version)

Non-AT testing covers:

  • Keyboard-only navigation (Tab, Shift+Tab, Enter, Space, Escape, arrow keys)
  • 200% browser zoom in desktop Chrome, Firefox, and Safari
  • 320 CSS px viewport width (reflow)
  • Forced colors / Windows High Contrast mode
  • prefers-reduced-motion enabled
  • prefers-contrast: more enabled

Assessment approach

Our ongoing assessment combines:

  1. Automated testing on every pull request. axe-core via Playwright, eslint-plugin-jsx-a11y at strict settings, a Lighthouse-style accessibility budget on the marketing surfaces, and a UI lint pass for common authoring slips (alt text, empty links, missing labels). A failing check blocks the merge. Run locally with pnpm audit:a11y.
  2. Manual review before every release. Keyboard-only walkthrough of the critical user journeys (read a public story, subscribe to Telemetry, sign up, upgrade, claim a credential, manage email preferences) and a screen-reader smoke test on the same journeys.
  3. User testing with disabled users. We are scaling this up in 2026. Reports from members and readers who use assistive technology are folded directly into the exemption log and triaged like any other production issue.

Automated testing catches an estimated 30%-50% of WCAG issues. Manual review and lived-experience testing catch the rest. We do not use accessibility overlays (accessiBe, UserWay, EqualWeb, AudioEye, or equivalents) — they have been the subject of FTC scrutiny, do not satisfy WCAG in the general case, and have themselves been named in ADA lawsuits.

Legal

This statement is provided in good faith. It does not limit any rights you have under applicable accessibility law, and it does not create rights beyond those already provided by law. Legal obligations vary by jurisdiction; The End Effector complies with the obligations that apply to it.

Statement version: v1 — published 2026-05-16. Next scheduled review: 2027-05-16.