Accessibility

What we have done, and what we have not

Most accessibility statements are a paragraph saying a company cares and a link to a standard. This one lists what is actually true, including the gaps, because a volunteer deciding whether they can use this needs facts rather than a commitment.

Seeing

  • Body text starts at 18 pixels on a phone and 19 on a larger screen. Most business software starts at 14 or 16.
  • A control in the header and footer of every page takes it to 21 or 24 pixels, and the whole layout scales with it rather than just the paragraphs. The choice is remembered on the device.
  • Body text meets or exceeds WCAG AA contrast throughout, and most of it meets AAA. Nothing important is carried by colour alone — every warning has words.
  • The page also respects your browser's own zoom and your operating system's text size, and does not break at 200%.
  • Every image and icon that carries meaning has a text description. Decorative marks are hidden from screen readers rather than read out as noise.

Tapping and typing

  • Nothing you have to press is smaller than 56 pixels on its short edge. The WCAG AAA guidance is 44. At the largest text setting ours grow to 64.
  • Controls are spaced so a near miss does not press the one next to it, and double-tap zoom is disabled on buttons so an impatient second tap does not zoom the page.
  • Every form field has a visible label above it, not a placeholder that disappears when you start typing.
  • Text inputs are at least 16 pixels, which stops iOS zooming the whole page when you tap into one.
  • Nothing is drag-only, swipe-only or hover-only. Every action has a button.

Keyboard and screen reader

  • Everything is reachable and operable with a keyboard alone. The focus outline is four pixels thick and high contrast, and it is never removed.
  • A skip link goes straight to the main content, which matters a great deal when a page has a long navigation.
  • Headings run in order, landmarks are real elements, and forms are properly associated with their labels and errors.
  • Things that update after you press a button announce themselves.

Motion, connection and old devices

  • If your device asks for reduced motion, Laevo has essentially no motion at all.
  • Pages are rendered on the server and send very little to the device, so Laevo works on an old phone and on the sort of wifi a community hall has.
  • The whole site works with JavaScript switched off or still loading — including the menu, which is a plain disclosure element rather than a script.

What we have not done yet

  • No offline mode. You need a connection to save a visit. This is the biggest gap and we are not going to dress it up.
  • English only, for now. Spanish is the next one. Until then, plain short sentences at least translate well in a browser.
  • No formal third-party audit. We have tested against WCAG 2.2 AA ourselves and with volunteers. We have not paid for an independent audit, and we would rather say that than imply a certificate we do not have.
  • No voice input beyond what your device provides. Dictation into our fields works because your phone does it, not because we built it.

If something here is not working for you

Tell us and we will fix it, and we will tell you when it is fixed. An accessibility problem is a bug and goes to the front of the queue — not into a backlog labelled improvements.

Tell us what is not working