Change 442996 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/MinervaNeue@master] WIP: Links should not be clickable in mobile page issue element

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

Change 442996 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Links should not be clickable in mobile page issue element

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

@Niedzielski looks good. I tried a few different templates that have links in them.

The link element is still selectable via tabbing, thoughts on avoiding that?

using tab to navigate to a hidden link in a page preview

It's also still right-clickable which came up in code review. @alexhollender, @Jdlrobson, do we want to handle these cases?

Alex we get into really hacky land if we want to disable tabbing and right clicking. Personally I'd rather we avoided this if we can.

If we do want to disable this we would have to flatten all links in the issues. We could do this via Javascript or as part of the PHP mobile formatter. As we saw when developing the page summary endpoint and moving the lead paragraph above infoboxes this can be done but comes with the expectation of lots of unplanned edge cases and follow up tasks.

I'm inclined to say that we should strip the links entirely. Hiding/disabling them (as we're currently doing) seems a bit hacky to me in the first place. I'm weary of adding more cost here. Unplanned edge cases are obviously hard to identify in advance, but any inclinations of what we'd potentially have to deal with if we flattened them?

I'm inclined to say that we should strip the links entirely. Hiding/disabling them (as we're currently doing) seems a bit hacky to me in the first place. I'm weary of adding more cost here. Unplanned edge cases are obviously hard to identify in advance, but any inclinations of what we'd potentially have to deal with if we flattened them?

Okay, if this is the case, I suggest cutting a new card or putting this card back in "needs analysis" in the backlog for another round of analysis and estimation. This is going to carry a lot more risk, so we'll need to work out what to do there and estimate differently.

Given we need to show the links in the overlay, we'd likely need to do this in JavaScript to retain those links. The JavaScript would flatten the links so momentarily (until JS has loaded) those links would be in the page. We'd have to be careful to only strip links and to retain characteristics of those links. We hit similar challenges with lazy loading images so we'll want to think through those before going ahead with this approach.

@alexhollender is the existing patch an improvement we want to keep or should we revert it?

Ok. Going forward I will be more clear about the expected behavior. I'm still a bit new to thinking about accessibility, including keyboard navigation. My apologies for not calling that out explicitly.

We could count the existing patch as a temporary improvement but I'm not sure it will be useful after the deeper fix.

The real problem here is the content we are printing has links (whether we like it or not). This is not going to change unless we talk to editors about that. If we don't talk, any solution we come up with is going to involve accessibility or performance problems or tech debt or all three of those things.

The advice to editors might be: "Don't put any links inside the issue field of the ambox template. Please only put them in the "fix" section.

@Jdlrobson ok - it's helpful to outline what the ideal case would be as you did above. How do we handle this for page previews? It seems like a similar situation.

In page previews we have a cached api with lots of complexity and corresponding tests. Regarding links we traverse the DOM and replace them with spans copying over all the elements on them. We could add similar code in to mobile web and in javascript rewrite the banner DOM. Note there may be edge cases that are not obvious so we would expect/ need to do some further QA. Would you like me to create a task for doing all that?

@alexhollender, I hope you don't mind but since you're at Wikimania this week and likely very busy, we're going to keep pushing this card as is through the pipeline. Please feel very welcome to open a new card for continued work.

Looks good to me on master. Tested a few mobile browsers. The entire thing is clickable.

I just checked and this change is on readers-web-master. Maybe you just got the old treatment? The A/B test resets every time a new browser tab is opened.