In one paragraph
User-scalable=no accessibility findings identify viewport settings that can restrict a visitor's ability to enlarge content. Remove unnecessary zoom restrictions and test the actual page at increased sizes, including controls and error messages. Browser overrides differ, so neither a restrictive tag nor a scanner pass alone proves the full user experience. Accessible resizing requires usable content and functionality after enlargement, not simply a permitted scale value.
Why it matters
WCAG 1.4.4 requires text to be resizable up to 200 percent without loss of content or functionality, subject to the criterion's scope and exceptions. Allowing browser zoom is a common approach, but the criterion assesses the result rather than one exact metadata string.
Some browsers override restrictive viewport settings; other environments may respect them. Avoid claiming every Android browser blocks zoom or every iOS browser behaves identically. Do not depend on a user's browser undoing a restriction the site need not impose.
Old boilerplate often added scale caps to conceal focus zoom or gesture issues. Those behaviours should be addressed with appropriate responsive layout, readable controls, and careful interaction design rather than broadly removing a user's magnification options.
How WebAuditOS evaluates this finding
The supplied source-markup rule reads the viewport meta value. user-scalable=no or a parsed maximum-scale below 2 fails; other inspected values pass. No viewport declaration is not graded by this rule. The source also associates the related axe viewport check with this page.
The threshold is a product check of author-supplied restrictions. maximum-scale=2 satisfies that comparison but does not prove usable 200-percent text enlargement. The rule does not exercise every browser, reflow breakpoint, fixed overlay, or interactive control after zoom.
How to fix it
- Inspect the final viewport declaration and any duplicate head output. Determine whether a theme, framework, mobile wrapper, or plugin adds a restriction after the initial template.
- For an ordinary responsive page, a practical starting point is:
<meta name="viewport" content="width=device-width, initial-scale=1">Remove unnecessary user-scalable and maximum-scale restrictions rather than increasing the cap only enough to pass. Validate changes against any specialised application requirements.
- Review CSS and scripts that interfere with gestures. A broad touch-action:none or a global gesture cancellation can create another barrier even when the metadata is permissive. Scope interactions carefully and preserve a way to enlarge useful content.
- If form focus produces unwanted zoom in a target browser, improve control typography and layout instead of disabling zoom globally. Larger readable control text can help in some environments; verify actual supported-browser behaviour rather than treating a fixed pixel value as universal.
- Test text and controls at 200 percent and relevant intermediate sizes. Check labels, error messages, navigation, dialogs, sticky headers, and content beneath fixed banners. Enlargement that hides a required action is not a successful result.
- Review reflow and horizontal scrolling separately against their applicable requirements. A viewport setting cannot certify either responsive usability or the distinct WCAG reflow criterion.
- Test actual supported phones and desktop browsers where practical, including in-app webviews if they are part of the service. Record whether browser settings override the page so an apparent success is not misinterpreted.
- Rescan the metadata and retain manual enlargement tests in the release process. Keep appropriate author controls only where justified, with their accessibility outcome actually evaluated.
What the fix can break
Removing a cap can expose fixed-size layout bugs previously hidden from testing. Fix clipped content, overlapping controls, and inaccessible dialogs instead of reinstating the cap.
Gesture-heavy interfaces need deliberate alternatives and focus behaviour. Do not assume every map, game, or canvas requires page-wide restrictions.
A missing viewport declaration can remain ungraded while the page is still difficult on mobile. Review the wider layout rather than treating ungraded as equivalent to a pass.
Questions
Does maximum-scale=2 prove WCAG compliance?
No. It passes the supplied numeric test; actual enlargement must preserve content and functionality.
Can I rely on a browser ignoring user-scalable=no?
No. Behaviour varies and users should not need an override to undo unnecessary restrictions.
Will removing the tag fix all mobile usability issues?
No. Typography, reflow, controls, and gesture handling still need testing.
Which related checks help?
Review form labels, image alternatives, and the mobile usability guide.