Keyboard and accessibility

Everything you can do with a pointer has a keyboard equivalent, which is what WCAG 2.5.7 asks of any drag interaction.

Keys

The timeline is one tab stop. Events are tab stops of their own.

Where	Keys	Does
Grid	Arrow keys, Home, End	Move the slot cursor
Grid	Shift + ← / →	Extend a selection. Esc drops it
Grid	Enter or Space	Select the slot or range (calls onSlotSelect, or creates an event)
Grid	Page Up / Page Down	Show the previous / next period, like the toolbar arrows. The cursor stays on the same column
Event	Enter	Open its details
Event	Space	Pick it up. Arrows move it, Space drops it, Esc cancels
Picked-up event	Shift + ← / →	Move the end edge: longer or shorter (needs onEventResize)
Picked-up event	Shift + Alt + ← / →	Move the start edge: earlier or later (needs onEventResize)
Group header, resource	Alt + ↑ / ↓	Move it one place (needs onGroupReorder or onResourceReorder; see Reordering)

Keyboard moves follow the same rules as the mouse: eventOverlap and isValidDrop apply, a rejected place is announced and shown in red, and an event cannot leave the visible range. After a drop, focus returns to the event that moved. Resizing from either edge reports through onEventResize with the new start and end, and an event cannot be made shorter than one slot (one day in the date views).

Paging

Page Up and Page Down with the grid focused do what the toolbar arrows do: they show the previous or next day, week, month, quarter or year, and call onDateChange and onRangeChange as the buttons do. The cursor stays on the same column, so in the week view it moves from Tuesday to the next Tuesday and in the day view it keeps its time of day. When the new period has fewer columns (31 days to 28) it lands on the last one. It is scrolled into view, and a screen reader hears where it is: “Moved to Ann, Thursday, October 8, 11:00 AM.” (labels.announce.pagedTo). The period title in the toolbar is a live region too.

Keys with Ctrl, Alt, Meta or Shift are left to the browser (Ctrl + Page Down switches tabs). While an event is picked up the keys do nothing, because it may not leave the visible period: drop it, page, and pick it up again. Paging does not mirror in a right-to-left layout.

Why these keys

• Page Up and Page Down are free in a grid that holds focus: they used to scroll the page, and are now the period keys. The arrows, Home and End keep scrolling the cursor into view.
• Shift + Alt + arrow extends Shift + arrow, which already moved the end. Screen readers use their own modifier for their commands (Insert or CapsLock for NVDA and JAWS, Control + Option for VoiceOver), and the browser’s Alt + ← (back) is only taken while an event is picked up.
• In a right-to-left layout the arrows mean what they show: ← moves forward in time, so Shift + Alt + ← moves the start edge later.

Semantics

• The timeline is role="grid" with rows and gridcells. Every cell has a name such as “Ann, Tuesday, March 10, 9:00 AM”, and today is marked with aria-current="date".
• Events are buttons with a label that includes the title, the resource and the time range.
• The toolbar buttons and view selector have names, and the period title is a live region.
• A polite live region announces picking up, moving, rejected places, dropping and selecting. A hidden description explains the keys. Set the grid name with ariaLabel.

What is tested, and what is not

• Keyboard flows are covered by automated tests, and the rendered scheduler is audited with axe-core in CI with no violations.
• It has not been tried with NVDA, JAWS or VoiceOver. Treat it as built to the patterns, not as certified.
• Colour contrast is up to you: event colors are your data, and axe cannot check contrast in a test environment.
• Announcements and the keyboard instructions come from labels, so they can be translated: see Languages and clocks. The translations in these docs are examples, not reviewed by native speakers.

If you hit a problem with a screen reader, please open an issue with the reader and browser you used.