Add Section and Add Widget canvas commands are not keyboard reachable

[vvallalta-code]

Summary

Contextual insertion commands such as Add section and Add widget are exposed only as pointer-hover controls. They are removed from sequential keyboard focus and are omitted from the toolbar shown when a canvas element is selected with the keyboard. A keyboard-only user therefore cannot perform the same insertion workflow as a pointer user.

This is the shared Paperbits root cause behind two downstream Azure API Management developer portal accessibility reports:

• ADO 30046849: Page sections and insertion commands are not keyboard accessible
• ADO 30059567: Add Section is not keyboard accessible

The unrelated User Profile, Favicon, and React Media cropper findings in those downstream reports are not part of this issue.

Environment

• Consumer: Azure API Management developer portal designer
• Reproduced with @paperbits/core 0.1.660
• The same controlling markup and command composition are present on the current paperbits-core master branch
• Browsers/assistive technology: Edge or Chrome with keyboard-only navigation; NVDA, JAWS, or Narrator for announcement verification

Controlling code

• src/ko/ui/defaultViewManager.html: renders every contextualCommand.hoverCommands button with tabindex=-1
• src/ko/ui/defaultViewManager.html: the selected-element contextual toolbar iterates selectCommands, but not hoverCommands
• src/section/sectionHandlers.ts: defines Add section as a hoverCommand
• src/grid/ko/gridEditor.ts, src/grid-cell/gridCellHandlers.ts, and similar handlers: define Add widget and related insertion actions as hoverCommands

Steps to reproduce

1. Open a Paperbits designer page containing at least one section/widget.
2. Without using the mouse, Tab to the design canvas and select a section or widget.
3. Use Tab, Shift+Tab, and the contextual-toolbar arrow keys to inspect available commands.
4. Attempt to invoke Add section or Add widget with Enter or Space.
5. Compare with pointer hover, where the insertion button appears and works.

Actual behavior

• Hover-command buttons have tabindex=-1, so they cannot be reached through normal Tab navigation.
• Selecting an element with the keyboard displays only selectCommands; insertion commands remain absent because they live in hoverCommands.
• Icon-only hover buttons do not expose a reliable accessible name from the command tooltip.
• Keyboard-only users cannot add sections/widgets at the selected insertion point.

Expected behavior

• Every actionable insertion command available to pointer users is available from the keyboard-selected context.
• Commands expose meaningful accessible names, for example Add section and Add widget.
• The contextual command pattern has coherent roles and supports Tab/Shift+Tab plus the expected Arrow-key, Enter, and Space interactions.
• Pointer behavior and insertion position are preserved.
• Non-actionable splitters are not exposed as commands.

Suggested direction

Render actionable hoverCommands in the selected contextual toolbar (or promote them into a shared command collection) and bind their accessible name from displayName or tooltip. Avoid making only the floating pointer-positioned controls tabbable if doing so creates duplicate tab stops; the keyboard-selected toolbar should provide one stable, discoverable route to each action.

A local consumer-side replacement of defaultViewManager.html proved this approach, but it was reverted because downstream consumers should not fork Paperbits templates.

Acceptance criteria

• Keyboard users can select a section/widget and reach Add section and Add widget without pointer hover.
• Each insertion control has a programmatic accessible name.
• Arrow keys, Enter, Space, Tab, and Shift+Tab work consistently with the chosen toolbar/listbox pattern.
• Focus remains visible and predictable before and after opening/closing the selector.
• Pointer activation and insertion placement do not regress.
• NVDA or JAWS and Narrator announce the command name and state/context appropriately in Edge or Chrome.
• Add a regression test for command presence, naming, and keyboard activation where practical.

Accessibility impact

This blocks keyboard-only operation of a core authoring workflow and impacts WCAG 2.1 criteria 2.1.1 (Keyboard), 2.4.3 (Focus Order), and 4.1.2 (Name, Role, Value).