Mobile accessibility evaluation requires real hardware. Emulators and browser device modes cannot reproduce how iOS VoiceOver, Android TalkBack, touch targets, gestures, and system-level focus actually behave on a physical phone or tablet. Before hiring an auditor, ask direct questions about their device inventory, request evidence in the form of screenshots or screen recordings, and confirm they evaluate with the actual screen reader paired with the actual operating system. If the answers are vague or the evidence shows desktop browser DevTools instead of a real device, the audit will miss issues that only surface on hardware.
| Verification Step | What to Look For |
|---|---|
| Ask about device inventory | Specific iPhone and Android models with OS versions, not generic claims |
| Request screen recordings | Real device footage showing VoiceOver or TalkBack in action |
| Review a sample report | Issues described with device-specific behavior, not desktop simulation |
| Confirm screen reader pairings | VoiceOver on iOS, TalkBack on Android, used on the actual hardware |
| Watch for red flags | Chrome DevTools device mode, BrowserStack only, or no mobile evidence at all |
Why emulators are not enough for mobile accessibility
An emulator can render a layout at a phone’s pixel dimensions. It cannot replicate the assistive technology stack. VoiceOver on a real iPhone uses gestures, rotor controls, and system focus behavior that browser DevTools do not produce. TalkBack on Android responds to swipe patterns and reading order that only function correctly on a physical Android device.
Touch target evaluation also breaks down in emulation. A 44 by 44 pixel target may pass a measurement check on desktop while still being awkward to tap on a real device with a real thumb. The auditor needs the device in hand.
What questions should you ask the auditor?
Direct questions surface the truth quickly. Vague answers are the signal.
Which specific iPhone models and iOS versions do you use for VoiceOver evaluation? Which Android models and OS versions do you use for TalkBack? Can you share a short screen recording from a recent mobile audit? Do you evaluate with the screen reader on the device itself or through a desktop simulation tool? How do you document touch target and gesture issues?
An auditor doing the work will answer with specifics: an iPhone 14 on iOS 17, a Pixel 7 on Android 14, screen recordings captured through QuickTime or the device’s built-in recorder. An auditor relying on emulation will pivot to talking about responsive design checks or browser tools.
Evidence to request before signing
Sample reports tell the story. Ask for a redacted mobile audit deliverable from a previous client. Look at how issues are described.
Real device evaluation produces issue descriptions that reference actual behavior: “On iPhone 14 with VoiceOver, the modal close button is not announced when focus moves into the dialog.” Emulator-based work produces generic descriptions: “Modal may not be accessible to screen reader users.”
Screen recordings are the strongest evidence. A 30 second clip of VoiceOver navigating a form on a real iPhone, with the device’s status bar visible, confirms the work happened on hardware.
Red flags during the sales conversation
Watch for these patterns when vetting an auditor:
References to “mobile evaluation” through Chrome DevTools device emulation only. Reliance on BrowserStack or similar cloud device farms without confirming screen reader access. No mobile screenshots or recordings in sample reports. Issue descriptions that read identically for desktop and mobile. Pricing that seems too low for the scope of mobile work claimed.
Cloud device farms have a place for visual rendering checks, but most do not give the auditor full access to native screen readers in the way real hardware does. If an auditor’s mobile process depends entirely on a cloud service, ask how they evaluate VoiceOver and TalkBack within that environment.
How real device work shows up in the deliverable
A mobile accessibility audit grounded in hardware produces issues mapped to specific device and OS combinations, screen reader output documented as it was actually announced, touch target measurements paired with usability notes from physical interaction, gesture conflicts identified where custom controls override system gestures, and reading order issues confirmed through swipe navigation rather than assumed from DOM order.
This level of detail is the difference between a report that informs remediation and a report that creates rework when developers cannot reproduce the issues.
Frequently asked questions
Should I hire an auditor who only uses emulators for mobile work?
No. Mobile accessibility issues that affect real users surface on real devices. An auditor without an iPhone and an Android device in their evaluation setup is delivering an incomplete picture, and the issues missed are often the ones that drive complaints and legal risk.
Are cloud device farms acceptable substitutes for owned hardware?
Cloud device services can supplement an auditor’s process for visual checks across many devices, but they rarely give full access to VoiceOver and TalkBack in the way owned hardware does. The strongest auditors own the primary devices they evaluate on and use cloud services only for edge cases.
How many devices does a thorough mobile auditor need?
At minimum: one current iPhone with VoiceOver and one current Android phone with TalkBack. A more complete setup includes an older iOS version, an older Android version, and a tablet from each platform when the product targets tablet users.
What if my product is web only and not a native app?
Mobile web still requires real device evaluation. Mobile Safari with VoiceOver behaves differently than desktop Safari, and mobile Chrome with TalkBack behaves differently than desktop Chrome. Responsive design checks in DevTools do not capture screen reader behavior on the device.
Can I ask for a live demo of mobile evaluation before hiring?
Yes, and you should. A short screen share where the auditor walks through VoiceOver or TalkBack on a real device, evaluating one of your pages or screens, removes all doubt. Auditors who do this work daily will accommodate the request without hesitation.
Hardware in hand is not a luxury for mobile accessibility work. It is the baseline. Verify it before you sign.
Find vetted accessibility auditors with real device capability. Contact the Accessibility Base directory to connect with professionals.