Accessibility target
The public site is designed toward the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. The goal is for people to read the product information, navigate the site, operate the browser demo, and reach the contact path with a keyboard or assistive technology.
Visual presentation
Text and controls use the shared deep-green, neutral, marigold, and warning-color system. Status and validation are expressed with words or symbols as well as color. Body copy is constrained to a readable measure, and browser zoom is not disabled.
Motion is limited to short opacity or transform transitions. Meaningful animation and smooth scrolling are removed when a device requests reduced motion.
Responsive and input behavior
Public routes recompose for narrow screens rather than shrinking desktop layouts. Menus remain dismissible and scrollable on short screens, legal navigation returns to document flow on smaller widths, and interactive targets are designed to be at least 44 by 44 CSS pixels.
The release review covers representative phone, tablet, and desktop widths, including a 320 CSS-pixel viewport and keyboard-only operation.
How the site is checked
The repository includes automated checks for:
- WCAG A and AA rules detected by axe on public routes;
- one H1, no horizontal overflow, and minimum target size;
- keyboard operation of the mobile menu, FAQ, and browser demo;
- valid internal links, headings, metadata, and route recovery.
Automated tests cannot confirm every experience. Release review also requires rendered inspection at mobile and desktop widths, reduced motion, zoom, and keyboard-only navigation.
Known limitations and boundaries
- Automated checks can miss reading order, wording, cognitive load, and assistive-technology differences.
- Romanized Hindi and bilingual examples require fluent human review for language quality; code checks cannot establish that quality.
- The contact action opens the visitor's email application. The accessibility of that application is outside this website's control.
- Any future embedded provider, account, call interface, or customer portal needs its own accessibility review.
Report an accessibility barrier
If a page, control, or document is difficult to use, describe the route, the task you were trying to complete, the problem, and the browser or assistive technology involved. Do not include passwords, private records, or regulated personal data.
The public contact channel is a general feedback route. No response deadline or formal remediation commitment has been established.