In a recent HRCD call, we discussed language accessibility for non-Left-to-Right languages, and dived into usability issues, anecdotes and frustrations from design, development, accessibility, and project management angles. We examine Right-to-Left design considerations here.
The lack of linguistic diversity on the web is a problem that has seen a lot of discussion over the years. While there is significant progress on representing various languages on the web, one missing component is representing languages that do not use the Latin script for writing.
In a recent Human Rights-Centered Design call, we discussed language accessibility for non-Left-to-Right languages, and dived into usability issues, anecdotes and frustrations from design, development, accessibility, and project management angles.
The Internet (as are computers in general), is designed from the ground up for the Latin script, which implies a directionality to the flow of user interface elements, from left-to-right (LTR), and from top to bottom. This presents a serious problem for any language that uses a right-to-left (RTL) script — such as Arabic, Farsi, Urdu, and Hebrew, but also others, such as Uighur, and Dhivehi, and languages using African scripts such as N'Ko and Adlam — resulting in many comically tragic renderings:
Images in this blogpost graciously provided by Moriel Schottlender.
Languages that use top-to-bottom script (such as Japanese, Korean, and Chinese), have gone as far as adapting their script to be left-to-right to be rendered by computers.
Arabic speakers have grown so frustrated with the failed attempts at Arabic inclusion, they started compiling bad examples of Arabic rendering on notarabic.com.
The lack of support for Arabic language content spans all layers of content production, from the tools used to design the user interfaces, to the browsers rendering the content.
When using a right-to-left language, you often use left-to-right characters for representing numbers, ranges, and other pieces of information. A bidirectional, or “bidi”, text is where these two different directional texts occur.
Something that is taken for granted, such as reading a string of emoji in sequence, becomes tricky in RTL languages. Do you read the emoji in RTL or LTR? Browsers, applications, and operating systems all have different implementations of such rules, and you cannot guarantee that the string of emoji that you sent will be rendered in the order that you intended on the recipient’s screen. RTL language speakers have resorted to hacks such as inserting a single RTL character at the beginning of a message to force the recipient’s app to render the content from right-to-left.
The behavior of numbers (which are read LTR in some RTL languages) is a particularly fraught area prone to design and development issues. An illustrative example of challenges people face outside of computers dealing with bidirectional issues is in the following hand-written sentence: text in Hebrew is written RTL, the number itself is written LTR, and the sentence concludes with RTL.
She's writing the sentence: "The lottery winner received [number] dollars!"
Often, ‘mirroring’ the interface (quite literally flipping it) to flow from right to left solves most problems, although not all of them. For example, mirroring a clock’s face would result in a lot of confusion. Some guidance included below from Moriel Schottlender.
Another problem is changing the orientation and location of buttons: the send message button is on the right side of the screen so you can press “send” with your right hand, and mirroring the user interface moves the send button away from your dominant hand (assuming right-handedness).
A lot of problems can be addressed by using HTML markup correctly. Examples where HTML markup can address such issues include using dir attribute at the top of the page, and then wrapping changes in base direction in markup as needed. Improvements introduced in HTML5 include automatic directional isolation of content where dir or <bdi> is used: this is particularly important for handling numbers properly, such as the bidirectional LTR number in a RTL sentence example. The W3C has recommended against the use of CSS direction and unicode-bidi properties for managing bidirectionality in HTML—they instead suggest using markup for better semantics and portability.
Moreover, the CSS Working Group of the W3C has proposed a solution that will help web designers support RTL interfaces much more easily. They propose logical CSS properties that allow the flow based on the logic of the script, as opposed to the physical flow. For example, you would set border-start, instead of border-left.
The support for logical CSS properties is fairly common across modern browsers, but it is still incomplete. If you use post-processing tools for your CSS, you can ensure compatibility across browsers using postcss-logical.
People using assistive technologies for RTL languages, like users with disabilities, are doubly-impacted by usability and accessibility issues. We talked about two priority fixes for users with disabilities using RTL languages. Developers first need to ensure the tool supports RTL, then secondly, developers need to be aware of backend issues: if things appear correct visually through CSS, but they are not correct on the back-end, technology like screen readers may read the text out of order.
Screen readers — or software which transmits whatever text is displayed on the computer screen into a form that a visually impaired user can process (usually tactile, auditory or a combination of both) — need further accommodation in how to read a language. Users may get particularly confused when their device interprets text from two different languages, particularly when the text does not include semantic indicators to make the directionality explicit. Some screen readers might read RTL text as individual letters read in reverse order, or as individual words read from left-to-right.
Content authors need to make sure that text both looks correct visually but also would be read out correctly by assistive technologies. Additionally, there are also bugs that need to be fixed at the browser level — how they are implemented, but also how they communicate with screen readers, and so on.
An additional use case to be aware of is screen magnification tools for readers with low vision considerations: It’s important to have ‘landmarks’ so people can orient themselves on the page: imagine an element where the label or content appears in an unexpected place. How do you navigate from there? It can feel like trying to find a needle in a haystack.
Moreover, RTL readers with cognitive disabilities also require assistive technology; when the technology misbehaves, it can be confusing for the user. Some people need to see and hear the content at the same time, for example, using text-to-speech while looking at the simultaneously. If this content does not match, it can be problematic.
We’re glad to hear! There are some low-hanging fruits. Here’s a short list:
Think about all the users of your platform. Are you making an intentional effort to make your interface elements RTL-friendly? Are you using web accessibility practices?
Start using logical-css in your code!
Run your code through http://rtl.works/ and implement any feedback it might give you.
Make sure that font sizes are matched between the different scripts that your interface is using (12 points in Latin script is easy to read, not so in Arabic script).
Are you an RTL user? The W3C is always looking for help from people who can identify gaps in support for RTL languages that can be addressed by HTML, CSS or other W3C technologies. If you want to influence the development of Web technologies, check out and click on the squares at https://w3c.github.io/typography/gap-analysis/language-matrix.html.
The W3C is currently documenting issues for the following RTL scripts: Adlam, Arabic, Hebrew, and N'Ko, but more can be added if there are experts who can help in describing the barriers they are facing.
Examples of broken Arabic in the wild: http://notarabic.com/
On the digitization of Urdu: https://restofworld.org/2021/bringing-urdu-into-the-digital-age/
Noto typeface case study - how Google sponsored the development of a font for 800 different languages
Media Show short introduction video to what localization is, with puppets https://www.youtube.com/watch?v=emiHr4t_SyE&list=PLAD0DF4D26FC60578&index=18
Localization Lab resources for designers and developers: https://wiki.localizationlab.org/index.php/Developer_Resources#Bidirectional_and_RTL_Languages
W3C matrix of languages and gap analysis: https://w3c.github.io/typography/gap-analysis/language-matrix.html
W3C guidance on bidirectionality and strings: https://www.w3.org/International/articles/strings-and-bidi/
W3C draft on bidirectional use cases: https://w3c.github.io/i18n-drafts/articles/lang-bidi-use-cases/index.en
W3C internationalization tutorials and recommendations on character use in HTML:
W3C overview on language enablement program
CSS logical properties:
if you use post processors, there's a postcss plugin:
RTL CSS properties:
Autoflips (allowing for exceptions) your CSS: cssjanus https://github.com/cssjanus
Mozilla - Building RTL aware websites:
Really good doc about the alternatives to using the normal left/right css: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/RTL_Guidelines
Accessibility ARIA considerations:
RTL implementation discussion in twitter bootstrap: https://github.com/twbs/bootstrap/issues/30918
More on digital accessibility, including tutorials: https://www.w3.org/WAI/
Microsoft’s localization guidelines https://docs.microsoft.com/en-us/globalization/localizability/overview