Add keyboard shortcuts to the toolbar

[matthiask]

There's an open pull request for adding keyboard shortcuts to the Django admin: django/django#19579

As discussed in the toolbar contributors call, we could do the same in the toolbar.

Maybe use H to jump to the history panel or something like that.

https://pypi.org/project/django-admin-keyshortcuts/

[MohammedAlkindi]

Concrete proposal, if useful.

Bare letters are riskier here than in the admin. The admin owns its page; the toolbar injects into arbitrary third-party pages. Single letters are also screen-reader quick-nav keys: H is "next heading" in NVDA and JAWS. A g prefix avoids both and matches the g i already in the admin PR.

Suggested v1: keep Escape, add ? for help, g then a letter per panel.

Panels are pluggable, so the letter should come from the Panel class and render as aria-keyshortcuts on the panel_button.html anchor, which already carries aria-controls. The admin's registerDeclarativeShortcuts() then works unmodified.

Three calls are yours, below. AI-assisted draft; the shadow-DOM note is the part I ran.

Proposed keys, and the three calls

Keys	Action	Scope
Esc	Close window, then panel, then toolbar	existing, unchanged
?	Show shortcuts dialog	toolbar open
g h	History	toolbar open
g s	SQL	toolbar open
g t	Templates	toolbar open
g r	Request	toolbar open

Letters are illustrative. The mechanism is the point, not this table.

1. Where does the letter live? A shortcut_key attribute on Panel keeps third-party panels working and stays translation-safe, unlike a hardcoded JS map. It needs a documented rule for two panels claiming the same letter.

2. Do shortcuts work while collapsed? Today onKeyDown is bound in showToolbar() and unbound in hideToolbar() (toolbar.js:298 and :278), so nothing listens when the toolbar is just a handle. Keeping that is the smallest change, and it means a shortcut can never fire on a page where the developer has not opened the toolbar. Expanding from collapsed would need that lifecycle changed.

3. Opt-out? The admin PR gates everything behind a localStorage toggle. Same here, or not worth it.

Shadow-DOM note. USE_SHADOW_DOM defaults to True, so I checked what that does to the admin's guard. In Chrome, keydown from inside the shadow root does reach a document listener, but document.activeElement returns the #djDebugRoot host rather than the focused inner element, and event.target is retargeted the same way. The case that matters is still fine: focus in a host page input reports that input, so isFocusedTextField() protects the developer's own forms as written. It just cannot see inside the toolbar. Harmless today, since the toolbar has no text inputs, though .djdt-scroll is focusable via tabindex="0".