Change #1184545 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/ReaderExperiments@master] Implement a "focus trap" for the overlay UI

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

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/569d61967e/w/

The patch looks good to me, but let's try doing a more formal QA process here. Once that is done it can be moved to sign-off, re-assigned to me, and closed.

Adding here testing notes for confirmation to review on whether some follow-ups are needed. Please let me know if some additional testing is needed or some issues need to be filed as separate tasks.

The testing was done on patchdemo Paris article

(1) Test case 1: Navigating with Tab
(1.1) on the page patchdemo Paris article Tab is clicked - the link 'Jump to content' is displayed as double-underlined with width >1600 px. The issue might be specific to Patchdemo quirks of vector skin. The production (wmf.17) starts displaying the issue with width >1620

>1600 Patchdemo	<1620 wmf.17

(1.2) Clicking Tab to navigate to the the gallery makes the whole element become selected. After that clicking on Enter or spacebar do not have any effect. Another Tab click will select the first image. The issue is present only on FF (Firefox 141 was tested)

(2) Test case 2: Focusing on elements
(2.1) A Gallery image with Tab focus can be viewed only when spacebar is clicked. Clicking on Enter will display the image page momentarily and then the article page is displayed.
That behavior - spacebar needs to be clicked, and Enter doesn't do anything, doesn't match the current spacebar/Enter behavior on wikis.

Although on wikis the behavior of spacebar/Enter clicks is not entirely consistent, their function is often the same - to activate an element. I used to think that the difference between spacebarand Enter, is that Enter acts as a mouse click, but spacebar click is for selecting menu items or activating radio buttons/check boxes.

(2.2) There are unreachable controls/options Share/Copy

(2.3) Clicking on x button (to return to the article page) results in lost focus

