Nexiv Labs is now operating six divisions across healthcare, veterinary, commerce and infrastructure. See the group →
Legal

Accessibility Statement

Our target, what we have built, what still falls short, how we test, and how to tell us about a barrier so we can remove it.

Last updated: 13 August 2026 Version 2.0 Target: WCAG 2.2 Level AA

In short: we target WCAG 2.2 AA, we test with automated tooling on every build plus manual keyboard and screen-reader passes each release, and we know we are not perfect. If something blocks you, email support@nexivlabs.com — we treat accessibility barriers as defects, not feature requests.

1. Our commitment

Nexiv Labs is committed to making its websites and platforms usable by as many people as possible, regardless of disability, assistive technology or context.

This matters more than usual in our case. Two of our divisions deliver healthcare and veterinary care. People seeking care are disproportionately likely to be unwell, in pain, distracted, anxious, using an unfamiliar device or relying on assistive technology. An interface that only works for a well-rested user on a fast laptop is not fit for that purpose.

2. Conformance status

We measure against the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.

Our current status is partially conformant: most of the standard is met, and some content does not yet fully conform. We state this plainly rather than claiming full conformance, because a claim we cannot evidence helps nobody. Known gaps are listed in section 5 with dates.

3. What we have built

3.1 Structure and navigation

  • Semantic HTML landmarks — header, nav, main, footer — on every page.
  • A "Skip to main content" link as the first focusable element.
  • Logical heading hierarchy, with one h1 per page.
  • A consistent, predictable navigation pattern across every page.
  • Descriptive, unique page titles.

3.2 Keyboard

  • Every interactive element is reachable and operable by keyboard alone.
  • Visible focus indicators with sufficient contrast, never suppressed.
  • Menus and dialogs close on Escape and return focus to their trigger.
  • Tab panels support arrow-key navigation; accordions are native buttons.
  • No keyboard traps anywhere in the interface.

3.3 Screen readers

  • Accessible names on all controls, including icon-only buttons.
  • aria-expanded, aria-selected and aria-current reflect actual state.
  • Decorative graphics — including diagrams and background patterns — are marked aria-hidden; informative graphics carry text alternatives.
  • Form errors are announced and programmatically associated with their field.
  • Status messages use aria-live regions.

3.4 Visual and motion

  • Text contrast meets or exceeds 4.5:1; large text and interface components meet 3:1.
  • Colour is never the only way information is conveyed — status always carries a label or icon too.
  • Layouts reflow to 320 px width and support 200% zoom without loss of content or function.
  • Text is real text, not images of text.
  • prefers-reduced-motion is honoured: animations, marquees and canvas visualisations stop or render statically.
  • Nothing flashes more than three times per second.

3.5 Forms and input

  • Every input has a persistent visible label; placeholders are never used as labels.
  • Required fields are marked in text as well as visually.
  • Autocomplete attributes are set on personal-data fields.
  • Touch targets are at least 24×24 CSS pixels with adequate spacing.
  • No time limits on form completion.

4. Clinical surfaces

Nexiv Health and Nexiv Vet apply the same standard plus additional requirements:

  • Consultation controls — mute, camera, end call, request help — are keyboard operable with announced state changes.
  • An audio-only fallback is always available where video cannot be used.
  • Live captioning support in consultations, with the ability to request a human interpreter.
  • Clinical documents can be exported as accessible, tagged files rather than flat images.
  • Critical alerts and red-flag warnings are conveyed through text, icon and colour together.
  • Where a carer or advocate is present, multi-party sessions support them explicitly.

5. Known limitations

We are aware of the following and are working on them:

LimitationImpactMitigationTarget
Canvas diagrams convey structure visually Screen reader users receive a summary label rather than the full detail Every diagram has an aria-label; the same information appears in adjacent prose and tables Q4 — full text equivalents
Some data tables scroll horizontally on narrow screens Extra effort for low-vision and mobile users Tables are keyboard-scrollable and never clip content Q4 — card layout below 620 px
A small number of older PDF exports are untagged Poor screen reader experience on legacy documents Accessible alternatives available on request within 2 business days Q1 — re-issued tagged
Third-party payment iframe Checkout accessibility depends partly on our provider Assessed at selection; issues escalated to the provider; telephone payment available Ongoing

6. How we test

  • Automated, every build. Axe-core checks run in the CI pipeline; a new violation fails the build rather than being logged for later.
  • Manual keyboard pass, every release. Every changed flow is completed using only a keyboard.
  • Screen reader testing, every release. NVDA with Firefox on Windows and VoiceOver with Safari on macOS and iOS.
  • Zoom and reflow. Verified at 200% and 400% zoom and at 320 px viewport width.
  • Contrast. Design tokens are contrast-checked at source, so a non-conforming colour cannot enter the palette.
  • Independent audit. Periodic external accessibility audit, with findings tracked to closure alongside security findings.

Automated tooling catches roughly a third of real issues. The manual passes are where the rest are found, which is why they are mandatory rather than best-effort.

7. Technical approach

Accessibility of this site relies on HTML, CSS, SVG and JavaScript. Content is server-rendered static HTML, so it is fully readable and navigable before any JavaScript executes. JavaScript adds progressive enhancement — collapsible menus, tabs, scroll reveal — and the site remains usable without it.

Accessibility features rely on the accessibility APIs of the browser and operating system. We support the current and previous major version of Chrome, Firefox, Safari and Edge.

8. Assistive technology compatibility

TechnologyPlatformStatus
NVDAWindows / FirefoxTested each release
JAWSWindows / ChromeTested periodically
VoiceOvermacOS / SafariTested each release
VoiceOveriOS / SafariTested each release
TalkBackAndroid / ChromeTested periodically
Dragon NaturallySpeakingWindowsSupported; report issues to us
Browser zoom & OS magnificationAllSupported to 400%
High contrast / forced coloursWindowsSupported

9. Report an accessibility barrier

If something on our site or platform is difficult or impossible for you to use, please tell us. We treat accessibility barriers as defects.

Helpful detail if you have it: the page address, what you were trying to do, your browser and assistive technology, and what happened instead.

What we commit to:

  • Acknowledgement within 2 business days.
  • An assessment and a plan within 10 business days.
  • A workaround offered immediately where a fix will take longer.
  • Blocking barriers prioritised into the current sprint, not the backlog.

10. Alternative ways to access our services

If any part of our platform is not usable for you, we will provide the same service another way at no additional cost:

  • Complete bookings, orders or payments by telephone with a support agent.
  • Receive documents in an alternative format — large print, plain text, tagged PDF or accessible HTML.
  • Arrange consultations by audio only, with a human interpreter or with a carer present.
  • Have a nominated representative act on your behalf, once identity and authority are verified.

11. What we are working on

  • Full text equivalents for every canvas diagram, so structure is available without sight.
  • Card-based responsive layouts to replace horizontally scrolling tables on small screens.
  • Re-issuing legacy PDF exports as tagged, accessible documents.
  • Expanding automated coverage to include focus-order and reading-order assertions.
  • A second independent audit covering the clinical consultation flow end to end.

This statement is reviewed at least annually, and whenever a significant change is made to our platforms.