Accessibility and Inclusive Design Questions

Direct answer. Mobile accessibility has its own concerns beyond the desktop-web checklist: platform screen readers (VoiceOver on iOS, TalkBack on Android) use swipe gestures rather than Tab/arrow keys to navigate, users can scale system font size (Dynamic Type on iOS, font scale on Android) which your layout must reflow to accommodate, touch targets need real physical size rather than mouse-pointer precision, and orientation/zoom behavior needs explicit support rather than being an edge case.

Concrete considerations.

• VoiceOver/TalkBack gestures: swipe right/left moves to the next/previous accessible element; a double-tap activates the focused element. Custom gesture-based interactions (a swipe-to-delete list item) need an accessible equivalent action exposed as a standard activation, since a screen reader user's swipe gesture is already consumed by VoiceOver/TalkBack navigation, not passed through to your custom gesture handler.
• Dynamic Type/font scaling: text set in fixed pixel sizes doesn't respond to a user's system-level text-size preference; using relative units (rem/em on web, or the platform's scalable text APIs in native code) lets a user who has set 200% system text size actually get a legible layout instead of clipped or overlapping text.
• Touch target sizing: the same 44x44pt/48x48dp minimum applies, with extra headroom warranted for users with tremor or limited dexterity.
• Orientation and zoom: locking an app to portrait-only, or disabling pinch-to-zoom, actively harms low-vision users who rely on zoom or a specific orientation for readability; WCAG 1.3.4 (Orientation) and 1.4.10 (Reflow) both address this directly.
• Platform-specific behaviors: iOS's rotor lets a VoiceOver user jump by headings, links, or form controls similarly to a screen reader's landmark navigation on web; Android's TalkBack has an equivalent reading-controls menu. Both require the same underlying semantic structure (headings, landmarks) that web accessibility already asks for.

Trade-offs and pitfalls. A cross-platform app built with a single shared UI layer sometimes ships accessibility metadata that works well on one platform's screen reader and poorly on the other, because iOS and Android map similar concepts (grouping, custom actions) to their accessibility APIs slightly differently; testing on both real screen readers, not just one, is the only reliable way to catch this.