---
name: apple-localization-accessibility
description: "Localize Apple app UI and verify accessible interaction. Use for string catalogs, locale-dependent layout, Dynamic Type, VoiceOver, contrast, motion, and platform input behavior."
---

# Apple Localization / Accessibility

## Purpose

Use this skill when text, layout, voice, input, color, motion, or locale behavior can affect whether the app is usable. Treat localization and accessibility as behavior, not polish.

## Localization Workflow

1. Inventory user-visible strings.
   - Prefer string catalogs where the project uses Xcode-native localization.
   - Keep format strings, pluralization, dates, units, and measurements locale-aware.
   - Do not concatenate localized sentence fragments.

2. Check assets and app metadata.
   - Localize assets only when meaning changes by locale.
   - Check app name, widgets, shortcuts, App Intents phrases, permissions, privacy strings, and notifications.

3. Prove layout.
   - Test long strings, right-to-left layout when relevant, narrow widths, Dynamic Type, and platform-specific title/toolbar constraints.
   - Use Xcode 27 localization assistance where it reduces mechanical misses, but verify in the app or previews.

## Accessibility Workflow

1. Define the interaction contract.
   - Every meaningful control has an accessible label, value, hint where useful, and action.
   - Decorative visuals are hidden from accessibility.
   - Dynamic content announces changes only when it helps the user.

2. Check major modes.
   - Dynamic Type and large content sizes
   - VoiceOver order and grouping
   - high contrast and differentiate-without-color
   - reduce motion and reduce transparency
   - keyboard, switch, and pointer/focus behavior where platform-relevant
   - haptics and audio that do not carry exclusive meaning

3. Prove with app-native evidence.
   - Use previews for variant coverage.
   - Use Simulator or device proof for VoiceOver, focus, and layout.
   - In Xcode 27 beta, Simulator and Device Hub accessibility toggles are setup aids, not VoiceOver proof; verify actual VoiceOver behavior in Simulator or on a device.
   - Use screenshots only after verifying that controls still fit and do not overlap.

## Strong Defaults

- Put localization keys near the user-facing feature, not in generic dumping grounds.
- Keep accessibility modifiers next to the view that owns the semantics.
- Do not add visible instructional text to compensate for inaccessible controls.
- Do not rely on color alone for health, alert, success, or failure state.

## Output

Provide:

- localized surfaces changed or checked
- accessibility behaviors changed or checked
- exact locale/content-size/mode proof
- remaining untested modes