Accessibility
Accessibility support, current limits, and how to report an issue.
Rostora is built to be usable with keyboard navigation, visible focus states, semantic controls, and reduced-motion preferences. This is a current statement, not a third-party audit.
Current support
- Core pages use semantic headings, links, buttons, forms, and native disclosure controls where possible.
- Keyboard-visible focus states are styled across landing, navigation, footer, FAQ, and proof links.
- Reduced-motion preferences are respected for marketing-page transitions and animated effects.
- External links that open a new tab include visible or accessible new-tab wording.
Reviewed areas
- Landing page hero, CTA links, FAQ disclosure controls, footer links, and proof cards.
- Product status page, changelog page, accessibility page, security page, pricing, privacy, and terms navigation paths.
- Demo/product mock is treated as supporting visual context, with nearby text explaining the core value.
- Color is not the only cue for CTA state; focus outlines and text labels remain visible.
Known limits
- A third-party VPAT or WCAG audit has not been published yet.
- The dense schedule mockup is visual-heavy and should not be the only way to understand the product.
- Some compact mono labels remain intentionally visual; the content around them carries the meaning.
- Screen-reader testing beyond semantic review should be documented before enterprise procurement claims.
Feedback path
- Email support@rostora.com with the page, browser, assistive tech, and issue description.
- Accessibility issues should be treated as product bugs, not support preferences.
- Procurement-specific accessibility requests can be discussed before Team rollout.
- This statement should be updated when testing coverage or known limits change.
Send the affected page, what you expected to happen, and what blocked you. Q10 Labs can confirm whether the issue is already known and when it can be addressed.