UX Encyclopedia

Accessibility Across Platforms and Devices

WCAG is web-born, but the needs it encodes are platform-independent. This file maps the practice onto each platform's APIs, screen readers, and settings. WCAG itself: WCAG Essentials; who: Inclusive Design.

Try it — look at the same UI the way a screen reader does. Four elements render either from semantic HTML or from styled divs. Switch the markup and watch the tree: native elements expose name, role and state for free; div soup exposes almost nothing. Click an element or a tree row to match them up.
Markup
Pricing

Billing

Simplified illustration of the accessibility tree — rows are hand-authored to mirror what VoiceOver or NVDA would report, not a live inspector. Format: name · role · state

Semantic markup: every element arrives in the tree with a name and a real role — the browser did the work.

The common core (transfers everywhere)

  • Semantics — name, role, value: every platform has an accessibility tree (DOM+ARIA, UIAccessibility, Android nodes, NSAccessibility, UI Automation). Native controls populate it for free; custom controls must expose name, role, value/state, and actions — or they simply don't exist for assistive tech.
  • Focus: visible indicator, sensible order, no traps, everything reachable without a pointer — keyboard, TV D-pad, and switch scanning all consume the same focus model.
  • Contrast (4.5:1 text / 3:1 UI) and never color alone.
  • Target size: 24 px WCAG floor; 44 pt / 48 dp in practice — on touch, TV pointers, and hand-tracked XR alike.
  • Captions/transcripts for all media; text scaling without clipping; reduced motion respected (an OS setting on every major platform, not just a CSS media query).

Web

  • WCAG applies directly — the full treatment is in WCAG Essentials (checklist, testing workflow, ARIA/APG, legal landscape).

Desktop applications

  • W3C's WCAG2ICT (Group Note, updated October 2024) is the official bridge: it interprets WCAG 2.0/2.1/2.2 criteria for non-web software and documents. Informative, not normative — but EN 301 549 and Section 508 lean on it, so it is the de facto rulebook for desktop apps.
  • macOS: the Accessibility API via NSAccessibility; standard AppKit/SwiftUI controls are exposed automatically, custom views need explicit roles/labels/actions. Test with VoiceOver and Full Keyboard Access.
  • Windows: UI Automation (UIA, successor to MSAA) is the API. Narrator ships in-box, but NVDA and JAWS dominate real usage — test with at least NVDA. Support Windows contrast themes (renamed high-contrast): respect system colors — forced-colors on web stacks.
  • Keyboard completeness is the desktop baseline: every command reachable by keyboard, honest tab order (see Desktop Software & Professional Tools). Respect OS text-size and display-scaling settings; never rasterize text.
  • Cross-platform frameworks (Electron, Flutter, Qt) don't guarantee accessibility-API integration — verify with a real screen reader on each OS; this is the most common gap in ported apps.

Mobile

  • W3C's mobile mapping, WCAG2Mobile ("Applying WCAG 2.2 to Mobile Applications"), is a Draft Note (first published May 2025, still in draft as of mid-2026, Group Note intended) covering native, hybrid, and mobile-web apps — the mobile sibling of WCAG2ICT.
  • iOS: VoiceOver; Dynamic Type (support the accessibility sizes, not just the default range); Switch Control; Voice Control (users speak visible labels — keep label-in-name); AssistiveTouch. Audits: Accessibility Inspector, plus performAccessibilityAudit() in UI tests (Xcode 15+ / iOS 17+).
  • Android: TalkBack; independent font scale and display size settings (use sp, test at maximum); Switch Access; Voice Access. Audits: Accessibility Scanner (labels, target size, contrast) and the Accessibility Test Framework in instrumented tests.
  • Gesture conflicts: with a screen reader on, touch is remapped — swipes move focus, double-tap activates. Every custom gesture (swipe-to-delete, drag, pinch) needs an alternative exposed as an accessibility action (WCAG 2.5.1/2.5.7 demand one anyway). Platform norms: Mobile App Design.

