Beta
Back to Legal Center

Accessibility Statement

What's accessible on Onyatrips today, and the gaps we're working on.

Last updated: 8 August 2026

Effective Date: 8 August 2026
Last Updated: 8 August 2026

Onyatrips is committed to making our Platform usable by as many people as possible. This Statement describes our current accessibility practices, including areas we are still working to improve, rather than asserting a conformance level we have not audited.

1. Our Commitment

Onyatrips wants the Platform to be usable by as many people as possible, including people who use assistive technology, rely on keyboard navigation, or need reduced-motion or high-contrast presentation. This Statement describes our current approach honestly, including where we fall short today.

2. Scope

This Statement covers the Onyatrips website (onyatrips.com) as it exists today. It does not cover third-party services embedded within the Platform (such as our Razorpay payment checkout or Google Sign-In widget), whose accessibility is controlled by those providers.

3. Conformance Target

We are not currently certified or independently audited against any accessibility standard. Where we reference the Web Content Accessibility Guidelines (WCAG) 2.1, we do so as a benchmark we aim to work toward, not as a conformance claim. A formal WCAG 2.1 Level AA conformance audit has not been performed. We do not state that Onyatrips "is WCAG 2.1 AA compliant" — only that this is a benchmark guiding our ongoing work, consistent with the instruction not to claim a conformance level that has not been verified.

4. What We Found: Confirmed Accessibility Features

The following accessibility features are implemented today, at least in part:

  • Reduced motion support: the site respects the prefers-reduced-motion operating-system/browser setting in multiple places (global styles and specific animated pages), scaling back or disabling non-essential animation for users who have this preference enabled.
  • Language attribute: the page's root HTML element declares lang="en", which helps screen readers select the correct pronunciation and language rules.
  • Some ARIA and semantic labeling: a number of interactive components use aria-label and related ARIA attributes (for example, our modal dialog component labels its close control for screen readers).
  • Keyboard dismissal on modals: our shared modal dialog component closes on the Escape key, a baseline keyboard-accessibility pattern.
  • Alternative text on images: a meaningful portion of image elements across the site include alt attributes.

5. What We Found: Known Gaps

We would rather disclose these than claim a conformance level we have not achieved:

  • No confirmed "skip to content" link. We did not find a skip-navigation mechanism that would let a keyboard or screen-reader user bypass repeated navigation (e.g., the site header) to reach the main content directly. This is a common and relatively low-effort accessibility improvement we have not yet implemented.
  • Form label association not confirmed. We do not consistently use explicit label/field pairing on form inputs. Some inputs may rely on aria-label or placeholder text instead, which is not automatically a violation, but placeholder-only labeling in particular is a known weak pattern for screen-reader and low-vision users; a targeted review of our forms (login, registration, profile editing, group creation, feedback) against this specific issue has not been completed.
  • No comprehensive, audited keyboard-navigation pass. Beyond the modal Escape behavior noted above, we have not completed and do not claim a full audit confirming that every interactive element on the site (menus, carousels, custom dropdowns, drag interactions) is fully operable by keyboard alone, with visible focus indicators throughout.
  • Color contrast not formally audited. We have not run the Platform's color palette through a formal contrast-ratio audit against WCAG thresholds; some combinations may not currently meet the 4.5:1 (normal text) or 3:1 (large text/UI component) targets typically used as a WCAG AA benchmark.
  • Captions/transcripts for audio or video content: where User-uploaded audio or video content exists on the Platform, we do not currently provide or require captions or transcripts.

We list these gaps because we would rather be specific and honest than make a general "we are accessible" claim that a specific user's experience might contradict.

6. Assistive Technology and Browser Compatibility

The Platform is built with modern, standards-based web technology (Next.js/React) and is intended to work with mainstream browsers and their built-in accessibility APIs. We have not completed formal testing with specific screen readers (e.g., NVDA, JAWS, VoiceOver) or documented a supported assistive-technology matrix.

7. Responsive and Mobile Accessibility

The Platform is built with responsive layouts intended to work across desktop and mobile screen sizes, including a dedicated mobile navigation and layout system. This supports zoom and reflow for many users, though we have not formally audited mobile-specific accessibility (such as touch-target sizing) against WCAG's mobile-relevant success criteria.

8. Cognitive Accessibility

We have not conducted a dedicated cognitive-accessibility review (e.g., simplifying complex flows, consistent navigation patterns, avoiding unnecessary time limits). This is an area for future improvement rather than a current, audited strength.

9. Third-Party Content and Accessibility Limitations

Some content on the Platform — third-party embedded checkout (Razorpay), Google Sign-In, and (if introduced in the future) third-party maps or other embeds — is controlled by the relevant third party, and its accessibility is governed by that provider's own accessibility practices rather than ours.

10. Known Limitations Summary

AreaStatus
Reduced motionImplemented in key areas
Language declarationImplemented
Some ARIA labelingPartially implemented
Modal keyboard dismissalImplemented
Image alt textPartially implemented
Skip-to-content linkNot found
Explicit form label associationNot confirmed
Full keyboard-navigation auditNot completed
Color contrast auditNot completed
Screen-reader testingNot completed
Formal WCAG conformance auditNot completed

11. Continuous Improvement

Accessibility is an ongoing effort, not a one-time project. We intend to address the gaps identified in Section 5 over time, prioritizing skip-navigation, form-label association, and a color-contrast pass as relatively achievable near-term improvements, with a fuller WCAG 2.1 AA audit as a longer-term goal.

12. Feedback

If you encounter an accessibility barrier while using Onyatrips, please tell us — specific reports (which page, which control, what assistive technology you were using, and what went wrong) are far more useful to us than a general complaint, and help us prioritize fixes accurately.

  • Email: legal@onyatrips.com, subject line "Accessibility Feedback"
  • We do not currently have a dedicated accessibility-feedback contact address or a committed response timeframe; requests are routed through our general legal/support contact today.

13. Changes to This Statement

We will update this Statement as we make accessibility improvements or complete a formal audit. Material changes will be reflected in an updated "Last Updated" date above.