Should progress bars in HTML progress and meter elements be read RTL? about alreq

[r12a]

Thanks, Shervin. I wanted to keep the scope of this question to the progress and meter elements because i'm aware that things are not so clear wrt playback controls. So, in summary, you're saying that the current browser behaviour for those specific elements is probably correct.

I'm also inclined to agree with that, because the UI is basically mirrored. For example, these controls are often accompanied by a bit of text that (through javascript) gives the actual numbers involved, which would also appear on the opposite side from the English UI for Arabic text (unless the content author/translator went to some additional trouble to override the direction). Even though the Persian Guidelines doc mentions progress bars, i suspect that when they are embedded in a line of text, they should follow the reading direction.

Anyone else has an opinion?

[shervinafshar]

This has been coming up often in bidi UX conversations and I don't have a good enough answer to it. On the one hand, it seems intuitive that the RTL progression of the text would be expanded to cover the directional behavior of progress bar and similar elements, but on the other hand, my experience shows that this could easily become problematic for some UI elements with significant roles on any specific UI canvas; e.g. considering video player time progress bar, is it also expected that its direction is RTL in an RTL UI context? How about the playback control icons (▶️, ⏯, ◀️)?

Since I'm unaware of any UX cognitive studies showing otherwise, I usually stick with the recommendation of Persian Graphical User Interface Specifications and Guidelines, chapter 2, section 3:

The position of user interface elements should be compatible with the experiences and expectations of the users (Principle 1). Such experiences and expectations may not be related to writing direction. As a rule of thumb, the interface elements that users read like normal text should follow writing direction. For other cases, you have to find out how they are traditionally placed in the locale you are targeting. Many expected placements actually follow left-to-right conventions even in right-to-left locales. The reason is that they either follow mathematical direction (like a progress bar) which is universally left-to-right, or they follow some real world equipment which have left-to-right orientation (such as audio/visual equipment mentioned earlier).

My best attempt recommendation would be based on the whether a UI element is text related or not; the examples above (tickets sold progress bar) makes sense to follow the direction of the paragraph, but for a progress bar in a non-textual context (say, a <div dir="rtl"> with an embedded video player), it might be too counter-intuitive and confusing for the users.

[r12a]

Extended the query to cover the input element with type set to range, which behaves the same way in browsers.

[r12a]

There are plans for a new 'switch' control in HTML, which would, for example, allow you to show something as on or off by sliding a highlight from one side to another. Again, we have the question about whether 'on' should be on different sides in LTR and RTL contexts.

[r12a]

I put out a question at https://w3c.social/@webi18n/111585791552312739:
Should HTML range and switch controls travel in a different direction from those in English text?

I received 2 responses:

Yes for range, ambivalent for toggle switch.

The number line in Arabic math textbooks always goes left to right, so the range line should stay consistent with that.

The switch toggle has visible indicator for when it is selected and when it is not. Physical analogy of light switches for example are not always consistent, so I don't think it matters for this either.

and

I think the most comprehensive guideline for this is provided by google material design. According to this document, the answer to your question is positive.

Everything except a few should be flipped.