Accessibility statement

1. Accessibility approach

Accessibility is treated as a product and engineering requirement rather than a final cosmetic pass. New public interfaces should prefer semantic HTML, native browser behavior and predictable interaction before custom accessibility workarounds.

2. Current public-surface controls

• Skip links are provided so keyboard users can move directly to primary content.
• Navigation and content use semantic landmarks and heading structure.
• Interactive links expose visible keyboard focus states.
• Layouts are responsive and designed to reflow on smaller viewports.
• Reduced-motion preferences are respected by the shared legal/public styles.
• Legal surfaces contain no application JavaScript and do not require pointer-only interaction.

3. Verification

The marketing build includes automated accessibility checks and explicit release assertions for public artifacts. Automated checks are useful evidence but do not replace keyboard, screen-reader, zoom, contrast and real-device testing by humans.

4. Scope boundaries

The protected platform, Mission Control, Product Cells and future customer applications can have different interaction patterns and must be assessed separately. A passing public-site check must not be reused as proof that every protected AVC application is accessible.

5. Known limitations

AVC has not yet completed an independent accessibility audit across every public and protected surface. Continuous changes during alpha may introduce regressions, and visual or assistive- technology testing still needs to accompany automated verification before production claims are made.

6. Standard used for engineering decisions

AVC uses WCAG AA principles as the practical engineering baseline for the public experience where applicable, while legal scope must be assessed for the actual service, users and market before claiming statutory compliance.