Accessibility Statement

1. Conformance target and approach

Our public-facing website targets WCAG 2.2 Level AA. We treat AA as the floor, not the ceiling, and follow the four WCAG principles: Perceivable, Operable, Understandable, and Robust (POUR). Where we find an issue, we prioritize it using the same severity framework we use in our Discovery engine's audit product:

• Critical (P1): blocks a core user journey for a broad audience group — fixed same sprint whenever possible.
• Serious (P2): blocks a non-core journey or severely degrades a core journey — fixed within 30 days of confirmation.
• Moderate (P3): degrades experience without fully blocking a user with standard assistive tooling — queued into the next regular release cycle.
• Minor (P4): cosmetic or narrow-impact issues — addressed as part of normal UI refresh work.

2. What we have done across the site

To align the six engines' marketing surfaces, the Core chatbot, and every informational page with WCAG AA, we have implemented or explicitly verified:

Perceivable

• Text alternatives. All meaningful images, the brand mark, engine 3D marks, blog article thumbnails, and CTA icons carry descriptive alt or aria-label text. Decorative elements and the chat-panel decorative backdrop use aria-hidden or empty alt so screen readers skip them.
• Color and contrast. Body copy, form labels, eyebrow kickers, CTA copy, and the footer legal links are checked against minimum 4.5:1 contrast; large UI text (headlines, 18px+ kickers) meets 3:1; icon-only buttons in the chat panel, chat toggle, and nav achieve 3:1 plus an accessible name.
• Resizable text. Sizes use responsive clamp() and viewport units so users can scale text up to 200% in the browser without loss of content or horizontal scrolling. On the engine chat and Core chat panels, inputs and messages remain readable at zoom.
• Visual content separation. The three 3D scenes on the home page (orbit, showcase, insights) have explicit text anchors and headings, so information conveyed visually is also available in a text equivalent: each engine has a role eyebrow and blurb, and the Services page uses the per-engine connector SVG with visible labels and keyboard-activatable cards.

Operable

• Keyboard. All interactive elements — site nav, engine cards, blog cards, FAQ accordions, the Core chatbot, per-engine chatbots, previous/next article arrows, showcase arrows and the bottom pill progress, and form inputs — are reachable and operable via keyboard with a visible focus ring. Focus order follows the visual reading order.
• Timing. There are no strict session timeouts on the public site. Chatbot sessions persist locally. The home page's scroll-driven scenes can be navigated at any pace using the nav anchors (About, Engines, Article, Contact), which jump directly rather than forcing an auto-play sequence.
• Motion. We honor prefers-reduced-motion: where the user has indicated reduced motion in their OS, decorative parallax depths, marquees, and 3D sway are disabled while the interactive content and models remain usable. Form accordion and chat panel openings are still animated but at a gentler, shorter timing.
• Target size. The brand navigation, previous/next article arrows, chat toggle, chat send and close icons, and mobile hamburger all meet the 24×24px target-size advisory for Level AA; footer links, article cards, and form inputs similarly sit above minimums.

Understandable

• Consistent navigation and language. Top nav, footer, page-hero breadcrumbs, and engine-card structure repeat consistently across About, Services, Blog, Blog Post, Contact, all six engine pages, and the three legal pages. Default language is en on every page.
• Form labeling and help. The Contact form uses visible labels plus placeholder text, marks required fields, and exposes invalid state via aria-invalid plus an inline form-status message. The consent checkboxes on step 3 link to Privacy and Terms for context.
• Error identification. Contact form validation surfaces a clear, human-readable error (e.g. "Please enter a valid email address.") in the status region and marks the specific failed field with aria-invalid so screen reader users understand what needs correction.

Robust

• Semantic HTML. Pages use landmarks (nav, section, header, footer, aside for the chat panel), headings in document order, and the same form structure on Contact and engine pages. Accordions use fieldsets and legends; progress steps use ordered lists.
• ARIA. Where native semantics are insufficient — the mobile hamburger (aria-expanded, aria-label), chat-panel toggle (aria-label, title), engine-card toggles (aria-expanded on the chevron), and the article filter buttons (active state) — we apply the minimum ARIA needed rather than overriding native roles.
• Tested with current assistive tech. The site is tested in the latest two stable versions of Chrome, Safari, and Firefox on Windows and macOS with NVDA, VoiceOver on macOS/iOS, and TalkBack on Android. Keyboard-only and screen-reader regression checks run before every major release of a new page or scene.

3. Per-engine surface notes

Because each engine has a different user-facing surface, here is how accessibility is handled for the most interactive parts of each:

