Built to be used
by everyone.
We want anyone to be able to learn about First AI Employee and get in touch, whatever device or assistive technology they use. We aim to conform to WCAG 2.2 Level AA. That is the current version the W3C recommends, and the benchmark that US ADA guidance and the EU's EN 301 549 point to. We test with automated checks and code review and fix what we find, but we don't claim that every page and feature fully conforms.
What we've done
The measures already in place across the site.
Real structure, and a way to skip the menu.
The site is built with proper HTML landmarks (header, navigation, main content, and footer) so assistive technology can move through a page by region. A “Skip to main content” link is the first thing a keyboard user reaches on every page, so nobody has to tab through the whole menu to get to the content.
Works with a keyboard, and shows where you are.
The site’s shared navigation, links, buttons, and form fields are designed to be reached and used with the keyboard alone, and whatever you are focused on shows a clear outline. Menus and dialogs close with the Escape key.
Honors “reduce motion.”
If your device is set to reduce motion, animations across the site, including the scrolling strip of industries and the small demo effects, are stilled.
Forms that are labeled and speak up.
Our contact and sign-up/onboarding forms have real labels tied to each field, mark required fields so a screen reader announces them (not just a visual asterisk), tell your browser what it can autofill, and announce “sent” and error messages instead of changing silently.
Results that announce themselves.
When an interactive tool recalculates (the cost calculators, the greeting and message generators, the article filters), the new result is announced to screen readers through a live region, and “copied to clipboard” confirmations are spoken too.
Menus that match how they behave.
The header drop-downs are exposed to assistive technology as a button that expands a short list of links, which is what they actually are, so what a screen reader announces lines up with how the menu really works.
Text you can read.
We aim for text and essential controls that meet the WCAG AA contrast minimum against their background, including the illustrated “before / after” cards and the demo text-message panel on the home page.
Where our testing stops.
We would rather tell you plainly than pretend the site is perfect. The automated check described below has a defined edge, and this is where it ends. If something on this site gets in your way, tell us and we'll fix it.
- Every published public sitemap URL, but not every product state. The automated run derives and checks each public URL in the sitemap. It cannot discover states that require account data, authentication, or an interaction outside its focused cases.
- English and Spanish, at desktop and 320-pixel widths. The automated run covers both locales at 1280 and 320 pixels and flags document-level horizontal overflow at 320 pixels. A narrow viewport is not a substitute for testing real browser zoom at 400 percent.
- Authenticated journeys require separate review. The dashboard, setup, onboarding, and other signed-in states are outside the public sitemap run. One focused sign-up reflow case is automated, but the latest recorded review did not complete the full authenticated journeys.
- Automated testing only reaches part of the standard. Software can flag a missing label or a weak contrast ratio. It cannot tell you whether link text makes sense out of context, whether a heading order tells the right story, or whether an error message actually helps. Those are human calls, and we can miss things.
Known accessibility issues
We are not currently aware of any unresolved accessibility barriers in the scope we have tested. This does not mean every page, browser, device or assistive-technology combination is free from problems. If you encounter a barrier, email [email protected] or call (361) 306-9553, and we will help provide access.
Run into a barrier? Tell a real person.
We aim to acknowledge accessibility requests within one business day. If you need information in another format or cannot complete a task, tell us what works for you and we will help provide an accessible alternative while we investigate.
Write to us at that address, or call and talk to us. Prefer the phone? That works for anything on this site.
How we assessed this. Our automated accessibility check is designed to run axe-core in headless Chromium against the same production build that goes live. It derives every published public English and Spanish URL from the sitemap and checks each at 1280 and 320 pixels. The narrow pass also detects document-level horizontal overflow, and focused interaction cases cover dialogs, booking, chat, cookie preferences, sign-up reflow, and keyboard-scrollable legal tables. It applies the WCAG 2.0, 2.1 and 2.2 Level A and AA rules and fails on any unsuppressed violation or broken route. The check is run on demand, not on a schedule. The most recent recorded production-build attempt, on August 24, 2026, did not complete because Chromium could not launch, so it reported no page as passing or failing. Automated testing reaches only part of the standard. We supplement it with code review, while human NVDA testing, real 400 percent browser zoom, and the full authenticated journeys remain outstanding in the latest recorded review. This is our own assessment, not a third-party certification. Last reviewed August 24, 2026; we update this page as the site changes.