Support Keyboard Navigation
See original GitHub issueMorning!
We are having a little trouble making our scrollTo links work from the keyboard. We could be doing something wrong, but as far as I can tell all scroll related events happen based off of onClick
. It would be nice for keyboard users to also support keyDown/keyUp of the enter key and possibly the space key.
Is this something that you do or are looking to support?
Thanks, Laurie
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (2 by maintainers)
Top Results From Across the Web
Support keyboard navigation | Android Developers
This lesson describes how you can better support navigation with a keyboard. Note: Supporting of directional navigation in your application ...
Read more >Keyboard Accessibility
A keyboard user typically uses the Tab key to navigate through interactive elements on a web page—links, buttons, fields for inputting text, etc ......
Read more >Keyboard Compatibility | Web Accessibility Initiative (WAI)
Many people use only the keyboard to navigate websites — either through preference or circumstance. Whether it's temporarily limited mobility,, A woman with...
Read more >Supporting Keyboard Navigation | Android Developers
When a user navigates your app using the keyboard Tab key, the system passes input focus between elements based on the order in...
Read more >Keyboard accessibility – Accessible Technology
Others prefer using a keyboard because it's more efficient than using a mouse. ... and most software applications, have extensive keyboard support.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yikes. I’ll come back to this this weekend. Sorry for the 2.5 year delay 😂
I spent a bunch of time looking into a11y practices around a “scroll-to-top” sort of button, and couldn’t find anything.
role=“scrollbar” doesn’t seem to properly catch the semantics of the Link element.
Since this library doesn’t have context of the whole app there’s not much we can solve from the library’s perspective besides advising in documentation.
I hesitated to make any changes to the codebase because Link currently has no defaults set.
I think @nielsboecker’s example is probably best, I might also add
role="button"
. I’d also recommend using @reach/visually-hidden to supply a hidden, but rendered text representation of any scroll button that may only rely on iconography or an image.Lastly, and the most difficult, you’d need to manage the change of applied focus depending on where somebody would scroll to. For example, imagine tabbing to the Link and hitting enter. You’re taken 1000px up. When the user hits tab again, I would think they’d expect to focus onto the next focusable element in there view.
@fisshy lemme know if I can add all of this to the README.