Accessibility

Accessibility at SAIGE.

We build SAIGE to be usable by as many people as possible — including customers using screen readers, keyboard-only navigation, voice control, magnification, or any assistive technology. This page documents the standards we follow, the patterns built into this site, the limitations we’re still working on, and how to reach us if something is in your way.

Our commitment

WCAG 2.1 Level AA, as a starting point.

Web Content Accessibility Guidelines (WCAG) 2.1 Level AA is the standard most accessibility regulations reference, including the U.S. ADA Title III interpretations, Section 508, and the European EN 301 549 directive. We design and build to that standard, test against it as part of our release process, and treat it as the floor — not the ceiling.

This statement covers meetsaige.com, the help center at docs.meetsaige.com, and the agency-program pages. The SAIGE customer dashboard at go.meetsaige.com follows the same standards, and we publish parallel updates to its accessibility posture as the product evolves.

What’s built in

Features and patterns on this site.

Every item below is implemented today and verifiable. If you find a gap between this list and what you experience, we want to know — see the contact section at the bottom.

Skip-to-content link

Every page has a 'Skip to content' link as the first focusable element. Keyboard users land on the main content without tabbing through the entire navigation each time.

Semantic HTML

Pages use the right landmark elements — header, nav, main, article, aside, footer — so assistive technology can announce regions correctly. Headings follow a logical h1 → h2 → h3 hierarchy with no skipped levels.

Keyboard-first interaction

Every interactive element on this site is reachable and operable with a keyboard alone. The before/after heatmap slider, the FAQ accordion, the help-center search, the niche cards, the agency-program form — all support Tab, Enter / Space, arrow keys, Home / End, and Escape where appropriate.

Visible focus rings

We use a high-contrast soft-blue outline on every focused element so keyboard users always know where they are. Focus styles never disappear behind hover states.

ARIA roles and labels on custom components

The heatmap comparison slider declares role=slider with aria-valuemin / aria-valuemax / aria-valuenow. The FAQ accordion uses aria-expanded and aria-controls. The help-center search announces its listbox via aria-autocomplete and aria-controls. Every icon-only button has an aria-label.

Color contrast

Body text on white meets the WCAG AA 4.5:1 ratio. Large text meets 3:1. Our primary call-to-action — white text on the SAIGE purple gradient — has been measured at roughly 4.7:1, comfortably above the threshold. The light gray we use for borders and dividers is never used as text.

Respects prefers-reduced-motion

Users who set a 'reduce motion' preference at the operating-system level get a calmer experience automatically. The heatmap-slider intro animation, the help-center transitions, and our hover lifts all collapse to zero-duration transforms when prefers-reduced-motion: reduce is set.

Form labels and error states

Every form field — agency-program application, free-audit forms, newsletter signup — has a visible label associated with the input. Validation errors appear inline with role=alert so screen readers announce them.

Image alt text

Every meaningful image has descriptive alt text. Decorative images (background gradients, glow effects) are marked aria-hidden so they don't distract screen-reader users. Product screenshots in the help center include captions that describe what the screenshot shows.

Resizable text and zoom

All page content reflows cleanly up to 200% zoom without horizontal scrolling on desktop. Headings use clamp() so they scale proportionally to viewport width without breaking layouts.

What we’re still working on

Known limitations.

Honesty matters more than a perfect rating. Three areas where we’re actively improving:

We have not yet completed a formal WCAG 2.1 AA audit by an independent third party. We self-test against the standard and run automated tooling (axe DevTools), but a full external audit is on our roadmap.
Our embedded chat widget is a third-party component (GoHighLevel). We've configured it for accessible defaults, but its internal accessibility is governed by that vendor's release cycle, not ours.
PDF exports of the help-center articles and the methodology infographic are accessible to screen readers in modern browsers, but we have not tagged them as full PDF/UA documents. If you need a tagged PDF for a specific article, contact us and we'll generate one.

Report a barrier

Tell us what we missed.

If something on this site (or in the SAIGE product) blocks you from doing what you came to do, please let us know. We treat accessibility reports as priority bugs — not feature requests.

Email: accessibility@meetsaige.com
Include the page URL, the device and browser you’re using, the assistive technology if any, and what happened versus what you expected. We respond within one business day.
Critical accessibility issues (you can’t complete a paid action — checkout, audit signup, account login) get a same-day workaround if a full fix takes longer.

Last updated: May 2026. This statement is reviewed quarterly.