Accessibility statement

Our commitment

We want everyone to be able to use this website and our software, regardless of how they access it — with a screen reader, by keyboard alone, at a large text size, with reduced motion, or with a high-contrast display.

We treat accessibility defects as defects. They go into the same backlog as any other bug and are prioritised on the same basis: by impact on the people affected.

Conformance

This website aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA.

We state this as an aim rather than a certification. We have not commissioned an independent audit, and we would rather say so plainly than imply a level of assurance we have not paid for. Where we become aware of a failure, we record it below and fix it.

What we have done

• Semantic structure. Pages use real landmarks, a single meaningful heading hierarchy, and lists and tables marked up as such.
• Keyboard access. Every interactive control is reachable and operable from a keyboard, in a logical order, with a visible focus indicator. A skip link is the first focusable element on every page.
• Contrast. Text and interface colours are chosen to meet at least the 4.5:1 contrast ratio required for body text at level AA, in both the dark and light themes.
• Text sizing. Layout is built in relative units and reflows without loss of content or function when text is enlarged to 200%, and at a 320 pixel viewport width.
• Motion. Transitions are subtle by default and are suppressed entirely when the operating system requests reduced motion. Nothing auto-plays, flashes or moves without user action.
• Colour independence. No information is conveyed by colour alone — status indicators carry a text label as well as a colour.
• No script dependency. The site is static HTML and CSS. With JavaScript disabled, all content and navigation remain available; only the theme switch and the mobile menu toggle are affected, and the site falls back to the operating system’s colour preference and a full-width layout.
• Images and icons. Decorative graphics are hidden from assistive technology; meaningful graphics carry a text alternative.
• Language. The document language is declared as British English, and abbreviations are expanded on first use.

How we test

• Automated checks against WCAG success criteria as part of our build process.
• Manual keyboard-only passes through every page and interactive control.
• Screen reader passes using the platform screen readers on macOS, iOS and Windows.
• Verification at 200% and 400% zoom, and at a 320 pixel viewport width.
• Checks with reduced-motion, increased-contrast and forced-colours settings enabled.

Automated tools catch only a fraction of accessibility problems. The manual passes are where most real issues are found, and we do not treat a clean automated report as evidence of conformance.

Known limitations

We are not currently aware of any content on this website that fails WCAG 2.2 level AA. This section is kept here deliberately: if we become aware of a failure, it will be listed here with a description and a target date for fixing it, rather than quietly omitted.

Our products

The same standard applies to the software we publish. Accessibility support — screen reader compatibility, dynamic text sizing, keyboard operation and reduced motion — is part of the definition of done for a release, not a later addition.

Where a product has accessibility characteristics worth stating specifically, they are documented on that product’s page.

Feedback

If you encounter a barrier on this website or in one of our products, please tell us at developer@neomanera.co.uk. Describing what you were trying to do, what happened, and what you were using to access it helps us reproduce the problem quickly.

We aim to acknowledge accessibility reports within two working days and to tell you what we intend to do about the issue and when. If you need information from this site in an alternative format, ask and we will provide it.