Accessibility

Software that some of your staff or customers cannot use is unfinished software. We treat accessibility as part of the build rather than a remediation project, and we would rather state honestly where we fall short than claim full conformance.

This site is partially conformant with WCAG 2.2 Level AA: most of the standard is met, with the exceptions listed in section 03.

• Keyboard access. Every interactive control — the tab sets, the pager, form fields, links — is reachable and operable by keyboard, in a logical order, with a visible focus ring. Tab sets move with the arrow keys. A skip link is the first thing in the tab order on every page.
• Contrast. Body text and interface labels are tested against the 4.5:1 minimum, and large text against 3:1. The palette's faintest grey is reserved for rules and dots and is never used for text.
• Motion. The promise, walkthrough and other-trades tab sets do not advance on their own; each shows its first item until you choose another. The hero pager and the small animations inside the mockups do run, and a Pause motion button in the hero stops all of them at once. Under a reduced-motion preference nothing advances at all, whether set before you arrive or changed while you read: the one clock behind the page is frozen, the pager shows its first slide, and the mockups hold their finished state.
• Structure. Real headings in order, landmark regions, and form labels tied to their inputs rather than placeholder text alone.
• Zoom and reflow. Layouts reflow to 400% zoom and down to 320px width without horizontal scrolling or clipped content.
• Text. No text baked into images, so it scales and can be read by a screen reader.

Stated plainly, because a page claiming perfect accessibility is usually wrong:

• Live regions. The animated mockups change content without announcing it to assistive technology. They are illustrative rather than functional, so no information is lost — but the markup should say so more clearly than it currently does.
• Dense data in the mockups leans on colour for status. A text label accompanies colour in every case, so nothing depends on colour alone, but the visual weight is carried by it.
• The mockups are illustrations. Their tables and calendars are laid out as grids rather than marked up as data tables, and on a narrow screen the densest of them scroll sideways inside their frame. Nothing in them is information you need; the text beside each one says what it shows.
• Testing coverage. We test with keyboard, zoom, contrast tooling and VoiceOver. We have not yet completed a full audit with JAWS or Dragon.

For client projects, accessibility is part of the scope rather than an add-on. In practice that means semantic markup, keyboard operability, tested contrast, labelled forms with errors described in text, and touch targets sized for real hands.

Where a client’s sector carries a legal obligation — public sector procurement, healthcare, education — we will say so during scoping and agree the conformance target in writing. Where a project inherits an inaccessible third-party component, we will tell you rather than quietly shipping it.

If you hit a barrier on this site or in software we built, email hello@nexusmind.dev with the page, what you were trying to do, and the assistive technology or browser you were using if you know it. A description in your own words is completely sufficient.

We aim to acknowledge within 2 business days and to fix or give you a timeline within 10. If a fix will take longer, we will tell you what the workaround is in the meantime.

If our response does not resolve the problem, you can escalate to the relevant authority in your jurisdiction — for example an equality or human rights commission, or the body responsible for enforcing accessibility regulations where you live. We would much rather hear from you first and fix it.