[Interest invokers] Keyboard inputs

[mfreed7]

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)?

[lukewarlow]

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]

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.

[nmn]

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.

I want to push back on this a bit. I think the "hovercard" pattern means showing the interesttarget on focus. The behavior is also consistent with how the content appears on "hover" when considering mouse interactions. There is also a major discoverability problem to hide the interesttarget behind a special hotkey.

However, I do agree with this part:

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.

I think the way to solve this conflict is by having two states for the interesttarget:

1. An inert preview only
2. An "activated" state where it behaves more like a dialog and the interactive elements within become focusable.

We've used a similar pattern for Facebook recently and the pattern seems to be working very well. Here are some of the details:

• When a HovercardTrigger link is focused, the Hovercard becomes visible, but it is inert and all the content withing is aria-hidden and unfocusable.
  • There is one exception: There is a small helper text that says something like "press the up arrow key to access link shortcuts"
  • This helper text has an id and it is used as the aria-hint value on the HovercardTrigger link
• When the user presses the chosen hot-key, (up and down arrow keys in our case), the Hovercard becomes "active" and starts to behave like an interactive modal dialog.
  • The focus is moved to the first interactive element within the hovercard.
  • There is focus trapping
  • There is visible Close button
  • Pressing escape closes the hovercard and returns the focus to the HovercardTrigger link
• Pressing escape also always hides the Hovercard inert preview. Giving the ability to use the up and down arrow keys for scrolling again.

Extra Notes

• I do see the possible concern that showing a preview on focus can feel overwhelming and -busy, but I think the focus order problems can be solved by having the two "preview" and "active" modes for the interest target.
• The "visual treatment" for what appears on focus is up for debate. I could see an argument for letting the UserAgent choose the best treatment here.
  • It might make sense to show the entire hovercard (in an inert state) in some scenarios;
  • and, to show a much more subtle indicator in other scenarios.
• There are concerns today that taking over the up and down arrow keys is problematic because they are normally used for scrolling. Our rationale was that it is more discoverable for keyboard users that are used to Focus Group patterns. As a web standard and different hot key could be chosen which users would learn to use.
• There is a question about the "delay" after focusing a link similar to the delay after hovering a link.
• One big benefit of this approach is that it unifies the mouse and keyboard interactions and makes it easy to switch between the two input methods easily.
  • Hovering on the link shows the inert preview of the hovercard
  • Hovering on the hovercard "activates" it and moves focus to it behind the scenes.

[mfreed7]

Thanks for the points about keyboard focus. Let's Agenda+ to discuss it.

I've also added a bit more detail about the current direction to the explainer, in this PR: #1155. Of course, any/all of that can be changed if we need to change directions.

[css-meeting-bot]

The Open UI Community Group just discussed [Interest invokers] Keyboard inputs.

The full IRC log of that discussion

