Accessibility statement
Last updated: 13 August 2026
The honest position: the written pages of this site are in reasonable shape, and the timetable editor itself is not. It cannot currently be operated without a mouse or trackpad. This page sets out exactly what works, what does not, and what you can do in the meantime.
No conformance claim
This tool does not currently conform to WCAG 2.1 Level AA, and it would be misleading to display a badge saying otherwise. The specific failures are listed below rather than summarised away. If you need a timetable and cannot use the editor, the workarounds section describes a route that does not involve the grid at all.
What works today
- Reduced motion is respected. If your system is set to reduce motion, all transitions and smooth scrolling are switched off.
- The written pages are keyboard accessible. About, privacy, terms, contact and the documentation pages are ordinary semantic HTML — headings, lists, tables and links, navigable in reading order.
- Text scales. The layout uses relative units and reflows down to narrow viewports, so browser zoom and larger default font sizes work without content being cut off.
- Language is declared. Every page sets its language correctly, so screen readers use the right pronunciation rules — including on the Spanish, German, French, Korean and Dutch versions.
- Colour contrast on text is high: dark navy on off-white for body copy throughout.
- Native controls where they exist. Times use real
<input type="time">fields, so your platform's own time picker and its accessibility behaviour apply. - Esc closes dialogs.
- Events carry their text. Titles, times and notes are real text in the grid, not baked into an image, so colour is never the only way to tell two events apart.
What does not work
The grid cannot be used with a keyboard
Empty time slots and placed events respond to clicks, but they are plain elements that cannot receive keyboard focus. There is no way to tab to a slot and press Enter to add an event there, and no way to reach an existing event to edit or delete it. This is the most serious problem on the list.
Moving an event requires a pointer
Dragging is implemented with pointer events only. There is no keyboard equivalent for nudging an event to a different time.
Form fields are not properly labelled
The dialogs show visible text labels beside each field, but those labels are not programmatically associated with their inputs. A screen reader will announce that there is a text box without reliably announcing what it is for.
Dialogs are not announced as dialogs
The Add event and Settings panels are not marked up as dialogs. Focus is not moved into them when they open, is not trapped inside them while they are open, and is not returned to the triggering button when they close. Screen reader users get no announcement that a dialog has appeared.
The grid has no structure for screen readers
Visually the timetable is a table of days against hours. Underneath it is a set of nested containers with no row or column semantics, so a screen reader cannot say which day or which hour a given event sits in.
No skip link
There is no "skip to content" link, so keyboard users pass through the masthead and toolbar on every page.
If the editor does not work for you
The most reliable route today avoids the grid entirely:
- Use the Add event button and its dialog to enter each event. The dialog is keyboard operable.
- Adjust times by reopening an event rather than dragging it.
- Export CSV for an accessible, structured version of the timetable, or JSON if you want a backup you can re-import later.
Because the JSON format is fully documented, a timetable can also be generated with a script and imported, bypassing the interface altogether. The structure and field reference are on the export formats page.
What is being done
These items are on the list in roughly this order, worst first: making slots and events focusable and operable by keyboard, associating labels with their fields, giving the dialogs proper dialog semantics and focus handling, adding grid semantics for screen readers, and adding a skip link.
Each will appear in the changelog with a date as it lands, and this page will be revised at the same time. No timetable is promised, because promising one and missing it would be worse than saying plainly that the work is outstanding.
Telling us about a problem
If you have hit a barrier that is not described here — particularly with a screen reader, voice control or switch access, none of which have been tested properly — please describe it through the contact page, including the assistive technology and browser you are using. Accessibility reports are treated at the same priority as data loss, which is the highest band on the known issues list.