Keyboard accessibility about mirador HOT 2 CLOSED

https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets
http://www.oaa-accessibility.org/example/40/

It's one thing to prevent "traps", and another to have a reasonable strategy for this. Screen-readers will tend to tab through the DOM rather than through meaningful regions of the UI (which has been hacked into existence out of DOM elements). We should develop a comprehensive strategy for navigating with the keyboard that works for users who need accessibility features and "power users".

I would recommend using tab to focus an object, and enter to "go into" that object. You can always "get out" of the current context by pressing escape. Example: Mirador loads with two windows open. By default the user is in the "viewer context". Tabbing therefore cycles through the buttons of the viewer, and over the workspace area. Having focused the workspace by tabbing, the user may now "enter" it by pressing "enter". Tabbing now focuses the windows of the workspace. "Entering" a window causes tab to cycle over the controls of the window, etc. To get back out to the viewer, press escape twice. This "releases" the user into the workspace context, and then "releases" them into the viewer context.

Without some comprehensive strategy of this kind, the user will simply tab through the hundreds of DOM elements that make up the application's interface, going from higher-level constructs like a window to the smallest button in no logical order except which one is first in the DOM.

It may also be nice (for power users) to have lettered commands that apply to the given context ("A" for annotations if the window's image view context is focused, "s" for "save annotation" if saving an annotation, etc.). Some libraries that can help with this are mousetrap.js.

from mirador.

There is some good information here, but I think the project has moved on with Mirador 3. Closing this issue now.

from mirador.