Another report: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=856026363&oldid=856017455&diffmode=source

@Jdlrobson is this something we can fix by modifying the code? I agree that it should be accessible via keyboard navigation. Unclear what design work there is to be done.

@alexhollender It's a double-sided issue. Providing keyboard accessibility to the settings without further refinement would mean an extra tab to go to the next tabbable element each and every time, having a negative impact on navigation for keyboard-users only.
We'd need to come up with an easy way to let keyboard users access settings probably just once per page…?!

@alexhollender we are focusing on page previews technical/design debt soon. Please consider if this should be a subtask of T284095.

In T192489#7176020, @Jdlrobson wrote:

@alexhollender so. . What is the plan here? Not clear to me from https://phabricator.wikimedia.org/T192489#4589791

Should we setup a meeting with Volker to discuss options?

I don't have the bandwidth to work on this currently. I'm happy to join a meeting with you and Volker if that would be helpful.

@ovasileva this is currently set to high priority, would this benefit from Alex's attention given our current page previews spike? Alternatively let's lower the priority and plan it for later.

Change 713022 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/extensions/Popups@master] POC: Allow cog to be focused from keyboard

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

Change 713022 abandoned by Nray:

[mediawiki/extensions/Popups@master] POC: Allow cog to be focused from keyboard

Reason:

POC only

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

Change 713022 restored by Nray:

[mediawiki/extensions/Popups@master] POC: Allow cog to be focused from keyboard

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

I looked at this today, and I agree with @Jdlrobson that this is probably going to be substantial work.

First, I'm a little bit confused w3's stance on whether the cog should be focusable in the first place. Under their description of a tooltip, they state the following:

Tooltip widgets do not receive focus. A hover that contains focusable elements can be made using a non-modal dialog.

However, maybe they would classify our page previews under the "non-modal dialog" category rather than as a tooltip. Elsewhere, they do support keyboard control for all functionality. The accessibility developer guide also supports it.

I made a POC of how this could generally work, but ran into the following challenges:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Popups/+/713022

• When the link is focused, how do we make the next tab go to the cog? This POC programmatically focuses the cog, but for some reason this doesn't seem to work in Safari (I haven't looked deep into this). Alternatively, the popup element could be placed directly after the link element in the DOM so the tab order naturally follows the DOM order, but then the positioning of the popup is at the mercy of the nearest parent element with non-static positioning (which is probably risky with user generated content).

• When the cog is focused, how do we make the next tab go to the next tabbable element after the link that triggered the popup? This patch just focuses back on the link, and this somehow seems to work in Chrome and Firefox (but again does not work in Safari).

Edit: I was able to address the Safari problems in my latest patch

Change 713022 abandoned by Nray:

[mediawiki/extensions/Popups@master] POC: Allow cog to be focused from keyboard

Reason:

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

@nray I agree that this is really tricky. Page previews shouldn't be categorized as a tooltip, as tooltip content shouldn't contain interactive elements (i.e. buttons, links). I'm also not sure if a non-modal dialogs is appropriate. Page previews are activated and deactivated on hover/focus events automatically, while non-modal dialogs are typically activated via click and require an action from the user to be dismissed (i.e. a close button or clicking outside of the dialog). As previously mentioned by @Volker_E, this is important as we don't want to force a keyboard user to tab through the settings cog again and again, or force a screen reader user to read the page preview summary of every link.

Even ignoring the technical challenges Nick pointed out above, I don't see an obvious solution that doesn't compromise UX or accessibility. I'd have to agree with @Volker_E that probably the best solution is to provide an alternative way for users to access the page preview settings on each page, so that the settings cog becomes superfluous or maybe even be removed altogether.

Change 713022 restored by Nray:

[mediawiki/extensions/Popups@master] POC: Allow cog to be focused from keyboard

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

Change 713022 abandoned by Nray:

[mediawiki/extensions/Popups@master] POC: Allow cog to be focused from keyboard

Reason:

POC only

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

Thank you @bwang . One thing I noticed while browsing the popups codebase is that we intentionally have at least a 500ms delay before showing the popup which might make quickly tabbing through the links a little easier (see below for an example of me quickly tabbing using my POC patch), but I assume that might still be problematic for accessibility

While I agree with the assessment here around the cog, could we not add link/button that is only visible to screen readers that says disable page previews at the top or bottom of the page? It could be hidden for non-screenreaders but would at least solve the problem here.

That's fine with me and seems like it is especially needed for anonymous screen reader users

Sorry to complicate this convo, but my understanding is that screenreader users aren't able to access page previews to begin with, so is there a point in adding a link to the settings cog? There's some relevant discussion in https://phabricator.wikimedia.org/T192627 (1, 2) with more context about this.

I believe the main set users this task concerns is keyboard users (i.e. someone with motor disabilities). We could still add a link/button that's visually hidden until focused and hidden from screen readers, but honestly I don't feel confident about adding a hidden link/button to all wikis, it feels a bit like a tacked-on solution. I'm almost starting to wonder if this is even worth addressing without better understanding how it's affecting users and it's priority :/

@bwang ha good point! I didn't think that one through in my last comment 😃

Lets continue conversation on =>T289193.