Accessibility Statement

SnagLabs AI LLC builds and sells software. Accessibility is part of doing that job properly, so we treat a barrier on this site the same way we treat a bug: reported, reproduced, prioritized, fixed.

This statement is written to be useful rather than reassuring. Every measure listed below is something in the code of this site, and every limitation listed below is something we know about and have not finished. We would rather tell you exactly where the edges are than claim a level of polish we cannot back up.

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. WCAG is organized in three levels: A is the floor, AA is the level most public bodies and courts in the United States treat as the practical benchmark, and AAA goes further than most general-audience sites can meet on every page. AA means, in a sentence: the content works without sight, without hearing, without a mouse, and without perfect colour vision, and it stays usable when text is enlarged or motion is switched off.

Read “aim to conform” literally. We build to WCAG 2.2 AA and test against it, and we are not claiming full conformance. No site of any size can honestly claim that without a complete audit against every success criterion on every page, and we have not had one done.

These are measures you can verify by using the site, not aspirations for a later release.

Keyboard and focus

• Every interactive part of the site — the header navigation, the mobile menu, the FAQ accordion, the multi-step contact form, the scheduler, and the savings calculator — is operable with a keyboard alone.
• A skip link is the first thing in the tab order on every page. It jumps past the navigation and moves focus into the main content, not just the scroll position.
• Focus is always visible. We use a single high-contrast focus ring throughout and never suppress it, including on custom controls such as the calculator sliders, where the ring is drawn on the slider handle so it reads as part of the control.
• The mobile menu is removed from the tab order and the accessibility tree while closed, rather than only hidden visually, so there are no invisible tab stops.

Structure and semantics

• One top-level heading per page, headings in a meaningful order, and real header, main, and footer landmarks with a labelled primary navigation.
• Long documents like this one carry a contents list with in-page links, so you can reach a specific section without reading through everything above it.
• Decorative images and graphics are hidden from assistive technology; images that carry meaning have text alternatives. Where a chart shows a figure, the figure is also stated in visible text, so nothing is communicated by colour or shape alone.

Colour and contrast

• Contrast is a documented property of our design system, not a per-page judgement call. Each colour token in our stylesheet is annotated with its measured ratio against the surfaces it appears on, with the AA target called out — our accent text colour, for example, is recorded at 6.50:1 on the light page background, and the dark-surface accent was chosen specifically because the next shade up measured 4.30:1 against one of our panel colours and would have failed there.
• Accent colours resolve automatically from the surface they sit on rather than being hand-picked at each use, so the same label cannot be contrast-correct in one band and wrong in the next. Our linter rejects hard-coded accent shades in components.
• The focus ring clears the 3:1 requirement for non-text contrast on both our light and dark surfaces.

Motion

This site is animation-heavy by design: scroll-driven reveals, a smooth-scrolling engine, and a signature animation on the homepage. All of it yields to your system setting. When your operating system or browser reports reduce motion:

• Smooth scrolling is switched off entirely — the smooth-scroll engine never starts, and the browser’s native scrolling takes over.
• Scroll-triggered reveals do not run. The content is rendered visible immediately rather than waiting for an animation, so nothing is ever hidden behind motion that will not play.
• The opening preloader is skipped and you go straight to the page content.
• The signature homepage animation jumps to its resolved state, the accordion opens and closes without animating, and control transitions are removed.

The same applies with JavaScript switched off or failed: the content is never hidden waiting for an animation to reveal it, and there is a timeout that forces everything visible if our motion code does not report ready.

Targets, forms, and privacy of input

• Buttons, form fields, calendar cells, and navigation links are built to a 44px minimum height, so they can be hit reliably by touch or with limited fine motor control.
• Every form field has a real associated label — we do not use placeholder text as a label. Validation errors are announced to assistive technology, appear next to the field they belong to, and pair colour with an icon and words.
• Results that update without a page load, such as the savings calculator’s totals, are announced through a live region, so you do not have to hunt for what changed. The calculator needs no email address to use.
• The site sends a permissions policy that switches off camera, microphone, and geolocation access. Nothing here asks for a sensor, and the browser is told to refuse on our behalf.

Automated. Our end-to-end test suite runs the axe-core accessibility engine against the site’s main routes — the homepage, the audit page, what we do, how we work, contact, about, the work and guides indexes, and an article page — on both a desktop and a mobile viewport. It checks the WCAG A and AA rule sets and fails on any violation rated serious or critical.

