Meeting minutes
<astearns> github-bot, take up whatwg/
Keyboard behavior for the `interesttarget` attribute
<github-bot> OK, I'll post this discussion to https://
masonf: i thought it would be good to intro interesttarget, first keyboard then touch screen
masonf: right now its an attribute called interesttarget with an idref
masonf: use case is hover triggered things. thats a very common use case, its on most websites generally speaking
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
masonf: i wont go into much more detail on that
masonf: the main concern we have to deal with is that we want to support all input modalities, not just mouse
masonf: it solves a real problem for developers. most sites have these tooltips and they have to reinvent this wheel every time
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
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.
masonf: the other way is to show something on focus. if they keyboard focus it then after a delay it shows up
masonf: these are both present on sites already
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
masonf: the focus issue also happens with mouse, but keyboard users are stuck in this list
masonf: thats fine unless the hovercard has interactive elements, which changes the list of keyboard focusable elements
masonf: in openui we had a bunch of brainstorming, id like to get ideas from this group too.
masonf: prefer discoverability, use focus as the trigger
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
to move focus into it
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
masonf: this is the idea from facebook, this is how they do things today
emilio: i agree that going for focus makes more sense
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
masonf: it has been considered, escape does close it since its a popover. there were some a11y concerns. maybe thats a great model though
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
keithamus: we trialed showing the hovercard on focus on github, and many users complained. it is not a pattern that uses like
keithamus: something more like a partial disclosure duriing focus and having a hotkey to activate is preferrable
keithamus: the discoverability is hard. because its non standard users dont know how to activate it. i think its alt down or alt up
keithamus: you can do this today and we expose it in our list of keyboard actions
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
keithamus: discoverability is hard, but partial disclosure is the right path forward
masonf: you said users dont like that it shows up on focus? what part?
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
astearns: and when you had it come up on focus, did you have a substantial delay?
keithamus: yeah we tried with delays as well but its insufficient
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
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
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?
keithamus: we distinguish between non rich tooltips and rich tooltips - we call one a tooltip and another a hovercard
keithamus: users find tooltips ok on focus because most of them are small and dont occlude content
keithamus: some of the longer ones are disruptive, but tooltips are fine
keithamus: hovercards which have buttons and the users bio, are 250px big and occlude a lot of content
keithamus: but they are very useful. we track engagement on them and see that theres very good engagement
keithamus: so yes there are use cases for both
lwarlow: the bit about pressing escape making it so it doesn't show up again, that is kind of automatic
lwarlow: if youre using more than one modality - if youve got focus and mouse, does hovering it show it again?
lwarlow: it might be that the gain lose interest mechanism is good enough without anything extra
keithamus: ive cited this before, but this is wikipedia saying that when they enabled this hovercard on android they saw 20% more links clicked
keithamus: this is genuiely things that websites want
masonf: the buttons on those hovercards are important
<lwarlow> Does Wikipedia explain how they do this on mobile?
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
astearns: if the hovercard isn't invoked then that doesn't get announced
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
masonf: i dont know what the best way to announce that to AT is
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
lwarlow: its important that we dont just tell developers to put alt up in there because it might be wrong
masonf: we probably need to localize the text as well
keithamus: we added aria describedby to say push alt up to open
keithamus: they were ambivalent the first time, but hearing it every time for every link was annoying
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
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
keithamus: the repitition was the big bug bear
keithamus: were willing to sacrifice discoverability for simplicity
masonf: i was talking to aaron leventhal, his concept was you could announce things 5 times, and browser know that and stop it
keithamus: there was something else i wanted to add. a big problem as well was deciding a hotkey
keithamus: if the browser had a control, people could get more familiar with it across sites
keithamus: there is nothing that exists today for back button etc.
astearns: since you took the discoverability hit, do you have data on how well it was discovered afterwards?
keithamus: no
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
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
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
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
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
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
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
masonf: maybe we can leave it there and move on to touch screen
<astearns> github-bot, take up whatwg/
Touchscreen behavior for the `interesttarget` attribute
<github-bot> OK, I'll post this discussion to https://
masonf: on touch screens, the situation is worse than keyboard
masonf: if we were starting browsers today, it would be pretty obvious what to do. every native app has an interaction pattern to show interest, and thats long press
masonf: the issue that we have is that browsers already did that a long time ago, and it already does stuff, and users like it
masonf: long pressing on a link gives you a preview of the link, and you get a menu like share or copy the link or open in a new tab
masonf: users do use those context menu items and expect them to be there
masonf: when talking to developers about this, what should the mechanism be? ok touch screen is taken, lets make up a new gesture, like long press and slide or double tab
masonf: lots of creative things, any of which could be valid, but none of which are engrained in what users know how to do
masonf: if you invent a new gesture just for this, nobody will find it
<tantek> +1 masonf concerns, weird touch gestures are very undiscoverable
masonf: the very strong pushback from devs seems to be that long press needs to be the thing
masonf: now you have two things to do with this one gesture
masonf: we also considered where you long press, and it gives you the existing menu with another item that says i want to show interest in this thing
masonf: or some magical ux way that you have the existing thing and a new thing
masonf: its too much. long pressing youve already invested a lot of time. if you didnt get what you wanted immediately then youll give up
masonf: with one long press you should get both: the context menu and the popover
masonf: akin to keyboard, im presenting the current direction
masonf: when you long press on a link, which seems to be the use case that matter the most (buttons are easier), the context menu that you would have gotten still shows up, but in a position that leaves room on the screen for the hovercard that is provided by the site
masonf: in portrait mode on a phone, a context menu shows at the bottom of the screen and the hovercard appears at the top. the user can tap both things
masonf: to do that, the browser has to make room, put the context menu somewhere else
masonf: the browser still maintains control and can put it wherever they want
masonf: on very small screens they can choose to only show the context menu
masonf: it should expose the remaining area with css environment variables
masonf: thats the basic behavior, theres a lot of details
masonf: in most browsers right now, those context menus come with a blurring of the site. that cant be done because then youd blur the hovercard
masonf: that is the concept
masonf: we are prototyping this in chromium. there are a lot of ux concerns. our ux teams are looking at this and deciding whether this is good for users
masonf: is this confusing or is it natural
masonf: there are a lot of open questions about how to do this. just moving the context menu - what if youre on a tablet or landscape orientation
masonf: id love to hear feedback or better ideas
astearns: this idea of adding something to the existing long press ui would have security concerns. the existing long press ui is provided by the browser, so users trust it more than something on a webpage. if any webpage can mimic this part of the browser ui, it can pretend that it is the browser
lwarlow: anything thats rendered within the frame - they already can spoof it. likewise, a right click context menu it trusted but i can hijack that and render a popover that looks identical
lwarlow: i would say you already can do all of that stuff, unless the ui escapes the frame, but i dont think it can in any of the browsers
lwarlow: if it blurred the browser ui as well theres something there
smaug: it darkens the background, so there is a distinction with a real context menu
smaug: also if you show the browser provided context menu and something on top of that, then its confusing for users to know which portion comes from the browser
smaug: i was testing chrome to see how long the context menu
smaug: if you have a link then it already covers the whole screen, so theres no space for popovers
smaug: if you have an image which is also a link, then the context menu already covers the whole screen
smaug: theres too many list items, they would need to be redesigned
astearns: have you considered allowing authors to give a long press behavior to elements only if there is not a current long press behavior for that element from the browser?
masonf: the primary use case is on links. on all browsers i know, links are the big thing that has a context menu. buttons are in that category
masonf: links are the key use case where they do intersect today
astearns: there possibly could be a path where we provide a web standard way of defining a long press behavior. we can show that its so useful that browsers will decide to allow the author version of a long press for links with an extra button to get to our own instead
masonf: we talked about that too. that was in the category of the two clicks, thats just the other direction of it. there was pushback on both of those because users really like the context menu, so making either of them harder felt like a no go
masonf: i actually shared your security concern. you can do this today, and i talked to some google security folks, and they all agreed that you can do this today
masonf: there is a blur that is provided by the browser, but the people in this room that this little blurring is a security signal and nobody else does
masonf: i was convinced by that
masonf: olli mentioned that some context menus are very long. in the chromium prototype, the regular one for links with images it becomes scrollable, so it will be important to make sure these are sorted
keithamus: this is github.com in firefox on ios. if you long press a link you get a preview. this is a native ios behavior. the menu falls off the bottom of the page, and i can drag to show more of the menu or more of the preview
keithamus: this is a common pattern in ios
keithamus: the problem is that the resulting preview is just not very helpful. if i click an avatar, i get a bit of the description, but the button isnt interactive. the button is just going to take me to the page
keithamus: were doing two server requests because we dont cache those. it is multi factorial that we use hovercards: its better ux and better performance, its a cost saving measure
keithamus: most of the data we got about the user we already got in the first request
keithamus: native apps, this is the wikipedia native app. i can long press and get this summary. this is the ideal thing for us
astearns: in the native app, is anything in that preview interactive?
keithamus: not that ive seen
keithamus: social media websites will have a similar feature
keithamus: since they have follow features, maybe theirs are interactive
dandclark: several variants of this have been discussed. ill put in a vote for the two stage model, where the long press gets you the content and then you can press something else to get the context menu from the browser. it solves the space problem because its just one button. it has an additional barrier to get to the native thing, but its not
another long press and its not a new gesture
masonf: i think the best way to spec this - speccing this is going to be an interesting question - but the placement of the context menu is going to be up to the browser
masonf: i think both the ios way and the extra button makes sense
masonf: how and where you render the context menu should still be up to the browser
lwarlow: the wikipedia native app on android is different. a tap on a link is what shows their preview ui
lwarlow: it has open in new tab and stuff
lwarlow: clicking the whole preview will do the navigation
lwarlow: i do wonder if this should just be that long press does the interesttarget thing
lwarlow: and the browser should just give up their context menu
lwarlow: its the sort of thing that peoplare going to try disabling the browsers native thing anyway and it will have worse ux
lwarlow: like they might just use a button instead of a link because that disables the browser ui
lwarlow: and use user-select:none
lwarlow: all the friction we add to this is probably just another layer of im not going to use this builtin browser feature. which maybe is fine, but worth keeping that in mind
lwarlow: the other alternative is the context menu you get in browsers, can we just let them render inside it? like replace the preview bit at the top? for links you usually get useless stuff at the top
lwarlow: thats how it works in native apps
lwarlow: the wikipedia example is like that
lwarlow: im hesitant on having two bits of ui just on a devs wont use this perspective
keithamus: we can disable the contextmenu, but thats not desirable because people do use the open in new tab thing
keithamus: we want to retain open in new tab, we can replicate it but its not what people want
keithamus: id like to keep exploring two context menus
keithamus: showing context options is important to me and github
masonf: long press does generate a contextmenu event you can preventdefault, but it sounds like in this room there are multiple opinions, so we could leave it up to the browser to choose
fantasai: i thought this was an interesting conversation, but apple does have concerns that are expressed in the issue and i cant explain better than that. just wanted to say there are concerns
astearns: not just apple, i also see martin thomson also expressing concerns
masonf: the concerns are all this feels funny, id love to have more discussion
fantasai: it would be useful to bring this up where tess and anne can participate. unfortunately they had conflicts today
masonf: can we just keep this particular part on the agenda and that could be the venue?
fantasai: tess might be on vacation next time, anne will be available
fantasai: and we have a f2f
astearns: if there is a meeting in 2 weeks, there probably wont be any css folks in it
masonf: maybe we should cancel the one in two weeks, and it sounded like in 4 weeks could be a good time?
fantasai: you might want to check in if they can make that one specifically
dbaron: if you also want martin thompson thats going to be hard to include australia
masonf: or a breakout on this topic
fantasai: yes