If customers cannot enlarge the text on your website, changing the font size on the homepage may only solve part of the problem. The browser might be prevented from zooming, a particular component might intercept the gesture, or the text might grow while its container cuts off the important details.
Start by reproducing the customer’s experience. Then repair the restriction or layout that causes it. For a business website, the useful outcome is that someone can read your offer, understand the price and complete an enquiry or purchase at a size that works for them.
First, identify what “zoom not working” means
Ask for the page address, device, browser and the action the customer tried. A short recording can be more useful than a screenshot because it shows whether the page refuses to enlarge or enlarges into an unusable layout. Keep customer details out of anything shared for diagnosis.
Separate these three reports:
- The whole page will not enlarge: investigate page-level zoom restrictions and browser behaviour.
- Zoom fails over one area: investigate that gallery, slider, map or other interactive component.
- Text enlarges but becomes unusable: investigate clipping, overlapping content and controls that move out of reach.
Repeat the test on an ordinary paragraph as well as the problem component. If possible, compare another browser on the same device. Record differences rather than assuming a successful test on your own phone disproves the report.
Also distinguish browser page zoom from a product photograph’s magnifier and the device’s screen magnification feature. They are different functions. A working product-image zoom does not demonstrate that the surrounding price, delivery information and purchase controls can be enlarged.
What should happen when text gets bigger?
The WCAG 2.2 Resize Text criterion calls for text, apart from captions and images of text, to be resizable up to 200% without losing content or functionality and without requiring assistive technology. Its explanation includes text labels and controls, and allows at least one supported text-scaling mechanism to meet the criterion.
That makes the check broader than “the heading looks bigger”. Can someone still read a field label, understand an error and activate the next step? Test intermediate enlargement levels too. A layout can break before the browser reaches 200%.
Use this as a focused investigation of resizing. Passing these checks alone does not establish that the whole website meets WCAG.
If mobile zoom is blocked, check the page and the component
Look for restrictive viewport settings
Ask your developer to inspect the viewport settings delivered by the affected page. Values such as user-scalable=no and maximum-scale=1 are warning signs. W3C’s viewport zoom testing rule checks for a prohibition on user scaling and a maximum scale below 2.
There is an important qualification: modern mobile browsers may ignore these restrictions or provide an accessibility override. Finding a restrictive value does not, by itself, explain every customer’s experience. Equally, a browser overriding it does not make the restriction a sensible design choice.
Have the developer remove unnecessary restrictions at their source, whether that is the theme, a template or an integration. Avoid adding a second competing viewport declaration as a quick patch. Then repeat the original device test.
Check components that take over touch gestures
A different investigation is needed when zoom works on the surrounding page but fails over a carousel or interactive panel. The W3C Pointer Events specification defines how touch-action controls browser panning and zooming. A value of none prevents those browser gestures from starting on the element. Relevant ancestor elements also affect which gestures are supported.
Ask the developer to inspect the affected component and its surrounding containers. A broad restriction intended for one draggable feature may have been applied over a much larger area.
The repair should preserve the component’s useful interaction while allowing appropriate browser gestures. For example, the specification’s manipulation value permits panning and continuous zooming, including pinch zoom, while restricting certain other gestures. It is a possible implementation choice to evaluate, rather than a universal replacement for every component’s settings.
If text grows but disappears, repair its container
A button can become taller when its label wraps. A service card can need another line. An error message can need more room than the empty space originally reserved for it.
W3C’s guidance on resizing text within containers explains how content can be lost when enlarged text outgrows its allocated space, and shows layouts that let text wrap and containers grow.
Use the actual failing component to brief the repair. Ask the developer to check fixed heights, forced single-line labels and overflow rules that hide content. Changing a font unit alone is not proof that the layout now works.
For example, suppose the second line of an enquiry form’s error message disappears at a larger text size. The acceptance check should be that the complete message remains available and the field can still be corrected. Simply making the message smaller would undermine the customer’s reason for enlarging it.
Give sticky headers and bottom bars room to move
A persistent navigation bar, cookie panel or booking button can occupy much of a smaller viewing area. Check them together, including with a phone turned sideways.
W3C’s sticky header and footer technique describes using available viewport width and height to stop regions remaining fixed when space is limited. This is an example approach, rather than a requirement to use that exact implementation.
Ask whether a persistent element should become part of the normal scrolling page at the affected size. Keep its function available. The customer still needs navigation and booking controls, but also enough space to read and act on the content between them.
Check reflow separately from pinch zoom
Being able to enlarge content is one check; fitting the resulting layout into a narrow viewing area is another. Under WCAG 2.2 Reflow guidance, ordinary vertically scrolling content should work at a width equivalent to 320 CSS pixels without losing information or functionality or requiring scrolling in both directions.
A desktop content viewport initially 1280 CSS pixels wide at 400% browser zoom is the standard example of that equivalent width. Use the browser’s content area, rather than the monitor’s advertised resolution, when setting up the check.
There are exceptions for content that needs a two-dimensional layout, such as a map or data table. The exception belongs to that content; it does not automatically cover the surrounding heading, search field or navigation.
Do not treat horizontal panning during mobile pinch zoom alone as proof of a reflow failure. Ask the developer to document the equivalent viewport width used for the separate layout test.
Verify the repair through a complete customer task
W3C’s browser zoom testing technique checks that content and functionality remain available at 200% and stresses testing across browsers. Turn that into a business task rather than a tour of attractive pages:
- Open a commercially important landing page and enlarge it using the browser’s available controls.
- Read the offer and any qualifying details, then open the relevant service or product page.
- Use the menu, product options or booking controls needed to continue.
- Complete a controlled test enquiry, or follow your shop’s agreed test checkout process. Trigger a validation error as well as the successful route.
- Check that confirmation information remains accessible at the enlarged size. Verify the test enquiry reaches its intended destination.
Repeat the original failing device and browser combination, then a second relevant combination. Keep a short record of the page, enlargement method, size, previous failure and observed result. A desktop browser’s mobile preview can help investigate a layout, but include an actual touch device when the reported problem involves gestures.
Prioritise barriers that prevent someone reading an offer or completing the task, then address the remaining inconsistencies across shared components. Include those components in future release checks so that a repaired enquiry form is not broken again by a template change.
If this reveals wider usability problems, our web design service can help bring the page layout and customer journey together. Contact BuzzBoost with the affected page and what happens when you enlarge it, and we can help identify the next practical step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
