Accessibility
Accessibility Statement
What we target, what we actually test, and where this site falls short today.
Conformance target
WCAG 2.2 Level AA is the target
We have not commissioned an independent accessibility audit or testing with real assistive technology, and we do not claim full conformance. What follows is what we actually check in our automated tests, how this site is built, and the gaps we already know about.
Automated testing
What we test automatically
Our automated test suite checks every route it lists — our main pages, plus a sample blog post and the blog archive — on two viewport projects: desktop (Chrome) and mobile (a Pixel 7 emulation). That route list is hand-maintained, not generated, so it does not reach every blog post, category, date archive, author page or search result individually. On every listed route, it checks:
- An axe-core accessibility scan against six WCAG rule-set tag combinations: 2.0 A, 2.0 AA, 2.1 A, 2.1 AA, 2.2 A and 2.2 AA.
- Exactly one main landmark, and exactly one heading level 1, on the page.
- No horizontal scrolling at any tested viewport width.
- Separately, the colour pairings this design system actually uses — body text, links, focus rings and the like, on every background that pairs with them — are checked against WCAG AA contrast ratios on every build. Two of the sixteen palette colours are decorative-only and documented as illegal to use as text, and that stays machine-checked too.
Built this way
How this site is built
- A “Skip to content” link before the header, provided automatically by WordPress core on every page.
- Every clickable control is a real link or button element — never a styled element standing in for one.
- Visible keyboard focus everywhere: a 2px outline, navy on light backgrounds and amber on dark, that is never removed.
- prefers-reduced-motion is honoured site-wide — animations and transitions collapse to near-zero duration, and every animated element still reads correctly in its static state.
- The homepage’s decorative particle-field animation is marked aria-hidden, so screen readers skip past it instead of describing motion that carries no information.
- Every page declares its language, and any passage in a different language is marked up so a screen reader switches pronunciation instead of reading it with English phonetics — for example the company’s registered Greek legal name in the footer, which appears on every page.
- Heading levels built in order by hand, page by page — the full sequence isn’t machine-checked (see the gaps below), but exactly one heading level 1 per page now is, on every route our test suite lists.
- The contact form uses real labelled fields, never a placeholder standing in for a label. If you leave something out, an error summary appears at the top of the page and receives keyboard focus automatically, and each field’s own message is linked to it so a screen reader announces exactly what to fix.
Known gaps
Where we fall short today
Automated tools catch a meaningful share of accessibility issues, not all of them. Here is what we already know is incomplete:
Automated tools only
No manual audit and no testing with real assistive technology — for example a screen reader — has been performed on this site.
Heading order beyond the h1 isn’t machine-checked
Our automated suite runs the WCAG 2.0, 2.1 and 2.2 A/AA rule sets, plus our own test asserting exactly one heading level 1 per listed route. Axe-core’s own heading-order check sits outside those, under its own “best practice” category, so the full heading sequence is still checked by hand during development, not asserted automatically.
Focus-ring contrast isn’t machine-checked
Axe-core has no rule for keyboard-focus-indicator contrast (WCAG 2.4.11), so every focus-ring colour pairing is checked by hand rather than asserted automatically. That is exactly how one dark-background focus ring shipped hard to see before we caught and fixed it by hand.
Only two fixed viewport widths are tested
Our suite tests one desktop width and one mobile width. We do not yet test reflow at a 320px viewport or at 400% zoom (WCAG 1.4.10).
Our route coverage is hand-maintained
The routes listed above are a maintained list, not every URL this site can render. Individual blog posts, category and date archives, author pages and search results are not each scanned on their own.
Greek translation isn’t published yet
The Greek version of this site is planned for a later phase and is not live today. Everything above describes the English site only.
No review date, and no dedicated accessibility contact
This statement has no preparation or review date, and there is no accessibility-specific contact or published escalation process — only the general email below.
Tell us about a problem
If something on this site is hard to use with a keyboard, a screen reader or any other assistive technology, tell us through the contact form or by emailing us directly at info@odyx.ai, and describe what happened — we do not yet have a dedicated accessibility contact, but we will do our best to help.
Start with one real demand.
We start with a focused discovery session and a short demonstration using one of your real demands.