Should SPACE to be allowed to activate the <a> element?

[MelSumner]

Background/ Use Case

I've been writing a call-to-action component. It visually presents as a button (through styling/CSS); when the developer invokes the component, they provide either an action or a URL/route. Based on what they provide, the component renders a button element (if action) or link (a element) (if URL/route) to the browser.

For a user with assistive technology, the correct element is announced and there are no issues.

For the user who is a keyboard-only user, this pattern falls down. It visually presents as a button, but, unlike the button (or other form controls) it does not respond to SPACE (spacebar).

Research

In reading the UI Events KeyboardEvent key Values specification, I find no mention of the SPACE key, specifically except as a side note in the Whitespace Keys section:

The space or spacebar key is encoded as " ".

I checked Navigation Keys; since when a a link (<a> element) has focus, pressing the SPACE key will scroll that area to the top of the user's viewport (but not consistently). However, it is not listed as a Navigation Key item.

Additional finds:

1. ENTER and TAB are are listed both in Control Characters and Whitespace Keys
2. I cannot find any mention of what the SPACE key should do in the HTML specification. It seems to more generically refer to event target activation behavior and user interaction task source.
3. UAAG outlines focus mechanism requirements, is there a specific interpretation for these?

How it works now

No matter what element has focus, pressing spacebar scrolls the page.

I previously thought that if an <a> element was focused, it would scroll that into view, but have since come to understand that the behavior was coincidental and it didn't matter what had the focus.

Request for consideration

Because users are able to scroll the page in other ways, (ARROW keys, HOME, END, PAGE UP, PAGE DOWN)
Because adding the SPACE functionality to the <a> element would resolve a keyboard-only user gap for something that needs to be a link but visually presented as a button (via styles),

Would we be willing to allow SPACE to be used for activation of links in the same way that it can activate a button?

[chlane]

@MelSumner could this be done as a widget in the authoring guidelines? Then we could add the guidance to support the spacebar in addition to the Enter key there. We would also need a widget name that makes sense.

[MelSumner]

@chlane in theory, it is one potential outcome. However, I think I am suggesting something even stronger; that by default, the a element should respond to SPACE the same way the button element does (and, let's put that specifically in writing in the appropriate spec). WDYT?

[chlane]

@MelSumner I think it would be great if the spacebar activated the <a> element or an ARIA link since Call To Action controls have been in such high demand for so long. Sighted mouse users might be surprised when they see the hover behavior from a link on something that visually looks like a button, but I don't think that is a severe issue IMO, but I'm not sure.

[scottaohara]

For the user who is a keyboard-only user, this pattern falls down.

What does 'falls down' mean here? It's not like it's utterly unusable? Do we have data to back up how often people use space vs enter to try to activate elements that look like buttons, and would help us determine the severity of this issue? Per at least the initial topic/proposal, it seems like a big swing to change the behavior due to instances of CTA controls, but a user would otherwise know not to press space for links that were styled closer to their defaults, unless they wanted to quickly scroll the page for reading purposes.

Playing devil's advocate (or continuing to i guess), the reverse - a button styled to look like a link should no longer be actionable via the space key, but instead scroll the browser viewport - should hold similar weight as a potential outcome. I'm absolutely not advocating for that, but want to call out that they are two sides of the same solution.

My major concern here is taking away a long standing behavior from links because some links, in the grand scope of all the links on the internet, are styled to look differently. Yes, there are other ways to scroll a page if taking away this feature, but they are slower (arrow keys) or not equivalent or even available on all keyboard types (page up/down).

Those will be my primary questions to address in the larger discussion :)

[JAWS-test]

I don't really understand the question because, as far as I know, neither the ARIA specification nor the HTML specification specifies how certain elements can be operated. This seems to me to be left to the respective operating systems and browsers. Of course there are conventions, but no binding rules. The conventions are mentioned in https://www.w3.org/TR/wai-aria-practices-1.1/, for example, but are not defined there. I.e. the only thing we could describe in ARIA Authoring Practices would be that role=link should be optional or necessarily operable with SPACE. If this is desired, the discussion should perhaps be moved to https://github.com/w3c/aria-practices.

If you design a link like a button (which is not a good idea) you can already make the link activatable with SPACE. This would not be a violation of any specification - but also not required according to WCAG 2.1.1, since WCAG does not require a specific keyboard operation, but only any.

At present, SPACE is identical with PAGE DOWN and SHIFT+SPACE with PAGE UP. This is independent of whether the focus is on a link or not.

[MelSumner]

I don't really understand the question because, as far as I know, neither the ARIA specification nor the HTML specification specifies how certain elements can be operated. This seems to me to be left to the respective operating systems and browsers. Of course there are conventions, but no binding rules.

@JAWS-test thank you for giving that extra clarification. 💯

I think it makes the ask even more crisp and narrower in scope, which will be useful.

[aleventhal]

This should be filed on WHATWG/HTML, because it's not about AT mapping.
It's about how UA's support .

This would not be a 100% backward compatible change. It could break those some web apps, somewhere, if they reuse spacebar for something else, and expect that to work when a link has focus. I don't know of any, but the web has everything.

[MelSumner]

So I have been testing this out on a bunch of web pages, and I think that we need more feedback.

I am seeing many instances of "if it is not a form element, spacebar scrolls the page". I think any scrolling I was seeing with a link focused was coincidental; I don't think this is how it works).

Def need more testing to see if it does anything when a link is focused (but, probably more efficient to look at browser code at this point).

[scottaohara]

yes. Space key is not doing anything special on hyperlinks. It is performing as expected because hyperlinks don't listen for space key press.

[JAWS-test]

@aleventhal

This should be filed on WHATWG/HTML, because it's not about AT mapping.

Theoretically it belongs more to WHATWG/HTML, but even there it would be out of place, is my guess. Because where in the WHATWG/HTML is it defined how an HTML element is to be operated? Maybe I missed it, but so far I haven't found that.

[brennanyoung]

If an author makes a focused link respond to Space as well as Enter. Does it violate anything but expectations? Any harm here? I've also seen people getting confused when radio buttons fail to respond to Enter, because this is a special case, even though it conforms to the ARIA spec.

I've posted on the APG board calling for a mention of these discrepancies in the page about developing a keyboard interface, because they're not obvious.