Skip to main content

Disoriented Scripts and the Text Direction Problem on the Web

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.

Published onMar 17, 2021
Disoriented Scripts and the Text Direction Problem on the Web

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: 

Parts of the mug are highlighted with the correct spelling, juxtaposed against the errors.

A mug with many languages translating the word "Tradition". Hebrew and Persian are written Left-to-Right instead of Right-to-Left. The Arabic is shown in broken letters.

Parts of the mug are highlighted with the correct spelling, juxtaposed against the errors.

The Arabic version of "tradition" — shown broken up and written backwards.

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

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. 

The bidi problem

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!"

A hand writes with pen in a notebook.

The first three words are in Hebrew (from Right-to-Left), and then the hand leaves space for a number (written Left-to-Right). As the hand writes, it's clear that there isn't enough room for the whole number: The number spills over and has to be written above the other text.

Mirroring the interface

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.

To flip or not to flip, a visual chart. Browser icons, article icons, and quotes icons can be flipped. A calendar icon probably doesn't need to. A history icon doesn't need to be flipped if it's a clock, but can be flipped if it's undo/redo buttons. A checkmark icon doesn't need to be flipped, unless you're left-handed.

A handy visual guide on flipping common iconography.

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

The (partial) solution

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.

What about accessibility?

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.

I want to support RTL!

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

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

Resources for designing for RTL 


No comments here

Why not start the discussion?