Skip to content
LUNTA

Accessibility

How this site is built to be used, and what we have not had checked.

Most accessibility statements assert a standard and stop there. This one names the target, says plainly that the assessment behind it is our own rather than an auditor’s, lists the measures you can check in this site’s own markup, and states where we already know it falls short.

If something here fails you, the last section is the part that matters: one address, a reply within two working days, and either a fix or a plain answer about why not.

Conformance status

A conformance claim has two halves — the standard a site is built to, and the strength of the evidence that it gets there. The second half is the one usually left out.

What this statement covers
This website, at every page under this domain. It does not cover systems we build inside a client engagement; the accessibility requirements for those are whatever that engagement’s statement of work sets, and they are agreed there rather than inherited from this page.
The standard
WCAG 2.2 Level AA. Every measure below is stated against it, and where a measure exists because of a specific criterion — focus that the sticky header would otherwise obscure, reflow at 400% zoom — the criterion is named so you can check the claim rather than take it.
Who assessed it
We did. This is a self-assessment, carried out against the code by the people who wrote it. No independent accessibility audit has been performed and no third party has certified this site. That is the same position our security page publishes for the certifications we do not hold, for the same reason: you should learn it here rather than in week three of a procurement review.
What happens when that changes
If an external audit is commissioned, its findings are published on this page — including the ones we fail — and this statement is rewritten around them. We are not putting a date on it, because a roadmap date nobody is accountable for is exactly the kind of claim this site exists to avoid.
What the automated score is worth
Automated audits run against the deployed site have reported 100 for accessibility on every page measured so far — a handful of representative routes, not yet all of them; the measured set and the method are recorded alongside the code. We publish that with both limits attached: coverage, and the deeper one — tooling of this kind can only decide the criteria a machine can decide, which is a minority of WCAG and none of the ones that turn on judgement, like whether a heading describes its section or an error message helps. Treat the score as a floor, not as conformance.

Structure, keyboard, and zoom

Each item here is a decision in the markup rather than an intention, so each one can be checked in a browser in about a minute without asking us for anything.

Content is in the page, not behind a script
Collapsed sections use the browser’s native disclosure element rather than a scripted accordion, so the text inside them is in the delivered HTML whether the interaction ever runs or not: it is findable with find-in-page, it is available to anything that reads the page, and it prints. The pages are statically generated, so what a page says does not depend on a script arriving.
One table treatment, applied everywhere a table appears
Every table on the site is rendered by a single component, so the same guarantees hold wherever one is used: the scroll container is a named, keyboard-focusable region, so a wide table can be panned without a mouse; the first cell of every row is a row header; a caption states what the table contains; and below the phone breakpoint the table stacks into blocks with each column name restated above its value — except the row’s own name, which leads its block — rather than running off the right edge. The cost of that stacking is in the limitations below.
The skip link moves focus, not only the viewport
The first stop in the tab order is a skip link to the main region, and its target takes focus rather than merely scrolling into view. A skip link that moves the viewport alone leaves the next keypress back where it started, which is the failure that teaches people to stop using skip links.
Two navigations carry two names
The desktop navigation and the mobile menu are separate landmarks with distinct accessible names. Two landmarks sharing one name is a navigation a screen-reader user has to disambiguate by trial, and it is the kind of defect no automated check will ever report.
The menu is reachable at 400% zoom
At 400% magnification, and on a landscape phone, the mobile menu is taller than the viewport it opens into. It scrolls inside the space below the header instead of pinning its overflow permanently off-screen, so every item stays reachable — the condition SC 1.4.10 sets for reflow at that magnification.
Pages print as documents
The site ships a real print stylesheet rather than leaving the browser to guess: paper colours with genuine contrast, table headers repeated across page breaks, headings kept with the text they introduce, the on-page contents nav dropped, and every disclosure printed open — because a failure path a reader cannot see on paper is the one thing this site must never ship. Print is an access route, not a courtesy.

Colour, focus, and motion

The palette is small and fixed, which makes the contrast question answerable once in a test rather than argued page by page.

