Accessibility Statement

Last updated: · Last reviewed:

Soverio (Identity Lab, UAB) is committed to making soverio.id accessible to as many people as possible, including users of assistive technology. This statement describes how we approach accessibility, the standards we aim for, and how to report a barrier.

Conformance status

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. This is the practical bar for B2B and public-sector procurement in the EU and is referenced by the European Accessibility Act (Directive 2019/882), which applies to relevant private-sector services from 28 June 2025.

soverio.id is partially conformant with WCAG 2.1 Level AA. Most of the site has been audited and any serious or critical issues identified have been resolved. The known limitations below are tracked openly.

Measures we take

  • Semantic HTML — landmarks (header, nav, main, footer), a single h1 per page, and a logical heading hierarchy.
  • Keyboard navigation throughout, with a visible "Skip to main content" link and visible focus rings on all interactive elements.
  • Forms have programmatically associated labels, error messages exposed via aria-describedby and aria-live, and autocomplete hints on all relevant fields.
  • Colour contrast meets WCAG AA for body text, links, and interactive controls. Brand orange used as a foreground colour has been darkened where needed to keep text legible.
  • Images have meaningful alternative text; decorative images use empty alt attributes.
  • Motion respects the prefers-reduced-motion media query — animations are disabled or reduced for users who request it.
  • Automated checks: every pull request runs axe-core across a representative set of pages and blocks the build on any serious or critical violation.

Known limitations

  • The newsletter and contact forms use Cloudflare Turnstile for bot protection. The widget is invisible by default and falls back to a brief interactive challenge for traffic that looks suspicious; this challenge may be harder for some users of assistive technology to complete.
  • Embedded Salesforce Web-to-Lead processing happens via a hidden iframe. Submission status is announced via a aria-live region but the underlying iframe is not exposed to screen readers.
  • Third-party analytics (Google Tag Manager / GA4) are loaded via Partytown in a web worker. They do not block the main thread, but they run only after explicit cookie consent.

Reporting a barrier

If you encounter content or functionality that you find inaccessible, please tell us. We aim to acknowledge a report within 5 business days and resolve confirmed accessibility barriers within 30 business days wherever feasible.

  • Web form: /contact/ — please mention "Accessibility" in your message so we can route it to the right person
  • Postal: Identity Lab, UAB · Vilnius · Lithuania

Please describe the issue, the page URL, the browser and assistive technology you were using, and what you expected to happen.

Assessment approach

Conformance has been assessed via a combination of automated scanning (axe-core via Playwright in CI on every pull request, and Lighthouse Accessibility audits as part of the build gate), expert manual review, and ongoing keyboard- and screen-reader-based smoke testing on the core user journeys (homepage, product, solution, blog, contact).

Standards referenced

Enforcement

If we are unable to resolve a confirmed accessibility issue you report, you may escalate to the supervisory authority for accessibility in your EU member state. In Lithuania, that is the Ministry of Social Security and Labour; in other member states, see the European Commission's list of national accessibility bodies.