Hotkey Mapper Tool accessibility improvements

[theinterned]

From a chat with @jscholes off-site:

This is a difficult sort of mechanism to make accessible for some users, because reliance on keyboard input (or tools that emulate it like speech recognition software) will conflict with the tool's requirement to take all keyboard input and swallow it. Indeed, as a screen reader user, it's difficult to get rid of it once loaded! :)

Here's what I'd suggest:

1. Give the hotkey input area (id="hotkey-code") a tabindex of "0", so users can explicitly place focus on it.
2. Give the same area the following attributes: role="application", aria-roledescription="Input Capture", aria-label="Hotkey", aria-live="assertive", and aria-atomic="true".
3. Bind your keydown handler to that input div#hotkey-code, instead of the entire document.
4. Make it visually obvious in some way that mouse users should click (or keyboard users should focus) the input area in order to trigger the behaviour, as it will no longer apply to the full page. This should include a focus outline.
5. Disallow Tab and Shift+Tab from being used as tool input, so users can get out of the input capture area. This is both an explicit accessibility recommendation for this page, as well as an inclusive design tip: users shouldn't be rebinding Tab and Shift+Tab so the tool should discourage it.
6. Remove tabindex="0" and role="button" from the clipboard-copy component. The inner button already has all of the semantics that are needed.
7. Move the copy button after the input area, both visually and in the mark-up, so users don't have to navigate backwards to reach it.

[jscholes]

Update (from the same conversation): looks like the role and tabindex attributes are dynamically added by the clipboard-copy component, so that might be a bit tricky. You could temporarily get around it in this code by adding role="none" and tabindex="-1" to the actual child <button>, plus moving aria-label="Copy to clipboard" onto the clipboard-copy element directly. But that's a temporary solution.

[jscholes]

CC @sinabahram who might find this interesting.

[theinterned]

Maybe the shortcut should be in a kbd element?

[jscholes]

@theinterned The kbd element doesn't currently have any impact on screen readers. Although, even if it did, my recommendation of role="application" would override those semantics anyway. If you want to be 100% semantically correct, you can render a kbd element inside the input div.