A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Is it OK to stop a button from being click-focusable?

simevidas
2019-11-11

On Twitter’s website (the new one), if I click on the Heart (:heart:) button to like a tweet in my timeline, and then press the space bar key to scroll the timeline by one screen, the page is not scrolled, but instead the Heart button is activated again (un-liking the tweet).

This happens because clicking that button focuses it (i.e., the button is click-focusable), and before I can use the space bar key again to scroll the page, I have to first click on an empty space to un-focus the button.

This is annoying, so I was wondering if this behavior could or should be changed to make these types of buttons not click-focusable.

Is click-focusability for buttons an accessibility requirement, or can websites stop buttons from being click-focusable if they think it’s better for usability?

LJWatson
2019-11-11

“Is click-focusability for buttons an accessibility requirement, or can websites stop buttons from being click-focusable if they think it’s better for usability?”

The ability to click or press (or tap) on a button is built into the design of the button element. Breaking any of these behaviours is not a good thing to do for either usability or accessiility.

simevidas
2019-11-11

My use of the term “click-focusability” may be confusing, so allow me my clarify: I am not suggesting to prevent people from activating the button in any shape or form.

My question is about removing focus from the button after it was activated via click. The goal is to allow people to use the space bar key to scroll the page after clicking on certain buttons.

So again, if a person activates the button via the mouse cursor, and not the keyboard, then and only then, the website would remove focus from the button as soon as the button’s action was completed.

denmch
2019-11-11

Retaining focus is necessary to allow multiple clicks/toggle via keyboard, as well as location for keyboard navigation. Without this functionality, people would need to tab away and back again in order to correct a mistake or if they changed their minds, and if focus were lost, they may have difficulty finding their way around the page.

Space/shift + space is a convenience for people solely navigating visually and by mouse, but it’s unreliable because space has other more important uses. fn + arrow on Mac or page up/page down on PC is only slightly less convenient and doesn’t impact the space bar. I think the path of least resistance is to navigate pages a little differently rather than work out a code solution that tries to break keyboard navigation in specific circumstances.