Accessibility

The product is being built with WCAG 2.2 Level AA as its accessibility target. The intended baseline includes keyboard operation, visible focus, semantic form labels, clear validation, sufficient contrast, reduced-motion support, responsive reflow, and meaningful headings and link text.

Meeting a target requires testing, not just implementation. No claim of full WCAG conformance should be published until the launch build and its third-party content have been evaluated.

If a person cannot use part of the experience, the opportunity team should offer an equivalent way to receive the information, provide responses, or request a conversation. The intended accessibility contact is jeromy@goatleads.com, but that address must be verified and monitored before launch.

When reporting an issue, it is helpful to include the page, device and browser, assistive technology if applicable, and a brief description of the problem. Do not include sensitive personal information in the report.

• The embedded overview video needs verified captions and a reviewed text transcript or equivalent alternative.
• The complete registration, qualification, scheduling, cancellation, and confirmation flows need keyboard and screen-reader testing.
• Error, empty, loading, expired-link, no-availability, and rate-limit states need understandable announcements and recovery instructions.
• The supported browser and assistive-technology matrix must be recorded after production-like testing.

Accessibility should be included in design review, code review, regression testing, content updates, and vendor selection. Material defects should be prioritized by user impact, and this statement should be updated when the test status or contact method changes.