Contrast is a test, not a judgement
The colour contract is enforced in the test suite, and it covers the three places this normally goes wrong. It checks both colourways against the tokens the stylesheet actually declares, so editing a palette value fails the suite before it can ship. It checks the translucent sticky header composited over the worst underlay it can sit on, which is where a solid-pairing check is blind — at its previous opacity the light colourway flattened to 3.86:1. And it checks opacity-modified text, which is how a muted heading once shipped at 2.9:1 while every solid pairing passed. Text is held at 4.5:1, and non-text — borders, the focus ring — at 3:1.
One focus ring, on everything that takes focus
There is a single focus style on the site, applied by one rule rather than restyled control by control: a two-pixel outline, offset from the element, following the element’s own radius. It uses the one accent colour this site reserves for arrival, which is what makes it read as “you are here, now” under a keyboard. The single element that suppresses it is the main region, which is not a control and receives focus only because the skip link sends it there.
Focus is protected from the sticky header
The header occupies the top of the scrollport on every page, and a focused link scrolled underneath it is what WCAG 2.2 added SC 2.4.11 for — focus obscured, not merely inconvenient. The scrollport is inset by the header’s exact height, so a control reached by tabbing backwards up a page stops below it rather than under it. Anchor offsets elsewhere are stated net of that inset, because the two properties sum.
The colourway toggle says what it did
Which icon and which label the toggle shows is decided in the stylesheet, so the delivered markup is already correct in either colourway with nothing to reconcile after load. A style change announces nothing, though, so the button also writes its result into a status region: pressing it is met with “Light colourway on” or “Dark colourway on” rather than with silence.
Motion is behind a preference, then behind it again
Every animation on the site is written inside a reduced-motion no-preference query, so a visitor who has asked their system for less motion is never shown one; a global rule collapsing animation and transition durations sits behind that as a second net for anything added later. Smooth scrolling is dropped under the same preference. Nothing loops, flashes, or plays on its own.
Type arrives without moving the page
Both faces are self-hosted and served from this origin, with a metric-matched fallback for the text face, so the swap when the webfont loads does not reflow what you are reading. Layout shift is an accessibility problem before it is a performance score — it moves the target out from under a pointer, a magnifier, or a finger.
Nothing is loaded from anyone else
There is no third-party script, tag manager, or font CDN on any page — and no accessibility overlay. Overlays are the usual shortcut at this point, and we will not fit one: they reinterpret a page a visitor’s own assistive technology has already interpreted, and they let a site announce conformance without changing anything underneath it. What is described above is the page itself.

Known limitations

Set out in the same typeface as everything above, on the reasoning our security page follows: a supplier page is only worth reading if it is capable of losing points.

This is a self-assessment, and that is the weakest part of it
Nothing on this page has been verified by an independent auditor, and none of it is a certification. We are confident in the individual measures, because they are enforced in code and in tests. We are less confident in the coverage: a self-assessment is best at finding the failures you already knew to look for, which is precisely why the section below asks you to tell us about the ones we did not.
Table semantics change on small screens
Below the phone breakpoint our one table treatment stacks into blocks, with each column name restated above its value and the row’s own name leading its block unlabelled. That restatement is a visual one: at that width the row-and-column relationships a table exposes to assistive technology are no longer available, so a reader on a narrow viewport gets a labelled list rather than a table. Every value is present, but the association is weaker than it is on a wider screen or on paper.
One tab stop that does nothing on a wide screen
The table scroll region keeps its tab stop at every width, including the widths where the table fits and there is nothing to pan, so a keyboard user meets one stop that does not do anything. Removing it would require measuring every table on every resize in the browser; we judged an inert stop the smaller cost. It is still a cost, and it is one we impose rather than pay.
No published assistive-technology test record
We do not publish a matrix of the screen readers, browsers, and platforms this site has been used with, because we would rather publish nothing than publish a list broader than what was actually done. If a specific combination matters to your organisation, ask, and we will tell you plainly what we have and have not tried.

If something here fails you

Write to us and say what happened — the page, what you were trying to do, and the browser or assistive technology you were using, if you can. You do not need to name a criterion or diagnose anything; a sentence describing what went wrong is more useful than a standards reference. We reply within two working days, tell you what we can fix and roughly when, and where a fix will take time we will say so and get you the same content another way.

hello@lunta.exampleOther ways to reach us

Last reviewed July 2026.