-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
'Skip to main content' link for screen reader users #4667
Comments
Keep in mind there is a big UI change (#4086) in progress. Anyway, any improvement is welcomed. |
I would like to take this |
I would like to add that skip links are not just for screen reader users, but for anyone navigating with a keyboard or keyboard-emulating technology. This is important because the skip link needs to be visible, at least then focused (as opposed to being invisible and only heard with a screen reader) |
Hey @ChrisBAshton I attempted a fix for your use case at #11066 and I was wondering what you think about it :) |
Zoinks!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.0.0-rc.16 containing PR #11066 that references this issue. Upgrade today to try it out! You can find this prerelease on the Closing this issue. Please re-open if you think there's still more to do. |
Heyo! 👋 This is an interesting one to me. We had a similar set of links in WordPress that are invisible until focused with a keyboard shortcut: Buttons!@yannbf, your proposal of appearing buttons is a great start. It is a frequently used pattern. Continuing down that path, I tried a few ideas using components from the Storybook Design System. One notable difference beyond styling is the location of the button next to the sidebar. It might not be the easiest option to implement, but it's important the button doesn't cover the items in the sidebar list. Secret AccordionI also did a quick mock where an extra level in the sidebar could appear with appropriate skip links. I don't love the design of this just yet (needs more deliberate styles and a better icon), but it might be a good approach for items in the sidebar list. KeybindingsAnother consideration here are keybindings and how to optimize for zooming around Storybook with a keyboard. @domyen suggested it might be tough (or alot of tabbing) to get around with the initial proposal. I tend to be wary of changing the behavior of arrows, In WordPress's editor, we added an array of keybindings to help folks out that didn't interfere with default behavior. Perhaps we can reuse a few of these shortcuts. In particular:
Those could perhaps map to "Navigate to the next/previous part of the story" and "Navigate to the toolbar." Perhaps we could even add a keybinding for "Navigate to the addons panel." To be clear, I think the predictable Appearing Buttons could coexist with the keybindings. |
Yay!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.4.0-alpha.31 containing PR #15740 that references this issue. Upgrade today to the
Closing this issue. Please re-open if you think there's still more to do. |
Is your feature request related to a problem? Please describe.
It is currently quite difficult to test the screen reader accessibility of a component, as you need to navigate past all of the navigation links and then step into the iframe to interact with the component.
Describe the solution you'd like
I would like to be able to tab once to focus on a "Skip to main content" link. Submitting the link would skip me as close as possible to the current component (i.e. an anchor point just above the iframe).
Describe alternatives you've considered
Other alternatives are to mark up the page more semantically, e.g. a
<nav>
on the component navigation and a<main role="main">
surrounding the iframe.It would then be possible to skip to the main landmark region using the native navigational shortcuts in the screen reader (e.g.
VO + U
for VoiceOver).Are you able to assist bring the feature to reality?
Yes, I would be happy to work on a PR if I know it will be considered for merge.
Additional context
We accessibility-test all of our components, and the current interface provides an unnecessary barrier to our UX/a11y testers.
The text was updated successfully, but these errors were encountered: