Extend <router-link> to set an aria-current attribute for active links, instead of an active class

[rjgotten]

What problem does this feature solve?

This feature enables developers to mark up the active router link in an accessible manner for users of assistive technologies.

What does the proposed API look like?

Similar to the active-class property on <router-link> introduce an aria-current string property, defaulting to a null value. When set, use the aria-current DOM attribute in addition to the active class.

Criteria for whether the DOM attribute should be set are the same as for active-class. The attribute should be set on the DOM node itself -- or instead on the special nested <a> element that router-link can upgrade, should one exist.

The DOM attribute's value should be taken from the aria-current router-link property. Optionally, this could be validated against the list of valid options as per the ARIA 1.1 specification and console warnings could be provided on attempts to set invalid values.

[posva]

I need a bit more help to know what is the right approach here. Is it just setting aria-current="page" along with the class? I based myself reading this article

[rjgotten]

That's pretty much it, yes.

The only nuance here is that there's more choices than just aria-current="page" and depending on what the router-link represents, something like aria-current="step" might be a better fit. (E.g. wizard steps in a purchase process?)

Hence the ability to configure the value of the attribute is needed.
(It's also a bit more future-proof should later ARIA revisions introduce new values.)

[enwin]

Hello there!

I just happened to have the same issue as I wanted to manage the aria-current attribute on certain links.

Any update on this improvement? I'm glad to help and do a PR if you want.

The first step would be to have the possibility to add the aria-current attribute to a user defined value but in the end I think that it would be better to leave the possibility to add any kind of attribute based on the active and exact data (that should be made available in the routerLink component). That means that the user will have to extend the default component maybe?

Happy to discuss the matter and give a hand 😃

[posva]

That means that the user will have to extend the default component maybe?

This is something we have in mind for the next iteration actually, to make it easier to extend router-link :)

[enwin]

Thats great news! Now I can't wait for the next version :P

My obvious question, and sorry for asking this: do you have an idea of the time frame for the next iteration?

Thanks for the reply

[posva]

Unfortunately not. I don't even know how much time I will have to work on it 😅

[enwin]

Haha

Take care and thanks for all the work done so far!

[marcus-herrmann]

For what its worth, here is one possible solution to work/hack with aria-current before the next version arrives:

https://github.com/accessible-app/vuejs/blob/master/src/App.vue#L75

[matthewjumpsoffbuildings]

This is interfering with my ability to manually set aria-current via my own logic. Is there a way to override this so vue stops stripping away aria-current when I don't want it to?

[posva]

Use the v slot api to have full control over all the attributes and events

[matthewjumpsoffbuildings]

It would be nice if there were some router instance properties to customise this behaviour, sort of like we can do with the active classes. For example in a current app I am building I want a certain aria-current value for exact matches, and a different aria-current value for non exact matches