[falbany]

Bug

With a workflow modal open (any useModalA11y modal), pressing Tab could move focus to the app behind the modal — file list, scan/launch controls — where a stray Enter/Space would then act on files mid-workflow.

Root cause

The Tab half of the focus trap lived in the handler attached to the dialog element's onKeyDown. That handler only sees key events that bubble through the dialog. When focus sat on document.body — after a backdrop click, or once a focused node unmounted (re-render churn) — a Tab keydown targeted the body, never reached the dialog handler, and the browser's native traversal moved focus to the first tabbable element in document order: the app behind the modal. From there it never came back.

Fix

The trap now owns every Tab press through a window-level capture listener installed while the modal is open (useModalA11y, the shared hook — all six modals inherit the fix):

• Focus outside the dialog → preventDefault, pull focus back to the first (or last, with Shift) control inside.
• Tab from the last focusable → wraps to the first; Shift+Tab from the first → wraps to the last. Also covers focus resting on the dialog root itself.
• Focus mid-dialog → untouched; traversal between the dialog's own controls stays native (inputs, selects, roving-tabindex rows all keep working).
• One listener per open modal; for stacked dialogs the most recently opened modal's handler runs last and wins — nesting resolves in favor of the topmost modal.

The returned onKeyDown handler keeps only Escape; its Tab branch was now-redundant duplicate logic and is removed. No consumer changes needed.

Verification

• New src/utils/useModalA11y.test.tsx (6 tests) exercises the hook through a minimal fixture with an app button rendered behind the dialog: pull-back from body (forward + Shift), both wrap edges, repeated Tabs stay inside, and Escape routing unchanged.
• Full web suite 157 pass — all existing modal tests (Several modals lack focus trap / dialog semantics (Timer, Shortcuts, Barcode, Camera, args dialog) #62/WorkflowRunnerModal: initial focus lands on the close button on open #81/WorkflowRunnerModal: Escape handled twice (hook + window listener) - double abort on close #83 focus/Escape/initial-focus behaviors) unbroken.
• tsc + vite build clean; dist/ rebuilt and committed.

[falbany]

Follow-up commit 8e52d09 (same keyboard-navigation concern): while testing the trap, buttons that don't carry the .btn class — workflow step rows, context-menu items, header icon buttons — turned out to have no focus indicator at all, so keyboard focus landed on them invisibly.

Added a zero-specificity baseline rule in index.css: every interactive element (button, inputs, links, [tabindex], …) shows a 2px indigo outline on :focus-visible (WCAG 2.4.7). Elements that already handle focus locally via focus-visible:ring utilities keep their ring and suppress the outline — the rule only fills the gaps, so no existing visuals change.