Accessibility at Docket

• Partly supported

  Keyboard operation

  Every page opens with a skip link to the main content. Pressing n starts a new card, / jumps to search, ? lists the shortcuts, and Escape closes a dialog. A project card can be moved with keyboard controls and a menu instead of dragging, and a task's status changes from a menu in its detail dialog. No one has walked every flow with only the keyboard.

  Evidence

  • frontend/src/components/Layout.tsx and frontend/src/__tests__/Layout.navigation.test.tsx in the Docket repo: the skip link moves focus to the main content
  • frontend/src/hooks/useKeyboardShortcuts.ts: the n, /, ?, and Escape shortcuts, which ignore typing in fields and dialogs
  • README.md in the Docket repo describes keyboard alternatives to dragging in ScanCards, including Arrange, then Move to top
  • A keyboard-only walkthrough of every flow has not been recorded.

• Partly supported

  Screen reader landmarks and labels

  axe-core scans every route and finds no violations in names, labels, and landmark structure. It has not been tested with a screen reader, and Docket's README says so.

  Evidence

  • frontend/src/__tests__/accessibility.test.tsx in the Docket repo scans every route with vitest-axe, in the light theme, with a project and a task loaded
  • The README's accessibility section: no manual VoiceOver, NVDA, or JAWS audit has been done

• Partly supported

  Contrast in light and dark

  Both themes come from the Renkara design tokens, and a ScanCards muted-text contrast failure was found and fixed with a browser check. Docket's automated scan runs in a test DOM that does not measure color contrast, so there is no full-page contrast result in both themes.

  Evidence

  • The Docket commit titled Fix ScanCards muted text contrast with canonical browser proof
  • README.md in the Docket repo: title and summary fields remain readable in both themes

• Partly supported

  Reduced motion

  The ScanCards styles turn animation off when the system asks for reduced motion. The rest of the interface inherits the design system's motion settings, which Docket's own tests do not check.

  Evidence

  • frontend/src/features/scancards/scancards.css in the Docket repo has two prefers-reduced-motion blocks

• Partly supported

  Text resize and zoom

  Browser tests reproduce the layout at 200 percent zoom at two desktop widths and check that the workspace, task controls, and confirmation dialog stay usable. They simulate the layout and do not use the browser's own zoom menu, and enlarging text alone has not been tested.

  Evidence

  • frontend/e2e/docket-ui-cleanup.spec.ts in the Docket repo: 200 percent zoom reflow at 1,280 and 768 pixels, in Chromium

• Partly supported

  Mobile and touch

  The board and a task open at 320 and 390 pixels wide in both themes with no sideways scrolling and every control inside the screen. The other pages have not had the same check recorded.

  Evidence

  • frontend/e2e/docket-mobile-overflow.spec.ts in the Docket repo: board and task at 320, 390, and 1920 pixels in light and dark
  • README.md in the Docket repo: ScanCards supports 375 by 667 layouts

No WCAG conformance level is claimed for Docket. Its test suite runs automated checks, and no one has audited it against WCAG or tested it with a screen reader. Docket's own testing notes say manual VoiceOver, NVDA, and JAWS passes are still to be done.

• Structure

  A skip link, labeled landmarks (header, navigation, main, footer), one h1 per page, and headings that do not skip levels.

• Keyboard and focus

  Links and buttons are native elements, so they work from the keyboard. Focus is drawn as a visible ring, and the menu closes with Escape.

• Contrast

  Text meets 4.5 to 1 in both the light and dark themes, checked against the stylesheet by the test suite.

• Motion

  Transitions and animation switch off when your system asks for reduced motion.

• Small screens and zoom

  Layouts hold at 375 pixels wide with no sideways scrolling, text resizes with the browser, and touch targets are at least 44 pixels.

• Automated scan

  Every page is scanned with axe-core at 375 and 1440 pixels in light and dark, and the checks fail on any serious or critical violation. Automated tools find only part of the problems, so this is a floor, not proof.

• Images

  Every product screenshot has a text description and comes in a light and a dark version that follows your theme.

• Your theme choice

  The theme follows your system setting until you pick one with the button in the header.