Access is a product requirement, not a final audit badge.

The public experience is intended to use semantic headings and landmarks, a skip link, keyboard-operable navigation, visible focus, sufficient contrast, meaningful labels, non-color status text, responsive layouts, and reduced-motion support.

Forms should provide programmatic labels, clear instructions, useful error messages, and an error summary. Workflow results should be announced to assistive technology where appropriate.

Meaningful images should have appropriate text alternatives; decorative images should be ignored by assistive technology. Videos, audio, PDFs, and office documents require accessible equivalents, captions, transcripts, reading order, or remediation appropriate to the material.

Private rights and identity documents may originate outside the platform and vary in accessibility. The operational process must offer a usable alternative without weakening confidentiality or legal review.

Automated checks can find only some barriers. Representative pages and end-to-end tasks require continuing tests with keyboard-only navigation, screen readers, zoom and reflow, high contrast, reduced motion, mobile viewports, and people with disabilities where feasible.

Third-party identity, payment, file-preview, email, and hosting experiences may have their own barriers. Provider selection and integration review must include accessibility rather than treating it as outside the service.

A dedicated public accessibility-feedback channel is not yet connected. Do not send accessibility feedback or confidential evidence through a founding application. Revisit this statement for a verified feedback channel; no fixed response time is promised at this founding stage.