Accessibility statement

Our target

We design and engineer toward WCAG 2.1 Level AA. Every release passes an automated axe-core audit on the highest- traffic surfaces (the home page, job browse, candidate profile, job detail, and the application flow). The audit runs as part of our CI pipeline so regressions don't ship silently.

What we've done

• Colour contrast. Every text + background combination on the public site clears the WCAG AA contrast threshold (4.5:1 for normal text, 3:1 for large text). The brand palette ships explicit -deep variants of the accent colours specifically for text foregrounds.
• Keyboard navigation. Every interactive control — menus, modals, the application form, the kanban pipeline — is reachable and operable with the keyboard alone. Focus rings are visible and high-contrast.
• Skip-to-content link. Every page exposes a keyboard-only skip link at the top so screen-reader and keyboard users don't have to tab through the full navigation on every visit.
• Semantic structure. Headings (<h1> through <h6>) are used for document outline, not visual size. Landmarks (<header>, <main>, <nav>, <footer>) wrap the corresponding regions on every page.
• Image alt text. Every meaningful image has a descriptive alt attribute. Decorative images are marked aria-hidden so assistive tech doesn't announce them.
• Forms. Every input has an associated <label>. Validation errors are announced via role="alert" and tied to the specific field via aria-invalid + aria-describedby, so a screen reader names the broken field on submit.
• Touch targets. Interactive controls are at least 44 × 44 px on mobile — the floor mobile-WCAG recommends for comfortable thumb tapping.
• Reduced motion. Animations honour prefers-reduced-motion. The verified-badge shimmer, the “LIVE” ticker pulse, and the kanban-drag visuals fade out or stop entirely for users who've asked their OS to limit motion.
• Hindi + nine other languages. A page-level Google Translate widget covers Hindi, Tamil, Telugu, Marathi, Bengali, Gujarati, Kannada, German, Arabic, Chinese, French and Japanese — available on every public page via the language selector in the header.

Known limitations

We're honest about where we're still working:

• Drag-and-drop kanban (employer ATS). Moving candidate cards between pipeline stages works fully with the keyboard, but the screen-reader announcement of the drop target is currently terse. Improving the live-region announcements is on the roadmap.
• Embedded video. User-uploaded video content (in posts and competition submissions) doesn't yet have automatically generated captions. We're evaluating a Whisper- backed captioning step for the upload pipeline.
• Charts on /pulse + /salaries. The visual charts are paired with a text summary of the same data, but the SVGs themselves don't expose individual data points to screen readers. Adding aria-labels + a tabular fallback view is pending.

Report a barrier or request an alternative format

If anything on the site is hard to use — a missing label, a low- contrast element, a keyboard trap, or a flow that doesn't work with your assistive tech — please tell us. We treat accessibility reports as we treat security reports: triaged within one business day, fixed promptly.

How we test

• Automated axe-core scans on every pull request — surfaces colour contrast, missing labels, and ARIA misuse before merge.
• Manual keyboard-only passes on signup, profile editor, job apply, and the employer ATS once per release cycle.
• Periodic screen-reader testing with VoiceOver (macOS / iOS) and NVDA (Windows) on the top user journeys.
• Lighthouse + Pingdom + GTmetrix runs after every production deploy — accessibility is one of the four scores we track.

Standards we follow

This site is built to conform with WCAG 2.1 Level AA and references the relevant sections of India's Rights of Persons with Disabilities Act, 2016 for digital service accessibility.