Accessibility is part of how we build, not an afterthought. This statement describes what we have actually implemented and where we still have work to do.
Our commitment
We want everyone to be able to use this website and our services, including people who use screen readers, keyboard navigation, magnification, or reduced-motion settings. We aim to follow recognised accessibility good practice, and we treat an accessibility barrier as a defect to be fixed.
What we have implemented
- Semantic HTML — proper landmarks, headings, lists and tables rather than generic containers.
- Keyboard navigation — every interactive element reachable and operable without a mouse.
- Visible focus indicators — a clear focus ring, never removed.
- Skip link — lets keyboard users jump straight to main content.
- Labelled form controls — every field has a programmatically associated label.
- Inline error messages — errors are described in text, linked to the field, and announced to assistive technology.
- Sufficient colour contrast — body and interface text checked against contrast guidance.
- Status announcements — success and error messages delivered through live regions.
- Reduced-motion support — animations and transitions are effectively disabled when your system requests reduced motion.
- Descriptive alt text — meaningful images described; decorative images hidden from assistive technology.
- Touch-friendly targets — interactive controls sized generously for touch input.
- Responsive layout — no horizontal scrolling required; content reflows on small screens.
- Language declared — the page language is set so screen readers pronounce content correctly.
Content practices
- Headings follow a logical order rather than being chosen for appearance.
- Link text describes its destination where possible.
- Information is never conveyed by colour alone.
- Text can be enlarged in the browser without breaking the layout.
- Tables used for data include header cells and captions.
Known limitations
We are honest about remaining gaps:
- Some embedded third-party content — such as externally hosted fonts or SDK libraries — is outside our control and may not fully meet the same standard.
- Where administrators publish content through the admin panel, accessibility depends in part on what they provide; we provide authoring guidance but cannot fully audit every item.
- Some legacy documents or downloadable files, if added, may not yet be fully accessible. New documents are created with accessibility in mind.
- We have not commissioned a formal third-party accessibility audit. We work to good practice and fix reported barriers.
Reporting an accessibility barrier
If you cannot use part of this website or one of our services because of a barrier, please tell us. Include the page URL, what you were trying to do, the barrier you encountered, and the assistive technology or browser you use if relevant.
- Email: support@zivox.co.in
- Form: Report an Issue — select "Accessibility barrier"
- Grievance route: Grievance Redressal
We aim to respond within 5 working days with an assessment and, where a fix is needed, a timeframe for it.
Assistance with a service
If a barrier prevents you from completing something important — such as submitting an enquiry or an application — contact us and we will complete the process with you through an alternative channel such as email or phone.
Improvement plan
- Continue testing pages with keyboard-only navigation.
- Test with commonly used screen readers.
- Improve the admin authoring guidance so published content stays accessible.
- Add accessibility checks to our pre-launch process for every project.
This document is provided for transparency and general information. It does not constitute legal advice. ZIVOX's approach is designed to support compliance with applicable Indian data-protection requirements and to be improved over time.
Questions about this document? Email info@zivox.co.in or use our Grievance Redressal process.