The widget should be dismissed just by the user moving their mouse away from the "i", with no "x" needed. Shown in this mockup and screenshot from mockup below:

I thought I had commented on this somewhere, but when first building this widget I included the X provided by OOUI for accessibility reasons. @Volker_E do you have thoughts on whether that X to close should be required from an accessibility standpoint?

In T238165#5675042, @kostajh wrote:

The widget should be dismissed just by the user moving their mouse away from the "i", with no "x" needed. Shown in this mockup and screenshot from mockup below:

I thought I had commented on this somewhere, but when first building this widget I included the X provided by OOUI for accessibility reasons. @Volker_E do you have thoughts on whether that X to close should be required from an accessibility standpoint?

There's two different ways to implement that functionality. From a pure recommendations perspective, this should probably not only work on :hover in the first place as it can't be triggered on touch screens. From an accessibility standpoint both implementations in OOUI are not fulfilling requirements out-of-box, sadly. Screen readers don't know how the trigger element (general PopupButtonWidget with click trigger misses ARIA attribute and popups ID wiring, I guess, that's what you're using there; form FieldLayout help PopupButtonWidget on :hover got the same issue – that's why we implemented and started recommending using helpInline in this cases instead.

So it should be triggered by hover/click, wired up and if so, provided a close button “x”.

In T238165#5683314, @Volker_E wrote:

From a pure recommendations perspective, this should probably not only work on :hover in the first place as it can't be triggered on touch screens.

