Accessibility statement

The commitment

This site targets WCAG 2.2 Level AA. That is the standard most commonly referenced in United States and Canadian accessibility requirements, and it is the bar the site is built and reviewed against.

Accessibility here is a build requirement rather than a retrofit. It is checked before launch alongside performance and security, and it is part of the scope on client projects too.

What has been done

• Colour contrast. Every text and background pairing in the design system is checked by computed value against the darkest and lightest surface it appears on, not by eye. The worst case ratio for any text colour on any surface is 5.1:1, which clears the 4.5:1 AA requirement for normal size text with margin. Body copy measures 9:1 or better.
• Keyboard access. Every interactive element is reachable and operable with a keyboard alone. There are no keyboard traps. A skip link is the first focusable element on every page.
• Visible focus. A single high contrast focus ring is used site wide and is never removed. It is visible against every background in the palette.
• Touch targets. Interactive controls measure at least 40 pixels tall, and the primary ones at least 44, which meets WCAG 2.2 target size guidance. Inline links inside a paragraph are exempt under that guideline and are not padded, because doing so would break the line spacing of the surrounding text. Every route is measured at seven viewport widths before release and the check fails the build if a control falls below the threshold.
• Motion control. The scrolling list of tools on the homepage has a visible pause button, because content that moves for more than five seconds has to be stoppable by someone who has not set an operating system preference.
• Zoom and reflow. Pinch zoom is never disabled. Content reflows to a single column at 320 pixels wide with no horizontal scrolling and no loss of function.
• Semantic structure. Real landmarks, one h1 per page, headings in order, lists marked up as lists, and form labels tied to their inputs. Icons that carry no meaning are hidden from assistive technology.
• Motion. Every animation is disabled when the operating system reports a preference for reduced motion. No content is conveyed by motion alone, and nothing flashes.
• Forms. Errors are announced, associated with the field that caused them, and described in words rather than colour alone. Focus moves to the error summary on a failed submission.
• Text over images. The design avoids text placed over photographic backgrounds, which is the most common source of unpredictable contrast failures.

Known limitations

Listing these is more useful than claiming perfection.

• The chat assistant. The panel is a labelled dialog, traps focus while open, returns focus to the launcher when closed, and announces new messages through a polite live region. What remains imperfect is the reading experience while a reply is still streaming: content that grows character by character is genuinely hard for any screen reader to announce cleanly, and the result can be repetitive. Anyone who finds that a barrier can use the contact form or call instead, and both reach the same person.
• Charts in the private dashboard. The traffic chart carries a table alternative that presents the same numbers as text. The hover tooltip itself is pointer only, so the table is the supported route for keyboard and screen reader users rather than an afterthought.
• Third party content. Where an external tool is embedded in future, its accessibility is set by its vendor. Any such embed will be tested and, if it fails, replaced or given an accessible alternative.
• Automated testing has limits. Automated tools catch roughly a third of real issues. Manual keyboard testing and screen reader spot checks cover more, but no process catches everything, which is why the report route below matters.

How this is tested

Keyboard only navigation on every route. Screen reader spot checks with VoiceOver on macOS and iOS and with NVDA on Windows. Contrast verified by computed value rather than by eye. Layout checked at 320, 375, 768, 820, 1024, 1280 and 1536 pixels wide. Reduced motion and forced colours checked at the operating system level.

Report a barrier

If something on this site is difficult or impossible for you to use, tell us and it will be fixed.

Email charliezservices@gmail.com or call (949) 596-4187. Include the page address, what you were trying to do, and the assistive technology and browser you were using if you know them.

Every report gets a reply within one business day. Straightforward fixes usually ship within a week. If a fix will take longer, you will be told when to expect it and given a way to get what you needed in the meantime.

Alternative formats

If any content here is not usable in the format it is published in, ask and it will be provided another way at no cost.