@SimoneThisDot thanks for creating this ticket. I think we will need to add a few more things especially pertaining to the following AC.

When Search Preview is open with the keyboard, set Focus on the first heading

1. What does "first heading" mean here? Will it be an aria label for the image or article name. Ideally if the image has an aria label it would be nice if not a generic one we can add.
2. Once the focus is on search preview we also need to allow users to navigate the rest of the search preview content through keyboard. So I would assume arrow up/down would go through various items in the preview. While the arrow left/right would allow users to switch the focus from preview to search results and vice versa.

What do you think? There is a separate ticket for allowing users to go from one preview to another but for it (like you said) we will need to add the buttons and only when the user is focused on those button can they use that functionality.

3. Also we don't have a good aria label for thumbnails. So perhaps we could add that here too. Does the image come with an aria label or do we have to come up with something generic?

1. I think we should add an hidden heading that explain what the Preview provides and the different blocks it is made of
2. We would not use the arrows to move between content but the user will use the Tab button as this would let them move between the different heading (using the arrows key would not be what they expect hence leaving it to be Tab based I guess is more beneficial)
3. The thumbnail and all images (even the commons) alt text is not really useful, most of the time is just the name of the image.

1. If we do hidden heading what would the visual focus be on while that text is being read?
2. Okay got it. Then in that case we could use left and right arrows to move between previews. I will add this in the AC.
3. Okay in that case we can leave it as is. The label says it's an article link which is correct behaviour.

While the app is in development I 2 pieces of text (that are not visible in design, but set behind the scene for accessible users:

1) The text attached to the aria label on the ARROW within the search Result. This should be used to inform the user that clicking that button will open the search preview and maybe explain what it is.
The text is used: Get access to further information on this article by accessing the search preview."

2) The text attached to the search preview dialog that is going to be used to explain visually impaired users what to the dialog is for and how to use it.
The text I used: Search Preview Dialog. Find further information such as Description, sections and interwiki information

cc: @Sneha @CBogen

@SimoneThisDot Below are suggestions to reduce the length of the label and make it more consistent with other messaging. Also I removed the verbs for #2 as the label is not an action.

#1: "Open the preview of this article."

#2: Preview dialog is now open. It shows key information on this article and related content."

(the second half of this is somewhat consistent with how we explain search preview in tutorial dialogue)

Change 880926 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[mediawiki/extensions/SearchVue@master] Enhance search Preview keyboard navigation

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

I have completed all the required AC expect the Move between article that is going to be covered by https://phabricator.wikimedia.org/T307051

Change 880926 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Enhance search Preview keyboard navigation

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

In T326641#8528607, @Sneha wrote:

@SimoneThisDot Below are suggestions to reduce the length of the label and make it more consistent with other messaging. Also I removed the verbs for #2 as the label is not an action.

#1: "Open the preview of this article."

#2: Preview dialog is now open. It shows key information on this article and related content."

(the second half of this is somewhat consistent with how we explain search preview in tutorial dialogue)

#1 and #2 are DONE - checked in betalabs with VoiceOver (Mac).

Current behavior for the following specs: (checked in betalbs)
(1)

• When Search Preview is open with the keyboard, set Focus on the first heading

The focus is on the entire popup, then it moves to the close (x) button:

first focus	next - focus on the close button

(2)
@Sneha, please confirm if the behavior is expected:

• If the Search Preview is closed, move focus to the search results that was currently displayed in the search preview

If the Search Preview is closed with esc button, the focus will be as the spec says.
If the Search Preview is closed via pressing the close button (the x), then clicking the tab for navigation will bring a user to a footer menu.
If a user navigates through the entire Search Preview, the focus will be on the footer menu.
(3)

• Use left and right arrows to switch between previews

The following comment from @SimoneThisDot, is applicable to the AC?

We would not use the arrows to move between content but the user will use the Tab button as this would let them move between the different heading (using the arrows key would not be what they expect hence leaving it to be Tab based I guess is more beneficial)

I did not find how arrows can be used in navigation.

Thank you so much for your great testing as always Elena...

1. after careful consideration I have changed this to actually focus the main body instead than the first heading. The main reason for it was that the first heading would not have provided absolutely any context to the user while focusing on the main dialog allows us to explain what the search view is.

2. There are two points here that need fixing:
3. When user clicks "x" with the Keyboard (not if they click) the focus should go back to the current result preview
4. When the last tabbable item of the search preview is reached, pressing tab again should revert back to the first heading and NOT go out of the preview

3. This is going to be tackled on another ticket: https://phabricator.wikimedia.org/T307051

Change 883158 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[mediawiki/extensions/SearchVue@master] Add keyboard navigation to Search Preview

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

In T326641#8552070, @SimoneThisDot wrote:

Thank you so much for your great testing as always Elena...

1. after careful consideration I have changed this to actually focus the main body instead than the first heading. The main reason for it was that the first heading would not have provided absolutely any context to the user while focusing on the main dialog allows us to explain what the search view is.

Thx, @SimoneThisDot! Yes, it makes sense.

2. There are two points here that need fixing:
3. When user clicks "x" with the Keyboard (not if they click) the focus should go back to the current result preview
4. When the last tabbable item of the search preview is reached, pressing tab again should revert back to the first heading and NOT go out of the preview

I'll will be waiting for the patch to be merged.

3. This is going to be tackled on another ticket: https://phabricator.wikimedia.org/T307051

Yes, the task - T307051 - covers the additional functionality (the arrows) perfectly well.

Change 883158 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Add keyboard navigation to Search Preview

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