Accessibility issue: inconsistent and incorrect keyboard activation of elements

[scoutb-cogapp]

UV version: [email protected]

I'm submitting a: bug report => please fork one of these codesandbox examples with a repro of your issue and include a link to it below

Issue description

When navigating by keyboard, it is very inconsisent how elements are activated: space or return key. Most work with both, some only with space, others only with return. This makes keyboard navigation confusing.

• examples for return key only: go, +, -, rotate, items inside the share modal and inside the more information sidebar
• examples for space key only: image controls forward and backward and also opening and closing the sidebars, switching between link and embed options in the share modal

On top of that, activating items by spacebar will also scroll the viewport to the bottom of the page. This will happen even for items that require the spacebar to activate (for example next-image-button in image controls will go to the next image but also scroll to the bottom of the page which means the image may become completely not visible).

Steps to reproduce

1. open this manifest
2. navigate the page and try out activating controls with space and return key
3. particularly, navigate to the image viewer area and inside there to the next button
4. activate by space bar and observe the viewport moving to the bottom of the page

Expected behaviour

Consistent keys used for activating elements. Commonly, it's return for buttons and links and space for activating options in forms and the like. But having both for all elements would also work

The space key should never scroll the user anywhere but especially not if it is used to activate links in other parts of the viewer.

Possible fix

It would probably help a lot if the image controls were to be turned into semantic html rather than divs, because buttons come with built-in functionality like that.

WCAG criterion

3.2.4 Consistent Identification (Level AA)

EDIT:

MDN suggests the following behaviour for links and buttons:

• links are activated by ENTER
• buttons are activated by SPACE or ENTER and to make sure that buttons behave like buttons and links like links to be consistent. (source)

[demiankatz]

Since this is quite a broad issue report, maybe we should break this down into smaller sub-parts so it's easier to address -- e.g. one issue for controls in the OpenSeadragon center panel, another issue for the controls in the embed dialog, etc. If other areas need attention, it would be good to have issues for those too. Would @scoutb-cogapp or other testers be willing to do this so we can more easily distribute the remaining work?

[damodeburca]

Please see #1157 for more detailed information on this issue with regard to the index & thumbnail tab

[LlGC-jop]

As this seems to relate to #1157 I'll take a look at them together

[crhallberg]

re: MDN - this is and should be the default behavior that the browser provides. I had this issue with the Media Controls PR that I opened. I had to add a boolean to some of the keydown listeners so that it doesn't always prevent propagation (which would block the above behavior).