Upgrade StoragePlugin toolbar buttons are still outside the keyboard navigation chain
Following up on "Accessibility: Getting to the toolbar buttons"
(https://forums.zotero.org/discussion/97505/), where in February 2023 dstillman
wrote that "In Zotero 6.0.22, available now, all toolbar buttons are accessible
via the keyboard."
That is true of Zotero's own buttons. A button a plugin adds to the toolbar is
not reachable by Tab, and as far as I can tell there is no supported way for a
plugin to put it there. Setting tabindex="0" on the button is not enough.
Reading chrome/content/zotero/zoteroPane.js: setUpKeyboardNavigation() installs
several keydown listeners, and each builds its own actionsMap as a `let` inside
the callback. moveFocus looks up actionsMap[event.target.id], then falls back
over event.target.classList. Every top-level key in those maps is one of
Zotero's own element ids or a specific Zotero class — zotero-tb-add,
zotero-tb-sync, search-input, tag-selector-list, and so on. There is no generic
"a toolbar button" key, and the maps are not reachable from outside their
closures, so a plugin's only way in would be to impersonate an id that Zotero's
own navigation depends on.
The consequence for a keyboard-only or screen-reader user is that a plugin's
toolbar control can be announced correctly, have a correct role and name, and
still be unreachable without a mouse. I checked the rest with Orca and the
markup side is fine; it is only the Tab order that a plugin cannot enter.
Is there a supported hook I have missed? If not, would you consider one — a
class the maps recognise, or a small registration call — so that a plugin button
can sit in the chain next to the native ones? I am happy to test a patch.
(https://forums.zotero.org/discussion/97505/), where in February 2023 dstillman
wrote that "In Zotero 6.0.22, available now, all toolbar buttons are accessible
via the keyboard."
That is true of Zotero's own buttons. A button a plugin adds to the toolbar is
not reachable by Tab, and as far as I can tell there is no supported way for a
plugin to put it there. Setting tabindex="0" on the button is not enough.
Reading chrome/content/zotero/zoteroPane.js: setUpKeyboardNavigation() installs
several keydown listeners, and each builds its own actionsMap as a `let` inside
the callback. moveFocus looks up actionsMap[event.target.id], then falls back
over event.target.classList. Every top-level key in those maps is one of
Zotero's own element ids or a specific Zotero class — zotero-tb-add,
zotero-tb-sync, search-input, tag-selector-list, and so on. There is no generic
"a toolbar button" key, and the maps are not reachable from outside their
closures, so a plugin's only way in would be to impersonate an id that Zotero's
own navigation depends on.
The consequence for a keyboard-only or screen-reader user is that a plugin's
toolbar control can be announced correctly, have a correct role and name, and
still be unreachable without a mouse. I checked the rest with Orca and the
markup side is fine; it is only the Tab order that a plugin cannot enter.
Is there a supported hook I have missed? If not, would you consider one — a
class the maps recognise, or a small registration call — so that a plugin button
can sit in the chain next to the native ones? I am happy to test a patch.