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

Improve vue-router's screen reader experience #2488

Open
marcus-herrmann opened this Issue Nov 19, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@marcus-herrmann

marcus-herrmann commented Nov 19, 2018

What problem does this feature solve?

This feature request is about the screen reader experience of apps built with vue-router. In a nutshell: When a user of assistive technology, such as a screen reader, activates a <router-link>, their focus stays on said link, giving them no feedback at all (user with sight don't have that problem because they see that parts of the app change). So it is about notifying user of DOM changes.

One way is to set the focus to the newly loaded content.

General links on this:

My suggestion on this to match Reach Router behavour (which puts, after route transition, the focus on the wrapper of the loaded components. In my understanding the vue-router counterpart for this is <router-view>).

You could also go even further by defining a "focus target". I wrote about this approach here: https://marcus.io/blog/accessible-routing-vuejs

What does the proposed API look like?

<router-view focustarget="someRefInChildComponent"></router-view>
// If focustarget is not supplied, focus after route transition is put on router-view itself

@posva posva added the discussion label Nov 19, 2018

@posva

This comment has been minimized.

Member

posva commented Nov 19, 2018

Thanks for bringing up the discussion. I've been looking at reach router for some time regarding this and it's something we should be able to provide

@tesla3327

This comment has been minimized.

tesla3327 commented Nov 20, 2018

I think this is a great idea, since I will have to implement this behaviour in order to make our app fully accessible.

Defining a focus-target instead of the default, as well as being able to opt-out of this behaviour completely seem to make sense to me as part of the API.

@marcus-herrmann

This comment has been minimized.

marcus-herrmann commented Nov 22, 2018

In this context, it would be great if we could add aria-currentto the active <router-link>. See #2116

@thedamon

This comment has been minimized.

thedamon commented Dec 3, 2018

I was looking at scrollBehaviour and thinking that it might make sense to tackle focusing on route change in a similar way, say, focusBehaviour.

It becomes a little tricky figuring out how to best handle focusing on elements. Typically, though a safe default would be the wrapper element for the route itself (you just might have to add tabindex="0" to it, possibly programmatically)
Perhaps each route could take either a ref name within that component, or an ID, or fallback to the wrapper element of the route component and router could attempt to move focus there on change?

I'm currently fighting with how to throw focus to a layout component with a router-view because I want to focus on its header on change of its router-view

@vuejs vuejs deleted a comment from Stegosource Dec 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment