A website behaves differently on a phone than it does on a laptop, and the assistive technology people use on each device behaves differently too. An accessibility audit that only looks at one environment misses issues that exist in the other. For most websites and web apps, the correct scope covers both mobile and desktop so the audit reflects how real users actually interact with the product.
The reason is practical. Touch targets, viewport behavior, mobile screen reader gestures, focus order on smaller layouts, and responsive components all introduce issues that desktop evaluation will not identify. Skipping mobile means shipping a report that looks complete but leaves a large portion of the user experience unverified.
| Factor | What it means for audit scope |
|---|---|
| Assistive tech | Desktop uses NVDA, JAWS, VoiceOver on macOS. Mobile uses VoiceOver on iOS and TalkBack on Android. Behaviors differ. |
| Layout | Responsive breakpoints change navigation, focus order, and component visibility. |
| Input method | Touch, keyboard, voice, and switch control each surface different issues. |
| WCAG criteria | Several success criteria, including target size and orientation, only apply meaningfully in a mobile context. |
| Conformance claim | A claim that does not specify environment is incomplete and can mislead procurement teams. |
What changes between mobile and desktop
The same page can pass a desktop evaluation and still produce issues on a phone. Hamburger menus replace top navigation. Modal dialogs reflow. Focus indicators that read clearly on a 1440px viewport can disappear inside a sticky header on a 375px viewport.
Screen reader behavior is the larger consideration. NVDA on Windows and VoiceOver on iOS interpret the same markup differently. A control labeled correctly for NVDA may announce poorly with TalkBack. The only way to know is to evaluate in both environments.
Which WCAG criteria depend on environment
A handful of WCAG 2.1 AA and WCAG 2.2 AA criteria are environment-sensitive. Target Size, Orientation, Reflow, and Pointer Gestures all surface differently on mobile. Focus Visible and Focus Not Obscured map differently when a soft keyboard pushes content up the screen.
A desktop-only audit can technically evaluate these criteria, but the auditor is not seeing how they behave for the people most affected. The report ends up reflecting an environment, not the product.
How does scope affect the audit report?
Scope drives every line of the report. If the audit covers desktop only, the conformance claim has to say so. If it covers both, the report will note which issues are environment-specific so the development team knows where to apply the fix.
This matters for procurement. A buyer reviewing an ACR or audit report wants to know the product was evaluated in the environments their users will actually use. A mobile-first SaaS product evaluated only on desktop creates a credibility problem the moment a buyer asks the obvious question.
When a single environment is acceptable
Some products genuinely live in one environment. An internal HR tool used only on company laptops can be scoped to desktop. A mobile app with no web counterpart is scoped to its native platform. The rule is to match scope to actual use, not to assume one environment stands in for the other.
For most public websites and ecommerce stores, both environments belong in scope. Traffic data alone usually settles the question, since mobile sessions often exceed desktop sessions on consumer sites.
What an audit covering both looks like
An auditor evaluating both environments works through the same page set twice, once on desktop with a desktop screen reader and once on mobile with a mobile screen reader. Findings are documented per environment when behavior differs. A single issue that appears in both is noted once with context.
The deliverable is a report that lets a developer reproduce each issue in the environment where it was identified. Without that, fixes get applied to the wrong layer and the issue persists.
Do mobile apps need separate audits from the website?
Yes. A native iOS or Android app is a distinct product with its own codebase, accessibility APIs, and platform conventions. It needs its own audit. A responsive website viewed on a phone is not the same as a native app and should not be treated that way in scope discussions.
Can a scan check mobile accessibility?
Automated scans flag approximately 25% of issues and operate primarily on rendered HTML. They do not interact with mobile screen readers, gesture inputs, or platform-level assistive technology. Scans can support a manual accessibility audit, but they cannot stand in for one in either environment.
How is scope priced when both environments are included?
Audit pricing generally reflects the number of unique templates or screens evaluated, with an adjustment when both environments are in scope. The increase is not double, since a meaningful portion of the work carries between environments, but it does reflect the additional evaluation time required.
An audit scoped to both mobile and desktop produces a report that holds up to procurement review, supports an accurate conformance claim, and gives the development team a clear path to remediation. Anything narrower should be a deliberate choice, not a default.
Contact Kris to discuss audit scope for your website or app: Contact Kris.