Accessibility

1Our Commitment

kibbu is for people who run other people’s infrastructure, and they do that work with whatever tools suit them: a keyboard and no mouse, a screen reader, magnification, a browser zoomed past 200%, an operating system told to keep motion to a minimum. This site is meant to work in all of those. We treat an accessibility defect the same way we treat any other defect, which is to say it gets fixed rather than explained.

2The Standard We Aim For

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. That is the level most public bodies and standards regimes point at, and it is the one we hold new work to.

Aiming is not the same as arriving. We do not claim this site is fully conformant, and we do not claim it is free of accessibility problems. What we claim is that the measures below are actually implemented, that the site is tested, and that we fix what we find.

3What Is Built In

Accessibility here is in the pages themselves rather than in an overlay or a widget bolted on top. We do not use an accessibility overlay. They sit between the reader and the page and often break the assistive technology the reader already has set up the way they want it.

• Native HTML doing its own job: buttons are buttons, links are links, the FAQ is a real disclosure element. ARIA is used where it adds something, not on top of elements that already carry the meaning.
• Every interactive element is reachable and operable by keyboard, in an order that follows the page, with a focus indicator you can see on both the light pages and the dark plates.
• A skip link at the top of every page, so the header is one keypress to get past rather than five.
• A navigation menu on small screens that opens and closes from the keyboard, holds focus while it is open, closes on Escape, and hands focus back to the button that opened it.
• One first-level heading per page and no skipped levels, so the document outline is a usable way to move around.
• Form fields with real labels, errors announced when they happen and tied to the field they belong to, and focus moved to where the reader needs to be next.
• Sliders that announce the value they represent rather than the raw number the control happens to store.
• Text that meets the contrast the standard asks for against the surface behind it, and status shown by words as well as colour. The green and orange this site uses for local and cloud work never appear without a word beside them.
• Images that carry meaning have alternative text; images that are decoration are hidden from assistive technology rather than described.
• Layout that survives zooming to 200% and beyond, and text that reflows rather than being clipped.
• Motion that stands down when your system asks it to, through the reduced-motion setting your operating system already has.

4How We Test

Automated checks run against the public pages of this site on every proposed change, at both a phone width and a desktop width, using an open-source accessibility engine configured for WCAG 2.2 Level AA. A change that introduces a detectable failure does not get merged. Linting rules catch a further class of problems while the code is being written.

Automated testing finds perhaps a third of what matters, so it is not the whole of it. We also work through the main pages by keyboard alone, check that focus is always visible and never trapped, read the pages in the order assistive technology would, and check the layout at 200% and 400% zoom.

5Known Limitations

Some things on this site are not where we want them yet, and it is more useful to name them than to leave you to find them.

• The cookie consent banner is provided by a third party. Its markup is theirs, not ours, and our ability to change it is limited by the plan we are on. If it gets in your way, tell us and we will take it up with them or replace it.
• Articles in the knowledge hub are written in Markdown, so heading order and link text there depend on the author getting it right rather than on the template.
• We test with the current versions of the major browsers and screen readers. Older combinations may behave differently, and we do not test every one.

6Telling Us Something Is Wrong

If any part of this site is hard or impossible to use, please write to hello@kibbu.io. It helps if you can tell us the page, what you were trying to do, and what you are using to read the site, but do not let a missing detail stop you from writing. A one-line message is enough.

We will acknowledge your message, investigate it, and tell you what we find and what we intend to do about it. If a fix is going to take a while, we will say so and give you a way to get at whatever you needed in the meantime.

If you would rather ask about how the site handles your data, that is the Privacy Policy, and the cookies it can set are in the Cookie Policy.

7Changes To This Statement

This page changes when the site does. If the measures or the limitations above stop being accurate, we update them and move the date at the top.