Keyboard behavior for the interesttarget attribute

[mfreed7]

What is the issue with the HTML Standard?

Some references first:

• The interest invokers explainer's keyboard section
• The OpenUI discussion thread about keyboard behavior
• A section of the explainer that discusses the alternative idea of using delayed-focus as the trigger.

This issue is a narrowed down version of the OpenUI discussion above, to hone in on the right final behavior. Essentially, the explainer lays this out:

For keyboard users, the UA will provide a hot-key such as Alt-Down, which will “show interest” in the element. Another hot-key such as the ESC key will provide a way to trigger “loseinterest”. These hot-keys must be chosen by the UA to be convenient for the user, while also not conflicting with existing UA-provided and OS-provided hot-keys. Other ideas include Alt-Space or Ctrl-Space for the show interest hot key.

Additionally, the appearance of the focus ring will be altered slightly when focus is on elements with interesttarget. This allows the user to discover that something is “different” about this element, and know that the keyboard activation hot-key will allow them to show interest. Since accessibility guidelines state that color alone cannot be enough to differentiate states, this focus ring change will likely need to be something like a slightly-thicker outline, or other shape change.

That's the current direction, coming out of OpenUI discussions. However, this issue is to check that with the folks in WHATWG. In particular:

• Should a hot-key (like Alt-Down) trigger interest, or should merely focusing the element and waiting for the interest-trigger-show-delay time to elapse be enough? Or something else?
• To indicate to the user that an element has interesttarget, should the focus ring be changed (and if so, how), or should something else be done such as changing the browser link preview text at the bottom left/right? Or something else?

[mfreed7]

We had a great discussion of the keyboard behavior today at OpenUI, and I'll be incorporating the conclusions into the explainer shortly. FYI. Thoughts appreciated, here or on the OpenUI issue.

[mfreed7]

We had a great discussion of the keyboard behavior today at OpenUI, and I'll be incorporating the conclusions into the explainer shortly. FYI. Thoughts appreciated, here or on the OpenUI issue.

I forgot to update this issue, but the explainer has been updated to incorporate the last OpenUI design session. The new behavior is that keyboard focus (after a delay) triggers the popover, but in a "not keyboard focusable" state. That keeps the popover from "stealing" the focus navigation order, if the user accidentally triggered it. Additional things will fully-activate the popover from that point. That requires a new interactivity:not-keyboard-focusable mode, and some new pseudo classes such as :has-partial-interest.

Thoughts appreciated.

[css-meeting-bot]

The CSS Working Group just discussed Keyboard behavior for the `interesttarget` attribute.

The full IRC log of that discussion

