Accessibility Statement

This statement covers the LevelSixLabs web application at levelsixlabs.com, including the public marketing pages and the signed-in application used by laboratory staff.

We are working towards WCAG 2.2 Level AA. We are a private supplier, so the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 apply to our customers rather than to us directly — but a university has to meet those obligations through the software it buys, so we treat them as ours in practice.

If your institution requires a completed EN 301 549 mapping or a VPAT before purchase, email us and we will complete your template.

• Keyboard navigation through the main application flows, including list pages where record names are real links rather than click-handlers on table rows
• A visible focus indicator on every interactive element, using :focus-visible so it appears for keyboard users without cluttering the mouse experience
• Dialogs, and the signed-in application's mobile navigation drawer, trap focus, close on Escape, lock background scrolling, restore focus to the control that opened them, and expose role="dialog" with aria-modal
• The public site's menu button is a disclosure rather than a drawer — it pushes the page down instead of covering it — so it does not claim to be a dialog and does not trap focus. It reports whether it is open, says what it controls, closes on Escape, and returns focus to the button
• Skip-to-content links on both the marketing site and the signed-in application
• Accessible names on icon-only controls, filter selects and form fields
• Semantic headings and landmark regions, so screen-reader users can navigate by structure
• A light and a dark theme, with colour utilities checked so that text does not disappear on either — enforced by an automated test that fails the build if a colour class only works on one theme

These are the things we know are not right yet. This list is deliberately specific.

• Around twenty less-frequently-used dialogs have not yet been migrated onto our shared accessible dialog component. The highest-traffic dialogs have been; the remainder may not trap focus correctly or announce themselves to a screen reader.
• We have not had an independent accessibility audit, and we do not yet run automated accessibility checks in our test suite.
• We have not carried out structured testing with screen-reader users. Our testing has been keyboard-first and developer-led.
• PDF and Excel exports are not tagged for accessibility. The same information is available as HTML in the application, which is the accessible route.
• Some data-dense tables (chemical inventory, booking calendars) are hard to use at high zoom or on a narrow viewport, even where they are technically navigable.
• QR code and print layouts are visual by nature; the underlying records they point to are fully navigable in the application.

If you hit an accessibility barrier, please tell us — including which page, what you were trying to do, and what assistive technology you were using if any. Email support@levelsixlabs.com. We aim to respond within one business day.

If you need information from LevelSixLabs in a different format, ask us and we will provide it.

• Migrating the remaining bespoke dialogs onto the shared accessible dialog component
• Adding automated accessibility checks to our continuous integration, so regressions fail the build rather than reaching customers
• Commissioning an independent audit ahead of general availability, and publishing the result here whether or not it is flattering

This statement was prepared on 14 August 2026 based on our own review of the service. It will be reviewed when the items in section 6 are completed, and at least annually.