Accessibility Statement

Identigy is committed to ensuring that identigy.com is accessible to people with disabilities. We treat accessibility as part of engineering quality — broken accessibility on a marketing site is a credibility signal for an identity-and-security vendor, not just a compliance box.

1. Standard we follow

We target WCAG 2.1 Level AA (Web Content Accessibility Guidelines published by W3C). Where reasonable, we exceed AA to AAA — notably on body-text contrast (typically ≥ 12:1 against the page background).

2. What we do

• Body text sits at AAA contrast against light and dark surfaces; cards and tinted blocks are verified separately.
• Keyboard navigation works on every interactive element. Focus rings are explicit (2px brand-blue, 2px offset) and visible only for keyboard users via :focus-visible.
• Image alt text is required for any image carrying meaning; decorative images use empty alt + aria-hidden.
• A built-in dark theme reduces glare and is toggleable in the header. The site respects prefers-reduced-motion — animations and smooth scroll are disabled when the OS requests it.
• Headings follow a single-h1-per-page rule with a consistent h1 → h2 → h3 hierarchy; the page outline (right-rail) is generated from those headings.
• Forms use explicit labels (no placeholder-as-label), required fields are marked, and validation messages name the affected field.

3. Known limitations

We test on the latest two versions of Chrome, Safari, Firefox and Edge, and on iOS Safari + Android Chrome. We do not currently certify the site against assistive-tech combinations beyond NVDA and VoiceOver.

Some third-party content (Cloudflare Turnstile widget, embedded video when used) ships with its own accessibility profile and may not match the rest of the site.

4. Report a barrier

If you encounter an accessibility barrier on this site, please tell us. We treat accessibility bugs at the same priority as security issues — most are fixed within one business week.

Email → info@identigy.com . Please include the page URL, the browser and OS you were using, and what you expected vs. what happened.

5. Audit method

We use a combination of axe-core automated checks, manual keyboard traversal, and contrast verification with WebAIM Contrast Checker against the canonical colour tokens declared in our design system. Audits run before every release that touches shared components or the token layer.