-
-
Notifications
You must be signed in to change notification settings - Fork 5k
Improve vue-router's screen reader experience #2488
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
Comments
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 |
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 |
In this context, it would be great if we could add |
I was looking at scrollBehaviour and thinking that it might make sense to tackle focusing on route change in a similar way, say, 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) 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 |
This is something I'm tackling over at https://github.com/oaf-project/oaf-vue-router and https://github.com/oaf-project more generally. |
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 :) |
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 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 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. |
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;
It's hard to find what to conclude for vue-router in general, except for the focusability on |
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.. 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 |
Marcy reached out to me on twitter, I got that part of my research interpretation wrong. Will update the article, soon-ish
|
Anyone still looking for solutions might be interested in checking out: In addition to announcing the new page at navigation, it can be used for other events like error messages. |
Revisiting this and it looks like aria-current is the only feature that could be automatically added by the Router.
These vary highly depending on the application nature, layout, animations, etc. Having a default in Vue router would break for many of them and become hard to patch. Instead, I think it would help to have an entry about accessibility in documentation with examples to implement each of these and where any necessary consideration or external resources could be listed. |
I've done something like this in App.vue. However, on iOS it sometimes doesn't focus correctly. Another element like a button on the page will take focus, but not always. It seems timing dependent. I've even used a setTimeout instead of nextTick and gotten mixed results. So not sure this method is 100% reliable.
|
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?
The text was updated successfully, but these errors were encountered: