Accessibility
The Nevis Access App is designed to be usable by people who rely on assistive technologies such as screen readers (TalkBack on Android, VoiceOver on iOS) and external keyboards. The app is designed to meet WCAG 2.1 Level A and AA requirements as well as the EN 301 549 standard.
Overview
Keyboard and navigation
All interactive elements are reachable and operable using an external keyboard. A visible focus indicator shows which element is currently active (WCAG 2.1.1, 2.4.7). Interactive elements use touch target sizes that meet the platform minimums - 48 dp on Android and 44 pt on iOS.
For users who cannot operate the camera, the Fetch channel and the Link channel provide alternatives to QR code scanning on both platforms. The Fetch channel is the preferred option as it requires no scanning or manual input. The app needs to support fetching pending operations which is part of the configurable app features during app ordering.
Screen reader support
All interactive elements have the correct accessibility roles, names, and states so TalkBack (Android) and VoiceOver (iOS) announce them accurately (WCAG 4.1.2). Non-text content such as icons has meaningful text alternatives (WCAG 1.1.1). Screen titles are structured as headings to support screen reader navigation (WCAG 1.3.1). Status and error messages are automatically announced by screen readers (WCAG 4.1.3).
On iOS, the app language is programmatically defined so VoiceOver switches to the correct voice automatically (WCAG 3.1.1).
The built-in OS screen readers (TalkBack on Android, VoiceOver on iOS) and other platform accessibility services work without any additional configuration.
Some third-party assistive applications - such as external screen magnifiers or overlay-based input tools - may be blocked by Tapjacking protection in the app. If your users rely on such tools, enable the Assistive Applications Compatibility option when ordering your application. See Assistive Applications Compatibility for details.
Forms and instructions
Form fields have accessible names and labels that persist while the user types (WCAG 1.3.1, 4.1.2). Integrators can provide additional instructional text for the PIN enrollment, PIN change, and number matching screens through optional localization keys (WCAG 3.3.2). For details, see Localization keys.
Internationalization
The app layout mirrors correctly for right-to-left (RTL) languages such as Arabic, Hebrew, and Persian. For more information, see Right to Left Languages.
Localization keys
Several accessibility features are configurable through optional localization keys. All keys are empty by default. When a key has no value, the corresponding label is not shown. When a value is set, the label appears on the relevant screen.
For information on how to provide values for these keys, see Localizations.
pin_enrollment_screen_instructions
Platform: Android, iOS
When set, this text is shown on the PIN enrollment screen above the PIN input, before the user submits the form. Use it to describe the PIN format requirements - for example, the minimum number of different digits or restrictions on consecutive digits.
pin_enrollment_screen_instructions,"The PIN must contain at least 4 different digits and must not contain more than 3 consecutive digits.",...
pin_change_screen_instructions
Platform: Android, iOS
When set, this text is shown on the PIN change screen above the PIN input, before the user submits the form. Use it to describe the same PIN format requirements as pin_enrollment_screen_instructions.
pin_change_screen_instructions,"The PIN must contain at least 4 different digits and must not contain more than 3 consecutive digits.",...
number_matching_screen_instructions
Platform: Android, iOS
When set, this text is shown on the number matching screen. Use it to explain to the user where the number is displayed and what they must do - for example, by referencing the browser or the web application where the out-of-band operation was started.
For more information on number matching, see Number Matching.
number_matching_screen_instructions,"Enter the number shown on the login screen in your browser.",...
go_back_to_home_screen_android
Platform: Android only
The default value is Go back to Home Screen. This text is used as the alternative text for the back navigation icon on screens that navigate back to the home screen. It replaces the Android system default (Navigate up), which is less descriptive for TalkBack users.
Provide a translation for each language your app supports.
go_back_to_settings_screen_android
Platform: Android only
The default value is Go back to Settings Screen. This text is used as the alternative text for the back navigation icon on screens that navigate back to the settings screen.
Provide a translation for each language your app supports.
pin_enrollment_screen_new_pin_label_ios
Platform: iOS only
When set, this text appears as a visible label above the New PIN input field on the PIN enrollment screen. Unlike the placeholder, this label remains visible after the user starts entering a PIN, giving VoiceOver users a persistent field description.
pin_enrollment_screen_new_pin_label_ios,"New PIN",...
pin_enrollment_screen_confirmation_pin_label_ios
Platform: iOS only
When set, this text appears as a visible label above the Confirm PIN input field on the PIN enrollment screen.
pin_enrollment_screen_confirmation_pin_label_ios,"Confirm PIN",...
pin_change_screen_new_pin_label_ios
Platform: iOS only
When set, this text appears as a visible label above the New PIN input field on the PIN change screen.
pin_change_screen_new_pin_label_ios,"New PIN",...
pin_change_screen_confirm_new_pin_label_ios
Platform: iOS only
When set, this text appears as a visible label above the Confirm New PIN input field on the PIN change screen.
pin_change_screen_confirm_new_pin_label_ios,"Confirm new PIN",...
App Store Accessibility Nutrition Labels (iOS)
The App Store Accessibility Nutrition Labels allow iOS app publishers to declare which accessibility features their app supports. The labels appear on the app's App Store product page and help users decide whether they can complete common tasks using assistive technologies such as VoiceOver or Larger Text before they download the app.
This section describes which labels apply to the Access App and which preconditions must be met for each. Because customers can customize the Access App with their own brand colors and fonts, not all labels automatically apply to every customized version of the app.
Accessibility Nutrition Labels are an App Store Connect feature and apply to iOS apps only.
Supported labels
The following table shows which labels the base Access App supports.
| Label | Base app | Notes |
|---|---|---|
| VoiceOver | Supported | All common tasks are operable with VoiceOver. |
| Voice Control | Supported | All interactive elements have accessible labels, which Voice Control relies on. |
| Larger Text | Supported | Text and touch targets scale with the iOS Dynamic Type system setting. |
| Reduced Motion | Supported | All screen transitions are fades. The loading spinner respects the Reduce Motion system setting. |
| Differentiate Without Color Alone | Supported | All state icons (error, success, warning) use a distinct shape in addition to color. |
| Dark Interface | Not supported by base app | The base app has no built-in dark color scheme. Dark mode support depends entirely on whether your customization includes dark-mode color variants. |
| Sufficient Contrast | Verify | Depends on whether your custom brand colors meet the minimum WCAG contrast ratios. |
| Captions | Not applicable | The app contains no video or audio-only content. |
| Audio Descriptions | Not applicable | The app contains no video content. |
Preconditions for customized apps
The following labels apply to all customized apps without additional steps required, with the noted exceptions:
| Label | Exception | |
|---|---|---|
| VoiceOver | ✅ | Only fails if you remove or override accessibility labels in your custom localizations. |
| Voice Control | ✅ | Follows from VoiceOver support. Same exception applies. |
| Larger Text | ✅ | Only fails if you substitute fixed-size custom fonts that do not respond to Dynamic Type. |
| Reduced Motion | ✅ | No action required. The Access App customization process does not include adding custom animations. |
| Differentiate Without Color Alone | ✅ | Only fails if your custom state icons (error, success, warning) use color as the sole differentiator, without any accompanying shape or symbol. |
For the following label, additional steps are required before you can indicate support:
Sufficient Contrast
To indicate support, ensure that your custom brand colors meet the WCAG AA minimum contrast ratios: 4.5:1 between body text and its background, and 3:1 for large text and non-text elements such as icons and borders.
Use Xcode's Accessibility Inspector or a color contrast checker to audit your brand colors before indicating support. Pay particular attention to:
- Secondary and tertiary text colors on their backgrounds (hint text, descriptive labels, placeholders)
- Button text on the primary button background color
- State indicator icons (error, warning, success) on white or near-white backgrounds
If any of these pairs fall below the minimum ratios, you cannot indicate support for this label.
Dark Interface
The base app has no built-in dark color scheme - it uses only the light-mode colors provided in your customization. There is no automatic adaptation to the system dark mode setting.
You can indicate support for this label only if your Access App customization includes dark-mode color variants for all brand colors. When dark-mode variants are configured, the app respects the system dark mode setting and switches to those colors. If only light-mode colors are provided, dark mode is not supported and this label cannot be indicated.
Google Play - Android Accessibility
Unlike the iOS App Store, Google Play does not offer structured accessibility declarations ("Nutrition Labels") on the store listing. Google Play has no Play Console form to declare specific assistive technology support, and no accessibility-specific badges or labels appear on an app product page.
This section describes Android accessibility capabilities of the Access App so that customers and end users understand which assistive technologies are supported.
Accessibility support declarations are an app description / documentation feature only on Android - there is no Google Play equivalent to the iOS App Store Accessibility Nutrition Labels.
Supported accessibility features
The following table shows which Android accessibility services the Access App supports.
| Accessibility feature | Base app | Notes |
|---|---|---|
| TalkBack (screen reader) | Supported | All interactive elements have content descriptions. All common tasks are operable with TalkBack. |
| Switch Access / Keyboard navigation | Supported | All interactive elements are keyboard-focusable with a visible focus indicator. |
| Large text / Font scaling | Supported | All text uses sp units and scales with the system font size setting. |
| Voice Access | Supported | All interactive elements have descriptive labels that Voice Access can match to voice commands. |
| Reduced Motion | Not supported | The app does not currently respond to the Remove Animations system setting. |
| Differentiate without color alone | Supported | All state icons (error, success, warning) use a distinct shape in addition to color. |
| Sufficient contrast | Supported or not supported | Depends on whether your custom brand colors meet WCAG AA minimum contrast ratios. |
| Dark theme | Not supported by base app | The base app has no built-in dark color scheme. Dark mode support depends entirely on whether your customization includes dark-mode color variants. |
| Captions | Not applicable | The app contains no video or audio-only content. |
| Audio descriptions | Not applicable | The app contains no video content. |
Disclosing accessibility in your Google Play listing
Because Google Play has no structured accessibility declaration feature, you can inform your users by including a short accessibility statement in the app's Full description field in Play Console. Example text you can adapt:
This app supports Android accessibility services including TalkBack, Switch Access, Voice Access, and system font scaling. All interactive elements have descriptive labels and are keyboard-navigable. State indicators (error, warning, success) use both color and shape so that color is never the sole differentiator.
Preconditions for customized apps
The following labels apply to all customized apps without additional steps, with the noted exceptions:
| Feature | Exception | |
|---|---|---|
| TalkBack | ✅ | Only fails if you remove or override content descriptions in your custom localizations. |
| Switch Access / Keyboard | ✅ | No action required. |
| Large text / Font scaling | ✅ | Only fails if you substitute custom fonts that use fixed dp sizes instead of sp. |
| Voice Access | ✅ | Follows from TalkBack support; the same exception applies. |
| Differentiate without color alone | ✅ | Only fails if your custom state icons use color as the sole differentiator without an accompanying shape or symbol. |
For the following features, additional steps are required before you can claim support:
Sufficient contrast
Ensure that your custom brand colors meet the WCAG AA minimum contrast ratios: 4.5:1 between body text and its background, and 3:1 for large text and non-text elements such as icons and borders.
Use the Accessibility Scanner app or Android Studio's Compose UI Check to audit your brand colors. Pay particular attention to secondary and tertiary text colors, button text on the primary button background, and state indicator icons on white or near-white backgrounds.
Dark theme
The base app has no built-in dark color scheme - it uses only the light-mode colors provided in your customization. There is no automatic adaptation to the system dark mode setting.
You can claim dark theme support only if your Access App customization includes dark-mode color variants for all brand colors. When dark-mode variants are configured, the app respects the system dark mode setting and switches to those colors. If only light-mode colors are provided, dark theme support cannot be claimed.