There is a setting almost nobody knows about, and the people who do use it generally need it: raising the text size in the browser settings. Not zooming the page, but a preference saying “text on every site should be bigger”.

Anyone who set it, then visited most Israeli websites, sees no change at all.

The cause is one unit of measurement

When a developer sets a text size, there are two main options.

A fixed unit, pixels. That is an absolute statement: this text will be this size, full stop. It silently overrides the user’s preference.

A relative unit. That is a relative statement: this text will be so many times the base size. And the base size is exactly the preference the user set in their browser.

The difference in the code is one character. The difference for someone who enlarged their text is between a site they can read and a site they cannot.

That is why on every site we build every text size is defined in a relative unit, without exception, and it is checked automatically on each build. Not for elegance, but because it fails silently: nobody complains, they just give up on the site.

What the standard says

The relevant criterion requires that text can be enlarged up to twice its size without losing content or functionality, at the binding level.

Note that the requirement is not only “the text grows”. It is that nothing breaks when it does: text is not cut off mid-sentence, a button does not leave the screen, two words do not overlap. That is a thirty-second check you can run now: take the page to 200 percent and see what happens.

The trap that comes from good design

There is a pleasant modern technique that grows the font gradually as the screen widens, instead of jumping between fixed sizes. It produces a smooth, professional result.

And it has a trap: if the formula rests only on screen width, it disconnects the text from the user’s preference entirely. The advanced solution cancels the whole benefit of the relative unit and returns us to a site where enlarging text does nothing.

The fix is simple: the formula has to include a relative component, not just screen width. We check that automatically, because it is a mistake that looks perfect in any visual review.

And what matters more than font size

During a typography pass on a client site we found something that repeats almost everywhere: the problem was not the font size but the line length.

The comfortable range is roughly 45 to 75 characters per line. That site had 106. Enlarging the font alone would have brought it to 87, still far off. What actually solved it was narrowing the column at the same time.

The reason is simple: when a line is too long, the eye has to find the start of the next one on every pass, and that is tiring. It does not look like a problem in a screenshot, and it is very noticeable by the third paragraph.

One more thing almost everyone misses

Desktop text should not be smaller than mobile text. That sounds backwards, and the reason is physical: at a computer people sit roughly 50 to 70 centimetres from the screen, and on a phone roughly 30 to 40. The same letter size looks smaller on the computer.

Accessibility passes tend to enlarge mobile and leave desktop behind, partly because the checking happens on a large screen where there is plenty of text and everything seems fine.

Two more units worth knowing

Line height with no unit. This sounds like a trivial technicality, and it is not. When the spacing between lines is set as a plain ratio, every element recalculates it from its own font size. When it is set with a unit, the computed value is inherited downward, and a paragraph with a large font inside a section with a small one ends up with cramped lines. It is a mistake that looks fine in a heading and is only felt in a paragraph.

Section height on a phone. A unit tied to the window height is calculated on mobile as though the browser address bar were hidden. The result is a section taller than the screen that jumps as you scroll. There is a newer unit that refers to the real height, and it is worth using.

And what is easy to miss in the check itself

When measuring whether something breaks under enlargement, it is tempting to check two screen widths and conclude all is well. With type that scales gradually that is precisely not enough, because the problem occurs between the widths rather than at the edges. In one pass we ran, measuring at two widths returned “zero problems”, and checking in between revealed twenty-three sizes that had actually got smaller.

In short

Someone who enlarged their browser text did it because they need it. A site that ignores that does not look broken; it simply loses that person quietly.

Three checks you can run today: take the browser to 200 percent and see what gets cut, count the characters in a line of a long paragraph, and compare the text size on desktop against your phone. Together they take under five minutes.

To be clear: everything here is general information, not legal advice.

Want us to check this on your site? Let’s talk ↗