The app should be usable by the people who need it.

What is in place

• Keyboard access

  Core navigation, dialogs, menus, and the task list are operable with a keyboard. Visible focus styles are kept instead of removed.

• Readable contrast

  Text and controls are designed against the active theme, including light, dark, and custom palettes. Themes are checked for low-contrast combinations.

• Reduced motion

  Decorative motion is restrained. Where an animation is present, it is short and does not block the task.

• Clear targets

  Interactive controls keep a usable size and spacing, with labels for icon-only buttons.

How the interface is built

The site uses semantic landmarks, one main heading per page, labelled form fields, and buttons with accessible names. Dialogs trap focus and return it when closed. The skip link moves focus past the header to the main content.

Colour is not the only signal for state. Selected items, errors, and completed tasks also change text or shape. The theme switcher respects the system preference when “system” is selected.

Known limitations

• New themes are reviewed manually; an unusual custom palette can still produce a weak contrast pair.
• The desktop shell inherits browser accessibility features, but native OS-level screen reader behaviour varies by platform.
• Older releases of the browser extension may not include the latest focus fixes. Update from the Chrome Web Store.

Feedback is part of the work

Accessibility is not a one-time checklist. If a shortcut, a colour pair, or a screen reader flow does not work for you, that is a product issue worth fixing. Send the details and we will treat it like any other bug.