<gregwhitworth> Zakim, start meeting
<Zakim> RRSAgent, make logs Public
<RRSAgent> I have made the request, Zakim
<Zakim> please title this meeting ("meeting: ..."), gregwhitworth
<gregwhitworth> meeting: Open UI Telecon
<gregwhitworth> masonf: there are discussions on keyboard to "show/lose" interest
<gregwhitworth> masonf: the explainer is up to date
<gregwhitworth> masonf: it says to show interest with a hot key and lose it with another hot-key (most obvious is escape) and we denote that the focus rect should change should occur
<gregwhitworth> masonf: we outline the pros and cons of this, is that it isn't easily discoverable that there is a special key to press when you get to these elements
<brecht_dr> q+
<gregwhitworth> masonf: the key other contender is to show the interest on focus after a delay
<gregwhitworth> masonf: the tricky thing there is that it can be annoying when traversing through the document and items in the card and interest causes a change in the tree it can cause other problems
<gregwhitworth> nmn: all of the things you said still hold with my proposal
<gregwhitworth> nmn: when you're focused on the trigger, you mentioned a different indicator, the idea is to have a "rich tooltip" to provide information and is inert and won't provide any additional tree changes
<gregwhitworth> nmn: you will still have to use a hot-key to invoke it but you'll be able to see it without having to use the hot-key
<gregwhitworth> nmn: the benefits are the quick short-cuts in the hover card
<gregwhitworth> nmn: the current solution doesn't give us the first value in order to get the short information of what you may/may not be able to achieve with the hover card
<masonf> q+
<gregwhitworth> nmn: we've shipped this to about 50% of Facebook and it works this way at the moment
<gregwhitworth> ack brecht_dr
<masonf> ack brecht
<nmn> +1
<gregwhitworth> brecht_dr: a question, we were talking about the trigger being a key and someone mentioned keys and noted that arrow keys and that makes sense since commonly in a "select" when you're within in it the arrow keys traverse up and down
<gregwhitworth> brecht_dr: I like the premise of another focus ring to inform the users
<gregwhitworth> ack keithamus
<nmn> q+
<gregwhitworth> keithamus: seems like this feature is dedicated to rich tooltips and we're steering towards interactions based on rich tooltips and I wonder if simpler scenarios can just be focus and if it's a keyboard user they should get that information quickly in non-rich scenarios
<gregwhitworth> keithamus: this begs the question, is there a way to automatically determine if it is a "rich tooltip" and allow two different modalities
<gregwhitworth> keithamus: if it's plain text we have one behavior and elect to opt-in to different behaviors
<gregwhitworth> +1 to Keith on other usecases
<gregwhitworth> ack masonf
<gregwhitworth> masonf: I am definately aiming to solving all 3 usecases, hovermenus, plain text and hover cards
<gregwhitworth> masonf: your point is a good one for plain tooltips this seems a bit heavy
<flackr> q+
<gregwhitworth> masonf: my main concern is the interactive ones
<gregwhitworth> masonf: there already is a switch for plain verse interactive content within it for accessiblitiy reasons defined by ARIA
<gregwhitworth> masonf: I kind of like the idea, but honestly my concern is the complexity of it and landing this in standards
<scott> q+ for aaron
<gregwhitworth> masonf: that is a fairly complex set of interactions that will be hard to standardize
<gregwhitworth> masonf: up and down arrow may be a problem so you'll need a modifier key since that will impact scrolling
<gregwhitworth> masonf: in the text of your proposal it sounds like the hover card is a modal dialog
<flackr> q-
<aaronlev5> q+
<gregwhitworth> masonf: that may be ok but I would point out where we shouldn't support dialog on interest target but we may want to re-open the issue since it sounds like the hovercard matches that usecase
<gregwhitworth> masonf: there is also a comment on the proposal on moving focus based on the mouse and that's normally a "no-no"
<gregwhitworth> ack nmn
<gregwhitworth> nmn: moving the focus based on mouse-issue...
<gregwhitworth> nmn: actually the dialog one first
<gregwhitworth> nmn: I'm trying to make it work today and with the tech today it made sense for it to be a dialog for us
<gregwhitworth> nmn: a way to think about it is there are two seperate views on the trigger
<gregwhitworth> nmn: a rich tooltip that shows when you hover and when you interact with it the content changes and it becomes more rich
<gregwhitworth> nmn: if you hover it, it is aria-hidden and inert and a aria-hint and the visual user with a mouse when you hover it shows you the view
<gregwhitworth> nmn: we wanted to make it so that if you have keyboard and mouse you get the same experience
<gregwhitworth> masonf: quick clarification, it doesn't need to be a dialog? You'd only lose the focus trapping?
<gregwhitworth> nmn: yes, although focus trapping allows us to keep the traversal simple
<gregwhitworth> nmn: this is a focus group so once it's invoked you can use the up and down arrow and the content will work. That may not translate to the web standards
<gregwhitworth> nmn: so it may not invoke in the same location to where physical direction keys may not make sense
<gregwhitworth> nmn: we hotly debated scrolling and arrow keys
<gregwhitworth> nmn: where we landed was to use the up and down arrow keys but if you press the escape always gets you back and you can use the arrow keys
<gregwhitworth> nmn: it was considered an OK trade-off
<gregwhitworth> nmn: if it was more wide-spread we would need to think of a different solution. In the past we chose a keyboard use-case and used a shortcut and unless you were using an AT it wasn't discoverable
<gregwhitworth> q?
<gregwhitworth> ack scott
<Zakim> scott, you wanted to discuss aaron
<gregwhitworth> ack keithamus
<keithamus> https://images.expertreviews.co.uk/wp-content/uploads/2023/06/keychron_v4_1_1.jpg
<gregwhitworth> keithamus:This image is going to unveil arrow keys, this is a 50% keyboard that may not have arrow keys
<gregwhitworth> keithamus: what do we do in those circumstances?
<aaronlev> q-
<gregwhitworth> masonf: how does a user with that keyboard scroll the page?
<gregwhitworth> keithamus: the w,a,s,d keys, etc
<gregwhitworth> flackr: we do have presidence with select and radio groups of using arrow keys
<gregwhitworth> nmn: The rich tooltip usecase and I was listening to the original proposal and one thought that occurred to me was if I wasn't trying to define for ALL input modalities, one would be for the rich tooltip and one for the menu
<aaronlev> Do we need to think about remote control scenarios where the user is using arrows to navigate between items?
<aaronlev> maybe long press in that case
<gregwhitworth> nmn: because then if you don't want the over-bearing rich experience you can just show a ring and then you can show the full card across that spectrum. I don't see how that works on touch screen
<gregwhitworth> masonf: key thing I want to do is try and limit the amount of options because there will be foot guns
<gregwhitworth> masonf: the goal is that "you've thought of hover and it works and then it works for everyone else"
<gregwhitworth> keithamus: you could do something like "eager" allows mouse or keyboard events will display the tooltips immediately
<gregwhitworth> keithamus: if you knew this you could have interactive content within the tooltip would block focus and then you can put a warning to devs in the console that it's not accessible
<nmn> q+
<gregwhitworth> keithamus: then you can have one that is like "intentional" but the delays are longer and the abstraction still exists but there are popover hint vs popover auto
<masonf> q+
<gregwhitworth> ack nmn
<gregwhitworth> nmn: in your example for the eager situation if you want interactions after explicitly intentions somehow how would that be handled?
<gregwhitworth> keithamus: eager is the menu example, you want submenus to open on hover and on focus and probably on touchstart, holding down, etc
<gregwhitworth> keithamus: maybe it's the wrong thing to think that it's exclusive to think that it's only for non-rich since it covers menus
<gregwhitworth> keithamus: I don't think that answers your question
<gregwhitworth> ack masonf
<flackr> q+
<scott> q+
<gregwhitworth> masonf: for the mouse specifically, hovering over an element and waiting for a time that's not a problem and there is no distinction between interactive and not interactive wheras you need that for keyboard
<gregwhitworth> masonf: so maybe you have something like "immediate" and if you have a submenu when I focus it I want to show it and I want it to be active
<gregwhitworth> keithamus: ironically the arrow keys would be the way
<gregwhitworth> keithamus: I have to use the arrow keys to traverse into the submenu
<gregwhitworth> masonf: the arrow keys matter depending on the direction
<gregwhitworth> ack flackr
<sarah6> q+
<gregwhitworth> flackr: I've heard disntinguishing between rich and non-rich. I think if it's not interactive it doesn't matter so we may not need to distinguish this
<gregwhitworth> flackr: it may be valuable to not having the tooltip precluding other potential targets
<gregwhitworth> flackr: forcing content to be inert may be valuable to explore for some of these automatic usecases
<gregwhitworth> flackr: regarding arrows impacting scroll I don't think it's a huge deal as we already do this in select and radio groups, the page stops scrolling
<gregwhitworth> masonf: there are a few exceptions that those are annoying if you have numerous of these
<gregwhitworth> flackr: how common is that though where you want to scroll it when you tab to it
<gregwhitworth> masonf: any time you want to scroll
<gregwhitworth> ack scott
<nmn> link to our implementation: https://www.icloud.com/iclouddrive/0cbA2oHnz7eTJXZtcoYUS-cVw#Screen_Recording_2024-11-21_at_6.35.59_PM
<gregwhitworth> scott: I'm going to respond to scrolling first, I completely understand where you're coming from and those are 20+ years of known things but if things like links and buttons no longer works
<gregwhitworth> scott: that's not good and we shouldn't do that
<nmn> q+
<gregwhitworth> flackr: let's say if you have already shown interest and you've reached the limits in that container once you're at the end of the options it can then scroll
<masonf> q+
<gregwhitworth> scott: yes that puts it back on the user though
<gregwhitworth> scott: the popup is also scrollable and they're scrolling that to then scroll the page then they can press escape, etc
<brecht_dr> q+
<gregwhitworth> scott: so we used to be able to scroll the page and now they can't but I want to make sure that we don't do something that when we compount on top of each other it becomes a problem
<gregwhitworth> scott: now back to what I wanted to talk about
<gregwhitworth> scott: I don't understand the menu usecase
<gregwhitworth> scott: for submenus and such I wouldn't expect a command to open one
<gregwhitworth> scott: if you're navigating through them and there is an indicator I would invoke it or press the arrow key to open that opens submenu
<gregwhitworth> scott: in most of those scenarios they are solely to open the sub-menu
<gregwhitworth> masonf: I'm glad that you brought it up is because it's something that is commonly hover trigger; maybe we should get rid of it but it delays
<gregwhitworth> q+
<gregwhitworth> masonf: activation almost always opens a submenu
<gregwhitworth> masonf: only question would be if it's harmful or not
<gregwhitworth> scott: my worry is that if this becomes a standardize thing then there is this hotkey to open it and things that should just be to "hit enter" we move away from it and it complicates it
<gregwhitworth> scott: should popover hint on hover be how this is exposed for sub menus. We don't need interest targets
<gregwhitworth> masonf: for popover hint you need a way to connect them I think
<gregwhitworth> ack sarah6
<gregwhitworth> sarah6: what I wanted to discuss around to automatically detect if something is rich or not
<gregwhitworth> sarah6: I actually think it's more common than rich verses not
<gregwhitworth> sarah6: if you have a static popup that's really big and have magnification they'll want to kill their computer
<gregwhitworth> sarah6: sometime it will be a short popup and it will have links in there but we don't intend for people to "really" go in there too often but that may be something that authors will need to determine
<gregwhitworth> sarah6: I think the browser figuring this out will be very hard
<gregwhitworth> masonf: quick follow up is that if we give authors control they may end up doing the wrong thing
<gregwhitworth> masonf: if we just had a way to have the authors to say "this is complex" and it allows us to force it to be inert
<gregwhitworth> masonf: the usecases you shared are good as they show the problems that can occur
<gregwhitworth> q?
<gregwhitworth> ack sarah
<gregwhitworth> ack keithamus
<gregwhitworth> keithamus: I agree with sarah
<gregwhitworth> keithamus: it has to do with size and impacting hiding content
<gregwhitworth> keithamus: but we need to solve issues with UI that are ephemeral and sub-menus sort of fall into this pattern
<gregwhitworth> keithamus: the menus that I typically interact with the hover will open the sub-menu and focusing it will open the sub-menu
<gregwhitworth> keithamus: the interestarget and commandfor both pointing to the user into the menu as there are subtle differences as that is what I'd like to see a menu coded
<gregwhitworth> nmn: quick response
<gregwhitworth> nmn: on the scolling and arrow keys and you get onto a script that is trigger you can press escape key or arrow key down twice then it will go back to scrolling the page
<sarah6> q?
<sarah6> q+
<gregwhitworth> nmn: if you make the popover scrollable then that is a problem
<gregwhitworth> nmn: I think it's fine to try something different than arrow keys if it's a web standard and people get used to it
<masonf> ack nmn
<gregwhitworth> nmn: another thought I keep having about the inert usecase
<gregwhitworth> nmn: maybe we give the useragent control over what shows up
<scott> when a screen reader is running (on windows) space works the same as enter. so if space were to be used, then screen readers would need to change to account for this
<gregwhitworth> nmn: our initial scenario was showing the hovercar at half opacity upon hover to inform the user that they can invoke it
<gregwhitworth> nmn: the useragent can do some type of graphical change to inform the user and that may impact the size of what you show, etc
<gregwhitworth> masonf: I keep trying to map this back to how we would "standardize this" and there is a discoverability problem with hot keys. But my concern is that the standard may not allow this so it doesn't get in the way
<sarah6> scott I think screen readers would need to have a fully separate way to indicate interest, since most keyboard options would already do something
<brecht_dr> q-
<gregwhitworth> masonf: maybe there is a pseudo element that when it's inert there can be a hot-key that allows the user to use it and you can change the visibilty
<gregwhitworth> nmn: *thumbs up*
<gregwhitworth> nmn: sounds better to me and I posted a link to a screen recording
<brecht_dr> because of what mason said.. +1
<masonf> ack mason
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack sarah
<gregwhitworth> sarah6: on regular down arrow keys we have a number of keys that can be used
<gregwhitworth> sarah6: navigation style stuff or tree or some other role, lists, interatctive lists, etc
<scott> q+ also confused about the inert talk
<gregwhitworth> sarah6: scott reminded me that enter and space trigger clicks in certain modes and space would be difficult there
<gregwhitworth> sarah6: there is a lot of AT that would need their own way to show interest
<gregwhitworth> sarah6: zooming software could override their own way to denote interest
<gregwhitworth> sarah6: will there be an event that they could listen to in order to possibly do that?
<nmn> +1
<keithamus> q?
<keithamus> q+ scott
<gregwhitworth> masonf: please open an issue on that as that sound interesting
<sarah6> ack me
<gregwhitworth> ack keithamus
<gregwhitworth> ack keithamus
<gregwhitworth> scott: I want to understand the talk about inert a bit more
<gregwhitworth> scott: making the popup make it inert, how would they know it's existed but it's inert
<gregwhitworth> scott: assume someone that is low vision with zoom and the popup is inert they won't be able to access it
<gregwhitworth> scott: maybe I've missed it
<gregwhitworth> masonf: we're coming close to the end of the meeting but I would like to summarize what I've heard
<gregwhitworth> masonf: the behavior is after a delay and you've focused an element that has an interesttarget that target will be shown but force it to be inert
<gregwhitworth> masonf: that makes it so that it doesn't add additional tab stops
<nmn> The actual relevant link: https://www.icloud.com/iclouddrive/093R9zAV5ic-A_hlfjXOBZxBw#Screen_Recording_2024-11-20_at_4.55.29_PM
<gregwhitworth> masonf: however when it shows it, there will be a pseudo element that will allow you to have a hot-key that will remove the inertness of it and you can engage with the content
<gregwhitworth> masonf: along the way there was a suggestion on the first state that aria-hint that informs the user on how to invoke it and remove its inertness
<gregwhitworth> scott: an ARIA details would not be there if it's inert
<gregwhitworth> scott: ok, that's making a bit more sense
<gregwhitworth> masonf: no that's good
<gregwhitworth> masonf: for plain tooltips that don't have interactive content they stay inert and their accname and description are a part of the triggering element
<masonf> q?
<gregwhitworth> nmn: I added a new link that is a bit more dramatic than what we shipped
<masonf> ack scott
<gregwhitworth> ack scott
<gregwhitworth> masonf: I'll take everything and try to summarize it in the issue
<gregwhitworth> Zakim, end meeting

[mfreed7]

Awesome discussion today - thanks for the great feedback. Based on that conversation, a somewhat new direction seems to be emerging, along the lines of @nmn's comment. I've tried to summarize that new direction here - please feel free to correct me where I missed something, or if you have additional suggestions for improvement:

• trigger "interest" in the element when it receives keyboard focus, after interest-target-show-delay seconds.
• "lose interest" in the element when focus leaves the interest invoker or its target, after interest-target-hide-delay seconds.
• When activated via keyboard only (these additional behaviors do not apply when activated via mouse or touchscreen):
  • the target popover is shown, but is rendered with interactivity: inert. This keeps the popover from inserting any additional tab stops into the sequential focus navigation order.
  • a hotkey (e.g. ALT-UP) will cause the popover to be "fully activated" which removes the interactivity rule. This makes it non-inert and available in the focus navigation order. Potentially the first focusable element within the popover should also be focused at this point? Maybe not.
  • a new pseudo class (e.g. :has-partial-interest or similar) will match on the target popover only when it is in the "partially activated" inert state. It's possible this makes more sense (semantically) to match on the interest invoker, but it seems easier to use on the target.
  • a new UA stylesheet will will be added: :has-partial-interest::after {content: "Press ALT-UP to activate this content"; interactivity: auto} which adds (developer-overridable) hints to the user about the hotkey. Note the interactivity value here - that makes the hint text non-inert so it shows up in the a11y tree. Additionally it should likely get special treatment in the a11y tree so that it gets announced.

