React Native / Inclusive native systems and release evidence / Lesson 13
Arabic accessibility and direction
Preserve meaning through localized messages, logical layout, text scaling, and platform-specific assistive behavior.
On this page
Lesson goals
- Accessibility starts with the task
- Expose the actual state and action
- Direction is distinct from translation
Accessibility starts with the task
A control must communicate its action, current state, and result without relying only on icon shape, color, or animation. Use a suitable role and meaningful label, then inspect whether grouping duplicates or hides useful content. VoiceOver and TalkBack expose different platform behavior, so one property or source inspection cannot certify both experiences. The first example presents a checkbox-like favorite choice with explicit checked state. Its label should be localized in the application. Do not announce every render or keystroke; choose state transitions that help the user complete the task and recover after failure.
Expose the actual state and action
The first module receives a boolean and a change callback from its owner. Its role and checked state agree with the visible selected marker. It requests a new value instead of independently mutating saved data. Whether the preference is saved immediately or remains a cancellable draft belongs to the parent’s command contract. A custom visual design still needs adequate target size, contrast, focus visibility, and understandable disabled behavior. The described semantics are intended properties, not a transcript of tested speech. Native assistive interaction remains unexecuted in the course environment.
import {Pressable, Text} from 'react-native';
export default function FavoriteChoice({checked, onChange}) {
return <Pressable accessibilityRole="checkbox" accessibilityLabel="Favorite workshop"
accessibilityState={{checked}} onPress={() => onChange(!checked)}>
<Text>{checked ? 'Selected' : 'Not selected'}</Text>
</Pressable>;
}
The control exposes checkbox intent and the supplied checked state.
The parent owns checked and the update policy. Exact spoken wording, focus order, and target usability require platform checks.
Direction is distinct from translation
The second module uses logical start spacing and chooses a reading-progress arrow from the current RTL state. This is one semantic arrow policy, not permission to mirror every brand mark or media icon. Arabic text can contain Latin identifiers and numbers whose direction needs careful review. I18nManager settings such as forceRTL are development/configuration concerns with persisted restart behavior, not an instant language-switch button to call during rendering. A localized application also needs whole messages, plural forms, and number/date formatting. Concatenating translated word fragments around a count does not preserve Arabic grammar.
import {I18nManager, View, Text} from 'react-native';
export default function NextSection({label}) {
return <View style={{flexDirection: 'row', alignItems: 'center'}}>
<Text>{label}</Text>
<Text style={{marginStart: 8}}>{I18nManager.isRTL ? '←' : '→'}</Text>
</View>;
}
The example’s reading-progress arrow points left in RTL and right in LTR.
Logical spacing follows the reading direction. No RTL setting is changed and no application restart or native layout is executed.
Respect text growth and platform qualifiers
Large font scale can change line count, row height, and scroll requirements. Prefer adaptable composition over disabling scaling to preserve a mockup. Platform-specific properties need their qualifiers: accessibilityLanguage is documented for iOS, while accessibilityLiveRegion is documented for Android. Do not claim one prop creates identical announcements everywhere. Keep error text associated with its field, and move focus only for a clear task reason. For meaningful result changes, coordinate announcements with accepted request identity so an obsolete error cannot interrupt a newer success. Reduced-motion preferences also belong in animation policy rather than an unrelated visual toggle.
Verify complete localized recovery flows
Review English and Arabic, long translations, mixed identifiers, large text, keyboard-only interaction where supported, and the intended screen readers. Include disabled controls, validation failure, successful correction, and returning focus after a modal closes. Resource checks can find missing messages but cannot establish actual speech or usable focus. A configured component test can inspect declared roles, while target tests must verify platform behavior. No VoiceOver, TalkBack, device, JSX parser, or React renderer was run here. Keep these unverified boundaries explicit alongside the source-derived expectations.
Common errors and fixes
An icon communicates no spoken action
- Why it happens
- Visual recognition replaced a meaningful semantic label.
- How to fix it
- Use a suitable control role and localized action label.
- Prevent it next time
- Test the full screen-reader task, not only a property dump.
A language switch repeatedly calls forceRTL in render
- Why it happens
- Persisted configuration was mistaken for an immediate render calculation.
- How to fix it
- Handle direction through the reviewed application localization workflow.
- Prevent it next time
- Separate text resources, layout direction, and restart requirements.
One platform-specific prop is promised on every target
- Why it happens
- Documentation qualifiers were omitted.
- How to fix it
- Retain iOS/Android qualifiers and verify each intended behavior.
- Prevent it next time
- Keep target-specific accessibility cases in the test matrix.
Check your understanding
1. Why should every arrow not automatically mirror in Arabic?
Show worked solution
Direction follows meaning. A progress arrow tied to reading order may reverse, while a physical orientation, brand, or media convention may have another rule. Document each semantic category and test it with localized content rather than applying one transform globally.
2. Does a passing message-resource check establish TalkBack error recovery?
Show worked solution
No. It establishes that the tested message variants exist and format as expected. Error association, announcement timing, focus movement, and the user’s recovery path require component and actual target evidence. State those boundaries separately when reporting accessibility work.
Key takeaways
- Accessibility starts with the task
- Verify complete localized recovery flows