Standard SW-1:2026.2 · Category 6 of 9

Mobile & Accessibility

Mobile-first indexing means the mobile rendering is the rendering. Accessibility overlaps heavily with it: semantic headings, contrast, labelled controls and alternative text serve assistive technology and machine readers with the same code. Faults here are recorded against WCAG 2.2 AA references where one exists.

Weight: 9 / 100
Checks: 4
Pass-blocking: 1
WOF analogue: Glazing & visibility

MB-01Critical failweight 3measured

Mobile and desktop render equivalent content

Does the mobile version contain the same content, links and markup?

Pass, advisory and fail criteria for MB-01
Pass	Mobile rendering contains the same main content, internal links, structured data and directives as desktop.
Advisory	Equivalent content but some secondary modules are collapsed or omitted on mobile.
Fail	Mobile omits main content, internal links or structured data present on desktop.

Why it matters

Indexing is mobile-first: the mobile rendering is the version assessed, so anything absent from mobile is effectively absent from the index. Content hidden behind accordions is fine — content not present in the mobile DOM at all is not. The most damaging pattern is a separate lightweight mobile template that drops structured data and internal links to save weight.

How we inspect it

We render each template at both viewports with the corresponding user agent and diff main content text, internal links, structured data and meta directives between the two.

Source: Dual render at mobile and desktop viewports with content and link diffing

Remedy

1Diff mobile and desktop DOM output for every template and list every omission.
2Restore missing content, links and structured data to the mobile rendering.
3Use responsive design rather than separate templates; where separate templates are unavoidable, enforce parity in tests.
4Collapsing content in an accordion is acceptable, but it must exist in the DOM.
5Verify with the mobile user agent, not by resizing a desktop browser window.

Verification

Recheck re-renders at both viewports and confirms content, link and markup parity.

Usually fixed by: Developer
Effort: Large · 1–3 days
Est. impact: high
Typical cost: NZ$600–2,400

MB-02Minor failweight 2measured

Viewport configured and controls are usable by touch

Is the page sized to the device with adequately spaced tap targets?

Pass, advisory and fail criteria for MB-02
Pass	Viewport meta present and scalable, no horizontal overflow, interactive targets at least 24 × 24 CSS px with adequate spacing.
Advisory	Minor overflow on a single component, or targets between 24 px and 44 px.
Fail	Viewport missing or zoom disabled, horizontal scrolling required, or targets under 24 px.

Why it matters

Disabling zoom with user-scalable=no is an accessibility failure that blocks users who need to magnify text, and it fails WCAG 1.4.4. Horizontal overflow on mobile makes content unreadable without pinching. Undersized tap targets produce mis-taps, which on a conversion path directly costs revenue.

How we inspect it

We check the viewport meta declaration, test for horizontal overflow at 390 px, and measure the size and spacing of every interactive element against WCAG 2.2 target-size guidance.

Source: Viewport meta inspection plus interactive element geometry at 390 px width

Remedy

1Set <meta name="viewport" content="width=device-width, initial-scale=1"> and never disable user scaling.
2Find overflow sources — usually fixed-width tables, images or unbroken strings — and constrain with max-width or overflow handling.
3Size interactive targets to at least 44 × 44 px on touch, with at least 8 px spacing between adjacent targets.
4Test on a real device at 390 px width, not just in a resized browser.

Verification

Recheck re-measures viewport behaviour and target geometry at mobile width.

Usually fixed by: Design
Effort: Medium · 2–8 hrs
Est. impact: medium
Typical cost: NZ$320–960

MB-03Minor failweight 2measured

WCAG 2.2 AA baseline met on key templates

Can the page be used with a screen reader and a keyboard?

Pass, advisory and fail criteria for MB-03
Pass	Zero critical or serious automated violations, complete keyboard traversal, visible focus indicators throughout.
Advisory	Only moderate violations, or focus indicators present but low contrast.
Fail	Any critical violation — missing form labels, keyboard traps, insufficient contrast on body text, or images conveying information without alternative text.

Why it matters

Accessibility is a legal obligation in most markets and a commercial one everywhere: an unlabelled checkout field excludes the customer entirely. It also overlaps substantially with machine readability, because the same semantic structure that lets a screen reader navigate lets a parser extract meaning. This standard scores the automated baseline only and says so plainly — passing it is a floor, not a certification of accessibility.

How we inspect it

We run the automated accessibility rule set across key templates and additionally traverse the page by keyboard to confirm focus order, focus visibility and absence of keyboard traps. Automated testing catches roughly a third of real issues and the report states this explicitly.

Source: Automated axe-core rule set against WCAG 2.2 AA, plus keyboard traversal

Remedy

1Add programmatic labels to every form control; placeholder text is not a label.
2Ensure text meets 4.5:1 contrast, and interface components and graphics meet 3:1.
3Provide meaningful alternative text for informative images and empty alt for decorative ones.
4Confirm every interactive element is reachable and operable by keyboard with a visible focus indicator.
5Follow up automated testing with manual screen reader testing on your primary conversion path.

Verification

Recheck re-runs the rule set and keyboard traversal and confirms zero critical or serious violations.

Usually fixed by: Developer
Effort: Large · 1–3 days
Est. impact: medium
Typical cost: NZ$600–2,400

MB-04Minor failweight 2measured

No intrusive interstitials on entry

Does a popup cover the content when someone arrives from search?

Pass, advisory and fail criteria for MB-04
Pass	No overlay occludes more than 20% of the mobile viewport within ten seconds of entry.
Advisory	A compliant consent banner or a small non-blocking prompt occupies a modest portion of the viewport.
Fail	A full-screen or majority-viewport overlay appears before the content can be read.

Why it matters

An interstitial that covers content immediately on arrival from search is explicitly discouraged by search engines and is one of the most reliable ways to increase bounce rate. Legally required consent notices are exempt from this check when sized reasonably. Email capture overlays on entry are not, and their measured conversion benefit rarely survives an honest look at the sessions they cost.

How we inspect it

We render at mobile viewport with a search referrer and measure the proportion of the viewport occluded by overlays within the first ten seconds, excluding legally required consent notices.

Source: Mobile render with referrer simulation and viewport occlusion measurement

Remedy

1Delay any promotional overlay until meaningful scroll depth or a second page view.
2Use inline or banner placements rather than modal overlays on mobile.
3Keep consent notices proportionate and dismissible without dark patterns.
4Ensure any overlay is dismissible by keyboard and traps focus correctly while open.

Verification

Recheck re-renders with a search referrer and re-measures viewport occlusion on entry.

Usually fixed by: Design
Effort: Small · 0.5–2 hrs
Est. impact: medium
Typical cost: NZ$120–400