Reach-ui: Tabs: left & right arrows are flipped in RTL langs

[felixmosh]

When the layout is RTL, left should be next & right should be prev.

I can create a PR for this, but I need guidance.

There are 2 possible solutions,

1. providing rtl prop, and then flip the behaviour.
2. using computedStyles directopn of the tabList

[venikx]

Hi @felixmosh

I'm going to be honest, not familiar with RTL languages. I apologize for my ignorance in advance.

What did you mean left should be next and right should be previous?
As far as I understand ` doesn't introduce the concept of next/previous, but only the concept of left/right. Adding the extra concept of left = prev and right = next (or the other way around in RTL) seems to be behavior that the consumer should handle, since you are giving extra meaning to the left/right behavior.

The behavior you're thinking of could be handled using "controlled tabs", where you handle the index of the visible tab yourself.

I'm going to read up on the spec about it and come back to you when I'm a bit less ignorant about the intl part of a11y.

[felixmosh]

RTL stands for right to left, when ever you render tabs, the first tab will be at the most right of the line, the second one will be in left of the first...

Checkout the example:
https://codesandbox.io/s/reach-tabs-rtl-example-6463w
on the ltr example, when you focus on the first tab and then clicking on the right arrow key it moved to second tab.

but, on the rtl example, if you do the same but clicking on the left arrow key (the correct key to press in rtl directionality) it moves to the last item instead of the second.

Therefore I've introduced the concept of next & prev.
Hope it explains the issue better.

[venikx]

I think I understand. I've tried looking up resources/references, but the only thing I can find explaining about the tab behavior is: https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel

Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab (See note below).

The bad thing it only speaks in the contact of a11y, not i18n. Do you have a similar doc to a spec?

I think the idea of @ryanflorence with reach-ui is to follow the w3 spec closesly for a11y, so I assume he'd like to the same for the i18n aspect of it. However at the moment I'm not even sure if any behavior is "formely" agreed upon or not. I browsed the i18n spec for a bit, but it's not as clear as the a11y one.

I also don't know how screen readers are supposed to react to it. Probably a good reference point there, but there should be a standard in doc format somewhere? If in right-to-left language truly everything is flipped, I would argue that going to the "next tab" in a RTL should indeed be achieved by pressing the "Left Arrow".

[felixmosh]

I'm a native RTL user :) I can assure u that it is weird to press the right arrow in order to focus on the left element.

[venikx]

Reading a bit more into it, it seems you are supposed to set the dir on an element (if the whole document is rtl, preferably the html/body tags. You are not supposed to css for that, according to https://www.w3.org/International/questions/qa-html-dir.

So potentially a little helper hook useIsRTL() or something could be create which gets that property from the nearest element. But I'm not sure how you'd query the dom to check if you are a child of such element is going to be a perf hit.
Another option would be to allow a rtl prop, but not sure what would be best to be honest.

Thanks for explaining! Learned about a right-to-left languages ^^

[felixmosh]

In my app I've added dir=rtl on the html.
This property is inherited, that means that you can use window.getComputedStyle(tabsRootElement).getPropertyValue('direction')
It will return rtl or ltr.

[venikx]

In my app I've added dir=rtl on the html.
This property is inherited, that means that you can use window.getComputedStyle(tabsRootElement).getPropertyValue('direction')
It will return rtl or ltr.

TIL! Cool man!
I guess that's a nice key to the solution.

[felixmosh]

Actually recently I've wrote a stars rating component that is accessible by arrows, I did neat trick,
onComponentDidMount I've queried the computed style of the main wrapper of my component using ref.

Check it out :]
https://codesandbox.io/s/react-stars-kqcxf

[chaance]

@felixmosh I think computedStyles is the way to go here. We definitely want to be able to adapt for RTL languages based on whatever is determined by the DOM. If you still want to create a PR I'll be happy to get it merged in quickly.

[felixmosh]

Cool!
I will happy to make a commit...

But I’m AFK till the end of the month

[venikx]

@felixmosh That's ok imho, reach-ui is probably the only open-source lib that interests me enough to contribute to once in a while. Any contributions be it committing code, updating docs or just helping out with other people's issues are welcome and I do them in waves (whenever I feel like and when I have time, because I don't spend 24/7 in code :laughing: ).

So I wouldn't feel bad about not being able to contribute until time allows you to ^^

[felixmosh]

@venikx, @chancestrickland I've looked at the source code, looks like I will need to add useDirection hook.

Questions:

1. Where to put that hook?
2. WDYT about the api of it?

useDirection api will return a ref & direction (rtl or ltr).
The ref will be putted on the dom element that we want to check it's direction. (direction property is inherited in css, so I guess that it is not correct to check the window direction but the tabs element it self).

I will be based on windowSize hook

[felixmosh]

ping?

[felixmosh]

ping?

[chaance]

@felixmosh Hoping to deal with this issue before the end of the week along with some other improvements for tabs. Stay tuned.

[felixmosh]

I've tested it, it works like a charm, thank you 🙏🏼