Test wiki created on Patch demo by Mmullie (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/886ad3c0dd/w/

In T402872#11153884, @Etonkovidova wrote:

(1.1) on the page patchdemo Paris article Tab is clicked - the link 'Jump to content' is displayed as double-underlined with width >1600 px. The issue might be specific to Patchdemo quirks of vector skin. The production (wmf.17) starts displaying the issue with width >1620

I'm going to guess this is just a Production/Patchdemo difference, since none of our work touches this.

(2) Test case 2: Focusing on elements
(2.1) A Gallery image with Tab focus can be viewed only when spacebar is clicked. Clicking on Enter will display the image page momentarily and then the article page is displayed.
That behavior - spacebar needs to be clicked, and Enter doesn't do anything, doesn't match the current spacebar/Enter behavior on wikis.

Although on wikis the behavior of spacebar/Enter clicks is not entirely consistent, their function is often the same - to activate an element. I used to think that the difference between spacebarand Enter, is that Enter acts as a mouse click, but spacebar click is for selecting menu items or activating radio buttons/check boxes.

Well now that turned into one hell of a inconsistent keypress events rabbit hole, but should be fixed - see updated patchdemo: https://patchdemo.wmcloud.org/wikis/886ad3c0dd/wiki/Paris#bodyContent

(1.2) Clicking Tab to navigate to the the gallery makes the whole element become selected. After that clicking on Enter or spacebar do not have any effect. Another Tab click will select the first image. The issue is present only on FF (Firefox 141 was tested)

(2.2) There are unreachable controls/options Share/Copy

(2.3) Clicking on x button (to return to the article page) results in lost focus

These are not directly related to this ticket specifically (which only handles the overlay focus trap, and didn't seek to properly address keyboard navigation), but they are indeed things to fix.
There's T400182 that already seeks to address keyboard navigation; I'll look that one over tomorrow to make sure that that ticket doesn't already address (some of) these findings, and will file a new ticket for any that remain.

In T402872#11157743, @matthiasmullie wrote:

In T402872#11153884, @Etonkovidova wrote:

(1.2) Clicking Tab to navigate to the the gallery makes the whole element become selected. After that clicking on Enter or spacebar do not have any effect. Another Tab click will select the first image. The issue is present only on FF (Firefox 141 was tested)

(2.2) There are unreachable controls/options Share/Copy

(2.3) Clicking on x button (to return to the article page) results in lost focus

These are not directly related to this ticket specifically (which only handles the overlay focus trap, and didn't seek to properly address keyboard navigation), but they are indeed things to fix.
There's T400182 that already seeks to address keyboard navigation; I'll look that one over tomorrow to make sure that that ticket doesn't already address (some of) these findings, and will file a new ticket for any that remain.

I agree that this is out of scope for the current ticket. But if we decide that we do want to improve the keyboard navigation behavior of the carousel component, we could update it to behave similar to how the Codex Tabs component works (demo here). Essentially, once focus lands on the carousel as a whole we could move it to an individual image and allow the use of arrow keys in addition to tab key to move back and forth.

Change #1184545 merged by jenkins-bot:

[mediawiki/extensions/ReaderExperiments@master] Implement a "focus trap" for the overlay UI

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

Do we need to file a follow-up task for anything here? @matthiasmullie if not feel free to move this to sign-off and I'll close it.

In T402872#11160449, @egardner wrote:

Do we need to file a follow-up task for anything here? @matthiasmullie if not feel free to move this to sign-off and I'll close it.

+1 to the question.

(2.2) There are unreachable controls/options Share/Copy

I compared the keyboard navigation UX to navigating images in MediaViewer (e.g. https://commons.wikimedia.org/wiki/File:SanMateo_(1)_04.jpg#/media/File:SanMateo_(1)_04.jpg). Images in MediaViewer do not have elements unreachable with keyboard navigation. Share/Copy options are elements in the new overlay that cannot be reached with keyboard navigation.

(2.3) Clicking on x button (to return to the article page) results in lost focus

After clicking Esc, a user is returned to an article page, but Tab button focus is lost.
That is quite a limitation on Tab navigation.

Should I file those issues separately? I reviewed T400182: Accessibility Audit - Images Entry Points. The work there has been done on WCAG Compliance Checklist: Horizontal Scroll Gallery. The scope of this task is UX keyboard navigation the overlay modal which has its own challenges.

In T402872#11163111, @Etonkovidova wrote:

(2.2) There are unreachable controls/options Share/Copy

I compared the keyboard navigation UX to navigating images in MediaViewer (e.g. https://commons.wikimedia.org/wiki/File:SanMateo_(1)_04.jpg#/media/File:SanMateo_(1)_04.jpg). Images in MediaViewer do not have elements unreachable with keyboard navigation. Share/Copy options are elements in the new overlay that cannot be reached with keyboard navigation.

(2.3) Clicking on x button (to return to the article page) results in lost focus

After clicking Esc, a user is returned to an article page, but Tab button focus is lost.
That is quite a limitation on Tab navigation.

Should I file those issues separately? I reviewed T400182: Accessibility Audit - Images Entry Points. The work there has been done on WCAG Compliance Checklist: Horizontal Scroll Gallery. The scope of this task is UX keyboard navigation the overlay modal which has its own challenges.

@Etonkovidova I think that filing a subsequent task for keyboard navigation improvements would be best. This task was about one specific feature (focus trap) but we can capture these issues in a follow-up task. Sounds like the issues so far are: some controls are not reachable, and focus is not properly restored on escape. Finally, we may want to support arrow-based keyboard navigation within the carousel component (kind of like how Codex Tabs and OOUI Tabs work).

We may also want a separate task for testing ARIA roles with something like VoiceOver for the overall feature.

In T402872#11160449, @egardner wrote:

Do we need to file a follow-up task for anything here? @matthiasmullie if not feel free to move this to sign-off and I'll close it.

Yes. I was going to do that today but it took me awhile to get to it. It's here: T404155 - feel free to expand if desired (e.g. arrow-based navigation)

Test wiki on Patch demo by Mmullie (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/886ad3c0dd/w/

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org//wikis/569d61967e/w/

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org//wikis/569d61967e/w/