Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Interest invokers] Keyboard inputs #1133

Open
mfreed7 opened this issue Dec 17, 2024 · 2 comments
Open

[Interest invokers] Keyboard inputs #1133

mfreed7 opened this issue Dec 17, 2024 · 2 comments

Comments

@mfreed7
Copy link
Collaborator

mfreed7 commented Dec 17, 2024

This issue mirrors #1052, but to discuss the keyboard interaction pattern specifically, for interesttarget.

Pulling from the conversation on #1052, a few things seem clear to me:

  • Activating the interestarget on keyboard focus seems like a bad idea. Users who are merely trying to tab their way through a document will get lots of "noise" with additional visual items showing up. Worse, if the activated hovercard contains interactive elements, those will be next in tab order and will re-route the user through each such hovercard.
  • Some might say that adding a delay (i.e. focus an element for a period of time) alleviates the above problem, but it merely adds confusion. Users will now have to tab very quickly through documents for fear of accidentally activating hovercards along the way. The same is true of mouse users hovering elements; however, mouse users have the luxury of being able to move the mouse all the way out of the way, and then later back to the same spot within the document. Keyboard users have no such luxury - they are in a linked list of focusable elements, and can't easily traverse out of order.
  • If focus cannot be the interesttarget trigger, then by definition the trigger must be another keyboard hotkey. The task becomes:
    1. Choosing a hotkey, and standardizing it, or...
    2. Allowing user agents to select the hotkey, and provide a way for users to discover the proper hotkey

I think the best for users would be #1, so that the same hotkey activates all hovercards, across browsers and platforms. Ideally this should be an easy hotkey to press, not requiring modifier keys, etc. Perhaps the best, most self-discoverable such hotkey would be either the up or down arrow?

My fear is that it'll be hard to find an available hotkey that works across all platforms and browsers. But perhaps the arrow keys might be one such option? I don't know what happens when you have something like a radio button group where each radio has an interesttarget, or similar situations. Perhaps we could just make all such conflicts illegal (ignore interesttarget)?

@mfreed7 mfreed7 added agenda+ Use this label if you'd like the topic to be added to the meeting agenda invokers labels Dec 17, 2024
@lukewarlow
Copy link
Collaborator

I think if we had a hotkey we'd need to make sure it's remappable in browser settings per WCAG.

Arrow keys would be interesting, though idk if that would mess with navigation for stuff like focus groups where it's perhaps legit to have an interest target.

Coming up with a new pattern on top of a potential novel touch system does concern me from an is this thing going to be speccable perspective. Both technically and politically. But if it's necessary then it's obviously worth it.

@css-meeting-bot
Copy link

The Open UI Community Group just discussed [Interest invokers] Keyboard inputs, and agreed to the following:

  • RESOLVED: add a UA stylesheet rule that indicates (when focused) that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it. This indicator can't just be a change of the :focus outline style, because developers commonly override that.
The full IRC log of that discussion <bkardell_> masonf: Just wanted to get more attention on this and talk about it - interest target needs a way (says, for example whatwg) that we need a way to always do this -- we just talked about how to activate with touch screens, now we need to talk about keyboards
<bkardell_> masonf: the one idea that came up which I think we rejected is when you focus it, it activates- it feels kind of parallel, but it turns out I think that that's not good for users generally because the tab key gets you through the document in order and it's kind of conflating two things
<scott2> q+
<bkardell_> masonf: the natural conclusion is that it can't be focus, it has to be some other key combination - the two options I think is that can be a standard one, or it just needs to abstractly require UAs to support
<masonf> ack scott
<bkardell_> scott2: I agree with everything you just said - I think I might have even been one of the people that pointed out that distinction you're talking about. there are even requirements for when something is activated on focus that there needs to be a way to dismiss it while still retaining focus
<brecht_dr> q+
<bkardell_> scott2: I would love there to be some indication that you can actually do this. I think some kind of styling might be useful - a default UA style that changes the focus indicator somehow - a slightly different variant that says "this thing is different and you can do something with it" - there is always going to be this problem with discoverability... if UAs could agree, that would be great
<bkardell_> scott2: across windows for a combo box alt+down arrow is the unofficial official way to activate it.. one of the reasons I think you would need a modifier key is that we don't want to undo the ability to scroll the screen with arrow keys - that is part of why I have been always against things like summary details or accordion using up and down -- it is very frustrating if you have a screen sized or positioned such that you can't actually do
<bkardell_> it
<masonf> ack brecht
<bkardell_> brecht_dr: +1 to the idea of having some kind of visual indicator that it will trigger an interest popover - an icon, could be on some pseudo element ... I think that works better than just learn keyboard behavior based on an outline - it's too subtle
<bkardell_> masonf: can you say - what do you mean by the pseudoelement
<bkardell_> brecht_dr: if you have a button with an interest target attached - it gets a pseudo element with some kind of indicator
<bkardell_> masonf: I had a similar idea that when you focus, something else shows up... but as Scott said it's a lot of popups
<masonf> There could just be a rule like `[interesttarget]:focus {outline: ...}`.
<bkardell_> scott2: I remember the idea that an information icon came up and was universally shunned - that is why I came up with an outline, to kind of split the difference - so there is some kind of default style where people could override it
<bkardell_> masonf: I think this is a pretty easy selector though, right?
<bkardell_> q+
<masonf> ack bkardell
<masonf> bkardell_: I actually liked the extra popup to show what the hotkey is for showing the hovercard. But as Mason points out, you can easily do that yourself.
<bkardell_> scott2: I would advocate that we have an indicator that all UAs can agree to and that we can make work 'by default' - websites can change it, but it's very well agreed and understood that a focus indicator means "this thing has focus"... in terms of people using screen readers and stuff, we can make that really clear. It's really the sighted keyboard user I think we need some visual indicator 'this is different'
<bkardell_> masonf: ok I think I see and I agree - do we want this to be default or just so simple you can easily do it?
<bkardell_> scott2: I think by default
<brecht_dr> +1 on by default
<bkardell_> q+
<bkardell_> q-
<brecht_dr> q+
<bkardell_> +1 on by default
<bkardell_> brecht_dr: that's kind of why I suggested a pseudo-element - if a UA changes something by default, someone can do their own icon which limits the discoverability, etc.
<bkardell_> q+
<bkardell_> brecht_dr: if it could be changeable that would help
<masonf> Proposed resolution: add a UA stylesheet rule like `[interesttarget]:focus {outline: ...}` to indicate that this element is special. No need for anything more, e.g. a popup describing how to activate it.
<masonf> ack brecht
<masonf> ack bkardell
<bkardell_> scott2: I don't disagree - people want to style stuff I just want there to be a way to have it by defaul
<masonf> bkardell_: I also prefer it to be default. If there's difficulty in that, I wouldn't necessarily want to die on that hill. Probably I wouldn't even require that people be able to change it outright, perhaps just customize it like changing the color.
<masonf> bkardell_: I prefer on by default, and prefer it to use color magic to make sure it's visible.
<masonf> Proposed resolution: add a UA stylesheet rule that indicates that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it.
<masonf> Proposed resolution: add a UA stylesheet rule that indicates (when focused) that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it. This indicator can't just be a change of the :focus outline style, because developers commonly override that.
<brecht_dr> +1
<masonf> RESOLVED: add a UA stylesheet rule that indicates (when focused) that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it. This indicator can't just be a change of the :focus outline style, because developers commonly override that.
<masonf> bkardell - I'm guessing it's the "Show a quick highlight on the focused object" in settings? That shows a separate outline for a few seconds each time you focus something new.

@gregwhitworth gregwhitworth removed the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants