Expo Go Accessibility Testing Limits in Managed Workflow

Context

Expo’s managed workflow restricts direct native code edits, meaning platform‑specific accessibility APIs are only available via config plugins or a pre‑build. Expo Go runs a fixed native shell, so custom accessibility behavior that depends on native changes cannot be reliably tested inside Expo Go. In contrast, a development build reflects the app’s native configuration more accurately.

Unresolved Decision

When building an app that relies on custom accessibility features, developers must decide whether to rely on Expo Go for quick iteration or to use a development build to validate screen‑reader focus, heading navigation, and dynamic type behavior. This decision also impacts how config plugins are used and how accessibility props are verified.

1. What specific accessibility props or native changes cannot be tested reliably in Expo Go but are available in a development build?
2. How can developers systematically verify that custom accessibility behavior introduced via a config plugin behaves the same in Expo Go and a production build?
3. Are there recommended patterns for documenting and testing accessibility in the managed workflow to avoid regressions when the native shell is updated?