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

[r12a]

Background

This question was prompted by the HTML issue at whatwg/html#8413

Currently, for RTL script text Blink, WebKit and Gecko engines all reverse the direction of the progress bar when progress, meter or input=range elements are used in HTML.

This means that the direction of the controls is the same as the reading direction of the text. For example:

Test for meter

Test for progress

Test for range input control

Question

Is it preferable for the direction of the control to follow the direction of the surrounding text, or should it always progress from left to right?

[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]

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?

[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.

[avidseeker]

As an Arabic speaker, I add my vote to keep the direction of these elements and not flip them. RTL is a writing direction not a UI direction that just flips everything in it like a mirror. Yes, some of the UI should be flipped because of how text is rendered, but that shouldn't extend to all possible elements.

1. Consistency: If RTL users are forced to use a LTR interface (which isn't uncommon, e.g: for a lack of translation), their muscle/visual memory would be reverse to what the button elements show.
2. Math: even in RTL textbooks, the number line is taught as increasing (progressing) from left to right, zero to positive.
3. Keeps things simple: avoids the headache, maintenance, and the possibility of bugs. LTR developers rarely would check what RTL elements look like.