Rendering accesskey

[annevk]

Firefox has a feature in XUL whereby we can underline the accesskey of an element or put it in parenthesis at the end, with a special case for the end being a colon. We're wondering if there's interest in addressing this use case in a standardized matter so sites can make use of it as well.

https://webaim.org/techniques/keyboard/accesskey#usersknow has some useful context for this discussion.

(I couldn't find an existing CSS issue and since it's somewhat specific to this HTML feature I thought it'd be best to start the discussion here.)

cc @bgrins @whatwg/css @whatwg/a11y

[annevk]

There are some challenges with this layout-wise. The pattern we're mainly interested in enabling is <element accesskey=...>text node children</element> which is doable, but it's unclear if not working when there's element children makes it sufficiently usable to be standardized.

Curious to hear what people think and what other markup patterns ought to be considered.

[tabatkins]

Hm. So the accesskey itself might be in the element 0 or 2+ times. That makes some of the simpler solutions not workable.

Here's a possible sketch:

• add an ::accesskey pseudo-element, which is text-like (not tree-abiding) and either wraps the first instance of the access key in the element's text, or the auto-generated text placed by the browser if there is none, with some default styling (underlined) that can be turned off with an appearance: none;. This only exists on elements with an accesskey attribute.
• add a property that controls whether or not ::accesskey is generated at all, defaulting to "no" for backwards compat.
• add a property that can be put on a child element to let it claim to be the accesskey, overriding the automatic selection/generation from the UA. The ::accesskey, if the parent allows it to generate, then wraps the child element.

Possibly the "default vs custom styling" can be selected by the "generate an ::accesskey" property, rather than by appearance on the ::accesskey itself; an auto value applies UA styling and makes it ignore any author-level CSS, while custom applies no UA styling (or some mandated-by-spec styling, so it's predictable) and lets author-level CSS style it. This is equivalent functionality, just a question of what is more natural or easier for implementations.

Whether or not it can select down into descendant text can go either way; I don't have a strong opinion on this, but lean toward "let descendants provide the accesskey".

[annevk]

Let me make the possible scenarios XUL reportedly (I'll verify) supports a bit more concrete:

Markup	Expected rendering (changes in bold and italic)
<el accesskey=a>Amazing</el>	Amazing
<el accesskey=z>Amazing</el>	Amazing
<el accesskey=1>Amazing</el>	Amazing (1)
<el accesskey=1>Amazing:</el>	Amazing (1):
<el accesskey=1>Amazing;</el>	Amazing; (1)

Effectively, there's two primitives:

1. Find X in the string and if it's not there, append it in some manner
2. Highlight X in the string

Low-level support for this is rather tricky though and getting all the edge cases and bidi right might not be worth it.

[Malvoz]

Should this apply to aria-keyshortcuts as well?

[cookiecrook]

Cc @aleventhal, who championed aria-keyshortcuts.

accesskey isn't used consistently b/c assistive technology and internationalization contexts (inc different keyboard layouts, for example numbers on the shift plane) make it challenging to associate these with a single, simple modifier. In short, all the keys are taken or blocked in some context or another.

aria-shortcuts is a slight improvement because it's not limited to the browser's reserved modifier for accesskey (usually Opt/Alt). The shortcut can be an unmodified key (e.g. "c" for Gmail's "compose new mail message" feature), or a multi-modifier shortcut ("Shift+Ctrl+c"). There's no magic though; the event handling is just JavaScript. The ARIA mapping just exposes which shortcut to the AT.