Apple’s core tenet:"The best technology should work for everyone." Accessibility is not an extra feature; it is part of inclusive design. This wiki breaks down "being friendly to all people" into actionable checklists, with real test cases from Apple’s official Landmarks App wherever possible.
1. Three Underlying Traits of Accessibility
An accessible interface satisfies all of the following:
- Intuitive — Interactions are familiar, consistent, and simple to operate.
- Perceivable — Information does not rely on a single channel, and supports visual, auditory, and haptic perception.
- Adaptable — Supports system accessibility features and also allows user customization.
2. The Nine Accessibility Principles (the checklist you should tape to your desk)
Apple groups accessibility into 3 categories covering 9 core principles. This is the evaluation baseline for the App Store Accessibility Nutrition Labels evaluation:
| Category | Principle | One-liner |
|---|---|---|
| Visual | Sufficient Contrast | Foreground and background have enough contrast so text is clear and readable |
| Dark Interface | Supports Dark Mode (some people need it for physiological reasons, not just preference) | |
| Larger Text | Text can scale up to ≥200% (some users need 310%) without breaking the layout | |
| Differentiate Without Color Alone | Express information through color + icons/shapes/text in multiple ways | |
| Reduced Motion | Respect the system toggle, and avoid zooming, sliding, parallax, and other motion that can cause dizziness | |
| Interaction | Voice Control | All operations can be completed entirely by voice, without touching the screen |
| VoiceOver | Visually impaired users can fully operate the app via spoken output + gestures/keyboard | |
| Media | Captions | Convert dialogue and sound effects in video/audio to text and display them during playback |
| Audio Descriptions | Insert spoken narration during gaps in dialogue to "describe what is happening on screen" |
Lessons from Landmarks App testing: The team used high-contrast color palettes from the start, but testing found that some colors still failed to meet standards when "Increase Contrast" was enabled — in the end, they chose to replace the colors instead of forcing them to stay, and checked both Light and Dark appearances.
3. Detailed Breakdown of the 6 Accessibility Dimensions
Organized by "what barriers users may face", which is easier to use than memorizing by feature:
| Dimension | Who it serves | Key practices |
|---|---|---|
| Vision | Blindness / color blindness / low vision / photosensitivity | Support 200% magnification (140% on watchOS) + Dynamic Type; follow WCAG contrast ratios; use system colors; don’t convey information by color alone; support VoiceOver |
| Hearing | Deaf or hard of hearing / noisy environments | Captions / translated captions / audio descriptions / text transcripts; supplement sound effects with haptic feedback (Music Haptics); replace audio cues with visual prompts |
| Mobility | Limited hand dexterity | Make controls large enough with sufficient spacing (12pt padding for bordered controls, 24pt for borderless); avoid complex multi-finger gestures; provide button alternatives for swipe/drag actions; support Voice Control / AssistiveTouch / Switch Control |
| Speech | Limited expressive ability / preference for text | Full Keyboard Access; do not override system keyboard shortcuts; support Switch Control |
| Cognition | Diverse cognitive abilities | Keep operations intuitive and consistent, use fewer custom gestures; reduce interfaces that auto-disappear after a time limit; avoid autoplay (provide start/stop controls); support Reduce Motion / Dim Flashing Lights; support Assistive Access simplified mode |
| visionOS | Spatial computing-specific | Support head / hand gesture / gaze control; avoid vertical perspective shifts and rapid eye movement; reduce peripheral animations and camera shake; do not anchor interface elements to the head |
Pitfall in Smart Invert testing: When testing Dark Mode, also test "Smart Invert Colors" — ensure images and videos are not incorrectly inverted (otherwise users cannot understand them).
4. How to Speed Up VoiceOver (Mac-tested techniques)
VoiceOver users have to navigate item by item with key presses, which is much slower than using a mouse. SwiftUI provides 3 grouping verbs + 2 remedies:
| Verb | Effect | When to use |
|---|---|---|
.contain |
Treat as a group and read child elements individually | Group a set of related controls (such as a "style group") so the whole group can be skipped as a unit |
.combine |
Merge the view and its child content into a single spoken announcement | Combine a title and button so they are read together as "Title, Apply button," letting users hear everything at once |
.ignore |
Skip internal content and read only the outermost element | Decorative nested elements |
accessibilityRotor |
Add a custom "rotor" shortcut menu | Browse only bookmarked pages (skip ordinary pages) |
accessibilityAction |
Add non-pointer action items | Make features that are "visible only on hover" (which VoiceOver cannot hover over) reachable via the action menu |
Pitfall: Mac interfaces have deep hierarchies, and accessibility containers tend to be nested many layers — don’t wrap too many groups (repeatedly entering and exiting groups is very tedious). Principle: clear structure + all elements identifiable by swipe + correct reading order and naming.
5. App Store Accessibility Nutrition Labels (How to declare truthfully)
Three core ideas + evaluation process:
- Three ideas: Design for everyone / Learn accessibility features (VoiceOver, Voice Control, Dynamic Type, Smart Invert) / Connect with disabled communities ("Nothing about us without us"to involve real disabled users in design and testing).
- Evaluation process: ① Define "universal tasks" (first launch / sign in / purchase / settings — what do users come to your app to do?); ② Test every accessibility feature × every universal task, across all devices; ③ "If a feature is irrelevant to the app, do not claim support for it".
6. Inclusive Design
Core mindset: constantly examine your own assumptions about others, and be willing to adjust designs as your understanding grows.
- Diversity factors: age / gender identity / race / sexual orientation / physical and mental attributes / permanent, temporary, or situational disabilities / language and culture / religion / education / political views / socioeconomic background.
- Inclusive language: Be clear and easy to understand, avoid technical jargon (provide definitions if you must use it), replace culture-specific slang.
- Gender: Use gender-neutral terms ("subscriber" instead of "he/she"); when gender information is needed, provide diverse options ("non-binary / self-identify / prefer not to say") + custom pronouns.
- Avoid stereotypes: Show diverse groups of people; don’t only depict male doctors / female nurses; don’t assume "family = man + woman + biological children"; frame questions around universal experiences ("your favorite activity") rather than "your favorite subject in college / your first car".
- People-first narration: Talk about a person’s achievements and goals first, then mention any disability they may have; disability exists on a broad spectrum (vision impairment includes low vision / total blindness / color blindness / photosensitivity…), and anyone may experience it (short-term / situational disability).
- Internationalization vs Localization: Internationalization = enabling software to handle multiple languages and regions; Localization = providing translated resources for a specific region. SF Symbols includes language-specific symbols and built-in LTR/RTL support to simplify localization.
7. Privacy
Core mindset: collect only necessary data + transparently explain its purpose + prioritize on-device processing.
| Key point | Practice · Counterexample |
|---|---|
| Ask only when needed | Only request permission when the user explicitly uses a given feature (ask for location only when the user taps the location button);do not ask at launch (unless that data is essential to the app, such as a navigation app needing location). |
| Be specific about purpose | ✅ "Record audio at night to detect snoring" ❌ "Microphone is used to provide a better experience" (too vague) ❌ "Turn on microphone permission" (no reason given) |
| Rules for pre-permission screens | You may add a custom explanation screen before the system prompt, but it can only have one button (use "Continue / Next," not "Allow"), and must not include other actions such as Cancel (otherwise users will feel manipulated). |
| Tracking requests | Tracking from launch must trigger the system prompt before any data collection;offering rewards in exchange for permissions is prohibited; do not use fake interfaces that mimic system prompts. |
| Location button | The Core Location location button on iOS/iPadOS/watchOS = one-time temporary authorization; its appearance can be customized but it must always convey the "share location" intent. |
| Data protection | Don’t rely only on passwords (use biometrics / Passkeys); store sensitive data in the keychain;do not invent your own authentication scheme (use Sign in with Apple / Password AutoFill); on macOS use a valid Developer ID + App Sandbox. |
8. Writing
Core mindset: define your tone + be action-oriented + establish consistent language patterns.
- Set the tone: Imagine who you are talking to (a banking app conveys trust and stability, a game app is relaxed and fun); create a list of common terms to maintain consistency.
- Adjust tone by context: Fall detection alerts should be serious and direct; fitness achievements can be light and celebratory.
- Action-oriented: Use active voice + verb labels ("Next" > "Let’s go!"); link text should clearly describe the action,do not use "click here" (it is not accessibility-friendly).
- Error messages should offer solutions: ✅ "Please choose a password with at least 8 characters" ❌ "Password too short"; avoid insincere phrasing such as "Oh no!".
- Empty state guidance When a list is empty, provide clear next-step suggestions or feature introductions.
- Settings labels: Be concise + describe "what happens when turned on" (let users infer what happens when turned off), don’t rely on complex path explanations.
- Input fields: Use placeholders to demonstrate format ("name@example.com"); when an error occurs, provide specific correction suggestions next to the field instead of a generic "Invalid input."
- Multiple devices: Keep text concise on small iPhone/Watch screens; on tvOS, keep copy short and understandable for group viewing.
9. Right-to-Left RTL (Arabic / Hebrew, etc.)
System UI frameworks support automatic RTL flipping by default, but several areas require manual checks:
| Element | RTL rule |
|---|---|
| Text alignment | LTR text aligns left, RTL text aligns right;paragraphs align according to their own language, not the surrounding context (English paragraphs in an RTL environment still align left); list items maintain consistent alignment. |
| Numbers | Do not reverse digit order (a phone/card number "541" is always "541"); however, the direction of progress bars / sliders / rating controls must be flipped. |
| Controls | Controls that display progress/values flip direction (right-to-left); button order flips to maintain logical consistency. |
| Images | Images with sequential/hierarchical relationships should have their display order flipped. |
| Interface icons | SF Symbols includes built-in RTL variants and Arabic/Hebrew localized symbols; flip icons that "indicate text direction" and "forward/backward motion" (such as speaker sound-wave direction); create localized versions for icons that contain text. |
Compiled from 11 pieces covering Foundations (Accessibility/Inclusion/Privacy/RTL/Writing) plus iOS and macOS systems and frameworks (Nine Accessibility Principles · Visual/Media/Interaction categories · Mac VoiceOver · Nutrition Labels). For visual foundations, see also Apple HIG Visual Foundations (Color/Typography/Layout/Materials/Motion/Dark Mode/Icons/SF Symbols/Branding).