get state from link to pass to parentDecember 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 (https://www.w3.org/TR/wai-aria-1.1/#aria-selected). Reach Router correctly adds
aria-current (https://www.w3.org/TR/wai-aria-1.1/#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.
December 27, 2018 at 11:49pm
@almerosteyn my usecase is having tabs. I was taking the example here: https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html 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?
it also looks like this article is suggesting using aria-selected vs aria-current for a link: https://simplyaccessible.com/article/danger-aria-tabs/
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: https://inclusive-components.design/tabbed-interfaces/
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.