1. Our commitment
We build to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — the international standard published by the W3C. It applies to Koha Cloud (the librarian panel and the public catalog), the Koha Certificate learning portal, which runs on Koha Cloud, and this website.
Accessibility is checked on every release, not once a year: a release that introduces a serious or critical barrier on a covered screen does not ship.
2. Where we conform today
Koha Cloud partially conforms to WCAG 2.2 Level AA. Partially means some parts do not fully conform to the standard. We have not yet completed a manual audit, so we make no claim of full conformance.
What we can show today, on every release:
- An automated scan with axe-core finds no serious or critical WCAG 2.2 A/AA violation on the covered screens — the public catalog home, search, record, sign-in and registration pages, the patron account, the librarian dashboard, the circulation desk, the cataloguing editor and every kind of data table — in light and in dark mode.
- A keyboard alone can check a copy out and back in at the circulation desk, sign in as a patron, place a hold and cancel it.
- Most pages start with a "Skip to main content" link — two known exceptions (the catalog home page and search results) are being fixed.
- Dialogs are named, keep focus inside while open, close with Escape, and return focus to the control that opened them.
- Text colours in every built-in dashboard palette and in the dark theme meet the 4.5:1 minimum, and this is checked by an automated test that reads the colours the application actually emits.
3. How we test
| Check | What it covers | When it runs |
|---|---|---|
| Automated scan (axe-core) | WCAG 2.2 A and AA rules that a program can decide, over the named screens | Before every release — a failure blocks it |
| Source checks | Icon-only buttons with no name, removed focus outlines, mouse-only click handlers, images with no alt text, zoom-blocking viewports | Before every release — a new instance blocks it |
| Keyboard-only browser tests | Circulation desk, patron sign-in, placing and cancelling a hold, dialog focus | With the end-to-end test suite |
| Colour tests | The muted text ramp, every dashboard palette, in light and dark | With the unit test suite |
| Manual audit with screen readers | What automation cannot judge: whether alt text means something, whether the order makes sense, what a screen reader says | Scheduled — see section 5 |
Automated testing finds roughly a third of real barriers. That is why the table above ends with a manual audit, and why this page does not claim more than the first four rows support.
4. What we know is not right yet
These are tracked, owned and counted by the same checks that gate each release; none may grow, and each can only be removed.
- Some icon-only buttons — edit, delete and close controls on secondary configuration screens — have no accessible name, so a screen reader announces only "button".
- Some search and filter fields remove the browser focus outline without drawing a replacement, so a keyboard user cannot always see where they are.
- A few controls respond to a mouse click but not to the keyboard.
- Form errors are announced when they appear, but are not yet programmatically tied to the field they describe.
- Screens outside the covered list have been checked by the source checks only, not scanned in a browser.
- Interactions that involve dragging have not yet been confirmed to have a keyboard or single-pointer alternative.
5. Screen readers and manual testing
We have not yet completed testing with screen readers, magnification, zoom and reflow, forced-colours modes and the other checks a person has to make. It is scheduled for completion by 15 December 2026: NVDA with Firefox and Chrome, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android, covering the circulation desk and the placing of a hold. Until it is done, the conformance report marks every criterion that depends on it as pending, rather than guessing.
6. What a library controls
A library chooses its own catalog colours, logo, pages and uploaded documents. We test the themes we supply. A library that changes colours, adds images or uploads files is responsible for the accessibility of that content — give images meaningful alternative text, keep text-on-background contrast at 4.5:1, and prefer accessible PDF or HTML for documents. Content from other publishers — embedded video, external databases — carries that publisher's own accessibility.
7. Tell us about a barrier
If something on our sites or in Koha Cloud is hard or impossible to use, tell us through the contact page: say what you were trying to do, the page, and the browser and assistive technology you use. A person reads every report and replies with what we will do about it. If you need information in another format, ask and we will provide it.
8. The conformance report
A full Accessibility Conformance Report — every WCAG 2.2 Level A and AA criterion, with how we evaluated it and its current status — is available on request through the contact page, in the standard VPAT 2.5 layout that procurement teams expect. This statement and that report were issued on 21 September 2026 and are re-issued every year, next by 21 September 2027, or sooner after a material change.