An accessibility scan we ran on a Hebrew site returned an odd finding: 108 pixels of horizontal scrolling on a page that looked entirely fine. The element identified as the cause was more surprising still.

It was the skip link. The component whose entire job is to improve accessibility was the one creating the accessibility failure.

How an accessibility component breaks a page

A skip link is the first link on a page, letting someone navigating by keyboard jump straight to the content instead of walking the whole menu. It is meant to stay hidden until reached by keyboard, then appear.

The most common way to hide it, the one in almost every code sample online, is to move it far off screen: a large negative value, say minus 9999 pixels, pushing it past the edge.

In English this works. The negative value pushes left, out of view, and the browser does not widen the document in that direction.

In Hebrew it does not. The direction inverts, the element lands on the opposite side, and the browser widens the document to contain it. On the site we tested that link ended up over 10,000 pixels wide, dragging the whole page with it.

The result: on a phone, every page on the site slid sideways. That is a failure of the criterion requiring content to fit a narrow screen without horizontal scrolling.

The correct pattern

Instead of moving the text off screen, shrink it to zero size and clip its display. It remains fully present for a screen reader and takes up no space in the layout, in both writing directions.

It is a change of a few lines, and it is the difference between an accessibility component that works and one that does harm.

Why this happens so often

Because nearly all the available knowledge online was written for sites flowing left to right. When a designer or developer searches for “how to hide text for screen readers”, they get a perfectly correct answer, for a different site.

And it repeats well beyond this one case:

A fixed side in the code. Anything written explicitly as “left” or “right” stays stuck when the page inverts. The fix is to write “start” and “end”, which flip on their own.

Arrows pointing backwards. A “next” arrow pointing right is correct in English and inverted in Hebrew. It looks minor, and to someone navigating by those cues it is genuinely confusing.

Animations entering from the wrong side. A component that should slide in from the side the eye comes from, entering from the opposite one.

And the testing tool itself. When we hunted for the element causing the overflow, we found the tool looks for an element extending past the right edge. In Hebrew the overflow runs left, so it correctly reported a problem and could not name the cause. The tools are written in English too.

How to check it yourself

Narrow your browser window to phone width, roughly 320 pixels, and try to scroll sideways. In both directions. If the page moves, there is overflow.

That is a thirty-second check, and it catches one of the most common defects on Hebrew sites: the page you can “drag” slightly to one side, which everyone assumes is just untidy.

How we found it, and that is part of the story

We did not spot this defect by eye. Genuinely: the page looked perfect on every screen we opened it on.

What caught it was a check that runs on every build and measures one simple thing, whether the document is wider than the window. The number was 108 pixels, which is enough to know there is a problem without knowing what it is. From there it was a hunt, and during that hunt we discovered the tool itself was looking the wrong way.

That is the real lesson here, and it reaches beyond RTL: defects of this kind are not found by looking, they are found by measuring. Nobody opens their own site and says “hold on, there are 108 stray pixels here”. What actually happens is that a visitor on a phone senses something shifting, cannot say what, and files it under a general impression that the site is a little careless.

And two more places that break quietly

Forms. A label aligned to a fixed side lands, in Hebrew, on the opposite side from its field, and the visual link between question and answer is broken. No automated check catches this, because in the code the label is associated correctly.

Tables. A wide table cut off on a narrow screen is a problem in any language, and in Hebrew it is cut off on the side nobody tries to scroll towards. The fix is to give the table its own scroll region, and to make sure that region can be reached by keyboard and not only by finger.

In short

Hebrew is not only a translation. It is an inverted flow direction, and any technique that depends on direction has to be re-examined. The knowledge available online is excellent, and most of it was written for a site flowing the other way.

On every site we build the check runs at three screen widths, including 320, and it looks in the direction nobody checks. The bug described here is exactly how we found it, and not by eye.

Want to know whether your site slides sideways on a phone? Let’s talk ↗