Accessibility statement
What we target, how we test, what we know is imperfect, and how to tell us when something does not work.
Last updated:
Our commitment
We build this website, and the software we deliver for clients, to be usable by people with a wide range of abilities and assistive technologies. Accessibility is part of how components are built rather than an audit performed at the end.
We target WCAG 2.2 Level AA. We believe this site substantially conforms to that standard, and we describe below both how we test and where we know there is more work to do.
What we have implemented
- A skip-to-content link as the first focusable element on every page.
- Semantic landmarks — header, navigation, main and footer — with a single, correct heading hierarchy per page.
- Full keyboard operation, including mega menus that open with Enter, Space or Arrow Down and close with Escape, returning focus to the trigger.
- A mobile navigation panel that traps focus while open, closes on Escape, and returns focus to the button that opened it.
- Visible focus indicators on every interactive element, with a higher-contrast variant on dark sections.
- Form labels tied to their inputs, errors announced in text with an icon rather than colour alone, and `aria-describedby` linking hints and errors to their field.
- Interactive targets of at least 44 by 44 pixels.
- Text contrast meeting or exceeding 4.5:1 for body text and 3:1 for large text and interface components.
- Full support for `prefers-reduced-motion` — all decorative animation stops when the preference is set.
- Descriptive text alternatives for meaningful graphics, and `aria-hidden` on decorative icons that duplicate adjacent text.
How we test
- Automated accessibility checks in the build pipeline, so a regression fails the build rather than reaching production.
- Automated end-to-end tests covering keyboard navigation of the header, mega menus and mobile menu.
- Manual keyboard-only passes on every significant page before release.
- Screen reader checks on key journeys using VoiceOver and NVDA.
- Testing at 200% and 400% zoom, and at 320 pixels wide, to confirm content reflows without horizontal scrolling.
Known limitations
We would rather list these than claim perfect conformance.
- The hero ecosystem diagram conveys its meaning through an SVG title and description. It is a supporting visual and the surrounding text carries the same information, but a longer text alternative would serve some users better.
- The case-study filter results update in place with a live-region announcement. We are still evaluating whether moving focus to the results heading would be a better experience for screen reader users.
- Third-party services added in future — such as a scheduling widget — may not fully conform. We will assess any such tool before adding it and note any shortfall here.
Compatibility
This site is designed to work with recent versions of Chrome, Edge, Firefox and Safari on desktop and mobile, in combination with VoiceOver, NVDA, JAWS and TalkBack. Older browsers may render it with reduced visual fidelity while remaining fully readable and operable.
Tell us about a problem
If you encounter a barrier on this site, email contact@xalicon.co with the page address and a description of what happened. We aim to acknowledge within two business days and to explain what we will do and by when.
If you need information from this site in an alternative format, ask and we will provide it.
Accessibility in what we build for clients
We apply the same standard to client software. Accessibility acceptance criteria go into stories, automated checks run in the pipeline, and we report conformance honestly — including anything that falls short — rather than issuing a statement that overstates the position.
Questions
Need something clarified?
If anything on this page is unclear or you want to exercise a right described here, get in touch and a person will respond.
Prefer email? contact@xalicon.co