[popover] Can we add focus-triggering to form elements?

[brechtDR]

Following up on issue #815

I was wondering of we should add the focus triggering to form elements. This behaviour can be seen from time to time in:

• Password information (example text: use minimum of one capital, special character, ....)
• Address information (example text: for residents outside of the uk, ....)
• Phone numbers (should start with...)

I know placeholder text is used for this as well, but I run into this behaviour from time to time where a tooltip is used.
Found an example on this page: https://flowbite.com/docs/components/popover/

Example screenshot

[josepharhar]

So is this the same as "interest" from issue #815? In which case it could be called hover triggering and focus triggering?

[lukewarlow]

Yeah I think this would just be interest triggering? I guess it does bring up the question of should it be configurable what constitutes interest. You might not want hover but do want focus?

[brechtDR]

Yes, exactly.

I think the behaviour on form elements could be different. Which is why I wanted to create a separate issue. I'd love to hear some thoughts on this.

[lukewarlow]

Yeah potentially alongside interesttarget and interestaction we need some sort of interesttriggers which takes a token list. The default will be all of them but then maybe we can have allowed values of hover, focus and longpress. That way you can also choose whether or not you want touchscreen based interest to trigger something?

<input interesttarget="mypopover" interestriggers="focus longpress">

Questions then is do we need to distinguish between focus and focus-visible and complexities like that?

Alternatively maybe we don't need a new attribute, could decide based on the event?

foo.oninterest = (event) => {
     if (event.trigger === 'hover') event.preventDefault();
}

[brechtDR]

That could be one way to go, by actually using interest as a attribute.
Another way to go is to keep it a bit more simple and have the focus value for target action available:

So that both could be added
popovertargetaction="interest"
popovertargetaction="focus"

Sidenote: I would not be in favour to add the following single option:
popovertargetaction="hover"

As this could potentially make authors overlook accessibility concerns

[css-meeting-bot]

The Open UI Community Group just discussed [popover] Can we add focus-triggering to form elements?.

The full IRC log of that discussion