You can also open it by tapping, (except you need to tap twice because the mouseenter and click event handlers get in a fight; that's an easy fix though). In any case, the mobile site will use a different widget (T238164: Newcomer tasks: Use Drawer component for mobile UI) so not a lot of people will see this on a touchscreen.

From an accessibility standpoint both implementations in OOUI are not fulfilling requirements out-of-box, sadly. Screen readers don't know how the trigger element (general PopupButtonWidget with click trigger misses ARIA attribute and popups ID wiring, I guess, that's what you're using there; form FieldLayout help PopupButtonWidget on :hover got the same issue – that's why we implemented and started recommending using helpInline in this cases instead.

Yeah, it's a PopupButtonWidget with an extra mouseenter event handler. Since screen readers don't know how to open it, the presence of the X does not really matter to them. At some point hopefully PopupButtonWidget will be fixed to use proper ARIA markup; will the presence of an X matter then? Is the close action even meaningful on a screen reader?
FWIW, you can also close popups by clicking/touching outside or by pressing Esc.

Change 552372 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Newcomer tasks: Fix explanation widget behavior on touch devices

https://gerrit.wikimedia.org/r/552372

Since screen readers don't know how to open it, the presence of the X does not really matter to them

Rather than screen readers, I was thinking about individuals who may have fine motor control difficulties, so maybe the mouse inadvertently hovers over the icon causing it to open unintentionally; or maybe they intentionally open it, but if we switch to using "hover out" to close, then they could easily unintentionally close it.

The other thing that's a bit tricky about using hover-out to close is that the gap between the icon and the popup means we need to include the space between the icon and the popup as area in the hover-in/hover-out behavior. Otherwise the mouse pointer can't make the leap from the "i" icon to the popup before the popup closes. But I'm sure we could figure out a workable solution for that.

@RHo taking into account the discussion above do you want to leave the X in place or remove it?

In T238165#5684048, @kostajh wrote:

The other thing that's a bit tricky about using hover-out to close is that the gap between the icon and the popup means we need to include the space between the icon and the popup as area in the hover-in/hover-out behavior. Otherwise the mouse pointer can't make the leap from the "i" icon to the popup before the popup closes. But I'm sure we could figure out a workable solution for that.

@RHo taking into account the discussion above do you want to leave the X in place or remove it?

I would ideally still like to not have the close "x" and essentially want this to behave like how page previews on Wikipedia, since afaik that is quite accessible-friendly, (per this article: https://blog.wikimedia.org/2018/04/20/why-it-took-a-long-time-to-build-that-tiny-link-preview-on-wikipedia/). However, if it sounds like @Volker_E you're saying this particular OOUI component behaves differently and not to the same a11y-friendliness, then we can consider leaving the "x" for now.

Regarding the hover @kostajh, would it be an easy change to add additional focus area around the icon so that there is no gap with between the icon and the popup card?

For reference please see this animated gif of the page previews hover behaviour

Change 552372 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Newcomer tasks: Fix explanation widget behavior on touch devices

https://gerrit.wikimedia.org/r/552372

In T238165#5684189, @RHo wrote:

Regarding the hover @kostajh, would it be an easy change to add additional focus area around the icon so that there is no gap with between the icon and the popup card?

So I assume the preferred behavior would be something like this:

• the popup opens when howering over the (i) icon
• the popup also opens when clicking on the icon (since you can't hover on mobile devices, or without a mouse on desktop)
• if the popup was opened via hover, it closes when the mouse leaves the popup (+ same safety area around it to make the behavior non-annoying)
• if the popup was opened via icon click, it only closes on another icon click

Am I getting that right?

In T238165#5691579, @Tgr wrote:

In T238165#5684189, @RHo wrote:

Regarding the hover @kostajh, would it be an easy change to add additional focus area around the icon so that there is no gap with between the icon and the popup card?

So I assume the preferred behavior would be something like this:

• the popup opens when howering over the (i) icon

• Yes

• the popup also opens when clicking on the icon (since you can't hover on mobile devices, or without a mouse on desktop)

• Not quite. It should only open a drawer when clicked on mobile per T238164

• if the popup was opened via hover, it closes when the mouse leaves the popup (+ same safety area around it to make the behavior non-annoying)

• Yes, exactly.

• if the popup was opened via icon click, it only closes on another icon click

• Yes, insofar as on mobile the click is on the "X" that appears in that bottom sheet/drawer component.

In T238165#5691640, @RHo wrote:

• Not quite. It should only open a drawer when clicked on mobile per T238164

The drawer is specific to the mobile interface (MinervaNeue) though. People can also use the desktop interface on mobile. Or they might be using a desktop computer but not using a mouse for some accessibility reason and "click" via focusing on the icon via tab navigation and pressing enter, in which case there is no hover action.

In T238165#5691661, @Tgr wrote:

In T238165#5691640, @RHo wrote:

• Not quite. It should only open a drawer when clicked on mobile per T238164

The drawer is specific to the mobile interface (MinervaNeue) though. People can also use the desktop interface on mobile. Or they might be using a desktop computer but not using a mouse for some accessibility reason and "click" via focusing on the icon via tab navigation and pressing enter, in which case there is no hover action.

Ah fair enough, but in that case can we not have the mouse out or scroll off be the thing that hides the pop-up rather than having the close icon? Like how the reference tooltip works when viewing Desktop on a mobile device:

Having said that, I have no strong opposition to keeping the close icon if this makes it substantially easier to implement an a11y-friendly solution.

Change 556479 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Remove close button from widget, close on hover out

https://gerrit.wikimedia.org/r/556479

Change 556479 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Remove close button from widget, close on hover out

https://gerrit.wikimedia.org/r/556479

For Design Review
(1) The general look - the gap is bigger comparing to page previews popups, but the explanation widget is visually sufficiently tied to the info icon (in my opinion).

• opening down
  
• opening up
  

(2) Hover and click functionality
The hover-out action for the task explanation widget works differently from page previews hover action. The widget will close

• if a mouse pointer will pass over the widget area and then out (the animated gif showing it)

• or a user clicks outside the widget area

In a sense, such behavior is allows a user to read the task explanation text, but it might feel a little bit annoying to be forced to do a specific action to close the widget.

(3) the mobile view

In T238165#5752532, @Etonkovidova wrote:

For Design Review
(1) The general look - the gap is bigger comparing to page previews popups, but the explanation widget is visually sufficiently tied to the info icon (in my opinion).

• opening down
  
• opening up
  

– I agree this is OK

(2) Hover and click functionality
The hover-out action for the task explanation widget works differently from page previews hover action. The widget will close

• if a mouse pointer will pass over the widget area and then out (the animated gif showing it)

• or a user clicks outside the widget area

In a sense, such behavior is allows a user to read the task explanation text, but it might feel a little bit annoying to be forced to do a specific action to close the widget.

– @Catrope - can we make it so that it behaves more like the page previews in that it closes once the user is out of the widget area OR the icon?
Secondly, this is my oversight and a nice-to-have, but how could the same css animation to fade-in-up/fade-in-down and fade-out-down/fade-out-up the pop-ups as page previews also be incorporated?

(3) the mobile view