• Discovery & Revenue Intelligence visualizations. Any chart, attribution diagram, or forecast chart delivered to a client (or surfaced in this website's demo versions) always includes a structured text summary of the finding, an accessible description, and a data table export so the insight is not locked inside a visual.
• Authority published content. Content produced by the Authority engine goes through a review step that includes heading structure, link purpose, alt text completeness, readable language level, plain-language summaries where needed, and captions/transcripts for any embedded media.
• Outreach send surfaces. Sequence copy written via Outreach is checked before send for accessible reply options, clear unsubscribe links, body-text contrast against common email client themes, and plain-text fallbacks for any HTML message.
• Demand creative. Ad creative produced by Demand is reviewed for 4.5:1 body-text contrast, readable font size, text-over-image guardrails, and — for any video creative — captions, a transcript, and where applicable audio description tracks or descriptive voiceover.
• Quotify buyer-facing flows. Quotify forms (quote flows, booking widgets, QR-code landing pages) are scoped against the same WCAG AA criteria as this website: field labeling, visible focus, clear error messages, captions for any video explainer, accessible calendar picker, and keyboard-operable next/back steps.

4. The Core and per-engine chatbot

Every page of this site that offers a chatbot (the Core Optimyzed chatbot on About, Services, Blog, Blog Post, Contact, and the legal pages; plus each engine's per-engine chat panel on engine-detail pages) is designed with the following accessibility features in mind:

• The chat toggle is a real <button> with a descriptive aria-label and a visible focus ring.
• When the panel opens, focus moves predictably and ESC closes it.
• The chat log is a live region so new bot and user messages are announced without manual re-reading.
• The send button is both Enter-submittable from the input and operable via pointer/touch/keyboard.
• Message text uses the same 4.5:1 contrast floor as page body text.
• Per the AI governance model, the Core router greets users with its role and capabilities and offers a human-hand-off path ("Book a Call") if the question cannot be answered.

5. Known limitations and work in progress

At the effective date above, we are aware of the following non-blocking limitations which are either scoped for the next release cycle or documented for users:

• 3D decorative mark canvas fallback description. The Three.js canvases (hero O mark, orbit engines, showcase marks, services-page constellation) are primarily decorative, brand, and illustration surfaces. They currently carry aria-hidden plus a visible, semantic, heading-and-text equivalent on every page. We are evaluating a long-description or supplementary transcript for the few cases where a canvas carries non-decorative data (e.g., an attribution diagram) rather than relying on the adjacent text summary.
• Drag-to-orbit on the Services constellation. The engine-connector starfield on Services supports pointer drag as a progressive enhancement only; keyboard and card-button activation remain the primary accessible paths for opening and reading each engine card, which carry the same body of information.
• Very small displays under 320px CSS width. A small number of ultra-tiny devices may require horizontal scroll on the four-step form progress pills inside the Contact 4-step form. We are evaluating wrapping the progress pills to a vertical stack under 340px without breaking the step-order semantics.

If you encounter a blocker not listed here, please report it and we will triage it using the severity table in §1.

6. Reporting an accessibility issue or requesting an accommodation

We want every user to be able to use the site. If you encounter a barrier, need a document in an alternative format, or want to request an accommodation related to any engine we offer, please use one of these channels and we will respond within five (5) business days:

• The form on the Contact page. Select subject "Accessibility request" so the Core router sends it directly to the correct specialist.
• Email the accessibility lead at the address published on the Contact page.
• Call the phone number on the Contact page. If lines are busy, leave a message with a preferred call-back time and format (voice, video relay, TTY-compatible relay, etc.).

When reporting a barrier, including the specific URL or engine surface, the browser and OS you are using, and the assistive technology (screen reader, magnification level, voice control, etc.) helps us reproduce and fix it faster. If you prefer a format other than email — e.g. plain text, large-print PDF, audio recording, structured document — tell us that and we will adapt the response accordingly.

7. Third-party content and tools

The site may embed or link to third-party tools (video embeds, calendar bookers, document viewers, chat or phone providers, maps, analytics). We review our main third-party partners for documented accessibility support and a public VPAT or equivalent where one is available. Where a third party controls a surface we cannot fully fix ourselves, we will help you use an alternative path, document the workaround, and — where commercially reasonable — escalate to the vendor.

8. Browser and assistive-technology compatibility baseline

The site is built and tested against the current and immediately previous major releases of Chrome (macOS and Windows), Safari (macOS and iOS), Firefox (macOS and Windows), and Edge (Windows). Assistive-tech baseline is the current release of NVDA + Firefox/Chrome on Windows; VoiceOver + Safari on macOS, iPadOS, and iOS; TalkBack + Chrome on Android; and Switch Control on iOS/macOS. If you use a different supported combination and encounter an issue, report it per §6 and we will add it to our test matrix.

9. Continuous improvement and feedback loop

Accessibility is not a one-time pass. The same continuous learning loop that the Agentic Marketing Department uses — Discovery learns → Authority publishes → Demand captures → Quotify books → Revenue Intelligence measures → Core routes the next change — is how we improve accessibility. We run:

• Automated scans on every production deploy, gated against no new P1/P2 regressions.
• Quarterly manual audits (keyboard, screen reader, color, mobile zoom) from an internal accessibility specialist plus an external third party at least once every 12 months.
• Annual reviews of this statement against the latest WCAG errata and our supported toolchain.

10. Formal feedback and enforcement

Where applicable regulation (e.g., EU Accessibility Act, UK Equality Act, ADA Title III in the US, AODA in Ontario) entitles you to a formal response, accessible complaint process, or specific remediation timeline, we will honor those requirements in full. Ask for the accessibility lead in any such filing and we will route it correctly through the Core.