Accessible React

# General

General Chatter

Trending conversations
Google Analytics
@hellojere · 3d
React Suspense + lazy over Parcel.js
@david-gomez · 42d
Setting basepath="/path" in the Router doesn't do anything..
@oooooooooooooooooooo · 7d
How to use dialog with react-pose?
@darkeye · 36d
How to inspect the inside of the MenuList?
@jmarantz · 5d

get state from link to pass to parent

Reach/General · December 19, 2018 at 1:04am

get state from link to pass to parent

December 19, 2018 at 1:04am

If I have a Link I'd like to pass `aria-selected=true` to the li its wrapping if the link is currently the active link.

how can I do this in Reach router?

December 19, 2018 at 7:22am

Hi. Not a Reach developer but also use it and chiming in on the ARIA side. aria-selected should be used for single and multi-select states of widgets and not navigation ( Reach Router correctly adds aria-current ( to the link in question. Adding aria-selected to the wrapping <li> would have unexpected results in screen readers. I would recommend against it.

  • reply
  • like

December 27, 2018 at 11:49pm

@almerosteyn my usecase is having tabs. I was taking the example here: and swapping the button for the a so would you suggest just switching the link from aria-selected to aria-current? also depending on the usecase of the component it may be a button or a link is there any way that you know of to swap out these kinds of features so that they're interchangable?

  • reply
  • like

it also looks like this article is suggesting using aria-selected vs aria-current for a link:

  • reply
  • like

December 28, 2018 at 12:37pm

@lifeiscontent I see now what you are trying to achieve. The question, of course is, if one should use a router to build a tabbed interface. Here is a great article on accessible tabbed interfaces by Heydon Pickering:

Quite a bit down in the article the idea of "views" in SPA's is addressed:

"What about the "views" in single-page applications: the different screens found at different routes? Technically, they are closer to the panels of our tab interface than whole web pages. But that's not to say they should be communicated as tab panels, because that's not what a user is likely to expect."

So while one could build a tabbed interface with the router, this means that the tabs are now connected to the browser URL and it starts to feel a lot like navigation. One would even need to update the page title in many cases. While styling them to look like tabs is up to the visual representation, I would personally deal with them as navigation items instead of a true ARIA tabs interface. So maybe that is something to consider, are they really tabbed interfaces in the first place?

That link you added seem to allude to this in any case. True tabbed interfaces have very specific and limited usecases. And can indeed quickly become confusing for a number of users.

As for the actionable element this depends. If you are building an ARIA tabbed interface you are replacing the role of the element so it really does not matter if it is an achor, a button or even a div. If you put `role="tab"` on the element you are overriding its native element role.

If the case of just creating visual tabs while still keeping normal semantics the choice would be down to what the effect of interacting with the element will be. Is it considered a navigation? The use a an `<a>`. I think that in most cases, where the router is involved, this would be the case.

Then to the use of `aria-selected` vs `aria-current`. Well `aria-selected` would be the better choice if it is supposed to act like a tabbed interface, `aria-current` should be the choice if it is supposed to act more like navigation.

I know this sounds a little but up in the air but it really comes down on the use case(s) in question.

  • reply
  • like