I believe this meets the following use case requirements:

• Better user activation story for non-interactive "tooltips" that shouldn't be so hard to activate. I.e. just focus an element to see the tooltip.
• Better discoverability story for rich "hovercards", because of the ::after text.
• Less risk of annoyance for keyboard users, since rich hovercards don't insert themselves automatically into the sequential focus order.
• Ability to override inertness for key use cases, such as menus (where the author would add :has-partial-interest {interactivity:auto} to show immediately on focus) and "large/obtrusive" tooltips (where the author would add :has-partial-interest {display:none} so content doesn't show on focus).
• The partial interest state can be indicated to the user (e.g. with :has-partial-interest {opacity:50%}) if desired, and the helpful text about the hotkey can be customized or hidden if desired.
• The default state "just works" for keyboard users, in the case that the developer just tested/developed using a mouse, and didn't do any of the above.

A few side notes about the conversation:

• We talked about the part of @nmn's comment about the hovercard being a modal dialog. He pointed out that this was just to be able to build this functionality with existing tools (i.e. the lack of interesttarget), and isn't a desired outcome. So it's ok to maintain our previous position that only popovers are supported by interesttarget, and not dialogs.
• @smhigley will open a separate issue about the potential need to be able to both cancel "interest" via preventDefault() and also directly trigger interest programmatically. This is to meet the needs of (among other things) zooming software, which might want to provide a more affirmative way to show interest that doesn't get in the way.
• The menu use case continues to feel a bit bolted on. We should continue to evaluate that use case as we go along and make sure it still makes sense, and is right to build with this API. I think it still makes sense, and the above is actually an improvement by a bit. But let's keep discussing.

[nmn]

Great summary of the discussion and I'm loving the new details. The whole idea of "interest targets" is starting to feel cohesive and making sense.

Some comments and responses to some interesting bits:

a new pseudo class (e.g. :has-partial-interest or similar) will match on the target popover only when it is in the "partially activated" inert state. It's possible this makes more sense (semantically) to match on the interest invoker, but it seems easier to use on the target.

Thinking of the use-cases I would want this on the target more than the invoker. The invoker can already use :hover and :focus-visible instead.

Additionally it should likely get special treatment in the a11y tree so that it gets announced.

Adding context: our current implementation uses aria-describedby which announces at a low-priority and various screen readers have the option to turn off such announcements. I think this is the right level of importance for this announcement as once the pattern is commonplace, users may not need it anymore.

Ability to override inertness for key use cases, such as menus (where the author would add :has-partial-interest {interactivity:auto} to show immediately on focus) and "large/obtrusive" tooltips (where the author would add :has-partial-interest {display:none} so content doesn't show on focus).

These pseudo classes tie everything together SO WELL!!

hovercard being a modal dialog... and isn't a desired outcome.

Just want to clarify that I'm more ambivalent on this issue. I missed the previous discussion on the reasons for choosing popover over dialog, but it might worth another once the rest of the decisions are made, so we pick the best a11y role given the overall interaction model we land on.

The menu use case continues to feel a bit bolted on.

Many of the use-cases I can think of hover interactions that are purely menus would probably be solved by having a CSS way to access top-layer.

However, I can also think of many use-cases where interest-target is better suited for menu-like interactions. One that comes to mind is the alternate key options you see when you long press a key on a phone's virtual keyboard. It's a something that works with a simple click. But if you linger on it (with focus/hover/or press), it reveals some additional options.

Side-note: "linger" feels like a good word to describe all the "interest" interactions.

[css-meeting-bot]

The Open UI Community Group just discussed [Interest invokers] Keyboard inputs.

The full IRC log of that discussion

<brecht_dr> masonf Last time we talked about this, i'd like to timebox this tot 15mins. The topic is keyboard activation of interesttarget
<brecht_dr> masonf In contrast on what is written in the explainer at the moment. the new proposal is rather than a hotkey usage, a focus on the element will trigger the target
<brecht_dr> masonf The nuance is that it might be anoying if it is a hovercard with focussable items inside of it
<brecht_dr> masonf To avoid that: when you show interest with a keyboard, any popover that is shown as a result of that will be inert
<sorvell> q+
<brecht_dr> masonf and at that point a hotkey will activate it, which will remove the inert
<brecht_dr> masonf One thing we'll need is a new pseudoclass for this semi-activational state
<brecht_dr> masonf The other is a hint for screen readers to give the information on how to toggle the interesttarget
<lwarlow3> q+
<brecht_dr> masonf there was a quesion on wether or not we should support modal targets, for now we only have popovers as a possible target for interesttarget
<keithamus> q+
<brecht_dr> masonf If we can, i would love to have a resolution on this being a good path forward
<gregwhitworth> ack sorvell
<brecht_dr> sorvell: I'd love to see this in explainer form
<brecht_dr> sorvell: Is there any relationship between the behavior between the distinction of keyboard focussing and the behavior of focus visible, which has a similar distinct behavior on how something gets focussed
<brecht_dr> masonf: There is a desire to change the default focus styling to show that's special (for example another focus ring)
<brecht_dr> sorvell: If it's a new behavior that goes along with it, that makes sense
<gregwhitworth> ack lwarlow
<brecht_dr> lwarlow3: I can't see how a modal dialog could, as this modal dialog inerts everything else. because your whole page becomes inert. You would need to have a dialog in a special mode
<sarah1> q+
<brecht_dr> lwarlow3: Given the amount of bugs we have with dialog at the moment, i think it will be very hard. I also think it doesn't make sense
<nmn> q+
<brecht_dr> lwarlow3: imo, i think this feature is already rightly so, complicated enough
<gregwhitworth> +1
<brecht_dr> lwarlow3: It would also open a lot of discussions
<brecht_dr> lwarlow3: I think the hasinterest should be on the trigger button.
<brecht_dr> lwarlow3: There is a desire to go: here is my trigger button, i want to style my target element
<brecht_dr> lwarlow3: I think has and has-partial interest should be on the trigger element
<brecht_dr> masonf: The hard part is that i wanted a UA styling rule that adds the hotkey. do you know there is an issue about adding a CSS selector for the target
<brecht_dr> lwarlow3: I will look for it, and open it if it's not there
<brecht_dr> masonf: To clarify luke, we should not allow modal dialogs, normal dialogs with popover attribute are still fine
<gregwhitworth> ack keithamus
<brecht_dr> keithamus: I agree with the modal dialog thing. I am concerned about the interaction. worried that users won't like that.
<brecht_dr> keithamus: I might also be using my mouse and at the same time using my keyboard, this is what confuses me about the current distinction of input modalities
<brecht_dr> masonf: If you are only using your mouse, you can't require a hotkey to activate it. Hover with the mouse, you have a fully popover, when roaming around with my keyboard, it would only partially show the popover
<brecht_dr> keithamus: when I press tab while moving my mouse and the cursor is wiggling around, i might be accidentally activating popovers while i'm pressing tab through the page. I don not want the tab-flow to change while using the accidental manouver of the mouse. I do think it should show partial interest, and moving the mouse in the popover could show
<brecht_dr> fully interest. The same could be with a keyboard, show partial interest and use a hotkey to activate full interest
<gregwhitworth> q?
<masonf> q+ scott
<brecht_dr> keithamus: We need a flow where both interesctions work the same
<brecht_dr> masonf: I follow
<gregwhitworth> ack sarah1
<gregwhitworth> ack sarah
<flackr> q+
<keithamus> q+
<brecht_dr> sarah1: We have been saying the word inert a few time, but i don't think litteral inert isn't the way to go. Inert = fully unfocussable. There are multiple cases where a developer would like to show partial interest
<brecht_dr> sarah1: Following that up with an action to show the full interest. There are many input modalities: pointer, voice, etc
<brecht_dr> sarah1: We were thinking that the appear on focus just not to be in the tab order
<brecht_dr> masonf: Is there an existing capability like that?
<gregwhitworth> ack scott
<brecht_dr> sarah1: Sort of changing tabindex
<brecht_dr> scott: There are already instances of popups where people only partially see them, and then they can use arrow key down just to enter in them
<brecht_dr> scott: How would someone be aware that this semi-inert thing exists?
<brecht_dr> scott: If we just take it out of the taborder, it would make things less difficult
<gregwhitworth> ack nmn
<brecht_dr> nmn: I think it's my fault for using the word inert. Because it has a tabindex of -1 over the whole line
<brecht_dr> mnm: We could make it inert, but not the container itself because this container has some sort of interaction where you can hover over it, but the content inside is actually inert
<masonf> q+
<brecht_dr> nmn: Hover triggers partial interest, focus as well. and when in partial interest you can use a hotkey or hover the target to make it fully active. The strange part is that there are two interactions on hover
<brecht_dr> nmn: first on the button, then on the card
<brecht_dr> nmn: there was some testing on when people use a keyboard alone. The idea was that when you fully activate the interest target, the focus moves into that hover card. That behavior is consistent with modal dialogs
<brecht_dr> nmn: We change something from role tooltip to something like a dialog when it is activated. From an interaction point of view, i feel that a modal interaction is cleaner compared to a popover
<masonf> q+ luke
<brecht_dr> nmn: With focustrapping, we noticed that you have a better idea of where you are at
<masonf> ack flackr
<gregwhitworth> Chair: Mason Freed
<brecht_dr> flackr: I wanted to point out that inert can't be hovered, it has pointer-events: none;
<brecht_dr> flackr: But i like the idea from Sarah, there is one additional complexity there. One thing I wonder is if the content would be read when it's not inert
<brecht_dr> sarah1: When you're talking about navigation efficiency, I would still opt for exposing it. You see the thing on the screen, so not getting there is weird. Also people combining screen readers with mouse
<nmn> q+
<brecht_dr> sarah1: People ignore instructions all the time such as "press this key to get more information". There are multiple instances of those in screen readers. For popover, I just think it should be there, there are many ways to skip the popover
<brecht_dr> nmn: The reason we didn't want it announced was the concern that there would be too much announced
<brecht_dr> nmn: Which is why we wanted to keep it with announcing that something is there. what would it announce? the title? or everything?
<brecht_dr> sarah1: The screen reader won't read anything when it opens, only when moving your virtual cursor inside of it. we could also talk with screen reader vendors on skipping capabilities
<masonf> ack keith
<nmn> q-
<flackr> Not just "be able to" navigate to it, but "must" navigate through it right?
<brecht_dr> keithamus: The target pseudo's can't be pseudo elements right? as this could affect children
<nmn> flackr +1
<brecht_dr> keithamus: I think there probably needs to be a pseudo-class on both the trigger and the popover
<lwarlow3> q-
<brecht_dr> masonf: Naming those classes might get hard
<brecht_dr> masonf: This magic tabindex thing, doesn't necessary need to be so magic. The magic tabindex inert would need a way to be overwritten with CSS.
<masonf> ack mason
<masonf> ack luke
<nmn> discussing #1164

[mfreed7]

Alright, another great discussion. Here's another summary of the (newish) direction the discussion is headed:

• The general direction of [Interest invokers] Keyboard inputs #1133 (comment) is still a good one, with a few tweaks.
• We reiterated (mostly) that interesttarget should only invoke popovers (including <dialog popover>) but should not invoke modal dialogs. Mostly the reasoning is the same as before, with the added point that with the new "partially activated" state, a modal dialog would cause the entire page to be non-interactive.
• The :has-interest and :has-partial-interest pseudo classes might need to match on both the trigger and the target. Likely with different names for trigger and target. Perhaps :has-interest-target and :has-partial-interest-target for the targets? Those aren't great, because "interest-target" itself is confusing.
• We roughly reached a conclusion that both keyboard focus and mouse hover should trigger the popover in "partial interest" mode. And then hitting the hot-key with the keyboard, or hovering the target popover with the mouse, should fully activate the popover. This enables a number of use cases where both the keyboard and the mouse are in use. I presume this also likely means the same is true for showing interest via long-press on touchscreen?
• The point was made that perhaps interactivity:inert isn't the right thing for "partial interest" popovers. It's too heavy-handed: it removes contents from the a11y tree, it adds pointer-events:none which makes hover impossible, etc. What's needed is a new CSS thing that behaves as if everything in the sub-tree has tabindex=-1, without actually sprouting attributes everywhere. (I will raise a CSS issue for this. @smhigley to help me with any other potential use cases, other than this issue, please. 😄 )

I'm going to get started incorporating the above into the explainer, so please speak up if you have objections.

[nmn]

Great summary!

Small addition to the second point:

We reiterated (mostly) that interesttarget should only invoke popovers (including ) but should not invoke modal dialogs. Mostly the reasoning is the #1064 (comment), with the added point that with the new "partially activated" state, a modal dialog would cause the entire page to be non-interactive.

If we were to use modal dialogs, we would have to only use that role for "full-interest", and we would need an "inert" or some other role during "partial-interest".

We are pretty much in alignment that one way (inert) or the other (focus-index="-1"), the interest targets will not be part of the focus tree by default and will require some kind of explicit keyboard interaction to "activate".

In such a scenario, the question is mostly about the best interaction pattern for when the focus is within the interest target. I think depending on the use-case a focus trap may or may not be desirable.

• For interest targets that behave like "addendums" having the focus move back out and to the next element in the tree makes sense.
• For interest targets that are more like "mini pages", a dialog-like focus trap might make more sense where you need to explicitly escape back out.

---

Also a question about inert.

Assuming that the interest target isn't going to be focusable anyway, what is the functional difference of using inert or not?

Would the entire content of the "partial-interest" interest target be used as the aria-hint? Would that work correctly when the interest target contains complex content?