<jarhar> masonf: i thought it would be good to intro interesttarget, first keyboard then touch screen
<jarhar> masonf: right now its an attribute called interesttarget with an idref
<jarhar> masonf: use case is hover triggered things. thats a very common use case, its on most websites generally speaking
<jarhar> masonf: the reason the agenda has keyboard and touchscreen is that the mouse interaction is pretty clear - hovering with the mouse after a delay activates the target which is typically a popover which opens
<jarhar> masonf: i wont go into much more detail on that
<jarhar> masonf: the main concern we have to deal with is that we want to support all input modalities, not just mouse
<jarhar> masonf: it solves a real problem for developers. most sites have these tooltips and they have to reinvent this wheel every time
<jarhar> masonf: they either dont think about keyboard/touch or create their own way, and they have no way to handle touch screen users and leaves them out
<jarhar> masonf: looking at design systems today, there are two directions: one is to have a hotkey. when users focus an element that can generate a hovercard, they push a hotkey and it shows up.
<jarhar> masonf: the other way is to show something on focus. if they keyboard focus it then after a delay it shows up
<jarhar> masonf: these are both present on sites already
<jarhar> masonf: the issues are that hotkeys aren't easily discoverable, and that focus based activation is that its a nuisance, if you just want to traverse the focusable elements and you stop somewhere then suddenly you have a hovercard
<jarhar> masonf: the focus issue also happens with mouse, but keyboard users are stuck in this list
<jarhar> masonf: thats fine unless the hovercard has interactive elements, which changes the list of keyboard focusable elements
<emilio> q+
<jarhar> masonf: in openui we had a bunch of brainstorming, id like to get ideas from this group too.
<astearns> q+
<jarhar> masonf: prefer discoverability, use focus as the trigger
<jarhar> masonf: to mitigate the problem of the focus detours, theres a bit of complexity added: when you stop at a focusable element, it will either have focusable or not focusable elements. it will be rendered in a way that is not keyboard focusable. even if it has buttons in it, hitting tab will not focus into it. at this point, a hotkey will allow you
<jarhar> to move focus into it
<jarhar> masonf: you get the best of both worlds, you can trigger it and see it, but you have a place to show users to press a hotkey to move focus into it
<hdv> q+ to ask how authors and users find out what the hotkey is on a given platform?
<jarhar> masonf: this is the idea from facebook, this is how they do things today
<astearns> ack emilio
<jarhar> emilio: i agree that going for focus makes more sense
<jarhar> emilio: i wonder if showing accidentally the hovercard is such a big deal. ideally these would close with escape. if you tab on something you dont want to see, then you can press escape and its gone. seems like a simpler model to me
<jarhar> emilio: that would be my initial model
<keithamus> q+
<jarhar> masonf: it has been considered, escape does close it since its a popover. there were some a11y concerns. maybe thats a great model though
<jarhar> astearns: i also wanted to ask the same question, escape is not a new thing people have to learn. not a big fan of adding another magic key that you have to learn or have to get announced from the hovercard if its cluttering the ui there
<jarhar> astearns: i expect designers will have that help text be the first thing on the chopping block
<hdv> q-
<astearns> ack astearns
<astearns> ack keithamus
<jarhar> keithamus: we trialed showing the hovercard on focus on github, and many users complained. it is not a pattern that uses like
<jarhar> keithamus: something more like a partial disclosure duriing focus and having a hotkey to activate is preferrable
<jarhar> keithamus: the discoverability is hard. because its non standard users dont know how to activate it. i think its alt down or alt up
<jarhar> keithamus: you can do this today and we expose it in our list of keyboard actions
<astearns> q+
<jarhar> keithamus: users dont know. we provided alt text which says push alt up to open hovercard, and that was annoying and redundant to screen reader users
<jarhar> keithamus: discoverability is hard, but partial disclosure is the right path forward
<jarhar> masonf: you said users dont like that it shows up on focus? what part?
<emilio> q+
<jarhar> keithamus: it was showing up at all. they are large enough that they occlude other important content. if youre using focus to read stuff, and then a popup occludes the thing that youre reading
<jarhar> astearns: and when you had it come up on focus, did you have a substantial delay?
<jarhar> keithamus: yeah we tried with delays as well but its insufficient
<jarhar> astearns: if we have a system where the popover comes up after some delay on a focus and there isn't a particular trigger and theres a hotkey to dismiss it, the user dismissing the popover should disable the popover from coming back again until focus changes i assume
<astearns> ack astearns
<jarhar> masonf: i think that would be a side effect of the trigger gaining focus and a delay, but yeah we should make sure thats tested
<lwarlow> q+
<jarhar> emilio: i was going to ask keith - this depends on the content right? on github if i press search field and then press tab, that shows tooltips on focus. theres probably use cases for both?
<astearns> ack emilio
<jarhar> keithamus: we distinguish between non rich tooltips and rich tooltips - we call one a tooltip and another a hovercard
<jarhar> keithamus: users find tooltips ok on focus because most of them are small and dont occlude content
<jarhar> keithamus: some of the longer ones are disruptive, but tooltips are fine
<jarhar> keithamus: hovercards which have buttons and the users bio, are 250px big and occlude a lot of content
<jarhar> keithamus: but they are very useful. we track engagement on them and see that theres very good engagement
<jarhar> keithamus: so yes there are use cases for both
<astearns> ack lwarlow
<jarhar> lwarlow: the bit about pressing escape making it so it doesn't show up again, that is kind of automatic
<jarhar> lwarlow: if youre using more than one modality - if youve got focus and mouse, does hovering it show it again?
<jarhar> lwarlow: it might be that the gain lose interest mechanism is good enough without anything extra
<keithamus> https://www.mediawiki.org/wiki/Page_Previews#:~:text=led%20to%20a%2020%25%20increase%20in%20links%20clicked%20per%20page
<jarhar> keithamus: ive cited this before, but this is wikipedia saying that when they enabled this hovercard on android they saw 20% more links clicked
<jarhar> keithamus: this is genuiely things that websites want
<jarhar> masonf: the buttons on those hovercards are important
<lwarlow> Does Wikipedia explain how they do this on mobile?
<jarhar> astearns: for the case where focus doesn't pop it up immediately, and there is a special hotkey to invoke the popup from focus, how does that get announced to the user? you were talking about the key being in the hovercard
<jarhar> astearns: if the hovercard isn't invoked then that doesn't get announced
<lwarlow> q+
<keithamus> q+
<hdv> q+
<jarhar> masonf: in terms of sighted users - back to the mode where focus shows the popover and theres an additional hotkey to move focus into it, you could have an after set of content which says how to do it
<jarhar> masonf: i dont know what the best way to announce that to AT is
<astearns> ack lwarlow
<jarhar> lwarlow: regarding the hotkey, whatever mechanism we come up with - if we let the developer style it thats fine but the text should be provided by the browser because the browser should let you remap this
<jarhar> lwarlow: its important that we dont just tell developers to put alt up in there because it might be wrong
<astearns> ack keithamus
<jarhar> masonf: we probably need to localize the text as well
<jarhar> keithamus: we added aria describedby to say push alt up to open
<jarhar> keithamus: they were ambivalent the first time, but hearing it every time for every link was annoying
<jarhar> keithamus: should we put this into our growth hacking thing, so you only see it 3 times? the complexity on client side is just not worth it
<jarhar> keithamus: if a browser were to do a pattern like that like this is how you can do this thing, that could be a path forward
<jarhar> keithamus: the repitition was the big bug bear
<jarhar> keithamus: were willing to sacrifice ?? for simplicity
<jarhar> masonf: i was talking to aaron leventhal, his concept was you could announce things 5 times, and browser know that and stop it
<dbaron> s/??/discoverability/
<jarhar> keithamus: there was something else i wanted to add. a big problem as well was deciding a hotkey
<jarhar> keithamus: if the browser had a control, people could get more familiar with it across sites
<jarhar> keithamus: there is nothing that exists today for back button etc.
<jarhar> astearns: since you took the discoverability hit, do you have data on how well it was discovered afterwards?
<astearns> ack hdv
<jarhar> keithamus: no
<jarhar> hdv: it helps to standardize this so people can get used to it. if there is a standard hot key, then people can get used to their system
<jarhar> hdv: with aria details for popovers, that behaves differently in different browsers. youll hear that you can go to popover content, its different in jaws and nvda, and doesn't exist in voiceover
<jarhar> hdv: thats not a bug but a feature. its a good thing that ATs can decide what to do. authors can hook into a standardized thing, and ATs can do whatever they want, like showing it 5 times and never again
<jarhar> hdv: for me, all of that speaks to yes we need to standardize this and its not invented at github alone because then github doesn't know how to do it right
<jarhar> masonf: i think my summary is that it sounds like most people are ok generally with focus being the trigger ,and theres an open question about this partial interest thing, although keith was maybe like dont use focus at all
<jarhar> astearns: im not sure that we should have a single solution for both small popover and large card. im not sure if its worth to have the complication to have two different ways of doing this that could be misused
<jarhar> masonf: all of these things sound simple, but the devils in the details, and the details are horrendous. thats where we should not make it complicated for a developer but we can put that complexity in the browser
<jarhar> masonf: maybe we can leave it there and move on to touch screen