Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
r12a opened this issue Oct 25, 2022 · 5 comments
Open

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

r12a opened this issue Oct 25, 2022 · 5 comments
Labels
i:bidi_text Bidirectional text i:interaction Forms & user interaction l:arb Arabic l:ks Kashmiri l:pes Persian l:ug Uighur l:ur Urdu question

Comments

@r12a
Copy link
Contributor

r12a commented Oct 25, 2022

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:

Screenshot 2022-10-25 at 13 01 50

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?

@r12a r12a added question i:bidi_text Bidirectional text i:interaction Forms & user interaction labels Oct 25, 2022
@shervinafshar
Copy link
Contributor

shervinafshar commented Oct 25, 2022

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 r12a added l:arb Arabic l:pes Persian l:ug Uighur l:ur Urdu l:ks Kashmiri labels Oct 25, 2022
@r12a
Copy link
Contributor Author

r12a commented Oct 25, 2022

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
Copy link
Contributor Author

r12a commented Oct 26, 2022

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

@r12a
Copy link
Contributor Author

r12a commented Dec 15, 2023

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
Copy link
Contributor Author

r12a commented Jan 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i:bidi_text Bidirectional text i:interaction Forms & user interaction l:arb Arabic l:ks Kashmiri l:pes Persian l:ug Uighur l:ur Urdu question
Projects
None yet
Development

No branches or pull requests

2 participants