18:59:18 <RRSAgent> RRSAgent has joined #openui
18:59:23 <RRSAgent> logging to https://www.w3.org/2025/02/20-openui-irc
19:03:17 <gregwhitworth> scribenick: gregwhitworth
19:03:29 <gregwhitworth> github-bot, take up https://github.com/openui/open-ui/issues/1133
19:03:30 <github-bot> Topic: [Interest invokers] Keyboard inputs
19:03:30 <github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1133.
19:03:46 <brecht_dr> present+
19:03:57 <gregwhitworth> Zakim, start meeting
19:03:57 <Zakim> RRSAgent, make logs Public
19:03:59 <Zakim> please title this meeting ("meeting: ..."), gregwhitworth
19:04:00 <nmn> nmn has joined #openui
19:04:02 <gregwhitworth> meeting: Open UI Telecon
19:04:14 <gregwhitworth> masonf: there are discussions on keyboard to "show/lose" interest
19:04:19 <gregwhitworth> masonf: the explainer is up to date
19:04:50 <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
19:05:14 <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
19:05:14 <brecht_dr> q+
19:05:30 <gregwhitworth> masonf: the key other contender is to show the interest on focus after a delay
19:06:05 <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
19:06:22 <gregwhitworth> nmn: all of the things you said still hold with my proposal
19:07:06 <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
19:07:30 <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
19:07:42 <gregwhitworth> nmn: the benefits are the quick short-cuts in the hover card
19:08:14 <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
19:08:16 <masonf> q+
19:08:27 <gregwhitworth> nmn: we've shipped this to about 50% of Facebook and it works this way at the moment
19:08:32 <gregwhitworth> ack brecht_dr
19:08:35 <masonf> ack brecht
19:08:41 <sarah6> sarah6 has joined #openui
19:08:46 <scott> scott has joined #openui
19:09:19 <nmn> +1
19:09:22 <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
19:09:33 <gregwhitworth> brecht_dr: I like the premise of another focus ring to inform the users
19:09:38 <gregwhitworth> ack keithamus
19:09:40 <nmn> q+
19:10:44 <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
19:11:10 <gregwhitworth> keithamus: this begs the question, is there a way to automatically determine if it is a "rich tooltip" and allow two different modalities
19:11:29 <gregwhitworth> keithamus: if it's plain text we have one behavior and elect to opt-in to different behaviors
19:11:33 <flackr> present+
19:11:43 <gregwhitworth> +1 to Keith on other usecases
19:11:48 <gregwhitworth> ack masonf
19:12:08 <gregwhitworth> masonf: I am definately aiming to solving all 3 usecases, hovermenus, plain text and hover cards
19:12:27 <gregwhitworth> masonf: your point is a good one for plain tooltips this seems a bit heavy
19:12:27 <flackr> q+
19:12:32 <gregwhitworth> masonf: my main concern is the interactive ones
19:12:54 <gregwhitworth> masonf: there already is a switch for plain verse interactive content within it for accessiblitiy reasons defined by ARIA
19:13:15 <gregwhitworth> masonf: I kind of like the idea, but honestly my concern is the complexity of it and landing this in standards
19:13:22 <scott> q+ for aaron
19:13:28 <gregwhitworth> masonf: that is a fairly complex set of interactions that will be hard to standardize
19:13:47 <gregwhitworth> masonf: up and down arrow may be a problem so you'll need a modifier key since that will impact scrolling
19:14:02 <gregwhitworth> masonf: in the text of your proposal it sounds like the hover card is a modal dialog
19:14:14 <aaronlev5> aaronlev5 has joined #openui
19:14:31 <flackr> q-
19:14:38 <aaronlev5> q+
19:14:44 <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
19:15:13 <gregwhitworth> masonf: there is also a comment on the proposal on moving focus based on the mouse and that's normally a "no-no"
19:15:15 <gregwhitworth> ack nmn
19:15:24 <gregwhitworth> nmn: moving the focus based on mouse-issue...
19:15:29 <gregwhitworth> nmn: actually the dialog one first
19:15:50 <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
19:16:08 <gregwhitworth> nmn: a way to think about it is there are two seperate views on the trigger
19:16:31 <gregwhitworth> nmn: a rich tooltip that shows when you hover and when you interact with it the content changes and it becomes more rich
19:17:25 <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
19:17:43 <gregwhitworth> nmn: we wanted to make it so that if you have keyboard and mouse you get the same experience
19:17:43 <bkardell_> bkardell_ has joined #openui
19:18:02 <gregwhitworth> masonf: quick clarification, it doesn't need to be a dialog? You'd only lose the focus trapping?
19:18:14 <bkardell_> present+
19:18:26 <gregwhitworth> nmn: yes, although focus trapping allows us to keep the traversal simple
19:18:56 <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
19:19:03 <scott> present+
19:19:17 <gregwhitworth> nmn: so it may not invoke in the same location to where physical direction keys may not make sense
19:19:26 <gregwhitworth> nmn: we hotly debated scrolling and arrow keys
19:19:55 <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
19:20:04 <gregwhitworth> nmn: it was considered an OK trade-off
19:20:41 <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
19:20:42 <gregwhitworth> q?
19:20:45 <gregwhitworth> ack scott
19:20:45 <Zakim> scott, you wanted to discuss aaron
19:21:04 <gregwhitworth> ack keithamus
19:21:07 <keithamus> https://images.expertreviews.co.uk/wp-content/uploads/2023/06/keychron_v4_1_1.jpg
19:21:34 <gregwhitworth> keithamus:This image is going to unveil arrow keys, this is a 50% keyboard that may not have arrow keys
19:21:44 <gregwhitworth> keithamus: what do we do in those circumstances?
19:21:45 <aaronlev> q-
19:22:09 <gregwhitworth> masonf: how does a user with that keyboard scroll the page?
19:22:24 <gregwhitworth> keithamus: the w,a,s,d keys, etc
19:22:42 <gregwhitworth> flackr: we do have presidence with select and radio groups of using arrow keys
19:23:25 <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
19:23:41 <aaronlev> Do we need to think about remote control scenarios where the user is using arrows to navigate between items?
19:23:49 <aaronlev> maybe long press in that case
19:24:00 <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
19:24:21 <gregwhitworth> masonf: key thing I want to do is try and limit the amount of options because there will be foot guns
19:24:46 <gregwhitworth> masonf: the goal is that "you've thought of hover and it works and then it works for everyone else"
19:25:14 <gregwhitworth> keithamus: you could do something like "eager" allows mouse or keyboard events will display the tooltips immediately
19:25:51 <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
19:26:18 <nmn> q+
19:26:25 <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
19:26:30 <masonf> q+
19:26:37 <gregwhitworth> ack nmn
19:27:00 <gregwhitworth> nmn: in your example for the eager situation if you want interactions after explicitly intentions somehow how would that be handled?
19:27:24 <gregwhitworth> keithamus: eager is the menu example, you want submenus to open on hover and on focus and probably on touchstart, holding down, etc
19:27:44 <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
19:27:51 <gregwhitworth> keithamus: I don't think that answers your question
19:27:54 <gregwhitworth> ack masonf
19:28:19 <flackr> q+
19:28:24 <scott> q+
19:28:30 <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
19:29:00 <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
19:29:10 <gregwhitworth> keithamus: ironically the arrow keys would be the way
19:29:22 <gregwhitworth> keithamus: I have to use the arrow keys to traverse into the submenu
19:29:44 <gregwhitworth> masonf: the arrow keys matter depending on the direction
19:29:46 <gregwhitworth> ack flackr
19:30:13 <sarah6> q+
19:30:21 <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
19:30:37 <gregwhitworth> flackr: it may be valuable to not having the tooltip precluding other potential targets
19:30:52 <gregwhitworth> flackr: forcing content to be inert may be valuable to explore for some of these automatic usecases
19:31:23 <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
19:31:52 <gregwhitworth> masonf: there are a few exceptions that those are annoying if you have numerous of these
19:32:07 <gregwhitworth> flackr: how common is that though where you want to scroll it when you tab to it
19:32:14 <gregwhitworth> masonf: any time you want to scroll
19:32:16 <gregwhitworth> ack scott
19:32:27 <nmn> link to our implementation: https://www.icloud.com/iclouddrive/0cbA2oHnz7eTJXZtcoYUS-cVw#Screen_Recording_2024-11-21_at_6.35.59_PM
19:32:56 <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
19:33:03 <gregwhitworth> scott: that's not good and we shouldn't do that
19:33:36 <nmn> q+
19:33:44 <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
19:33:49 <masonf> q+
19:33:53 <gregwhitworth> scott: yes that puts it back on the user though
19:34:18 <gregwhitworth> scott: the popup is also scrollable and they're scrolling that to then scroll the page then they can press escape, etc
19:34:43 <brecht_dr> q+
19:34:51 <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
19:34:58 <gregwhitworth> scott: now back to what I wanted to talk about
19:35:04 <gregwhitworth> scott: I don't understand the menu usecase
19:35:16 <gregwhitworth> scott: for submenus and such I wouldn't expect a command to open one
19:35:49 <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
19:36:11 <gregwhitworth> scott: in most of those scenarios they are solely to open the sub-menu
19:36:45 <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
19:36:47 <gregwhitworth> q+
19:37:00 <gregwhitworth> masonf: activation almost always opens a submenu
19:37:21 <gregwhitworth> masonf: only question would be if it's harmful or not
19:37:57 <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
19:38:20 <gregwhitworth> scott: should popover hint on hover be how this is exposed for sub menus. We don't need interest targets
19:38:37 <gregwhitworth> masonf: for popover hint you need a way to connect them I think
19:38:44 <gregwhitworth> ack sarah6
19:39:10 <gregwhitworth> sarah6: what I wanted to discuss around to automatically detect if something is rich or not
19:39:22 <gregwhitworth> sarah6: I actually think it's more common than rich verses not
19:39:38 <gregwhitworth> sarah6: if you have a static popup that's really big and have magnification they'll want to kill their computer
19:40:15 <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
19:40:28 <gregwhitworth> sarah6: I think the browser figuring this out will be very hard
19:40:51 <gregwhitworth> masonf: quick follow up is that if we give authors control they may end up doing the wrong thing
19:41:17 <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
19:41:29 <gregwhitworth> masonf: the usecases you shared are good as they show the problems that can occur
19:41:31 <gregwhitworth> q?
19:41:35 <gregwhitworth> ack sarah
19:41:37 <gregwhitworth> ack keithamus
19:41:43 <gregwhitworth> keithamus: I agree with sarah
19:42:07 <gregwhitworth> keithamus: it has to do with size and impacting hiding content
19:42:53 <gregwhitworth> keithamus: but we need to solve issues with UI that are ephemeral and sub-menus sort of fall into this pattern
19:43:15 <gregwhitworth> keithamus: the menus that I typically interact with the hover will open the sub-menu and focusing it will open the sub-menu
19:44:07 <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
19:44:14 <gregwhitworth> nmn: quick response
19:44:16 <Penny> Penny has joined #openui
19:44:48 <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
19:44:51 <sarah6> q?
19:44:54 <sarah6> q+
19:45:10 <gregwhitworth> nmn: if you make the popover scrollable then that is a problem
19:45:41 <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
19:45:46 <masonf> ack nmn
19:45:57 <gregwhitworth> nmn: another thought I keep having about the inert usecase
19:46:14 <gregwhitworth> nmn: maybe we give the useragent control over what shows up
19:46:29 <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
19:46:46 <gregwhitworth> nmn: our initial scenario was showing the hovercar at half opacity upon hover to inform the user that they can invoke it
19:47:13 <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
19:48:00 <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
19:48:03 <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
19:48:31 <brecht_dr> q-
19:48:31 <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
19:48:36 <gregwhitworth> nmn: *thumbs up*
19:48:37 <scott> scott has joined #openui
19:48:46 <gregwhitworth> nmn: sounds better to me and I posted a link to a screen recording
19:48:52 <brecht_dr> because of what mason said.. +1
19:48:54 <masonf> ack mason
19:48:59 <gregwhitworth> ack gregwhitworth
19:49:10 <gregwhitworth> ack sarah
19:49:29 <gregwhitworth> sarah6: on regular down arrow keys we have a number of keys that can be used
19:49:49 <gregwhitworth> sarah6: navigation style stuff or tree or some other role, lists, interatctive lists, etc
19:49:50 <scott> q+ also confused about the inert talk
19:50:17 <gregwhitworth> sarah6: scott reminded me that enter and space trigger clicks in certain modes and space would be difficult there
19:50:33 <gregwhitworth> sarah6: there is a lot of AT that would need their own way to show interest
19:50:55 <gregwhitworth> sarah6: zooming software could override their own way to denote interest
19:51:18 <gregwhitworth> sarah6: will there be an event that they could listen to in order to possibly do that?
19:51:20 <nmn> +1
19:51:21 <keithamus> q?
19:51:25 <keithamus> q+ scott
19:51:28 <gregwhitworth> masonf: please open an issue on that as that sound interesting
19:51:29 <sarah6> ack me
19:51:32 <gregwhitworth> ack keithamus
19:51:41 <gregwhitworth> ack keithamus
19:51:53 <gregwhitworth> scott: I want to understand the talk about inert a bit more
19:52:14 <gregwhitworth> scott: making the popup make it inert, how would they know it's existed but it's inert
19:52:32 <gregwhitworth> scott: assume someone that is low vision with zoom and the popup is inert they won't be able to access it
19:52:38 <gregwhitworth> scott: maybe I've missed it
19:52:58 <gregwhitworth> masonf: we're coming close to the end of the meeting but I would like to summarize what I've heard
19:53:25 <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
19:53:37 <gregwhitworth> masonf: that makes it so that it doesn't add additional tab stops
19:53:58 <nmn> The actual relevant link: https://www.icloud.com/iclouddrive/093R9zAV5ic-A_hlfjXOBZxBw#Screen_Recording_2024-11-20_at_4.55.29_PM
19:54:05 <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
19:54:35 <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
19:54:49 <gregwhitworth> scott: an ARIA details would not be there if it's inert
19:54:54 <gregwhitworth> scott: ok, that's making a bit more sense
19:54:58 <gregwhitworth> masonf: no that's good
19:55:26 <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
19:56:11 <masonf> q?
19:56:11 <gregwhitworth> nmn: I added a new link that is a bit more dramatic than what we shipped
19:56:13 <masonf> ack scott
19:56:14 <gregwhitworth> ack scott
19:56:35 <gregwhitworth> masonf: I'll take everything and try to summarize it in the issue
19:58:09 <gregwhitworth> Zakim, end meeting
19:58:09 <Zakim> As of this point the attendees have been brecht_dr, keithamus, flackr, bkardell_, scott
19:58:12 <Zakim> RRSAgent, please draft minutes
19:58:13 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/20-openui-minutes.html Zakim
19:58:20 <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent.  Goodbye
19:58:20 <Zakim> Zakim has left #openui
21:01:24 <Penny> Penny has joined #openui
23:53:42 <Penny> Penny has joined #openui