TV / 10-foot

  • Focus-based D-pad navigation is both constraint and gift: the whole UI is already a focus graph, so switch and screen-reader access ride on the same rails — get focus order and visibility right and most of the work is done. Never orphan or trap focus.
  • Screen readers: VoiceOver (tvOS), TalkBack (Google TV), VoiceView (Fire TV). US law (CVAA + FCC rules) requires captions with user-customizable rendering — honor the system caption style. Details and sources: TV & 10-Foot Interface Design.

Watches & wearables

  • VoiceOver (watchOS) and TalkBack (Wear OS) work on watches; watchOS AssistiveTouch enables one-/no-handed use via hand gestures — platform specifics in Wearables & Smartwatch Design.
  • Haptics as redundancy, not sole channel — pair every haptic cue with a visual (and vice versa): users may lack sensation, wear the device loosely, or have haptics off. Treat one-handed and no-hand (voice/gesture) operation as first-class paths.

VR / AR / XR

  • Reference documents: W3C's XAUR (XR Accessibility User Requirements — Working Group Note, 2021; informative, cataloguing ~19 user needs across navigation, interaction, customization, multimodal I/O) and the XR Association's Developers Guide accessibility chapter. No normative XR standard exists yet.
  • visionOS ships VoiceOver, Zoom (magnifies the camera view of the real world too), Dwell Control (hands-free selection), Pointer Control (head/wrist/finger pointing instead of eye tracking), Switch Control, Voice Control, and system captions — support system input rather than bypassing it.
  • Meta Quest (per Meta's current help/dev docs): system-level live captions, mono audio, color correction, display contrast, adjustable font size, Adjust Height (virtual height offset — also serves seated play), thumbstick calibration, voice commands, a system screen reader; plus Accessibility VRCs (Virtual Reality Checks) — store-level app requirements/recommendations.
  • Locomotion comfort options are accessibility features: teleport, snap turn, vignette, seated/standing modes, one-handed/remappable controls serve vestibular and motor disabilities, not just preference (mechanics in Virtual Reality Design — don't rebuild, expose as settings).
  • Photosensitivity is amplified in headsets: flashing fills the whole visual field with no way to look away — treat WCAG's three-flashes rule as a hard floor; add warnings and effect-reduction.
  • Subtitles in 3D (convention, not standard): head-anchored or smoothly following at ~1–2 m depth, speaker/direction indicators, adjustable size/placement — never locked to a speaker the user may face away from.

Voice interfaces

  • Accessibility for voice: speech recognition fails disproportionately for dysarthria, stuttering, deaf and non-standard accents (Google's Project Euphonia/Relate exists for this gap) — and some users are non-verbal. Every voice interface needs a non-voice path: touch/keyboard input, transcripts, a GUI fallback.
  • Deaf and hard-of-hearing users need visual output: a voice-only smart speaker excludes them by construction; smart displays and companion apps mitigate. Show what was heard and done as text.
  • Voice as assistive tech: for motor and vision disabilities voice is often the primary channel (Voice Control, Voice Access, smart-home assistants) — which raises the reliability bar; see Voice & Conversational Interfaces.

Cross-cutting practice

  • One accessibility bar per product: feature parity across web, desktop, and mobile clients — a flow accessible on web but broken in the iOS app is a broken flow.
  • Testing matrix by platform: NVDA (+ JAWS if budget) on Windows, VoiceOver + Safari on macOS/iOS, TalkBack on Android, VoiceOver on tvOS/watchOS — pair each screen reader with its home platform.
  • Respect OS settings everywhere: text size, bold text, reduce motion, contrast, caption style. Don't invent per-app toggles for things the OS provides — an in-app "large text mode" that ignores Dynamic Type is a bug. Sync genuine app-level prefs across devices.
  • Automated audits (axe, Accessibility Scanner, Xcode audits) catch only a fraction on every platform — the manual screen-reader and keyboard/focus passes from WCAG Essentials apply everywhere.

Sources

↑↓ to navigate · Enter to open · Esc to close