In one paragraph
Viewport width=device-width missing means the first source viewport declaration lacks the explicit phrase recognised by this check. That can reflect a fixed-width legacy layout, but some other settings produce a similar browser result without the phrase. Use an appropriate responsive configuration and test actual behaviour. Passing a substring check does not validate every viewport token, resolve duplicates, or prove the page fits its available space.
Why it matters
The viewport declaration gives the browser sizing and scaling information. width=device-width is an explicit way to align the intended layout with the device's CSS-width context, not a declaration of a fixed number of hardware pixels.
Fixed widths and scale settings interact. A width with initial scale can act as a minimum layout width in applicable browser behaviour, and a scale-only declaration can sometimes infer a similar layout to an explicit device width. Avoid promising that every fixed value produces one identical miniature page or that initial-scale always substitutes perfectly across clients.
Changing this declaration does not switch all responsive CSS on or off. It changes conditions within which layout and media queries operate. The underlying styles must still handle long content, media, orientation, and interaction.
How WebAuditOS evaluates this finding
The supplied source rule inspects the first viewport content for width=device-width with its documented case and spacing allowance. A match passes; an existing declaration without the recognised form warns at low severity. No viewport or unparseable content is not graded here.
It does not fully parse all conflicting values, validate duplication, test actual CSS breakpoints, or exercise zoom. A tag containing the accepted phrase can pass despite other problematic settings. The separate presence and zoom checks address other limited aspects.
How to fix it
- Inspect all emitted viewport metadata and the current browser layout. Identify whether a fixed width is intentional, copied legacy configuration, or the output of competing templates.
- For ordinary responsive content, an explicit common setup is:
<meta name="viewport" content="width=device-width, initial-scale=1">Review actual scaling needs rather than treating the example as a universal complete mobile policy. An initial scale can be omitted in suitable browser-supported layouts.
- Remove unintended fixed widths and conflicting duplicates at their source. Do not simply append the recognised phrase to a string containing contradictory declarations.
- Keep enlargement available. An accepted width setting does not justify adding user-scalable=no or an unnecessarily restrictive maximum scale.
- Inspect actual breakpoints, element sizes, overflow, images, and text wrapping. A legacy nonresponsive design can need CSS work in addition to metadata correction.
- Test different widths, orientations, zoom, virtual keyboards, and embedded application views where relevant. Distinguish layout viewport and visible viewport behaviour rather than assuming one screenshot covers every condition.
- If a scale-only or specialised configuration is intentional and works appropriately, document the detector limitation and evaluate whether an explicit conventional declaration improves clarity without changing required behaviour.
- Rescan width, presence, and zoom checks separately and retain functional mobile tests. The goal is a readable operable page, not merely a matching source token.
What the fix can break
A viewport change can reveal fixed-size components or alter initial scaling. Repair those assumptions with a controlled layout review.
Late script changes can cause reflow or inconsistent initial presentation. Prefer a deliberate initial configuration where possible.
Do not claim every warning means an unusable site or every pass means a complete responsive design. The rule's string test has a narrower purpose.
Questions
Is a scale-only declaration necessarily unusable?
No. Some browser behaviours can produce a similar layout, though the supplied detector requires an explicit width token.
Does device-width mean hardware pixels?
No. Interpret it in the browser's CSS viewport model, including scaling and density context.
Does a width pass guarantee zoom remains available?
No. Zoom restrictions are a separate setting and need their own review.
Which related checks help?
Review viewport presence, zoom, and the mobile usability guide.