Why test both kinds of enlargement?
People enlarge websites for many reasons: to read small text, distinguish controls, or use a screen from farther away. A page that looks tidy at its default size may become difficult to use when its contents grow. Testing enlargement helps reveal problems that a visual check at one screen size can miss.
Browser zoom usually enlarges the entire page, including text, images, and interface controls. Text-only resizing, where a browser offers it, increases text size without enlarging everything else in the same way. These are different tests. A button might work well under full-page zoom but lose its label when only the text grows. Conversely, a layout that handles larger text might still require awkward sideways scrolling at high browser zoom.
Set up a repeatable test
Start with a representative set of pages rather than testing only the home page. Include a long article, navigation menus, a form, and any page with cards, tables, or a complex header. Note the browser, operating system, window size, and starting zoom level so someone else can reproduce what you see. Reset zoom to its default before each test.
First use the browser’s zoom controls to increase the page in steps, checking it at 200% and, if practical, 400%. Keep the browser window at a typical desktop size rather than widening it to make the design fit. At higher zoom levels, the available space for the page effectively becomes narrower, so responsive layouts often switch to their compact form. Then reset zoom and try the browser’s text-only zoom or text-size setting, if available. Check at least one substantial increase rather than stopping when the difference is barely noticeable.
Browser settings vary, and some browsers do not provide a straightforward text-only option. Record what you were able to test instead of treating one method as a substitute for the other. Repeating the checks in another browser can also help distinguish a site problem from a browser-specific behavior.
Look for more than larger letters
At each setting, read the page and complete a simple task, such as opening the menu, finding an article, or submitting a test form without sending real personal information. Look for text that overlaps another element, disappears behind a fixed header, is cut off inside a button, or sits on top of a form field. Check that headings, labels, error messages, and link text remain visible and understandable.
Move through interactive elements with the keyboard as well as a pointer. When a menu, dialog, or dropdown opens, can you reach its contents and see where keyboard focus has moved? If a sticky banner takes up much of the enlarged view, does it block the content or the control needed to close it? Pages may need more vertical scrolling when enlarged; that is usually less troublesome than forcing readers to scroll sideways for each line of ordinary text.
Pay special attention to components with limited space: navigation bars, card grids, search boxes, and buttons with long labels. Content that needs a wide layout, such as a detailed table or diagram, may reasonably need its own horizontal scrolling area. The important question is whether the surrounding page remains readable and whether users can still reach and understand that content.
Use a small task to reveal layout problems
Imagine testing a community-events page. At default size, three event cards sit side by side, each with a title, description, and registration button. At 200% browser zoom, the cards stack vertically, which is fine. But the first button’s label is cut off because the button has a fixed height. With text-only enlargement, a longer event title overlaps the date beneath it. These are two distinct problems, even though both involve the same cards.
Continue the task rather than stopping at the first visual defect. Can you open an event, read its details, and find the registration form? Perhaps the form’s labels remain readable, but a required-field message appears outside the visible area of a narrow panel. Following a short journey helps show whether an issue is merely untidy or actually prevents someone from completing a task.
Record findings that a team can act on
For each issue, write down the page, browser, enlargement method and level, window size, and steps to reproduce it. Describe what should be visible and what happened instead. A screenshot can show overlap or clipping, while a brief note explains whether the affected control can still be used. Group repeated problems, such as labels clipped across many forms, so the team can look for a shared component rather than fixing each page separately.
After a change, repeat the original steps and check nearby layouts too. Removing a fixed height may solve a clipped button label, for example, but the taller button should still fit within its card. Zoom and text-resizing tests do not replace broader accessibility testing, yet they are a quick, practical way to find barriers to reading and completing everyday tasks.
