Accessibility Statement
Last reviewed: July 2026
Our Commitment
OmniAssist is committed to ensuring digital accessibility for people with disabilities. We continually improve the user experience for everyone and apply relevant accessibility standards to our platform. We believe that every person — regardless of ability — should have equal access to AI-powered assistance.
Conformance Status
OmniAssist targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. The platform is partially conformant — most content meets the standard, with the known exceptions described below.
| Criterion | Level | Status |
|---|---|---|
| 1.1.1 Non-text Content | A | Passes — decorative images carry empty alt attributes |
| 1.3.1 Info and Relationships | A | Passes — semantic HTML landmarks (main, header, nav, aside) used throughout |
| 1.3.4 Orientation | AA | Passes — no orientation lock applied |
| 1.4.3 Contrast (Minimum) | AA | Partially passes — muted text raised to OKLCH 0.62 lightness; warm gold accent elements are a known exception (see below) |
| 1.4.4 Resize Text | AA | Passes — viewport meta allows pinch-zoom; text scales without loss of content |
| 1.4.10 Reflow | AA | Passes — responsive layout reflows at 320 px width |
| 2.1.1 Keyboard | A | Passes — all interactive elements are keyboard-reachable |
| 2.1.2 No Keyboard Trap | A | Passes — focus is never trapped outside modal dialogs |
| 2.4.1 Bypass Blocks | A | Passes — landmark regions allow screen-reader skip navigation |
| 2.4.3 Focus Order | A | Passes — logical tab order maintained across all pages |
| 2.4.7 Focus Visible | AA | Passes — visible focus rings on all interactive elements |
| 3.1.1 Language of Page | A | Passes — lang="en" set on all pages |
| 3.3.1 Error Identification | A | Passes — form errors are identified in text, not colour alone |
| 4.1.2 Name, Role, Value | A | Passes — ARIA labels applied to icon-only buttons and custom controls |
| 4.1.3 Status Messages | AA | Passes — toast notifications use role="status" via Sonner |
Known Limitations
The following issues are known and represent intentional design decisions or technical constraints. We document them here in the spirit of transparency.
Warm gold accent — colour contrast
The primary brand accent (warm gold, OKLCH 0.72 0.15 75) achieves approximately 3.8:1 contrast against the near-black background, which falls short of the 4.5:1 ratio required by WCAG 2.1 SC 1.4.3 for normal-sized text. This applies to selected navigation states and decorative highlights. These elements are purely decorative or redundant with adjacent text, so no information is lost. We have documented this as a design-intent exception and continue to monitor it.
Streaming AI responses
Tokens streamed in real time are appended to the message container without individual ARIA live announcements for each token, as this would cause excessive screen-reader verbosity. The completed response is announced once streaming finishes via an aria-live="polite" region.
Third-party embeds
The Stripe payment portal and Manus OAuth login screen are rendered by third-party providers. Their accessibility conformance is governed by Stripe and Manus respectively and is outside OmniAssist's direct control.
Technical Approach
OmniAssist is built with accessibility as a first-class concern. Our technical implementation includes:
- Semantic HTML5 elements (
main,header,nav,aside,section) on all pages - ARIA labels on all icon-only buttons and custom interactive controls
- Keyboard shortcuts documented in the in-app Keyboard Shortcuts modal (Cmd+/)
- Visible focus rings preserved on all interactive elements
- Pinch-zoom enabled — no
maximum-scalerestriction in the viewport meta tag - Colour contrast audited with axe-core; muted text lightness raised to OKLCH 0.62
- Dark and light theme support, respecting
prefers-color-schemeon first load - Scrollable regions are keyboard-focusable (
tabIndex=0) - All images that convey meaning include descriptive
alttext; decorative images usealt="" - Form validation errors are communicated in text, not colour alone
Assistive Technology Compatibility
OmniAssist is designed to be compatible with the following assistive technologies:
| Technology | Notes |
|---|---|
| Screen readers (NVDA, JAWS, VoiceOver) | Landmark navigation and ARIA labels tested; live regions announce dynamic content |
| Keyboard-only navigation | All features accessible without a mouse; focus order follows visual layout |
| Browser zoom up to 200% | Layout reflows without horizontal scrolling or content loss |
| High-contrast mode (Windows) | Semantic colours adapt; no information is conveyed by colour alone |
| Reduced motion | Animations respect prefers-reduced-motion where supported |
Feedback and Contact
We welcome feedback on the accessibility of OmniAssist. If you encounter a barrier or need content in an alternative format, please reach out using any of the following methods:
Enforcement Procedure
If you are not satisfied with our response, you may contact the relevant national enforcement body in your jurisdiction. For users in the European Union, this may be your national data protection authority or equality body. For users in the United Kingdom, the Equality and Human Rights Commission (EHRC) is the relevant enforcement body. For users in the United States, the Department of Justice oversees ADA Title III compliance for web services.
Assessment Approach
OmniAssist assessed the accessibility of this platform using the following methods:
- Automated testing with axe-core via Puppeteer across all major pages
- Manual keyboard navigation testing on Chrome, Firefox, and Safari
- Screen reader testing with VoiceOver on macOS
- Colour contrast verification using OKLCH colour calculations
- Ongoing regression testing via Vitest unit tests covering ARIA attributes and semantic structure