Improve vue-router's screen reader experience

[marcus-herrmann]

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:

• Google's A11ycasts episode #22 on focus management in SPAs
• How to deal with the same problem in Angular
• Reach Router for React take on focus management in routers

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]

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]

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]

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

[thedamon]

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

[danielnixon]

This is something I'm tackling over at https://github.com/oaf-project/oaf-vue-router and https://github.com/oaf-project more generally.

[posva]

That's cool, I wasn't aware of focus restoration being a common issue with routers. I will also take a look at that. It's nice of you to put some of the links in your repo, I will also be able to check those :)

[mdarrik]

What would need to be done to move this issue forward? This can be a pretty big accessibility problem with Vue-Router, and working around it for every project isn't super ideal. I definitely would like the ability to set the focus based on a ref, as some user research suggests skip links might be one of the best places to deposit focus after navigation (see this talk by Marcy Sutton and Samuel Proulx at Inclusive Design 24 for reference).

I'm not sure if this would be a breaking change (because the focus behavior would be different)? And I assume there'd be some design decisions to consider when the user is handling their focus management outside of vue-router. Would a flag/boolean prop make sense? Like call router view like this <router-view resetFocus="true" :refToFocus="myRef">. Where refToFocus is optional (and maybe makes resetFocus optional if set?).

I'm happy to try and open a PR on this if it doesn't seem like something that needs to wait for a vue-router v4.

[marcus-herrmann]

Now, after a little bit more than a year (and with some user research, conducted by @marcysutton in a Gatsby/React app), I'd like to modify my initial suggestion:

https://marcus.io/blog/improved-accessible-routing-vuejs

tldr;

• Focusing the app wrapper after route change
• Working with skip links (which cannot be implemented without a hack in the current vue-router)
• Route title announcement with live region.
• Demo: https://codesandbox.io/s/improved-accessible-routing-vue-u0dh9

It's hard to find what to conclude for vue-router in general, except for the focusability on <router-view> (and the other improvments regarding internal anchors and aria-current).

[thedamon]

Great summary! I just bookmarked your article to read before seeing the response here.

Focusing the app wrapper may cause some issues. In chrome if you throw focus to an element that's larger than the screen, it will just scroll the bottom into view (And this behaviour seems differnet in firefox, safari and IE..
Any focus management will need to take scroll management into account (though that could be on the user). (and without getting too deep into it, focus/scroll options work poorly together with current standards and that could cause issues, so it might be nice to look into that (or just let people fight it out on their own?)

Maybe a separate issue but I do agree skip-links are important to accessibility in general and having them 'just work' in router would go a long way toward encouraging accessible websites

[marcus-herrmann]

Focusing the app wrapper may cause some issues.

Marcy reached out to me on twitter, I got that part of my research interpretation wrong. Will update the article, soon-ish

Maybe a separate issue but I do agree skip-links are important to accessibility in general and having them 'just work' in router would go a long way toward encouraging accessible websites
👍