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

[mfreed7]

I wanted to come back to this issue and discuss the "partial interest" concept. I've heard feedback from several folks (some a11y experts among them) that perhaps the partial interest concept is too heavy-handed, and not worth the potential benefit. Indeed, in the discussion above, I see these comments:

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
emilio: that would be my initial model
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
astearns: i expect designers will have that help text be the first thing on the chopping block

I also have a concern that the feature might actually make it harder for keyboard users to understand what's going on, since they now have to press something special to get to the target popover's content, vs. just pressing the "normal" tab key to get there.

The partial interest concept adds significant complexity:

• The pseudo classes need to have a value for partial.
• There will need to be a pseudo element on the target popover that shows the "hint" text (e.g. "Press Alt-Up to activate"), so that it can be styled (or removed) by the developer.
• Implementation-wise, figuring out if partial interest is needed takes a bit of machinery, since the target popover needs to first be shown before its contents can be evaluated for focusability.
• Developers will have to contend with all of this, and I can see a desire to simply override it all and make there be just two states: no interest and full interest.

Given the above, it seems like this concept might be a) annoying to users, and b) annoying to developers. In which case, perhaps we should just remove this functionality? My anecdotal experience is that most hover-triggered popovers in the wild would not be seen as intrusive to users, since they contain at most one or two focusable elements (e.g. a "Follow" button), if they have any focusable content at all.

If in practice we find that such a feature is needed later, it seems like it could be added in a backwards-compatible way. Or at least the current shape of the proposal doesn't seem too breaking, if added later.

[css-meeting-bot]

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

The full IRC log of that discussion