One detail worth stating, because it shows what these checks are worth: the suite runs with reduced motion forced on. Our scroll reveals hide their targets until they animate, and an automated scanner skips anything with zero opacity — so for a while the suite passed while dozens of elements were failing contrast, invisible to the scanner. Forcing reduced motion lifts that gate, and it caught a real regression the day it was added.

Manual. We tab through the site with a keyboard only, checking the header, the mobile menu, the multi-step form, and the scheduler, and we verify that the skip link actually moves focus into the main content rather than only scrolling the page. We reload key pages with the operating system’s reduce-motion setting on. We review copy for plain language, because no scanner can measure whether a sentence is clear.

What we do not do. We have not commissioned a professional accessibility audit, and we have not run usability testing with disabled participants or a full manual screen-reader pass across every page. When we do either, this page will say so.

A candid list is the point of a page like this. These are the gaps we are aware of today.

• Automated testing has a ceiling. Axe-core catches contrast, ARIA, and structural problems. It does not catch cognitive load, confusing wording, an illogical reading order that is still technically valid, or a focus order that is correct but unhelpful. Those depend on our own review, which is fallible.
• Not every page is in the automated sweep. The scan covers our main routes. Newer and lower-traffic pages — including this one — are built on the same components and reviewed by hand, but they are not yet all in the automated list.
• No full manual screen-reader pass. We have not walked every page of the site end to end with NVDA and VoiceOver. Our confidence rests on the automated pass, the specific flows we have checked by hand, and the use of well-tested primitives for complex widgets. That is reasonable confidence, not proof.
• The spam-check widget on the contact form is not ours. The contact form uses Cloudflare Turnstile to keep bots out. It renders in a third-party frame, we cannot change its internals, and our automated scan excludes framed content because scanning it would only report on someone else’s code. The parts around it — the heading, the loading and error states, and the rest of the form — are ours and are accessible. If that widget is what stops you, use the email route in the next section and skip the form entirely.
• The design leans on motion. Reduced motion is honoured throughout, and we consider that support genuine. But the default experience uses scroll-driven reveals and a smooth-scrolling engine, and a design built that way can still feel disorienting to some people even when the setting is respected. If that is you, tell us — it is useful information and we would rather have it than not.
• Third-party frames and outbound documents. Anything embedded from or linked to another service is governed by that service’s accessibility, not ours. See the next section.

Some parts of this site come from other companies, and some links leave it. We choose our vendors carefully and we raise problems with them, but we cannot fix another company’s code, and we will not claim their accessibility as ours.

• The bot and spam-protection widget on our contact form is provided by Cloudflare and rendered from their servers.
• Links to other websites — a vendor’s privacy policy, a standard, a piece of research — lead to content published and maintained by someone else.

If a third-party component on our site is the barrier, we still want to hear about it. We will report it upstream, and in the meantime we will get you the information or the booking directly ourselves.

This is the part of the page that matters. If any part of this site is hard to use, or you cannot do something here that you should be able to do, email us and we will fix it or work around it. You do not need to know why it is broken, use the right terminology, or identify a WCAG criterion. “I cannot get past the form” is a complete and useful report.

To help us reproduce the problem fast, include whatever you have to hand:

• The page you were on, and what you were trying to do.
• What happened instead, in your own words.
• Your browser and device, and any assistive technology you use — screen reader, magnification, voice control, switch access, keyboard only.

If none of that is convenient, send us one line. We would rather have a vague report than none.

Accessibility work on this site is not finished, and we do not expect it ever to be “done”. What we do: run the automated checks as part of our test suite so a regression fails before it ships, keep the contrast ratios documented alongside the colours themselves, check keyboard operation by hand when we build a new control, and extend the automated sweep as pages are added. Reports from real people go to the front of that queue.

Requesting an alternative format

If you need anything published here in another format — this statement, our Terms of Service, our Privacy Policy, a guide, or an audit report — email accessibility@snaglabs.ai and say what would work for you. Large print, plain text, a structured document, or a phone or email walkthrough are all fine. We do not charge for this, and we will not ask you to explain why you need it.

Other ways to reach us

For anything that is not about accessibility, write to hello@snaglabs.ai. The rest of our contact addresses, and the other documents that govern your use of this site, are listed on our legal hub.