Inclusive design
How Oblixa designs the product to work with a keyboard, a screen reader, and reduced motion — and how to tell us when something gets in the way.
Reviewed
Commitments
Public pages and a defined set of product routes are checked with automated accessibility scans in our test suite.
Navigation, forms, and disclosures are keyboard-reachable in visual order, with a skip link straight to the main content.
Every interactive element keeps a visible focus ring, and standard text is designed toward WCAG AA contrast in light and dark mode.
Landmark regions and ordered headings let screen readers move between sections; ARIA is used only where a native element falls short.
Fields carry programmatic labels, required fields are marked for assistive technology, and errors are announced next to the field.
When your system requests reduced motion, non-essential animation is dropped and transitions are turned off instead of moving content.
Layouts reflow down to small screens and stay usable at 200% browser zoom without hiding content or primary actions.
Support
If something stops you from completing a task, tell us and we'll route it to the team that can fix it. You don't need an Oblixa account to send a report.
What helps us fix it faster
Either option reaches the Oblixa support team.
Conformance
We don't claim formal conformance or third-party certification. Oblixa targets WCAG 2.2 AA, and we treat reported barriers as priority fixes.