<keithamus> astearns: next, keyboard behaviour of interesttarget attribute
<keithamus> masonf: we talked about this before, the issue to re-raise is the partial interest concept. This is meant for keyboard users...
<keithamus> .. if you are tabbing through a doc with interestfor, and if you stay there for long enough then the popover will show, and if it has additional tab stops then it'll divert the flow of focus to the popover. So maybe you paused to read and now you have a detour to keep moving a long
<keithamus> .. we have a lot of machinery to keep this going.
<keithamus> .. So when you focus an element with interestfor, there is magic that means the popover contents aren't traversable until you press a hotkey.
<keithamus> .. To do that you need pseudo classes to tell you you're in that state, you need a hotkey, you need some way of telling the user what the key is and so on
<una> q+
<keithamus> .. This was raised to me by an a11y expert that this might be annoying than problem solving. For example a sighted keyboard user can see the content but cannot traverse it until they press this magic hotkey.
<lwarlow> q+
<bkardell> q+
<keithamus> .. The confusion factor might be worse than the problems it solves.
<keithamus> .. It's probably annoying to users, it might be annoying to developers because it involves a lot more machinery, and it might be annoying to implementers because it's a lot more to implement.
<keithamus> .. The current shape of the partial interest feature is that we can add it later, without too much breakage. It might change some of the UI but it will be okay for users.
<keithamus> q+
<astearns> ack una
<keithamus> una: I worry this adds a lot of complexity for developers, and introduces the opportunity to mess things up with a11y. It's a bunch of states developers don't normally think about. They might mess up the default experience.
<keithamus> .. why can't we have something like select? Where you can use the tab key but arrow keys move you through the inner items
<keithamus> .. so if you don't use the arrow keys you move to the next item
<keithamus> .. then you don't have to worry about partial interest etc.
<keithamus> .. seems that adds more complexity and more opportunity to make a11y mistakes.
<keithamus> masonf: adding the partial interest thing is an a11y concern because people might not activate it but I think the same could be true for different keyboard keys - that some are traversable via tab and some by arrow keys.
<keithamus> una: people who implement this today, what do they do?
<keithamus> masonf: wikipedia has one interactive element inside the popup and it's not keyboard accessible.
<keithamus> masonf: everyone does it differently, some don't do it at all
<keithamus> una: creating a uniform way for everyone to do it would be good then
<keithamus> masonf: that's what I am proposing - using the tab key
<astearns> ack lwarlow
<keithamus> lwarlow: I don't think this functionality of partial interest is worth it. If there was a clear user need, then I could see it. If in practice, it doesn't provide the benefits we thought it did then +1 to removing it
<keithamus> .. the problem with using the arrow keys is in makes sense in some patterns but not others. This is the general solution so we should do the minimum subset. e.g. a menu element might make sense for arrow keys but others might not.
<una> q+
<keithamus> .. in the case where you're quickly tabbing through stuff there is the interest show delay property, which alleviates most of these problems. Especially if we end up in the situation again where it's keyword based - where the browser can customise what this means to them, then it even more alleviates this problem
<keithamus> .. by the time you reached the next element it would have gotten rid of it, so it's fine in the tab order.
<keithamus> masonf: there are delays, they are numbers, the browser can override them. There's also always the esc key, you can always use that to get rid of these.
<keithamus> lwarlow: what if its popover=manual?
<keithamus> masonf: it loses interest, which is specified to close the popover
<astearns> ack una
<keithamus> una: the delays don't solve this, sometimes the user wants to see the content, without interacting with a follow. Escape might solve it.
<astearns> ack bkardell
<keithamus> bkardell: I am a little concerned there's a lot of speculation about what we should do and not a lot of how this must work. Like is there a cowpath? It seems to me like standards aren't the greatest venue to come up with new ideas. How does this work in mac or linux?
<masonf> qq+
<keithamus> .. there might not be a solid answer, or a very small N of 1 or 2. People who use the affordances for tabs, how they should work in terms of tab stops, you'll get two answers.
<keithamus> .. there's not necessarily a right or wrong. Just differing opinions.
<keithamus> .. we find this out through use. So if the pattern is used a lot on desktop, or super common patterns, or some kind of study.
<una> q-
<keithamus> .. Have implementations, do user testing, publish the research and see how we arrived to that answer.
<lwarlow> So Facebook I think has this and they have this partial interest functionality I believe (because one of their engineers proposed this). So might be worth seeing what he thinks again?
<keithamus> .. We do studies in origin trials and things. But I don't think people get to see how that works.
<astearns> ack masonf
<Zakim> masonf, you wanted to react to bkardell
<keithamus> masonf: 1. We've done a lot of studies, mostly on the web, about half the sites surveyed weren't keyboard accessible and we shouldn't follow that cowpath. The other half, roughly, do the tab-stop solution. Native... I imagine add things to tabstop but I haven't seen any magical behavior
<keithamus> .. lastly we're working with folks to produce studies about both
<astearns> ack keithamus
<masonf> keithamus: motivation behind partial interest was the result that Github did (which I can cite on request). Github has the tab stop pattern, users found it annoying.
<masonf> keithamus: there is a group of users that use keyboard, the tab stop pattern was annoying. We could have tweaked the delays, perhaps needed more work there. But we don't want to make things timing dependent. People respond differently to timing.
<masonf> keithamus: Github went with shortcut. Problem is that it's not discoverable. Less annoyed though. I'm not opposed to the tab stop model. My worry is that people get user complaints.
<masonf> q+
<bkardell> citation would be great, yeah
<masonf> keithamus: last thing: around focus, there's a problem that focus should never be obscured. This can be the case with these popovers.
<masonf> keithamus: if you're adding delays, and you move focus out of the popover, and the popover is obscuring focus, that's WCAG 2411 violation.
<masonf> keithamus: you need to know as soon as you leave, you need to close the popover
<astearns> ack masonf
<lwarlow> q+
<keithamus> masonf: a few things about the browser based feature might mitigate these issues
<keithamus> masonf: the browser can tweak these settings, so making delays longer, or infinite.
<keithamus> q+
<keithamus> .. the focus question....
<keithamus> .. escape loses interest immediately might help this situation
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<keithamus> .. the interesting question is whether the popover when losing focus is obscuring the popover... ???
<keithamus> .. I hope the feature includes things to mitigate these.
<astearns> ack lwarlow
<keithamus> lwarlow: partial interest was also from one of the facebook engineers who joined openui.
<keithamus> .. possible it's worth discussing with them again
<keithamus> .. see if they have more insights
<keithamus> .. as an example of a website that does this.
<astearns> ack keithamus
<masonf> keithamus: couple comments: the preference thing I'm dubious of. I don't think people interact with preferences a ton.
<masonf> keithamus: it might be worth exploring - are you familiar with "red teams". Try to break the feature. Interesting idea: call for objections.
<masonf> keithamus: we're constantly producing demos to show how it works, but we could instead try to break the feature. How can we do bad things, then try to mitigate problems.
<masonf> keithamus: try manual popovers, do wonky CSS stuff, occluding the focus, etc.
<masonf> keithamus: Origin trials are interested customers, and don't try to break it. Maybe try to approach people who don't like it and see why.
<keithamus> astearns: given the choice between added to tab order vs some less discoverable key, I am in favour of adding it to the tab order. I worry there might be some other way of activating it that would be more accessible that might be a good default.
<keithamus> astearns: Given what we know now, masonf's path of "figure it out later" might make sense but more investigation that this isn't a bad default is warranted.