Story: On desktop, a low vision user zooms in with CTRL + Plus to read more easily. Zooming makes the paragraph expand, and a horizontal scrollbar appears to access the full content.
Are you able to spot what the main issue is for people with low vision?
We asked folks on LinkedIn and gave four options:
- Option 1: Too much text in one line
- Option 2: Must scroll sideways to read
- Option 3: Text is too big after zooming
- Option 4: Text is missing colour for impact
The answer: Option 2. Users have to scroll sideways to read the content.
TLDR;
Scrolling sideways and up and down is very hard for people with low vision. How much harder? Not 3 times. Not 5. Not 10 or 20. It can be up to 70 times harder to read the same content others read in one go.
This is because they have to read word by word, scroll sideways, remember the last words, scroll again, and keep going. Horizontal scrollbars are hard to use and arrow keys do not always work.
Full Explanation
The problem is not just scrolling sideways. The real issue is scrolling in two directions: up and down, and side to side. We say “scrolling sideways” because it is easier for English speakers to understand.
To see why scrolling in two directions is hard, we need to look at how people with low vision use web pages.
Some people with low vision cannot read at arms length. They need to make the text bigger. On a laptop, they could lean in close to the screen, but that can hurt their neck. On a phone, they could hold it close to their face, but their arm gets tired quickly.
So instead, they use a tool called a Screen Magnifier.
The Basics on Screen Magnifiers
A screen magnifier works like a digital magnifying glass for your screen. It makes everything bigger, not just one webpage. It runs on your computer or phone, so all apps and websites follow the same settings.
It is not the same as zooming into each webpage. It works across everything.
Screen magnifiers can be used on both computers and phones. For example:
- iOS: Settings > Accessibility > Zoom
- Windows: Start menu > Magnifier
People use screen magnifiers in different ways. Some use the mouse pointer. Some use the keyboard. Some turn on speech to hear what’s on the screen. Some make the pointer bigger. Some use a fixed zoomed-in area. Some do all of these.
For this example, I’ll focus on someone with low vision using the mouse pointer to move around the page.
Desktop Screen Magnifiers
Imagine someone with low vision sitting at their computer, using a screen magnifier to read a web page.
They have opened the page and set the magnifier to 400%. Windows screen magnifier can go up to 1600%, but we’ll stick with 400% for now.
At high zoom, they see only a small part of the page. To see more, they move the mouse pointer. The pointer works like the handle of a magnifying glass. Wherever it goes, the zoomed-in view follows.
They have a lot of space to move around, but this makes things harder. It’s tough to learn where things are on the page. Some parts might be off to the side, and they won’t know unless they pan across.
Reading sentences is also tricky. They have to remember the last word before moving to the next part.
Users Want Less Mouse Movement
The mouse pointer lets them move around the page, but it’s not a fun experience. They have to keep scrolling with the mouse or swipe the touch pad again and again. It gets boring fast, and doing this for hours each day can become painful.
Screen magnifier users try to avoid using this experience when they can. The first thing they want is to stop panning left to right on their desktop. They know this happens because they have zoomed in a lot, but they also know how to fix it.
They can cut down the side-to-side panning by making the browser narrower. The best case is when the browser width matches their zoom level, so no panning is needed at all.
It may not match the exact magnification level if the user zooms in too far. However, reducing the browser size is still better than keeping it full screen.
What should happen is that the content fit neatly inside the resized window. No sentences fall off the edge and there is no horizontal scrollbar.
This smooth experience is called content that “reflows“.
Note: Zooming into a browser using CTRL + PLUS has the same effect as physically resizing the window to a smaller width. Both actions reduce the visible content area, which helps screen magnifier users avoid horizontal panning
Once the window is reduced, especially to an ideal width, magnifier users only need to scroll up and down to read. Side-to-side movement is no longer necessary. This makes a big difference to their experience.
Back To Our Story
Let me repeat it so you don’t have to remember:
Story: On desktop, a low vision user zooms in with CTRL + Plus to read more easily. Zooming makes the paragraph expand, and a horizontal scrollbar appears to access the full content.
After reading the explanation above, it’s clear: the problem is that people cannot view the full content without using a horizontal scrollbar.
Despite their best efforts to avoid panning, the website still forces them to after they’ve zoomed in and resized their browser window to read more comfortably.
Some content, such as tables or graphs, may need to be understood in two dimensions. Shrinking them to fit can make the information unreadable, and reflowing them may change its meaning.
However, most online content should resize without issue. If it does not, the website likely has not been designed or built to support it.
This is what happens when content does not reflow.
Is this a WCAG failure?
Yes and no.
There is a rule called Success Criterion 1.4.10: Reflow (Level AA) that may apply, but only in certain cases.
It is important to assess each case individually. If one element requires two-dimensional scrolling, the rule applies only to that element, not to the entire webpage.
It applies to horizontal languages like English at a page width of 320 pixels, and to vertical languages like traditional Japanese at a page width of 256 pixels.
Why does the direction of the language matter? Because this rule is meant to reflect how desktop users zoom into a page. The shape of the screen and the reading direction both affect how the content should behave.
The rule must be testable, so it sets clear widths that match how people with low vision zoom or resize their browser.
For English readers, screens are usually wider than they are tall. English is read left to right. A common screen width is 1280 pixels, and zooming to 400% gives a test width of 320 pixels. Scrolling happens vertically.
For traditional Japanese readers, screens are often taller than they are wide. Japanese is read top to bottom. A common screen height is 1024 pixels, and zooming to 400% gives a test height of 256 pixels. Scrolling happens horizontally.
When It Fails WCAG
An example of a failure for Success Criterion 1.4.10: Reflow is if all the following are true:
- The page is 320 CSS pixels wide.
- The content cannot be fully read without scrolling sideways.
- The content is in English (a horizontal reading language).
- A horizontal scrollbar appears.
- The horizontal scrollbar is needed to understand the content.
When It Does Not Fail WCAG
An example of a pass is if any of the following are true:
- The English page is larger than 320 CSS pixels wide
- A horizontal scrollbar appears, but is not needed to understand the content
- The content requires two dimensional scrolling to be understood, such as a table.
You might be thinking that these requirements seem very narrow. It may feel unfair to hold websites to such specific conditions, especially since low vision is a spectrum and users may zoom to 300 percent or other levels.
That concern is valid. WCAG does not cover every situation. However, it does make a strong effort to protect those most vulnerable to barriers online.
The measurements used in these rules are designed to highlight serious accessibility issues. They are also chosen to be reasonable targets that most web pages can meet.
Misconceptions About SC 1.4.10 Reflow
I thought it would be best to clear up any conceptions at this stage.
Some assume the rule requires testing both horizontal and vertical dimensions together, even for English content.
They often apply the 320-pixel width and 256-pixel height at the same time, and check whether the content fits within that combined space.
When the content does not fit at both this width and height, they raise concerns claiming that users with low vision cannot access certain elements because they fall outside the visible area.
Whilst arguments could be made for these being valid concerns, they do not constitute failures of SC 1.4.10 Reflow
Success Criterion 1.4.10 Reflow does not require content to fit within both dimensions at once.
Conclusion
By now, it should be clear that horizontal scrollbars on English websites are a problem. They force people with low vision to read in two directions, which takes unnecessary and often exhausting effort.
No one should have to struggle just to read your content.
And they will not stay. They will leave and go to a competitor who has made their site easier to use.
If you found this article helpful, please leave a comment. We would love to hear your thoughts. Your feedback means a great deal to us.