Accessibility

Accessibility

Keyboard-first accessibility details for GPTool.

GPTool is designed around a keyboard-first accessibility baseline.

The current extension focuses on predictable keyboard use, visible focus, clear panel state, and practical alternatives to pointer-only actions. It is intended to be usable without a mouse for the main project-management flows inside the GPTool panel.

Overview

  • GPTool can be opened from the browser-level extension shortcut, not just by clicking the toolbar icon.
  • The in-page launcher exposes an accessible name and expanded state.
  • Focus moves into the panel when it opens and returns to the launcher when it closes through keyboard interaction.
  • Menus, modals, and status messages manage focus deliberately instead of leaving it ambiguous.
  • Appearance options include:
    • Brushed metal
    • High contrast light
    • High contrast dark

Keyboard Shortcuts

  • macOS: Command+Shift+Y
  • Windows, Linux, ChromeOS: Alt+Shift+P

These shortcuts use the browser-managed extension command. They open, focus, or toggle GPTool without relying on a ChatGPT page-level keyboard listener.

Panel Navigation

  • Tab and Shift+Tab move through launcher controls, toolbar controls, search, visible tree rows, row action buttons, settings controls, and modal actions.
  • Escape closes the GPTool panel when focus is inside it.
  • Search is the primary entry point once the panel opens.

The panel keeps focus movement explicit and visible rather than depending on hidden hover states.

Tree And Project Navigation

The main project browser uses a tree pattern with an active row model:

  • only the active row is in the main tab sequence
  • the active row’s actions button is also reachable
  • folder disclosure remains a separate button

Supported keyboard behavior:

  • Enter
    • root row: return to the top-level GPTool view
    • folder row: open that folder view
    • project row: open that project
  • Space
    • folder row: expand or collapse
  • ArrowUp / ArrowDown
    • move between visible rows
  • ArrowRight
    • expand the focused folder
  • ArrowLeft
    • collapse the focused folder, or move focus to its parent row
  • PageDown / PageUp
    • page the list and move focus with it
  • Shift+F10 or ContextMenu
    • open the row actions menu for the focused item

Double-click is available for some folder-open behavior, but the keyboard path does not depend on double-click.

Row menus provide the keyboard alternative to pointer-first actions such as move, unfile, reparent, and delete.

Current menu behavior:

  • opening a menu moves focus to the first enabled item
  • disabled items are skipped by keyboard focus
  • ArrowUp / ArrowDown move between enabled items
  • Enter or Space activates the focused item
  • Escape closes the menu and restores focus to its trigger
  • moving focus outside the menu closes it

Dialogs And Recovery Flows

GPTool uses dialog semantics for confirm, input, and picker flows.

  • input dialogs focus the text field automatically
  • confirm and picker dialogs focus a useful action first
  • Escape cancels and closes the dialog
  • closing a dialog restores focus to the opener when possible

This applies to operational flows such as folder changes and backup import or restore tasks.

Focus, Status, And Readability

  • Visible focus styling is preserved across launcher, toolbar, tree rows, menus, settings, and dialogs.
  • Status output uses live regions for lightweight action feedback.
  • Busy-state messaging is surfaced through a dedicated live status surface.
  • High contrast light and high contrast dark appearances are available in Settings for users who prefer a flatter, stronger-contrast presentation.

Current Scope And Limits

GPTool’s current accessibility baseline is keyboard-first.

That means GPTool currently aims to support:

  • keyboard opening and closing
  • predictable focus movement
  • keyboard navigation through the tree
  • keyboard access to menus and dialogs
  • visible focus and stronger contrast options

It does not currently claim:

  • full screen-reader certification
  • a separate keyboard drag-and-drop mode
  • exhaustive WCAG audit coverage for every browser and host-page variation

Where drag-and-drop exists, the keyboard-equivalent path is provided through row menus rather than a separate drag interaction model.