<hdv> brecht_dr: because of the issue about the anchor… it made me think should it be shown on an input element in general
<hdv> brecht_dr: form elements may be a good case where to use it
<Luke> q+
<hdv> brecht_dr: like, in a password field it could show password suggestions / rules
<gregwhitworth> ack gregwhitworth
<jarhar> q+
<gregwhitworth> ack Luke
<hdv> brecht_dr: should we also allow it on form fields on focus?
<keithamus> q+
<hdv> Luke: do you specifically want focus only?
<hdv> Luke: or do you mean interest on form elements?
<hdv> brecht_dr: my first idea was should we just interest… but then I thought maybe you want only the focus and not necessarily the hover
<hdv> brecht_dr: focus only would be an option imo, but not hover only
<hdv> Luke: in the same way that hover only could be an a11y issue, could you not also have focus only to be an a11y issue, if people don't have an input method that is able to focus
<hdv> Luke: my thought is we could add the trigger type to the interest event
<scotto> q+
<hdv> Luke: you could then just check if the trigger type is focused and then prevent default
<gregwhitworth> ack jarhar
<hdv> jarhar: I only realised after second reading this was truly about focus… and realise you only want the password suggestion thing when it's focused
<zcorpan> q+
<hdv> jarhar: if we're going to replace popovertarget with this new invoker thing… then this can probably work the same way?
<hdv> Luke: the action is what happens to the target element
<gregwhitworth> ack keithamus
<hdv> keithamus: i'm somewhat cautious / considered about reintroducing this idea of fixed input modality… part of the reason for interesttarget is that we abstract away individual input modalities
<hdv> keithamus: all these modalities kind of have problems… there was some discussion about emerging technologies at TPAC … with regards to input type… like what does this do with Apple Vision
<hdv> keithamus: future proofing is important
<gregwhitworth> q+
<hdv> keithamus: there was a related request… using JS you could query what invoked?
<hdv> keithamus: I want feedback on the proposal… but if I were the benevolent dictator of this proposal, I would say let's not think about that
<hdv> keithamus: I can't think of cases where focus is desired but hover is really actually not ? or is that more of an aesthetic choice? do you want to prescribe this on your user?
<Luke> +1
<Luke> q+
<hdv> keithamus: eg maybe are there cognitive concerns? that would be a better justification maybe?
<gregwhitworth> ack scotto
<hdv> scotto: there are some cases where you want it to appear on focus but not on hover… the example of a password strength dialog may be one… 
<hdv> scotto: you don't want these things just popover all over the place when you're just mouse over the form
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<brecht_dr> q+
<hdv> scotto: and it could be annoying for people with motor impairments if their mouse gets stuck in one position while focus has moved on elsewhere… is why things popping up on hover is a weird thing in general
<hdv> scotto: Luke said earlier… something about doing preventDefault at interests… if someone uses JavaScript to do that anyway, why not have them use JavaScript to do this in the first place?
<keithamus> q+
<hdv> scotto: I do want to make sure we create popover and interesttarget and whatever it be, we treat these as primitives/attributes/collections of behaviours that they were meant to be… and not have them be shoehorned into something else that they might be able to do as well
<hdv> scotto: we keep trying to make attributes… I don't think it makes sense to make popover as an attribute into every HtML that we need
<hdv> s/HtML/HTML
<gregwhitworth> ack zcorpan
<jarhar> i have to leave early, nice comments scott
<hdv> zcorpan: I wanted to say two things… one: whether form controls are focusable is configurable
<hdv> zcorpan: second: if we can make popovers appear on focus and disappear on blur… that seems like an accessibility issue, especially for screenreader users, when they focus an input, the screenreader would go into forms mode so they only interact with that field, until they exist that control… if the popover disappears at that point, they would have no way to get to it
<hdv> zcorpan: we should be careful about opening and dismissing in ways that might not be accessible
<gregwhitworth> ack Luke
<scotto> to simon's point - yes, there would need to be a lot of other ways that devs would need to hook this up, for exactly what he mentioned
<hdv> Luke: to scott's point…different users might want interest to mean different things
<hdv> Luke: would be interesting for users to be able to configure that in their UA
<scotto> q+
<hdv> Luke: Im assuming if we did it on focus, there would be some way to tell the screenreader, here's another thing you can focus, and then the blur event would be if they get out?
<hdv> Luke: I don't know if forms mode would prevent them from going into the popover always?
<hdv> Luke: exposing it inside of the JavaScript would be useful even if we don't want to encourage it to be prevented
<hdv> Luke: not sure if actual usecase, but potentially there is
<hdv> Luke: so that people can do different things if they want to
<hdv> gregwhitworth: one thing you called out, keithamus… I don't care about future devices, I've heard about that ad nauseum… I've heard this used as an argument to derail discussion
<hdv> gregwhitworth: if someone comes out with a new widget… that's probably an argument we miss some primitive… 
<hdv> gregwhitworth: this is one of the reasons we didn't do much standardising of forms at all, because we couldn't anticipate future tools
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: when scott spoke about hovering can be annoying… also part of ux in general, not having things appear on hover all the time is an important choice
<Luke> q+
<hdv> brecht_dr: when it comes to focusing an input element… isn't it the same thing when you have a button that opens on interest?
<hdv> brecht_dr: wouldn't you then also use the focus on the button?
<hdv> brecht_dr: why should it be ok for a button but not an input?
<hdv> zcorpan: depends on when it is dismissed… I was assuming, maybe incorrectly, the popover would only be [breaking up]
<gregwhitworth> ack keithamus
<hdv> keithamus: to the hover point… in my experience, there is always a delay? to Luke's point, that kind of behaviour can be configured if we keep this as an abstract notion
<hdv> keithamus: and then maybe browser vendors could in the future remove that
<hdv> keithamus: whatever the browser considers as the user is expressing their interest in this element
<hdv> brecht_dr: fair enough
<hdv> zcorpan: [returned] I think the issue is not with the popover, it is when it is automatically dismissed
<hdv> zcorpan: if it is dismissed on blur of the input element, that could be an issue
<gregwhitworth> ack scotto
<gregwhitworth> q+
<hdv> scotto: adding on to that… whether it'd be an input or a button… whatever this popup is… the way it would be exposed to someone using a screenreader would be entirely how a developer hooked it up …if it was the password recognition field , arguably it was a live region… if it was associated as a description for that input fields, it would be announced when that input is focused and no-one would actually have to navigate to it
<hdv> scotto: if it would contain interactive elements, then _that_ would be a reason for someone to want to navigate to it… so then when popover would open focus would actually need to go for it , that use case is probably being accounted for, sounds like Mason is doing that
<hdv> scotto: so the popover kind of repositions itself in the popover
<hdv> s/popover/DOM order
<hdv> scotto: so it would be another way a user could go into the popover element without dismissing it
<hdv> scotto: that's why we defined a “details relationship” between the popover and the invoking element, for screenreaders that support it there is a key they can use it to enter the popover
<hdv> scotto: say you would end up with an associated description, that's on the developer to do
<hdv> scotto: it becomes a lot easier for the developer, if there is a has-tooltip=id and the tooltip has the id, and everything is hooked up, that's great, then the browser could do all the work for the developer
<keithamus> q?
<hdv> scotto: there are ways to to this
<hdv> scotto: still a lot of things the developer needs to know how to do and possibly can do wrong
<gregwhitworth> ack Luke
<hdv> Luke: if you focus an input on a picker it immediately open… so we need to be careful in how we decide what ocunts as interest on what platform… focus on desktop is fine, but focus on mobile already has an associated action
<gregwhitworth> zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<hdv> gregwhitworth: brecht_dr, did you want to get to a resolution? what is left open for us?
<hdv> brecht_dr: I guess we want to know whether this is something we need to investigate further?
<hdv> gregwhitworth: yes, sounds good to investigate further on GitHub if there's no further actions
<gregwhitworth> zakim, open the queue
<Zakim> ok, gregwhitworth, the speaker queue is open

[lukewarlow]

Coming back to this having been thinking on input "Pickers" recently they're a good example of something you might want to show on invoke (click) but also you might want to show on focus. But that you don't want to show on hover.

Combobox for example is something that might benefit from focus triggering but not hover.

Just thought I'd note this.

[lukewarlow]

Going to close this and continue discussing in #1036