Keyboard Navigation Improvements for Hovercards

[j0siepy]

⛰️ The challenge

The only way to interact with hovercards in dotcom right now is limited to mouse users (hover over the triggering link). This violates WCAG 1.4.13 (Content on Hover or Focus), inhibiting some users when there are hovercards in the UI.

🍰 Our Approach

We introduced keyboard behavior so that users can navigate and dismiss hovercards without needing to use a mouse. When a user is focused on a link with a hovercard, users can press alt + up to make the hovercard appear and move focus inside. Focus is trapped, just like it would be in a dialog and users can press esc to dismiss the hovercard and restore focus to the link.

Based on both community and internal feedback we have also introduced user settings to disable all hovercards.

👂Feedback

Please share your thoughts in the comments. If you are interested in providing more in-depth feedback, let us know there as well.

All users:
What is the best way to make the Alt+Up keyboard shortcut discoverable but not noisy?
Tell us about your experience of moving focus into/out of a hovercard? How does this impact your workflow?

Screen reader users:

• How helpful or unhelpful would it be if hovercards automatically appear on focus?

Keyboard only users:

• Would it be useful to have links with hovercards visually distinguished from other links? For example, having a differently-styled underline or a focus indicator.

Screen magnification users:

• Can you access and navigate to the controls for hovercards easily?

Anyone who may be negatively impacted by this change that we may not have accounted for:

• This keyboard shortcut is only available when the focus is on a hovercard link, not anywhere else on the page. Does the Alt+Up keyboard shortcut interfere with your setup?
• Is there anything about the experience for your specific set up that you would like to share?

[aardrian]

I am thrilled to see this opened as a discussion for user feedback. I think some readers might appreciate context for what spurred it, including the feedback and even a screen recording: https://github.com/orgs/community/discussions/127592

I look forward to seeing what y'all have to say (and yes, I am boosting this to AT users I know so they can hopefully weigh in).

[nebeker]

Using a screen reader I'm noticing reading order issues inside hovercards - the follow button coming up in between the different regions. "Press Esc to close this hovercard" isn't too annoying, since it's at the end - if you know the widget, you'll never have to hear it again - but may still be redundant since that's the typical interaction style. There are a whole lot of regions and groups to go through, but I could also change my verbosity settings.

They're everything but discoverable - I just learned the shortcut from this thread. If I wanted to learn about a user, I'd follow the link to their profile. I don't remember wanting to know about a user in context, but this seems like a good way to do that, conceptually.

Using magnification, they're easy enough to dismiss by moving the mouse away, if I'm not interested in them. If I am, it could be easier to have an X button, so I can push the side of the screen with the mouse to pan around and not have it dimissed unintentionally.

Putting all that together, for me, a nice interface would be something like an arrow button next to a username I can click/activate if I want the info. That would then pop up a card with an X button. That would also fix the discoverability, at the cost of an extra element everywhere.

@aardrian the elephant toots at midnight? Can we start that?

[aardrian]

My elephant toots all the hours of the day.

[jscholes]

@j0siepy I'm grateful for the update, but unclear about how it addresses the concerns raised in https://github.com/orgs/community/discussions/127592. Your comment here, and the changelog entry only talk about the keyboard behaviour (which AFAIK was already present), and don't mention accessible descriptions or other forms of link annotation at all.

If the solution is literally that:

1. link annotations have been removed;
2. the keyboard behaviour has been retained; and
3. if you don't want the keyboard behaviour, you can turn it off...

... then that's fine. But I think it could be more explicitly spelled out, to acknowledge the problems screen reader users experienced in the first place.

[paulshryock]

leaving us open to audit issues

Should read: "excluding some users from using our site"

[j0siepy]

Thank you for the feedback! Updated that section.

[jscholes]

Much of this advice is both wrong and would make GitHub less accessible. As it was clearly written by an LLM with no editing, I won't bother breaking down why.

[aardrian]

Commenter joined 2½ hours before writing that and the only link is spam, so yeah.