Accessibility

Last updated 18 August 2026.

What this covers

This statement covers the marketing site at qrthatlasts.com and the application at app.qrthatlasts.com, which is where you make and manage codes. It does not cover the checkout, which is hosted and run by Paddle, or the pages of anybody whose site a code points at.

We are a private company rather than a public sector body, so the Public Sector Bodies Accessibility Regulations 2018 do not apply to us. This statement is voluntary. The Equality Act 2010 does apply to us, and so does the plain fact that a QR code on a museum wall is read by whoever is standing in front of it.

How accessible we think this is

Partially conformant with WCAG 2.2 level AA. Parts of both sites meet it and parts do not. The parts we know about are listed further down, with what we intend to do.

We have not had an external audit, and nobody has issued us a certificate. If you need a formal accessibility conformance report for a procurement process, ask and we will tell you honestly what it would take and how long it would be before we could produce one worth reading.

What we have checked, and how

Checked on 18 August 2026, by hand, in a desktop browser:

• Keyboard. The sign-in and account-creation forms were walked through with the Tab key alone. Every control can be reached and used, in the order it is written on the page, and none of them traps the focus.
• Visible focus. Whatever the keyboard is on draws a two pixel outline, offset by two pixels so it is not swallowed by the control it surrounds. It was measured rather than eyeballed: the two blues we use come out at 5.2 to 1 in the application and 6.5 to 1 on this site, against the page behind them, where the standard asks for 3 to 1.
• Field labels. Signing in, creating an account, asking for a password reset link, and entering a code we have given you all have a label on the screen that stays there while you type. A label that is only a placeholder disappears at the first keystroke, and a screen reader reads the field as nothing at all.
• Movement. Everything that moves on the marketing site is behind a check for the reduced motion setting in your operating system. With it on, nothing animates, and the page renders in the state the animation would have finished in.
• Without JavaScript. The content of the marketing pages is in the HTML the server sends. Nothing is faded in from nothing, so a page with scripts blocked is a page you can read.
• Language and structure. Both sites declare British English at the root, and the pages checked have one first-level heading and put their content inside a main landmark with the navigation and the footer outside it.

What we know is not right yet

• There is no skip link on either site. Somebody using a keyboard or a screen reader has to go through the header and the navigation on every page before reaching the content. This fails WCAG 2.4.1. It is a small change and it is the next one we are making.
• Two forms inside the application still label their field with placeholder text alone: setting a new password from a reset link, and entering a second-factor code. Both fail WCAG 1.3.1, 3.3.2 and 4.1.2. The rest of the forms a customer meets have been fixed.
• We have not checked colour contrast on every combination. The palette was designed against the standard and the main text and background pairings pass, but there are small grey captions and disabled controls we have not measured one by one.
• The staff console has not been checked at all. No customer can reach it. It is listed here because leaving it out would make this statement look more complete than it is.
• Artwork you download is artwork. An SVG, EPS or PDF of a QR code is a picture for a printer. It carries no text layer and no tagging, and it is not a document in the sense the standard means. What you print it next to is where the accessible version of the information belongs, which is worth thinking about before the print run: a code with no readable address or plain text beside it is unusable to anybody who cannot scan it.

What we have not tested

Said plainly, because a statement that lists only what passed is not worth reading:

• We have not tested with a screen reader in the hands of somebody who uses one daily. Our checks are the accessibility tree and the markup, which is not the same thing.
• We have not tested with voice control, with a switch device, or with screen magnification above 200 per cent.
• We have not run a full automated audit across every page, and we would not claim much from one if we had.
• We have not tested on mobile screen readers.

None of that is a reason to wait before telling us something is wrong. The fastest route to a fix is somebody who hit the problem describing what happened.

Telling us about a problem

Write to hello@qrthatlasts.com and say what you were trying to do, what happened, and what you were using. We aim to reply within five working days, and we will tell you whether we can fix it and roughly when, rather than thanking you for the feedback and going quiet.

If you cannot use part of the product because of something on this page, tell us that too. We would rather do the thing by hand for you while we fix it than leave you stuck.

If you are not happy with how we respond, the Equality Advisory and Support Service takes complaints about how a business in England, Scotland or Wales has treated a disabled customer.

How this statement was prepared

Prepared on 18 August 2026 by the person who made the changes it describes, using manual checks in a desktop browser and a read of the markup. It was not prepared by an outside auditor. It will be reviewed when the skip link and the two remaining forms are done, and the date at the top will change when it is.

Related reading: our privacy notice, our terms, and what we claim and how to check it. If you are already a customer, the same points apply inside the application.