Accessibility on iOS and Android

A screen that looks complete and passes every visual review can still be genuinely unusable for a screen-reader user — a custom-built swipeable card from an earlier lesson that has no way to be activated without a drag gesture, an icon-only button with no label a screen reader can announce, or a live score update that changes on screen with nothing telling a screen-reader user it changed at all. Accessibility is not a visual styling concern layered on top of a finished screen; it is a second, parallel interface — the accessibility tree — that a screen reader navigates instead of the visual layout, and a component with no accessibility properties set is, to that interface, either invisible or meaningless, regardless of how polished it looks visually.

iOS's VoiceOver and Android's TalkBack are both screen readers, but they are genuinely different products with different navigation gestures, different verbosity conventions, and some real differences in which React Native accessibility props they respect and how. Treating them as one interchangeable "accessibility mode" tested once on whichever platform is more convenient produces exactly the platform-specific accessibility gaps this lesson exists to prevent — the same category of silent, untested divergence the platform-differences lesson covered for shadows and back navigation, applied here to the accessibility tree specifically.

This is an exercise lesson: every code block below is something to actually turn on VoiceOver or TalkBack and test, not just read. Build the pieces in order — correct roles and labels on custom components, a live region announcing a dynamic update, and a focus-management fix for a modal — and by the end you should be able to reason about what a screen reader actually announces for a given component, not just what it visually renders.

Analogy🏏Cricket

🏏 Think of it like cricket: A radio commentary team covering a match for listeners who cannot see the ground is not simply describing the same broadcast a television viewer gets, quieter — radio commentary is an entirely separate, deliberately constructed interface to the same underlying match, built specifically for an audience that has no visual channel at all, and a commentator who assumes the television graphics are somehow implicitly available to a radio listener leaves that listener with genuine gaps a sighted viewer never experiences. A commentator has to explicitly narrate the field placement, the exact delivery, the batsman's reaction, everything a television viewer absorbs visually in an instant, because none of it exists for the radio audience unless it is deliberately, explicitly said. Just as radio commentary is a separate, deliberately constructed interface built specifically for listeners with no visual channel, the accessibility tree is a separate, deliberately constructed interface built specifically for users navigating with a screen reader instead of sight. Just as a commentator who assumes visual information is implicitly available leaves radio listeners with real gaps, a developer who assumes visual layout is implicitly meaningful to a screen reader leaves screen-reader users with real, functional gaps. The insight is that a second interface serving a different sense has to be built deliberately and explicitly, not assumed to inherit meaning automatically from a channel that audience cannot actually perceive.