Is this feasible?

Yes.

The DOM of the popup widget supports having an anchor element position over the contents via CSS like:

<div class="oo-ui-popupWidget-popup" style="width: 320px; height: auto;">
    <div class="oo-ui-clippableElement-clippable oo-ui-popupWidget-body" style="max-width: 712px; max-height: 585px;">
        <div class="ext-ipinfo-widget oo-ui-widget oo-ui-widget-enabled" aria-disabled="false">
            <dl class="ext-ipinfo-widget-property-properties"><!-- ... --></dl>
            <a class="ext-ipinfo-widget-overlay" href="/wiki/Special:Contributions/xxx.xxx.xxx.xxx?ipinfo=open"></a>
        </div>
     </div>
</div>

.ext-ipinfo-widget {
    position: relative;

    .ext-ipinfo-widget-overlay {
        top: 0;
        left: 0;
        bottom: 0;
        right: 0;
    }
}

Would this affect the user's open/close pref on the accordion? Can it be independent of it?

It musn't affect the preference. We'd need to:

1. Update the decision to render the infobox (accordion) as initially collapsed/expanded is on the server side to take into account a new ipinfo=open parameter
   • The parameter's name is TBD
2. Update the logic that persists the setting from the client side to ignore the first time the collapses the accordion if it was initially expanded due to that parameter

@Prtksxna: I've been bold and have added AC to the task and a link to my notes ☝️. If you're happy with the task, then we can move it to Cards ready for discussion.

Looks good. Thanks @phuedx!

A quick disclaimer: I don't actually have much insight into how this tool will be used in practical application. That said, I'm not sure I agree with the intuitiveness of making the popup entirely clickable. I understand that the existing UX this builds off of is the previews feature? I think it works for the previews feature because it's clear that it's a preview (from everyone's favorite wikipedia page, Philosophy):

In comparison, the IP Info popup looks like a discrete set of information:

Making the popup a link will also make the text un-copy-pasteable. I'm not sure how valuable that feature is but just wanted to point it out.

This is my personal opinion and I'm not going to push strongly on it and if the people who will actually be using this tool are fine with it then that's even better. I had some concerns about if (in the hypothetical) the UX was unpopular and if there were any avenues for user feedback/our options to respond to that.

Thanks for going over these @STran 🙏🏾

In T293723#7445290, @STran wrote:

The fading out w/the clipped word conveys to the user that this is a preview only and that there's more information to be accessed.
In comparison, the IP Info popup looks like a discrete set of information.

Yeah, we used the fading out there because the content is incomplete. Here the sets of information are complete but it isn't the entire information. I'll brainstorm some options to see if we can indicate that there is more and if that helps.

Making the popup a link will also make the text un-copy-pasteable. I'm not sure how valuable that feature is but just wanted to point it out.

In our usability tests we didn't see anyone do this. Its more common for CheckUsers, but they use a different tool for it anyway.

I had some concerns about if (in the hypothetical) the UX was unpopular and if there were any avenues for user feedback/our options to respond to that.

Yep we're looking for some ways to collect feedback. We're considering some options right now - talk page, flow, yes/no feedback, quick surveys and of course instrumentation to see how the thing is getting used.

@Prtksxna do you think this ticket is ready to be worked on?

In T293723#7483367, @Niharika wrote:

@Prtksxna do you think this ticket is ready to be worked on?

Yep! I'll create a separate ticket if we add a "more information here" indicator in the popup.

Thanks @phuedx - I have a few more questions about accessibility.

Are there any concerns about making a clickable area that navigates to a separate page without making it visually obvious? I'm thinking of people who may be visually impaired, have slow devices, or just difficulty interacting with their device suddenly arriving on a new page without understanding how. Pinging @Volker_E as an accessibility expert. Related to this, what experience should we provide for keyboard-only contexts, screen readers, etc?

Since we're going to be collecting feedback, could we start with something less unusual, like an obvious button/link - then see whether making the whole popup clickable is needed?

I had a couple of thoughts on this that I'm noting here:

What does PagePreviews do?

• When you hover over or focus a link it opens a popup
• The title attribute of the link is blanked so that the default tooltip isn't shown
• The popup is divided into three sections:
  • The image (which is a link to the page)
  • The extract (which is a link to the page)
  • The footer (which has an icon that is a link to a preferences modal)
• I couldn't find a way to tab into the popup (so no way to reach the settings through keyboard)
• Pressing enter on the link takes you to that page

How is the IP Info popup different?

• The interaction is on click (not on hover)
• We need a way to give focus to the popup, so that when people click it, they're taken to Special:Contribs (unlike PagePreviews, where the link takes you to the same place)
• There is only a single interactable item in the popup (no settings icon here)

What I think we should do
@Volker_E please guide, if this is the right approach.

• Make sure that the info icon button has aria-haspopup property (docs) that points to the popup
• The popup should have the dialog role (docs) and a corresponding aria-owns property
• We'll also need to have a way that pressing tab after the info icon takes you to the popups link element (docs) and then out of the popup.
• Focus inside the popup would be to the link to Special:Contribs. Like PagePreviews the entire content would be a link
• Hitting esc anywhere should close the popup

Change 767244 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/IPInfo@master] [WIP] Add link to Special:Contributions from popup

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

Change 767246 had a related patch set uploaded (by STran; author: STran):

[oojs/ui@master] Add aria properties to PopupButtonWidget

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

@Prtksxna Could we have a hover state to show that it's a link? Additionally, could I get some copy for the link for screenreaders (the copy is not visible but screenreaders will be able to read it out)? I have it set to just the ip right now.

In T293723#7746068, @STran wrote:

@Prtksxna Could we have a hover state to show that it's a link?

Do you mean a hover state for the entire popup? If yes, there won't be any apart from the default cursor change (similar Page Previews).

Additionally, could I get some copy for the link for screenreaders (the copy is not visible but screenreaders will be able to read it out)? I have it set to just the ip right now.

Link here being the entire contents of the popup, right? Would this be the title attribute of the same or some other aria- attribute?

Yes the link that covers the entire popup. It's better to not wrap the contents of the popup in an a tag because screenreaders will read everything as part of the link. Instead, I made an a tag, put some text in it, and then used css to make it cover the entire popup. That way, screenreaders will read the a tag and then the ip info independently (at least, VoiceOver which I tested with will).

Thanks! The title can be the same as the original link which is Special:Contributions/$ip.

Change 767246 merged by jenkins-bot:

[oojs/ui@master] PopupButtonWidget: Add ARIA properties to JavaScript version of PopupButtonWidget

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

Change 767244 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Add link to Special:Contributions from popup

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

Change 770069 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] Update OOUI to v0.43.2

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

Change 770069 merged by jenkins-bot:

[mediawiki/core@master] Update OOUI to v0.43.2

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

Change 770926 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@REL1_38] Update OOUI to v0.43.2

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

Change 770926 merged by jenkins-bot:

[mediawiki/core@REL1_38] Update OOUI to v0.43.2

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

@Tran
The infobox (accordion) on the Special:Contributions page was NOT expanded even if it should be collapsed per the user's setting.
I tested on beta: https://en.wikipedia.beta.wmflabs.org/wiki/0.29309421560561466?action=history
I was able to test on my local box and same experience, the Infobox did not expand. Per specification it should be expanded.

The accordion opens now on Beta and local box. Tested in Safari, Firefox, Chrome, IE, and IE Edge

Change 971122 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[oojs/ui@master] Fix slightly misplaced ARIA attributes on PopupButtonWidget

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

Change 971122 merged by jenkins-bot:

[oojs/ui@master] Fix slightly misplaced ARIA attributes on PopupButtonWidget

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

Change 980958 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/core@master] Update OOUI to v0.48.3

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

Change 980958 merged by jenkins-bot:

[mediawiki/core@master] Update OOUI to v0.48.3

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