Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard mappings on feed example "restaurant" #3144

Open
OliKei opened this issue Oct 15, 2024 · 5 comments
Open

Keyboard mappings on feed example "restaurant" #3144

OliKei opened this issue Oct 15, 2024 · 5 comments

Comments

@OliKei
Copy link

OliKei commented Oct 15, 2024

https://www.w3.org/WAI/ARIA/apg/patterns/feed/examples/feed/

Recommendations for lists require to use arrow keys, home and end keys and optionally "type ahead" to efficiently navigate among list items.
Lists gain focus with a single TAB key and often also loose focus on use of the TAB key. Additionally the list may also offer group skipping.
See keyboard best practices. https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/

The sample does use of the recommended keystrokes, instead the user has to press TAB many times to get from one item to the next (with an invisible stop where the focus is not visible, which does not conform to WCAG2.2 2.4.7 Focus visible).

@mcking65
Copy link
Contributor

Hi @OliKei, since a feed article can contain interactive widgets that consume arrow keys, the feed example uses page up/down. That way, it doesn't matter where focus is inside of an article, the user can immediately jump to next/prior.

When focus is on the article, the focus ring should be drawn around the entire article. If that is not happening, that is a bug.

@JAWS-test
Copy link

In current versions of Chrome, Edge and Firefox, the focus is clearly visible for all TAB steps

@JAWS-test
Copy link

JAWS-test commented Oct 16, 2024

since a feed article can contain interactive widgets that consume arrow keys,

I don't think this is the main reason, because the navigation also applies if the feed only contains text. It seems more important to me that a feed is not a selection list, but contains individual page areas and that screen reader users use the arrow keys to read the page content. The screen reader does not switch to form mode for a feed.

A change is only possible when ARIA implements something like interactive lists. There are already several proposals for this: w3c/aria#1325 and w3c/aria#2036

@OliKei
Copy link
Author

OliKei commented Oct 16, 2024

In current versions of Chrome, Edge and Firefox, the focus is clearly visible for all TAB steps

true, it only happened on macOS Safari, however, it is not always reproducible. Today it was also working OK on Safari. Fascinating.

Yes, interactive lists would be a great enhancement.

@css-meeting-bot
Copy link
Member

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3144 - Feed keyboard interaction issue.

The full IRC log of that discussion <jugglinmike> Topic: Issue 3144 - Feed keyboard interaction issue
<jugglinmike> github: https://github.com//issues/3144
<jugglinmike> Matt_King: Feed is not something that exists in desktop, so everything that we did in feed is kind of tentative in a way
<jugglinmike> Matt_King: If we had "experimental" content back in the day, we would have marked it as such
<jugglinmike> Matt_King: The keyboard suggestions in it are not based on desktop conventions because there is no such thing as a feed on a desktop
<jugglinmike> Matt_King: Judging from the most recent comments on this issue, it seems like maybe there is a problem with focus visibility in Safari
<jugglinmike> Matt_King: But now, I'm not sure based on the most recent comment
<jugglinmike> Matt_King: It's not clear to me that there is a problem, actually
<jugglinmike> Matt_King: I will come back to this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants