From 6b40e7048e2c2c740cced52bbed89f2b04480471 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 29 Apr 2026 20:13:45 -0700 Subject: [PATCH 01/17] Initial commit This document provides a comprehensive checklist for accessibility considerations specific to native mobile experiences, including guidelines, best practices, and resources for iOS and Android applications. --- checklists/mobile-checklist.md | 313 +++++++++++++++++++++++++++++++++ 1 file changed, 313 insertions(+) create mode 100644 checklists/mobile-checklist.md diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md new file mode 100644 index 0000000..4cbc21a --- /dev/null +++ b/checklists/mobile-checklist.md @@ -0,0 +1,313 @@ +# Mobile Checklist + +This checklist summarizes accessibility considerations specific to native mobile experiences (iOS and Android), drawing from [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), the [W3C Guidance on Applying WCAG 2.2 to Mobile Applications](https://www.w3.org/TR/wcag2mobile-22/), and best practices identified by GitHub. + +Use this checklist when designing or building **native mobile experiences** (iOS and Android). Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web, so this checklist stands on its own. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. + +The one exception: if part of your app uses a **web view** (an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content), apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. + +For per-interaction annotation guidance, pair this checklist with the [User Interactions tutorial](../tutorials/user-interactions.md) and the [Mobile annotations tutorial](../tutorials/mobile-annotations.md). The mobile annotations tutorial also includes a list of [design considerations](../tutorials/mobile-annotations.md#design-considerations) worth reviewing before you start annotating. For per-SC application notes when auditing, see the [Mobile-WCAG Mapping (Internal only)](https://github.com/github/accessibility-audit-guide/blob/main/mobile/mobile-wcag-map.md). + +**Further reading:** +- [Mobile annotations tutorial](../tutorials/mobile-annotations.md) +- [User Interactions tutorial](../tutorials/user-interactions.md) +- [Guidance on Applying WCAG 2.2 to Mobile Applications - W3C](https://www.w3.org/TR/wcag2mobile-22/) +- [Guidance on Applying WCAG 2 to Non-Web ICT (WCAG2ICT) - W3C](https://www.w3.org/TR/wcag2ict-22/) +- [Accessibility documentation - Appt](https://appt.org/en/docs) +- [Apple Human Interface Guidelines: Accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility) +- [Material Design: Accessibility](https://m3.material.io/foundations/accessible-design/overview) + +--- + +## 1. Color + +- [ ] **Meaning is not conveyed with color alone** + - Status, severity, and selection indicators should also use a label, icon, shape, or text treatment. +- [ ] **Color contrast is observed across both light and dark modes** + - Functional text has a **4.5:1** contrast ratio (or higher) with its background. + - Functional graphics (icons, status indicators, control identification) have a **3:1** contrast ratio (or higher). + - Verify both system themes since gradients and elevation tints can shift contrast. +- [ ] **Designs respect user color settings** + - Account for high contrast modes, Smart Invert (iOS), and color correction (Android). Don't bake essential information into images that get inverted. + +### Suggested Tools + +- [Check color contrast - Figma Docs](https://help.figma.com/hc/en-us/articles/360041003774-Apply-paints-with-the-color-picker#h_01JQF1T71AC72G6VDXN27B77V0) +- [Web Color Contrast Checker - WebAIM](https://webaim.org/resources/contrastchecker/) +- [Colour Contrast Analyzer for Mac and Windows - TPGi](https://www.tpgi.com/color-contrast-checker/) + +--- + +## 2. Hierarchy + +- [ ] **Each screen has at most one Title** + - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. Note: in WCAG terms, [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) applies to the application as a whole on native, but the per-screen title is still the right pattern for orientation. +- [ ] **Headings are used sparingly and only when they help structure the screen** + - Unlike the web, mobile screens often don't need headings. Use them when content has clear sections that benefit from rotor or TalkBack heading navigation. +- [ ] **Reading order matches visual order** + - Screen readers narrate in view-tree order. Walk the screen with the VoiceOver rotor (iOS) and TalkBack swipe gestures (Android) to confirm that headings, links, form controls, and landmarks surface in the right order. This is especially important on cards, carousels, and bottom sheets. +- [ ] **Grouping is annotated** + - Use a Mobile Grouping Stamp to mark elements that should be announced as one unit (avatar + name + timestamp on a comment, for example). This includes any content block that should read as a single unit rather than several separate stops. + +### Annotations that can help +- [Mobile Structure Stamp](../tutorials/mobile-annotations.md#mobile-structure-stamp) +- [Mobile Grouping Stamp](../tutorials/mobile-annotations.md#mobile-grouping-stamp) + +### Exercises + +- Sketch out the focus order with arrows before annotating. If the line zig-zags, simplify the layout or regroup elements. + +--- + +## 3. Content (Label, Value, Role, Hint) + +- [ ] **Every interactive element has a Label** + - Labels are the primary way assistive tech identifies a control. Match the visible text where possible so voice control users can speak what they see (per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html)). For elements without visible text (icon-only buttons, avatars, etc.), be explicit about which label belongs to which control. +- [ ] **Stateful controls have a Value** + - Toggles, sliders, segmented controls, and inputs need a current value (e.g., "On", "75%", "@octocat"). +- [ ] **Roles and traits are specified per platform** + - iOS uses traits (button, header, adjustable, selected). Android uses roles and state descriptions. Annotate both if you ship to both. +- [ ] **Hints are used only for non-obvious interactions** + - Don't put critical info in hints. Users can disable them, and they're announced last. +- [ ] **Decorative elements are hidden from assistive tech** + - Mark with `accessibilityElementsHidden` (iOS) or `importantForAccessibility="no"` (Android). +- [ ] **Language of the app is set, and any sections in a different language are identified** + - On native, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). + +### Annotations that can help +- [Mobile Details](../tutorials/mobile-annotations.md#mobile-details) +- [View Context Stamps and Details](../tutorials/mobile-annotations.md#view-context-stamps-and-details) for web views, user-generated content, and non-native content + +--- + +## 4. Images, graphics, and other media + +- [ ] **Functional images and icon-only buttons have an accessible label** + - Decorative images should be hidden from screen readers, not given empty labels that still get focused. +- [ ] **Important text is not baked into images** + - It can't be translated, scaled with Dynamic Type, or copied. +- [ ] **Video and audio include captions, transcripts, or audio descriptions where applicable** +- [ ] **Auto-playing or scrolling content can be paused, stopped, or hidden** + - Includes auto-advancing carousels, looping animations, and live previews. +- [ ] **Nothing flashes more than 3 times per second** + +### Resources + +- [Alt Text Guide - GitHub Workplace Accessibility](https://github.com/github/workplace-accessibility/blob/main/resources/content-accessibility/alt-text-guide.md) +- [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) + +--- + +## 5. Interactivity and touch targets + +- [ ] **Touch targets are at least 44x44 pt (iOS) / 48x48 dp (Android)** + - This meets [WCAG 2.2 SC 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) of 24x24 CSS pixels with healthy margin, and aligns with both platforms' HIG guidance. + - Targets that let users select a value spatially based on position within the target (sliders, color pickers, map pins inside a draggable region) are considered a single target for this SC. +- [ ] **Adjacent targets have enough spacing** + - Aim for at least 8 pt/dp between tappable elements to prevent mis-taps. +- [ ] **Buttons and links are used appropriately** + - Buttons trigger actions. Links navigate. Don't style one as the other. When annotating, identify every element that performs an action when activated so the right role is applied. +- [ ] **Each button and link has a unique, descriptive name** + - Avoid repeated "More", "Open", or "View" labels in lists. Include context (e.g., "Open pull request 142"). +- [ ] **Disabled buttons are avoided** + - Prefer an inactive style with feedback explaining what's missing, or hide the action until it's available. + +### Annotations that can help +- [Mobile Button Stamp](../tutorials/mobile-annotations.md#mobile-button-stamp) + +### Resources + +- [Getting To The Bottom Of Minimum WCAG-Conformant Interactive Element Size - Smashing Magazine](https://www.smashingmagazine.com/2024/07/getting-bottom-minimum-wcag-conformant-interactive-element-size/) +- [Apple HIG: Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons) +- [Material Design: Touch targets](https://m3.material.io/foundations/designing/structure#1da3138c-2b54-4f5b-9c88-dbf6e6b9c12a) + +--- + +## 6. Gestures and motion + +The [User Interactions tutorial](../tutorials/user-interactions.md#touch-gesture) groups touch gestures into three tiers: **Basic** (single tap, double tap, long press), **Specialized** (swipe, drag, tap-and-hold), and **Advanced** (multi-finger, pinch, rotate, path-based). Use this section to verify each tier is used appropriately. + +- [ ] **Primary actions use Basic gestures** + - Single tap is the most accessible. Reserve it for the most important interactions on a screen. +- [ ] **Specialized gestures are used sparingly and have a single-point alternative** + - Pinch-to-zoom, swipe-to-delete, swipe-to-reveal-actions, and tap-and-hold all need a button or menu equivalent. Required by [SC 2.5.1 Pointer Gestures](https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html). +- [ ] **Advanced gestures are avoided unless essential** + - Multi-finger taps, two-finger rotation, and path-based gestures should not be the only way to do something. If they are essential, document the [accessible alternatives](https://tetralogical.com/blog/2023/03/17/foundations-pointer-gestures/#examples-of-accessible-alternatives). +- [ ] **Drag-and-drop has a non-dragging alternative** + - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html). Reorder lists with up/down buttons, move items with a menu, etc. +- [ ] **Custom gestures are exposed as VoiceOver and TalkBack Custom Actions** + - So screen reader users can discover and trigger them without performing the gesture. +- [ ] **Animations and transitions respect Reduce Motion** + - Honor `UIAccessibility.isReduceMotionEnabled` (iOS) and `Settings.Global.TRANSITION_ANIMATION_SCALE` (Android). Replace large motion with cross-fades or instant transitions. +- [ ] **Pointer cancellation is supported** + - Per [SC 2.5.2 Pointer Cancellation](https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation.html), trigger actions on the up-event so users can drag off a control to cancel. + +### Annotations that can help +- [Touch gesture (User Interactions)](../tutorials/user-interactions.md#touch-gesture) +- [User Interactions: Custom Action](https://gh.io/annotation-tutorial-user-interactions) + +--- + +## 7. Device settings and platform behavior + +Mobile users rely heavily on system-level settings to make their device usable. The [Device setting annotations](../tutorials/user-interactions.md#device-setting) cover the most common ones. Designs need to respect these settings, not fight them. + +- [ ] **Both portrait and landscape orientations are supported** + - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's essential (e.g., a piano app). Many users mount their device in a fixed orientation for accessibility reasons. +- [ ] **Layouts adapt to Dynamic Type (iOS) and Font size scaling (Android)** + - Test at the largest accessibility text sizes per [SC 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html). Content should reflow without truncation or overlap. +- [ ] **Viewport zoom and viewport resize don't break the layout** + - Magnifier, browser zoom inside web views, and split-screen / multitasking on tablets all change the available viewport. No content overlap, no obscured controls. +- [ ] **Reduce Motion is honored** + - Annotate any motion-heavy transition with the Reduced motion device setting so engineering knows to gate it. +- [ ] **Voice Control labels match visible text** + - Voice Control (iOS) and Voice Access (Android) let users speak the name of a control. If your label and visible text drift apart, voice users can't activate it. +- [ ] **Functionality does not require device motion to operate** + - Shake-to-undo, tilt-to-scroll, and similar interactions need a button equivalent and should be possible to disable. Per [SC 2.5.4 Motion Actuation](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html). + +### Annotations that can help +- [Device setting (User Interactions)](../tutorials/user-interactions.md#device-setting): Reduced motion, Viewport zoom, Voice input, Viewport resize, Orientation, Shake device + +--- + +## 8. Forms + +- [ ] **Inputs have a persistent visible label, not just a placeholder** + - Per [SC 3.3.2 Labels or Instructions](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html). +- [ ] **Keyboard type matches the input** + - Email, number, phone, URL keyboards reduce errors and effort. +- [ ] **Autofill, autocomplete, and content type hints are set** + - iOS `textContentType`, Android `autofillHints`. Helps password managers and reduces redundant entry per [SC 3.3.7 Redundant Entry](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html) and [SC 1.3.5 Identify Input Purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). +- [ ] **Errors are announced and tied to the field** + - Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). Use live regions or accessibility focus to surface errors. Don't rely on color alone. +- [ ] **Legal, financial, or test submissions can be reviewed, corrected, or reversed** + - Per [SC 3.3.4 Error Prevention (Legal, Financial, Data)](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html). + +### Annotations that can help +- [Form Element](https://gh.io/annotation-tutorial-form-element) + +--- + +## 9. Layout + +- [ ] **Layouts adapt across device sizes** + - Cover small phones, large phones, foldables, and tablets. Verify safe areas, notches, and home indicators don't obscure content. +- [ ] **Content reflows without loss of information or functionality** + - On native, [SC 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) applies through WCAG2ICT guidance: when users resize text via Dynamic Type or font scaling, content should reflow without requiring scrolling in two dimensions for primary content. Tables, image galleries, and similar are reasonable exceptions. +- [ ] **Persistent UI (nav, help, status) appears in consistent locations across screens** + - Per [SC 3.2.3 Consistent Navigation](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) and [SC 3.2.6 Consistent Help](https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html). +- [ ] **Web view content (only) supports text spacing overrides** + - [SC 1.4.12 Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) applies only inside a web view on native. For embedded HTML content, verify line height up to 1.5x font size, paragraph spacing up to 2x, letter spacing up to 0.12x, and word spacing up to 0.16x. Native UI is governed by Dynamic Type / font scaling instead (see §7). + +--- + +## 10. Touch and keyboard navigation + +- [ ] **Every touch interaction is reachable with an external keyboard** + - Bluetooth keyboards, Switch Control (iOS), and Switch Access (Android) all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. +- [ ] **A visible focus indicator appears when navigating with a keyboard or switch** + - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). +- [ ] **Focus order is annotated and matches the visual flow** + - Avoid focus that jumps back and forth across the screen. +- [ ] **There are no focus traps** + - Modals, sheets, and overlays must let users dismiss and return focus to a logical place. Per [SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html). +- [ ] **Custom controls expose proper accessibility actions** + - A custom slider should respond to increment/decrement actions, not just drag. +- [ ] **Keyboard shortcuts don't override platform or assistive tech shortcuts** + - Check against VoiceOver, TalkBack, Switch Control, and Voice Control shortcut tables before claiming a key combo. See the [Keyboard shortcut annotation guidance](../tutorials/user-interactions.md#keyboard-shortcut). +- [ ] **No single-character shortcuts are introduced for new features** + - Per [SC 2.1.4 Character Key Shortcuts](https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html). If you must, allow users to remap or disable them. Note: long-press gestures and platform-provided accessibility features don't meet WCAG's definition of a keyboard shortcut, so they're not in scope here. + +### Annotations that can help +- [Ordering](https://gh.io/annotation-tutorial-ordering) (Focus Order, Arrow Stop) +- [Keyboard shortcut (User Interactions)](../tutorials/user-interactions.md#keyboard-shortcut) + +--- + +## 11. Platform parity + +- [ ] **Stock platform controls are preferred over custom ones** + - A native segmented control, switch, or date picker comes with accessibility behavior built in. Before designing a custom control, check whether a standard one would do the job. +- [ ] **iOS and Android specs are both annotated when shipping to both platforms** + - Use the iOS (blue) and Android (green) variants of mobile annotations to make platform differences visible on the canvas. +- [ ] **Stock components use the platform's native accessibility behavior** + - When using a system component, toggle "Follow stock native pattern" in your Mobile Details annotation and link to the platform docs. +- [ ] **Platform conventions are respected** + - Back navigation, modal dismissal, and primary action placement differ between iOS and Android. Don't force one platform's pattern onto the other. +- [ ] **Components are identified consistently across the family of related apps** + - If your team ships a suite of apps (e.g., GitHub Mobile + GitHub for iPad + an extension app), [SC 3.2.4 Consistent Identification](https://www.w3.org/WAI/WCAG22/Understanding/consistent-identification.html) and [SC 3.2.3 Consistent Navigation](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) apply across the set, not just within a single app. The same icon should mean the same thing everywhere. +- [ ] **Web views, user-generated content, and non-native content are flagged** + - Use [View Context Stamps](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so testers know where annotation handoff happens. For web view content specifically, run it through the [Designer](./designer-checklist.md) and [Engineering](./engineering-checklist.md) checklists. + +--- + +## 12. Platform functions + +The [Platform function annotations](../tutorials/user-interactions.md#platform-function) flag built-in behaviors that can disorient users if they're not designed carefully. + +- [ ] **Loading states have clear visual and programmatic feedback** + - Use a live region announcement, not just a spinner. See [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement). Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). +- [ ] **Automatic transitions are avoided or controllable** + - System-initiated screen, state, or content changes should be paused, slowed, or dismissable. Common offenders: onboarding carousels, auto-advancing tutorials. Per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). +- [ ] **Opening external content is announced** + - "Opens in Safari", "Opens in browser", or "Opens in a new window" warnings prevent disorientation, especially when leaving an app for a web view. +- [ ] **Time limits can be turned off, adjusted, or extended** + - Exceptions: real-time events (auctions, live games) or time limits beyond 20 hours. Per [SC 2.2.1 Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html). +- [ ] **Cognitive function tests have an accessible alternative** + - CAPTCHA puzzles, math challenges, and memory checks need an alternate path. Per [SC 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html). Note: passwords used to unlock the underlying platform (device passcode, biometric unlock) are out of scope for this requirement at the app level. + +### Annotations that can help +- [Platform function (User Interactions)](../tutorials/user-interactions.md#platform-function): Loading, Automatic transition, Open in new tab, Time limit, Cognitive puzzle +- [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement) + +--- + +## 13. Notifications and live updates + +- [ ] **Status changes are announced via Live Regions** + - Search results, form validation, toast notifications, and async updates need an accessibility announcement so screen reader users don't miss them. Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). +- [ ] **`polite` vs `assertive` is chosen intentionally** + - Use `assertive` only for critical info (errors, blocking states). Default to `polite`. +- [ ] **Off-screen and dynamically appearing content has defined accessibility behavior** + - When new content appears (a bottom sheet opens, a card is inserted, a banner slides in), decide whether focus should move to it, whether it should be announced, and whether off-screen elements are hidden from assistive tech until they're visible. +- [ ] **Auto-dismissing UI can be paused or extended** + - Snackbars, toasts, and OTP inputs need an accessible alternative. + +### Annotations that can help +- [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement) + +--- + +## Testing + +- [ ] **Tested with VoiceOver on a real iOS device** +- [ ] **Tested with TalkBack on a real Android device** +- [ ] **Tested with the largest Dynamic Type / font scaling setting** +- [ ] **Tested with Reduce Motion enabled** +- [ ] **Tested in both light and dark mode, and in both portrait _and_ landscape** +- [ ] **Tested with Voice Control (iOS) and Voice Access (Android)** +- [ ] **Tested with an external keyboard or Switch Control / Switch Access** + +### Suggested Tools + +- [Accessibility Inspector - Apple](https://developer.apple.com/documentation/accessibility/accessibility-inspector) +- [Accessibility Scanner - Google](https://support.google.com/accessibility/android/answer/6376570) +- [Appium accessibility checks](https://appium.io/docs/en/2.0/) +- [Espresso Accessibility Checks - Android](https://developer.android.com/training/testing/espresso/accessibility-checking) + +--- + +## Additional Resources + +- [Mobile annotations tutorial](../tutorials/mobile-annotations.md) +- [User Interactions tutorial](../tutorials/user-interactions.md) +- [Accessibility documentation - Appt](https://appt.org/en/docs) +- [Guidance on Applying WCAG 2.2 to Mobile Applications - W3C](https://www.w3.org/TR/wcag2mobile-22/) +- [Guidance on Applying WCAG 2 to Non-Web ICT (WCAG2ICT) - W3C](https://www.w3.org/TR/wcag2ict-22/) +- [Mobile-WCAG Mapping - GitHub Accessibility Audit Guide (Internal only)](https://github.com/github/accessibility-audit-guide/blob/main/mobile/mobile-wcag-map.md) +- [Apple Accessibility Programming Guide](https://developer.apple.com/accessibility/) +- [Android Accessibility developer guide](https://developer.android.com/guide/topics/ui/accessibility) +- [Does WCAG 2.2 apply to native apps - TetraLogical](https://tetralogical.com/blog/2024/07/18/wcag2ict/) +- [Getting To The Bottom Of Minimum WCAG-Conformant Interactive Element Size - Smashing Magazine](https://www.smashingmagazine.com/2024/07/getting-bottom-minimum-wcag-conformant-interactive-element-size/) +- [Foundations: pointer gestures - TetraLogical](https://tetralogical.com/blog/2023/03/17/foundations-pointer-gestures/) +- [Foundations: Keyboard accessibility - TetraLogical](https://tetralogical.com/blog/2025/05/09/foundations-keyboard-accessibility/) From 498edf8c19d073a70c6b72bd48c54740c5556ac2 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Thu, 30 Apr 2026 10:02:01 -0700 Subject: [PATCH 02/17] Apply suggestions from code review Co-authored-by: Eric Bailey --- checklists/mobile-checklist.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 4cbc21a..cf58355 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -1,10 +1,10 @@ # Mobile Checklist -This checklist summarizes accessibility considerations specific to native mobile experiences (iOS and Android), drawing from [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), the [W3C Guidance on Applying WCAG 2.2 to Mobile Applications](https://www.w3.org/TR/wcag2mobile-22/), and best practices identified by GitHub. +This checklist summarizes accessibility considerations specific to iOS and Android, drawing from [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), the [W3C Guidance on Applying WCAG 2.2 to Mobile Applications](https://www.w3.org/TR/wcag2mobile-22/), and best practices identified by GitHub. -Use this checklist when designing or building **native mobile experiences** (iOS and Android). Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web, so this checklist stands on its own. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. +Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. -The one exception: if part of your app uses a **web view** (an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content), apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. +The one exception: if part of your app uses a **web view**, apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. Examples of web view content are an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content. For per-interaction annotation guidance, pair this checklist with the [User Interactions tutorial](../tutorials/user-interactions.md) and the [Mobile annotations tutorial](../tutorials/mobile-annotations.md). The mobile annotations tutorial also includes a list of [design considerations](../tutorials/mobile-annotations.md#design-considerations) worth reviewing before you start annotating. For per-SC application notes when auditing, see the [Mobile-WCAG Mapping (Internal only)](https://github.com/github/accessibility-audit-guide/blob/main/mobile/mobile-wcag-map.md). @@ -55,7 +55,7 @@ For per-interaction annotation guidance, pair this checklist with the [User Inte ### Exercises -- Sketch out the focus order with arrows before annotating. If the line zig-zags, simplify the layout or regroup elements. +Sketch out the focus order with arrows before annotating. If the line zig-zags, simplify the layout or regroup elements. --- @@ -125,7 +125,13 @@ For per-interaction annotation guidance, pair this checklist with the [User Inte ## 6. Gestures and motion -The [User Interactions tutorial](../tutorials/user-interactions.md#touch-gesture) groups touch gestures into three tiers: **Basic** (single tap, double tap, long press), **Specialized** (swipe, drag, tap-and-hold), and **Advanced** (multi-finger, pinch, rotate, path-based). Use this section to verify each tier is used appropriately. +The [User Interactions tutorial](../tutorials/user-interactions.md#touch-gesture) groups touch gestures into three tiers: + +1. **Basic** (single tap, double tap, long press), +2. **Specialized** (swipe, drag, tap-and-hold), and +3. **Advanced** (multi-finger, pinch, rotate, path-based). + +Use this section to verify each tier is used appropriately. - [ ] **Primary actions use Basic gestures** - Single tap is the most accessible. Reserve it for the most important interactions on a screen. @@ -154,7 +160,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Both portrait and landscape orientations are supported** - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's essential (e.g., a piano app). Many users mount their device in a fixed orientation for accessibility reasons. -- [ ] **Layouts adapt to Dynamic Type (iOS) and Font size scaling (Android)** +- [ ] **Layouts adapt to iOS' Dynamic Type and Android's Font Size Scaling** - Test at the largest accessibility text sizes per [SC 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html). Content should reflow without truncation or overlap. - [ ] **Viewport zoom and viewport resize don't break the layout** - Magnifier, browser zoom inside web views, and split-screen / multitasking on tablets all change the available viewport. No content overlap, no obscured controls. @@ -204,7 +210,7 @@ Mobile users rely heavily on system-level settings to make their device usable. ## 10. Touch and keyboard navigation - [ ] **Every touch interaction is reachable with an external keyboard** - - Bluetooth keyboards, Switch Control (iOS), and Switch Access (Android) all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. + - Bluetooth keyboards, iOS Switch Control, and Android Switch Access all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). - [ ] **Focus order is annotated and matches the visual flow** From 7a4121c4757b2c27a1671637151b81295aafd069 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Thu, 30 Apr 2026 14:30:43 -0700 Subject: [PATCH 03/17] Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- checklists/mobile-checklist.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index cf58355..16508be 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -150,7 +150,7 @@ Use this section to verify each tier is used appropriately. ### Annotations that can help - [Touch gesture (User Interactions)](../tutorials/user-interactions.md#touch-gesture) -- [User Interactions: Custom Action](https://gh.io/annotation-tutorial-user-interactions) +- [User Interactions tutorial](https://gh.io/annotation-tutorial-user-interactions) --- @@ -254,7 +254,7 @@ The [Platform function annotations](../tutorials/user-interactions.md#platform-f - [ ] **Loading states have clear visual and programmatic feedback** - Use a live region announcement, not just a spinner. See [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement). Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). - [ ] **Automatic transitions are avoided or controllable** - - System-initiated screen, state, or content changes should be paused, slowed, or dismissable. Common offenders: onboarding carousels, auto-advancing tutorials. Per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). + - System-initiated screen, state, or content changes should be paused, slowed, or dismissible. Common offenders: onboarding carousels, auto-advancing tutorials. Per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). - [ ] **Opening external content is announced** - "Opens in Safari", "Opens in browser", or "Opens in a new window" warnings prevent disorientation, especially when leaving an app for a web view. - [ ] **Time limits can be turned off, adjusted, or extended** From 6359f4478152b25d30652c42c925bd7cb346fff7 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Tue, 5 May 2026 12:48:07 -0700 Subject: [PATCH 04/17] Apply suggestions from code review Updated language for clarity and added guidance on accessibility practices in mobile app design. --- checklists/mobile-checklist.md | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 16508be..03fdb93 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -6,7 +6,9 @@ Native mobile has its own set of accessibility patterns, APIs, and user expectat The one exception: if part of your app uses a **web view**, apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. Examples of web view content are an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content. -For per-interaction annotation guidance, pair this checklist with the [User Interactions tutorial](../tutorials/user-interactions.md) and the [Mobile annotations tutorial](../tutorials/mobile-annotations.md). The mobile annotations tutorial also includes a list of [design considerations](../tutorials/mobile-annotations.md#design-considerations) worth reviewing before you start annotating. For per-SC application notes when auditing, see the [Mobile-WCAG Mapping (Internal only)](https://github.com/github/accessibility-audit-guide/blob/main/mobile/mobile-wcag-map.md). +For per-interaction guidance, pair this checklist with the [User Interactions tutorial](../tutorials/user-interactions.md) and the [Mobile annotations tutorial](../tutorials/mobile-annotations.md). Use these when you're specifying individual interactions or framing a design review. The mobile annotations tutorial also includes a list of [design considerations](../tutorials/mobile-annotations.md#design-considerations) that surface the right questions before you start annotating. + +For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://github.com/github/accessibility-audit-guide/blob/main/mobile/mobile-wcag-map.md). Mobile changes how some WCAG Success Criteria apply, with a few being partial or having non-obvious scoping, and the mapping document captures those differences in one place so audits stay consistent. **Further reading:** - [Mobile annotations tutorial](../tutorials/mobile-annotations.md) @@ -44,6 +46,8 @@ For per-interaction annotation guidance, pair this checklist with the [User Inte - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. Note: in WCAG terms, [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) applies to the application as a whole on native, but the per-screen title is still the right pattern for orientation. - [ ] **Headings are used sparingly and only when they help structure the screen** - Unlike the web, mobile screens often don't need headings. Use them when content has clear sections that benefit from rotor or TalkBack heading navigation. +- [ ] **Layouts favor a simple, predictable flow** + - On some frameworks like React Native, the operating system determines reading order by scanning the screen roughly top-to-bottom, left-to-right, and there's no API to override it. Designs that follow a clear vertical flow narrate correctly regardless of framework, and they're easier for everyone to scan visually too. - [ ] **Reading order matches visual order** - Screen readers narrate in view-tree order. Walk the screen with the VoiceOver rotor (iOS) and TalkBack swipe gestures (Android) to confirm that headings, links, form controls, and landmarks surface in the right order. This is especially important on cards, carousels, and bottom sheets. - [ ] **Grouping is annotated** @@ -62,7 +66,9 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, ## 3. Content (Label, Value, Role, Hint) - [ ] **Every interactive element has a Label** - - Labels are the primary way assistive tech identifies a control. Match the visible text where possible so voice control users can speak what they see (per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html)). For elements without visible text (icon-only buttons, avatars, etc.), be explicit about which label belongs to which control. + - Labels help people understand the purpose of a control. They're useful for everyone and especially important for people with cognitive disabilities. + - For Voice Control and Voice Access users, the visible label text must be programmatically associated with the control so users can speak the name they see. Per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html). + - For elements without visible text (icon-only buttons, avatars, etc.), be explicit in your annotations about which label belongs to which control. - [ ] **Stateful controls have a Value** - Toggles, sliders, segmented controls, and inputs need a current value (e.g., "On", "75%", "@octocat"). - [ ] **Roles and traits are specified per platform** @@ -70,7 +76,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Hints are used only for non-obvious interactions** - Don't put critical info in hints. Users can disable them, and they're announced last. - [ ] **Decorative elements are hidden from assistive tech** - - Mark with `accessibilityElementsHidden` (iOS) or `importantForAccessibility="no"` (Android). + - Mark with `accessibilityElementsHidden` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) — most images aren't truly decorative. - [ ] **Language of the app is set, and any sections in a different language are identified** - On native, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). @@ -106,14 +112,14 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Adjacent targets have enough spacing** - Aim for at least 8 pt/dp between tappable elements to prevent mis-taps. - [ ] **Buttons and links are used appropriately** - - Buttons trigger actions. Links navigate. Don't style one as the other. When annotating, identify every element that performs an action when activated so the right role is applied. + - Buttons trigger actions. Links navigate. Don't style one as the other. When annotating, consider the action performed when interacting with each element, and ensure that the right role is applied. - [ ] **Each button and link has a unique, descriptive name** - Avoid repeated "More", "Open", or "View" labels in lists. Include context (e.g., "Open pull request 142"). - [ ] **Disabled buttons are avoided** - Prefer an inactive style with feedback explaining what's missing, or hide the action until it's available. ### Annotations that can help -- [Mobile Button Stamp](../tutorials/mobile-annotations.md#mobile-button-stamp) +[Mobile Button Stamp](../tutorials/mobile-annotations.md#mobile-button-stamp) ### Resources @@ -159,7 +165,7 @@ Use this section to verify each tier is used appropriately. Mobile users rely heavily on system-level settings to make their device usable. The [Device setting annotations](../tutorials/user-interactions.md#device-setting) cover the most common ones. Designs need to respect these settings, not fight them. - [ ] **Both portrait and landscape orientations are supported** - - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's essential (e.g., a piano app). Many users mount their device in a fixed orientation for accessibility reasons. + - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's essential (e.g., a piano app). Many users mount their device in a fixed orientation for accessibility reasons. _All functionality and content must remain available across orientations._ - [ ] **Layouts adapt to iOS' Dynamic Type and Android's Font Size Scaling** - Test at the largest accessibility text sizes per [SC 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html). Content should reflow without truncation or overlap. - [ ] **Viewport zoom and viewport resize don't break the layout** @@ -167,12 +173,12 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Reduce Motion is honored** - Annotate any motion-heavy transition with the Reduced motion device setting so engineering knows to gate it. - [ ] **Voice Control labels match visible text** - - Voice Control (iOS) and Voice Access (Android) let users speak the name of a control. If your label and visible text drift apart, voice users can't activate it. + - Voice Control on iOS and Voice Access on Android let users speak the name of a control. The visible text and the programmatic accessibility label must match — if they're visually similar but programmatically different (or vice versa), voice users can't activate the control. - [ ] **Functionality does not require device motion to operate** - Shake-to-undo, tilt-to-scroll, and similar interactions need a button equivalent and should be possible to disable. Per [SC 2.5.4 Motion Actuation](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html). ### Annotations that can help -- [Device setting (User Interactions)](../tutorials/user-interactions.md#device-setting): Reduced motion, Viewport zoom, Voice input, Viewport resize, Orientation, Shake device +[Device setting (User Interactions)](../tutorials/user-interactions.md#device-setting): Reduced motion, Viewport zoom, Voice input, Viewport resize, Orientation, Shake device --- @@ -184,13 +190,15 @@ Mobile users rely heavily on system-level settings to make their device usable. - Email, number, phone, URL keyboards reduce errors and effort. - [ ] **Autofill, autocomplete, and content type hints are set** - iOS `textContentType`, Android `autofillHints`. Helps password managers and reduces redundant entry per [SC 3.3.7 Redundant Entry](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html) and [SC 1.3.5 Identify Input Purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). -- [ ] **Errors are announced and tied to the field** - - Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). Use live regions or accessibility focus to surface errors. Don't rely on color alone. +- [ ] **Errors are announced, indicated with text, and tied to the field** + - Identify what went wrong using text, not just color or an icon. + - When the fix is determinable, also suggest how to correct it (e.g., "Email must include @"). Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). + - Use live regions or accessibility focus so screen reader users hear errors when they're announced. - [ ] **Legal, financial, or test submissions can be reviewed, corrected, or reversed** - Per [SC 3.3.4 Error Prevention (Legal, Financial, Data)](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html). ### Annotations that can help -- [Form Element](https://gh.io/annotation-tutorial-form-element) +[Form Element](https://gh.io/annotation-tutorial-form-element) --- @@ -209,7 +217,7 @@ Mobile users rely heavily on system-level settings to make their device usable. ## 10. Touch and keyboard navigation -- [ ] **Every touch interaction is reachable with an external keyboard** +- [ ] **Every touch interaction is reachable and operable with an external keyboard** - Bluetooth keyboards, iOS Switch Control, and Android Switch Access all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). @@ -280,7 +288,7 @@ The [Platform function annotations](../tutorials/user-interactions.md#platform-f - Snackbars, toasts, and OTP inputs need an accessible alternative. ### Annotations that can help -- [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement) +[Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement) --- From 964c9abe54089b82b03b9d6b894fb863baa65708 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Tue, 5 May 2026 12:55:31 -0700 Subject: [PATCH 05/17] Add mobile accessibility checklist link to README Added a checklist for mobile accessibility considerations. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index d83205e..56d7eae 100644 --- a/README.md +++ b/README.md @@ -84,6 +84,7 @@ For GitHub staff, the "Annotation Toolkit" is enabled in the Figma Asset panel - [The Tiered Model](deep-dives/tiered-model.md) - Prioritizing around time constraints or knowledge gaps - [Accessibility Checklist for Designers](checklists/designer-checklist.md) - [Accessibility Checklist for Engineers](checklists/engineering-checklist.md) +- [Accessibility Checklist for Mobile](checklists/mobile-checklist.md) - Accessibility considerations for native iOS and Android experiences ## Resources ### Design system annotations (GitHub Blog series) From e43f12c351086aa11b96cdf998abb6a4eb7adab8 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Tue, 5 May 2026 13:46:20 -0700 Subject: [PATCH 06/17] Add platform feature links Updated checklist items to include links for Smart Invert, color correction, VoiceOver, TalkBack, Reduce Motion, iOS Dynamic Type, and Android Font Size Scaling for better accessibility guidance. h/t @ericwbailey --- checklists/mobile-checklist.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 03fdb93..9a48861 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -30,7 +30,7 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu - Functional graphics (icons, status indicators, control identification) have a **3:1** contrast ratio (or higher). - Verify both system themes since gradients and elevation tints can shift contrast. - [ ] **Designs respect user color settings** - - Account for high contrast modes, Smart Invert (iOS), and color correction (Android). Don't bake essential information into images that get inverted. + - Account for high contrast modes, [Smart Invert (iOS)](https://support.apple.com/guide/iphone/change-display-and-text-size-iph3e2e1fb0/ios), and [color correction (Android)](https://support.google.com/accessibility/android/answer/11183305?hl=en-GB&sjid=1525872318388975084-NC#zippy=%2Cuse-colour-correction:~:text=Colour%20correction%20and%20grayscale%20settings%20help%20your%20device%20compensate%20for%20colour%20blindness.%C2%A0). Don't bake essential information into images that get inverted. ### Suggested Tools @@ -45,11 +45,11 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu - [ ] **Each screen has at most one Title** - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. Note: in WCAG terms, [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) applies to the application as a whole on native, but the per-screen title is still the right pattern for orientation. - [ ] **Headings are used sparingly and only when they help structure the screen** - - Unlike the web, mobile screens often don't need headings. Use them when content has clear sections that benefit from rotor or TalkBack heading navigation. + - Unlike the web, mobile screens often don't need headings. Use them when content has clear sections that benefit from rotor or [TalkBack](https://support.google.com/accessibility/android/answer/6283677) heading navigation. - [ ] **Layouts favor a simple, predictable flow** - On some frameworks like React Native, the operating system determines reading order by scanning the screen roughly top-to-bottom, left-to-right, and there's no API to override it. Designs that follow a clear vertical flow narrate correctly regardless of framework, and they're easier for everyone to scan visually too. - [ ] **Reading order matches visual order** - - Screen readers narrate in view-tree order. Walk the screen with the VoiceOver rotor (iOS) and TalkBack swipe gestures (Android) to confirm that headings, links, form controls, and landmarks surface in the right order. This is especially important on cards, carousels, and bottom sheets. + - Screen readers narrate in view-tree order. Walk the screen with the [VoiceOver](https://support.apple.com/guide/iphone/turn-on-and-practice-voiceover-iph3e2e415f/ios) rotor (iOS) and TalkBack swipe gestures (Android) to confirm that headings, links, form controls, and landmarks surface in the right order. This is especially important on cards, carousels, and bottom sheets. - [ ] **Grouping is annotated** - Use a Mobile Grouping Stamp to mark elements that should be announced as one unit (avatar + name + timestamp on a comment, for example). This includes any content block that should read as a single unit rather than several separate stops. @@ -67,7 +67,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Every interactive element has a Label** - Labels help people understand the purpose of a control. They're useful for everyone and especially important for people with cognitive disabilities. - - For Voice Control and Voice Access users, the visible label text must be programmatically associated with the control so users can speak the name they see. Per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html). + - For [Voice Control](https://support.apple.com/guide/iphone/use-voice-control-iph2c21a3c88/ios) and [Voice Access](https://support.google.com/accessibility/android/answer/6151848) users, the visible label text must be programmatically associated with the control so users can speak the name they see. Per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html). - For elements without visible text (icon-only buttons, avatars, etc.), be explicit in your annotations about which label belongs to which control. - [ ] **Stateful controls have a Value** - Toggles, sliders, segmented controls, and inputs need a current value (e.g., "On", "75%", "@octocat"). @@ -149,7 +149,7 @@ Use this section to verify each tier is used appropriately. - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html). Reorder lists with up/down buttons, move items with a menu, etc. - [ ] **Custom gestures are exposed as VoiceOver and TalkBack Custom Actions** - So screen reader users can discover and trigger them without performing the gesture. -- [ ] **Animations and transitions respect Reduce Motion** +- [ ] **Animations and transitions respect [Reduce Motion](https://support.apple.com/guide/iphone/customize-onscreen-motion-iph0b691d3ed/ios)** - Honor `UIAccessibility.isReduceMotionEnabled` (iOS) and `Settings.Global.TRANSITION_ANIMATION_SCALE` (Android). Replace large motion with cross-fades or instant transitions. - [ ] **Pointer cancellation is supported** - Per [SC 2.5.2 Pointer Cancellation](https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation.html), trigger actions on the up-event so users can drag off a control to cancel. @@ -166,7 +166,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Both portrait and landscape orientations are supported** - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's essential (e.g., a piano app). Many users mount their device in a fixed orientation for accessibility reasons. _All functionality and content must remain available across orientations._ -- [ ] **Layouts adapt to iOS' Dynamic Type and Android's Font Size Scaling** +- [ ] **Layouts adapt to [iOS' Dynamic Type](https://developer.apple.com/documentation/uikit/scaling-fonts-automatically) and [Android's Font Size Scaling](https://support.google.com/accessibility/android/answer/11183305)** - Test at the largest accessibility text sizes per [SC 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html). Content should reflow without truncation or overlap. - [ ] **Viewport zoom and viewport resize don't break the layout** - Magnifier, browser zoom inside web views, and split-screen / multitasking on tablets all change the available viewport. No content overlap, no obscured controls. @@ -218,7 +218,7 @@ Mobile users rely heavily on system-level settings to make their device usable. ## 10. Touch and keyboard navigation - [ ] **Every touch interaction is reachable and operable with an external keyboard** - - Bluetooth keyboards, iOS Switch Control, and Android Switch Access all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. + - Bluetooth keyboards, [iOS Switch Control](https://support.apple.com/en-us/119835), and [Android Switch Access](https://support.google.com/accessibility/android/answer/6122836) all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). - [ ] **Focus order is annotated and matches the visual flow** From 8cf949eab32f7392da06e63f95f7d851215ec585 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Tue, 5 May 2026 13:49:08 -0700 Subject: [PATCH 07/17] Add Mobile Checklist to resources --- tutorials/mobile-annotations.md | 1 + 1 file changed, 1 insertion(+) diff --git a/tutorials/mobile-annotations.md b/tutorials/mobile-annotations.md index 193a16a..014d223 100644 --- a/tutorials/mobile-annotations.md +++ b/tutorials/mobile-annotations.md @@ -176,6 +176,7 @@ Users often come across content that wasn't built with the platform's native UI ## Resources +- [Accessibility Checklist for Mobile](./../checklists/mobile-checklist.md) - [​Accessibility documentation - Appt](https://appt.org/en/docs) - [Guidance on Applying WCAG 2.2 to Mobile Applications - W3C](https://www.w3.org/TR/wcag2mobile-22/) - [Mobile-WCAG Mapping - GitHub Accessibility Audit Guide (Internal Only)](https://github.com/github/accessibility-audit-guide/blob/main/mobile/mobile-wcag-map.md) From 70cdc5c0a033210ced72bbd1d27a69373071fd30 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 13:24:05 -0700 Subject: [PATCH 08/17] Update mobile checklist with suggestions from @julianmka --- checklists/mobile-checklist.md | 40 +++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 9a48861..1ec0bd1 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -33,10 +33,10 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu - Account for high contrast modes, [Smart Invert (iOS)](https://support.apple.com/guide/iphone/change-display-and-text-size-iph3e2e1fb0/ios), and [color correction (Android)](https://support.google.com/accessibility/android/answer/11183305?hl=en-GB&sjid=1525872318388975084-NC#zippy=%2Cuse-colour-correction:~:text=Colour%20correction%20and%20grayscale%20settings%20help%20your%20device%20compensate%20for%20colour%20blindness.%C2%A0). Don't bake essential information into images that get inverted. ### Suggested Tools - +- [Accessibility Scanner - Google](https://support.google.com/accessibility/android/answer/6376570) — Detects color contrast issues on Android, among other accessibility checks - [Check color contrast - Figma Docs](https://help.figma.com/hc/en-us/articles/360041003774-Apply-paints-with-the-color-picker#h_01JQF1T71AC72G6VDXN27B77V0) - [Web Color Contrast Checker - WebAIM](https://webaim.org/resources/contrastchecker/) -- [Colour Contrast Analyzer for Mac and Windows - TPGi](https://www.tpgi.com/color-contrast-checker/) +- [Colour Contrast Analyzer for Mac and Windows - Vispero](https://vispero.com/lp/color-contrast-checker/) --- @@ -44,6 +44,8 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu - [ ] **Each screen has at most one Title** - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. Note: in WCAG terms, [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) applies to the application as a whole on native, but the per-screen title is still the right pattern for orientation. +- [ ] **If a screen has no title bar, include a prominent heading near the top of the content** + - Screens without a top app bar (Android) or navigation bar (iOS) should still orient users — a clear, prominent heading at or near the top of the visible content gives screen reader users and everyone else a place to land. - [ ] **Headings are used sparingly and only when they help structure the screen** - Unlike the web, mobile screens often don't need headings. Use them when content has clear sections that benefit from rotor or [TalkBack](https://support.google.com/accessibility/android/answer/6283677) heading navigation. - [ ] **Layouts favor a simple, predictable flow** @@ -68,6 +70,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Every interactive element has a Label** - Labels help people understand the purpose of a control. They're useful for everyone and especially important for people with cognitive disabilities. - For [Voice Control](https://support.apple.com/guide/iphone/use-voice-control-iph2c21a3c88/ios) and [Voice Access](https://support.google.com/accessibility/android/answer/6151848) users, the visible label text must be programmatically associated with the control so users can speak the name they see. Per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html). + - On iOS, you can also define alternate `.accessibilityInputLabels` so Voice Control users can activate a control with multiple spoken names. For example, a trash icon button labeled "Delete" could also accept "trash" or "garbage". This is especially valuable when a control's primary accessibility label is long or technical. - For elements without visible text (icon-only buttons, avatars, etc.), be explicit in your annotations about which label belongs to which control. - [ ] **Stateful controls have a Value** - Toggles, sliders, segmented controls, and inputs need a current value (e.g., "On", "75%", "@octocat"). @@ -76,9 +79,9 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Hints are used only for non-obvious interactions** - Don't put critical info in hints. Users can disable them, and they're announced last. - [ ] **Decorative elements are hidden from assistive tech** - - Mark with `accessibilityElementsHidden` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) — most images aren't truly decorative. + - Mark with `.accessibilityHidden(true)` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) — most images aren't truly decorative. - [ ] **Language of the app is set, and any sections in a different language are identified** - - On native, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). + - On native, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). For implementation details across native frameworks, see [Appt's SC 3.1.2 guidance](https://appt.org/en/guidelines/wcag/success-criterion-3-1-2). ### Annotations that can help - [Mobile Details](../tutorials/mobile-annotations.md#mobile-details) @@ -112,19 +115,20 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Adjacent targets have enough spacing** - Aim for at least 8 pt/dp between tappable elements to prevent mis-taps. - [ ] **Buttons and links are used appropriately** - - Buttons trigger actions. Links navigate. Don't style one as the other. When annotating, consider the action performed when interacting with each element, and ensure that the right role is applied. + - On mobile, the convention differs from the web. Use **buttons** for anything that navigates within your app or triggers a system function (e.g., initiating a phone call, opening a deep link). Reserve **links** for content that opens in the device browser or a web view. When annotating, consider the action performed when interacting with each element, and ensure that the right role is applied. - [ ] **Each button and link has a unique, descriptive name** - Avoid repeated "More", "Open", or "View" labels in lists. Include context (e.g., "Open pull request 142"). - [ ] **Disabled buttons are avoided** - Prefer an inactive style with feedback explaining what's missing, or hide the action until it's available. ### Annotations that can help -[Mobile Button Stamp](../tutorials/mobile-annotations.md#mobile-button-stamp) +- [Mobile Button Stamp](../tutorials/mobile-annotations.md#mobile-button-stamp) +- [View Context Web View Stamp](https://github.com/github/annotation-toolkit/blob/main/tutorials/mobile-annotations.md#web-view) ### Resources - [Getting To The Bottom Of Minimum WCAG-Conformant Interactive Element Size - Smashing Magazine](https://www.smashingmagazine.com/2024/07/getting-bottom-minimum-wcag-conformant-interactive-element-size/) -- [Apple HIG: Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons) +- [Apple HIG: Accessibility (Mobility)](https://developer.apple.com/design/human-interface-guidelines/accessibility#Mobility) - [Material Design: Touch targets](https://m3.material.io/foundations/designing/structure#1da3138c-2b54-4f5b-9c88-dbf6e6b9c12a) --- @@ -140,13 +144,15 @@ The [User Interactions tutorial](../tutorials/user-interactions.md#touch-gesture Use this section to verify each tier is used appropriately. - [ ] **Primary actions use Basic gestures** - - Single tap is the most accessible. Reserve it for the most important interactions on a screen. -- [ ] **Specialized gestures are used sparingly and have a single-point alternative** + - Single tap is the foundational, most accessible touch gesture. Interactive elements assume single tap unless otherwise specified — reach for Specialized or Advanced gestures only when there's a strong reason and an alternative path exists. +- [ ] **Specialized gestures are used sparingly and have a single-tap alternative** - Pinch-to-zoom, swipe-to-delete, swipe-to-reveal-actions, and tap-and-hold all need a button or menu equivalent. Required by [SC 2.5.1 Pointer Gestures](https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html). - [ ] **Advanced gestures are avoided unless essential** - Multi-finger taps, two-finger rotation, and path-based gestures should not be the only way to do something. If they are essential, document the [accessible alternatives](https://tetralogical.com/blog/2023/03/17/foundations-pointer-gestures/#examples-of-accessible-alternatives). - [ ] **Drag-and-drop has a non-dragging alternative** - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html). Reorder lists with up/down buttons, move items with a menu, etc. +- [ ] **Custom components support the VoiceOver scrub gesture (iOS)** + - On iOS, the two-finger scrub gesture (sometimes called the Z-shape gesture) acts as a back/dismiss for VoiceOver users — it can navigate backward, dismiss modals, and collapse custom components. Stock components handle this automatically. If you're building custom components that should be dismissable or collapsible, wire up scrub support manually. - [ ] **Custom gestures are exposed as VoiceOver and TalkBack Custom Actions** - So screen reader users can discover and trigger them without performing the gesture. - [ ] **Animations and transitions respect [Reduce Motion](https://support.apple.com/guide/iphone/customize-onscreen-motion-iph0b691d3ed/ios)** @@ -193,7 +199,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Errors are announced, indicated with text, and tied to the field** - Identify what went wrong using text, not just color or an icon. - When the fix is determinable, also suggest how to correct it (e.g., "Email must include @"). Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). - - Use live regions or accessibility focus so screen reader users hear errors when they're announced. + - Use live accessibility announcements or accessibility focus so screen reader users hear errors when they're announced. - [ ] **Legal, financial, or test submissions can be reviewed, corrected, or reversed** - Per [SC 3.3.4 Error Prevention (Legal, Financial, Data)](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html). @@ -221,12 +227,12 @@ Mobile users rely heavily on system-level settings to make their device usable. - Bluetooth keyboards, [iOS Switch Control](https://support.apple.com/en-us/119835), and [Android Switch Access](https://support.google.com/accessibility/android/answer/6122836) all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). -- [ ] **Focus order is annotated and matches the visual flow** - - Avoid focus that jumps back and forth across the screen. +- [ ] **Focus order is annotated for complex layouts when needed** + - For most simple, top-to-bottom screens, the default focus order works fine and shouldn't be overridden. When a layout is complex (cards with multiple actions, side-by-side groups, custom controls), annotate the intended focus order so engineering knows where overrides are needed. Avoid prescribing focus order on screens where it isn't necessary. - [ ] **There are no focus traps** - Modals, sheets, and overlays must let users dismiss and return focus to a logical place. Per [SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html). - [ ] **Custom controls expose proper accessibility actions** - - A custom slider should respond to increment/decrement actions, not just drag. + - For example, a custom slider should respond to increment/decrement actions, not just drag. - [ ] **Keyboard shortcuts don't override platform or assistive tech shortcuts** - Check against VoiceOver, TalkBack, Switch Control, and Voice Control shortcut tables before claiming a key combo. See the [Keyboard shortcut annotation guidance](../tutorials/user-interactions.md#keyboard-shortcut). - [ ] **No single-character shortcuts are introduced for new features** @@ -260,11 +266,11 @@ Mobile users rely heavily on system-level settings to make their device usable. The [Platform function annotations](../tutorials/user-interactions.md#platform-function) flag built-in behaviors that can disorient users if they're not designed carefully. - [ ] **Loading states have clear visual and programmatic feedback** - - Use a live region announcement, not just a spinner. See [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement). Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). + - Use live accessibility announcements, not just a spinner. Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). - [ ] **Automatic transitions are avoided or controllable** - System-initiated screen, state, or content changes should be paused, slowed, or dismissible. Common offenders: onboarding carousels, auto-advancing tutorials. Per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). - [ ] **Opening external content is announced** - - "Opens in Safari", "Opens in browser", or "Opens in a new window" warnings prevent disorientation, especially when leaving an app for a web view. + - "Opens in browser" or "Opens in a new window" warnings prevent disorientation, especially when leaving an app for a web view. - [ ] **Time limits can be turned off, adjusted, or extended** - Exceptions: real-time events (auctions, live games) or time limits beyond 20 hours. Per [SC 2.2.1 Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html). - [ ] **Cognitive function tests have an accessible alternative** @@ -272,13 +278,13 @@ The [Platform function annotations](../tutorials/user-interactions.md#platform-f ### Annotations that can help - [Platform function (User Interactions)](../tutorials/user-interactions.md#platform-function): Loading, Automatic transition, Open in new tab, Time limit, Cognitive puzzle -- [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement) +- [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement): The Figma component helps annotate live accessibility announcements and is named 'Mobile Live Region Announcement' for cross-platform familiarity. --- ## 13. Notifications and live updates -- [ ] **Status changes are announced via Live Regions** +- [ ] **Status changes are announced via live accessibility announcements** - Search results, form validation, toast notifications, and async updates need an accessibility announcement so screen reader users don't miss them. Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). - [ ] **`polite` vs `assertive` is chosen intentionally** - Use `assertive` only for critical info (errors, blocking states). Default to `polite`. From ad82955f4a21f79d2872941687c8ff9ebc2e0ba0 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 13:53:46 -0700 Subject: [PATCH 09/17] Enhance mobile checklist with exercises and error handling Added exercises for evaluating design element necessity and clarified error handling in forms. --- checklists/mobile-checklist.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 1ec0bd1..25f73af 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -38,6 +38,9 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu - [Web Color Contrast Checker - WebAIM](https://webaim.org/resources/contrastchecker/) - [Colour Contrast Analyzer for Mac and Windows - Vispero](https://vispero.com/lp/color-contrast-checker/) +### Exercises +Quick gut-check: remove the element in question from the design. If the rest still makes sense and is usable without it, the element may not need to meet contrast requirements. + --- ## 2. Hierarchy @@ -78,6 +81,12 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - iOS uses traits (button, header, adjustable, selected). Android uses roles and state descriptions. Annotate both if you ship to both. - [ ] **Hints are used only for non-obvious interactions** - Don't put critical info in hints. Users can disable them, and they're announced last. +- [ ] **Directionality is not used in content** + - Avoid wording like "see below" or "to the left/right" — content positions shift across orientations, screen sizes, and reading order. Use "first/last" or "previous/next" instead. +- [ ] **Truncation is only used when unavoidable** + - Truncated text hides information and can break for users at larger Dynamic Type sizes. Prefer reflowing, wrapping, or progressive disclosure (expand/collapse) over truncation. When truncation is unavoidable, ensure the full content is reachable some other way. +- [ ] **Content is written in plain language** + - Aim for an 8th-grade reading level. Explain abbreviations on first use. Avoid complex metaphors, regional phrases, idioms, and jargon. This helps people with cognitive disabilities, non-native speakers, and anyone reading on a small screen in a distracted context. - [ ] **Decorative elements are hidden from assistive tech** - Mark with `.accessibilityHidden(true)` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) — most images aren't truly decorative. - [ ] **Language of the app is set, and any sections in a different language are identified** @@ -198,6 +207,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - iOS `textContentType`, Android `autofillHints`. Helps password managers and reduces redundant entry per [SC 3.3.7 Redundant Entry](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html) and [SC 1.3.5 Identify Input Purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). - [ ] **Errors are announced, indicated with text, and tied to the field** - Identify what went wrong using text, not just color or an icon. + - Place inline errors next to or below the field with the error. For form-level errors (e.g., a submission summary), surface them at the top or bottom of the form with line items linking to each affected field. - When the fix is determinable, also suggest how to correct it (e.g., "Email must include @"). Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). - Use live accessibility announcements or accessibility focus so screen reader users hear errors when they're announced. - [ ] **Legal, financial, or test submissions can be reviewed, corrected, or reversed** From eec71c7de7804e990296148334c82cd8582aa10d Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 14:44:23 -0700 Subject: [PATCH 10/17] Revise color exercises section --- checklists/mobile-checklist.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 25f73af..6b2ddc3 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -32,15 +32,15 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu - [ ] **Designs respect user color settings** - Account for high contrast modes, [Smart Invert (iOS)](https://support.apple.com/guide/iphone/change-display-and-text-size-iph3e2e1fb0/ios), and [color correction (Android)](https://support.google.com/accessibility/android/answer/11183305?hl=en-GB&sjid=1525872318388975084-NC#zippy=%2Cuse-colour-correction:~:text=Colour%20correction%20and%20grayscale%20settings%20help%20your%20device%20compensate%20for%20colour%20blindness.%C2%A0). Don't bake essential information into images that get inverted. +### Exercises +Remove the element in question from the design. If the rest still makes sense and is usable without it, the element may not need to meet contrast requirements. + ### Suggested Tools - [Accessibility Scanner - Google](https://support.google.com/accessibility/android/answer/6376570) — Detects color contrast issues on Android, among other accessibility checks - [Check color contrast - Figma Docs](https://help.figma.com/hc/en-us/articles/360041003774-Apply-paints-with-the-color-picker#h_01JQF1T71AC72G6VDXN27B77V0) - [Web Color Contrast Checker - WebAIM](https://webaim.org/resources/contrastchecker/) - [Colour Contrast Analyzer for Mac and Windows - Vispero](https://vispero.com/lp/color-contrast-checker/) -### Exercises -Quick gut-check: remove the element in question from the design. If the rest still makes sense and is usable without it, the element may not need to meet contrast requirements. - --- ## 2. Hierarchy From 26eea9973fa8784f156b1c3ee6d0b7ca18fd3669 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 15:53:07 -0700 Subject: [PATCH 11/17] Apply suggestions from code review, trim redundant wording --- checklists/mobile-checklist.md | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 6b2ddc3..379fa18 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -2,7 +2,9 @@ This checklist summarizes accessibility considerations specific to iOS and Android, drawing from [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), the [W3C Guidance on Applying WCAG 2.2 to Mobile Applications](https://www.w3.org/TR/wcag2mobile-22/), and best practices identified by GitHub. -Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. +Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. + +Across both platforms, the underlying user needs are the same: people must be able to perceive, operate, and understand the experience equivalently, even when the patterns and conventions differ. Differences in *how* something is implemented across iOS and Android are expected and fine. Differences in *whether* a user can access information, complete a task, or form an understanding are not. The one exception: if part of your app uses a **web view**, apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. Examples of web view content are an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content. @@ -54,7 +56,7 @@ Remove the element in question from the design. If the rest still makes sense an - [ ] **Layouts favor a simple, predictable flow** - On some frameworks like React Native, the operating system determines reading order by scanning the screen roughly top-to-bottom, left-to-right, and there's no API to override it. Designs that follow a clear vertical flow narrate correctly regardless of framework, and they're easier for everyone to scan visually too. - [ ] **Reading order matches visual order** - - Screen readers narrate in view-tree order. Walk the screen with the [VoiceOver](https://support.apple.com/guide/iphone/turn-on-and-practice-voiceover-iph3e2e415f/ios) rotor (iOS) and TalkBack swipe gestures (Android) to confirm that headings, links, form controls, and landmarks surface in the right order. This is especially important on cards, carousels, and bottom sheets. + - Screen readers narrate in view-tree order. Walk the screen with the [VoiceOver](https://support.apple.com/guide/iphone/turn-on-and-practice-voiceover-iph3e2e415f/ios) rotor (iOS) and TalkBack swipe gestures (Android) to confirm that headings, links, and form controls surface in the right order. This is especially important on cards, carousels, and bottom sheets. - [ ] **Grouping is annotated** - Use a Mobile Grouping Stamp to mark elements that should be announced as one unit (avatar + name + timestamp on a comment, for example). This includes any content block that should read as a single unit rather than several separate stops. @@ -73,7 +75,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Every interactive element has a Label** - Labels help people understand the purpose of a control. They're useful for everyone and especially important for people with cognitive disabilities. - For [Voice Control](https://support.apple.com/guide/iphone/use-voice-control-iph2c21a3c88/ios) and [Voice Access](https://support.google.com/accessibility/android/answer/6151848) users, the visible label text must be programmatically associated with the control so users can speak the name they see. Per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html). - - On iOS, you can also define alternate `.accessibilityInputLabels` so Voice Control users can activate a control with multiple spoken names. For example, a trash icon button labeled "Delete" could also accept "trash" or "garbage". This is especially valuable when a control's primary accessibility label is long or technical. + - On iOS, alternate .accessibilityInputLabels let Voice Control users activate a control with multiple spoken names. For example, a trash icon labeled "Delete" could also accept "trash" or "garbage" — useful when the primary label is long or technical. - For elements without visible text (icon-only buttons, avatars, etc.), be explicit in your annotations about which label belongs to which control. - [ ] **Stateful controls have a Value** - Toggles, sliders, segmented controls, and inputs need a current value (e.g., "On", "75%", "@octocat"). @@ -84,7 +86,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Directionality is not used in content** - Avoid wording like "see below" or "to the left/right" — content positions shift across orientations, screen sizes, and reading order. Use "first/last" or "previous/next" instead. - [ ] **Truncation is only used when unavoidable** - - Truncated text hides information and can break for users at larger Dynamic Type sizes. Prefer reflowing, wrapping, or progressive disclosure (expand/collapse) over truncation. When truncation is unavoidable, ensure the full content is reachable some other way. + - Truncated text hides information and can break when text is scaled up. Prefer reflowing, wrapping, or progressive disclosure (expand/collapse) over truncation. When truncation is unavoidable, ensure the full content is reachable some other way. - [ ] **Content is written in plain language** - Aim for an 8th-grade reading level. Explain abbreviations on first use. Avoid complex metaphors, regional phrases, idioms, and jargon. This helps people with cognitive disabilities, non-native speakers, and anyone reading on a small screen in a distracted context. - [ ] **Decorative elements are hidden from assistive tech** @@ -161,9 +163,9 @@ Use this section to verify each tier is used appropriately. - [ ] **Drag-and-drop has a non-dragging alternative** - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html). Reorder lists with up/down buttons, move items with a menu, etc. - [ ] **Custom components support the VoiceOver scrub gesture (iOS)** - - On iOS, the two-finger scrub gesture (sometimes called the Z-shape gesture) acts as a back/dismiss for VoiceOver users — it can navigate backward, dismiss modals, and collapse custom components. Stock components handle this automatically. If you're building custom components that should be dismissable or collapsible, wire up scrub support manually. -- [ ] **Custom gestures are exposed as VoiceOver and TalkBack Custom Actions** - - So screen reader users can discover and trigger them without performing the gesture. + - On iOS, the two-finger scrub (Z-shape) gesture acts as a back/dismiss for VoiceOver users — it can navigate backward, dismiss modals, and collapse components. Stock components handle this automatically. Custom components that should be dismissible or collapsible need scrub support wired up manually. +- [ ] **Custom Actions are also exposed to other accessibility services** + - Alternatives to gestures are needed by users of speech recognition (Voice Control / Voice Access), Switch Control / Switch Access, and external keyboard navigation, not just screen reader users. - [ ] **Animations and transitions respect [Reduce Motion](https://support.apple.com/guide/iphone/customize-onscreen-motion-iph0b691d3ed/ios)** - Honor `UIAccessibility.isReduceMotionEnabled` (iOS) and `Settings.Global.TRANSITION_ANIMATION_SCALE` (Android). Replace large motion with cross-fades or instant transitions. - [ ] **Pointer cancellation is supported** @@ -188,7 +190,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Reduce Motion is honored** - Annotate any motion-heavy transition with the Reduced motion device setting so engineering knows to gate it. - [ ] **Voice Control labels match visible text** - - Voice Control on iOS and Voice Access on Android let users speak the name of a control. The visible text and the programmatic accessibility label must match — if they're visually similar but programmatically different (or vice versa), voice users can't activate the control. + - Voice Control (iOS) and Voice Access (Android) let users speak the name of a control. The visible text and programmatic label must match — if they don't, voice users have to fall back on workarounds. On iOS, alternate .accessibilityInputLabels can serve voice control users when a single label can't do both jobs. - [ ] **Functionality does not require device motion to operate** - Shake-to-undo, tilt-to-scroll, and similar interactions need a button equivalent and should be possible to disable. Per [SC 2.5.4 Motion Actuation](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html). @@ -207,7 +209,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - iOS `textContentType`, Android `autofillHints`. Helps password managers and reduces redundant entry per [SC 3.3.7 Redundant Entry](https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html) and [SC 1.3.5 Identify Input Purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html). - [ ] **Errors are announced, indicated with text, and tied to the field** - Identify what went wrong using text, not just color or an icon. - - Place inline errors next to or below the field with the error. For form-level errors (e.g., a submission summary), surface them at the top or bottom of the form with line items linking to each affected field. + - Place inline errors next to or below the field with the error. For form-level errors (e.g., a submission summary), surface them at the top or bottom of the form. - When the fix is determinable, also suggest how to correct it (e.g., "Email must include @"). Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). - Use live accessibility announcements or accessibility focus so screen reader users hear errors when they're announced. - [ ] **Legal, financial, or test submissions can be reviewed, corrected, or reversed** @@ -238,7 +240,8 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). - [ ] **Focus order is annotated for complex layouts when needed** - - For most simple, top-to-bottom screens, the default focus order works fine and shouldn't be overridden. When a layout is complex (cards with multiple actions, side-by-side groups, custom controls), annotate the intended focus order so engineering knows where overrides are needed. Avoid prescribing focus order on screens where it isn't necessary. + - Default focus order works fine for simple, top-to-bottom screens — don't override it. Avoid prescribing focus order on screens where it isn't necessary. + - For complex layouts (cards with multiple actions, side-by-side groups, custom controls), annotate the intended focus order so engineering knows where overrides are needed. - [ ] **There are no focus traps** - Modals, sheets, and overlays must let users dismiss and return focus to a logical place. Per [SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html). - [ ] **Custom controls expose proper accessibility actions** @@ -252,6 +255,9 @@ Mobile users rely heavily on system-level settings to make their device usable. - [Ordering](https://gh.io/annotation-tutorial-ordering) (Focus Order, Arrow Stop) - [Keyboard shortcut (User Interactions)](../tutorials/user-interactions.md#keyboard-shortcut) +### Resources +[Mobile keyboard navigation and testing - Workday Accessibility](https://github.com/workday-accessibility/accessibility-eval/blob/main/keyboard.md) + --- ## 11. Platform parity @@ -280,11 +286,11 @@ The [Platform function annotations](../tutorials/user-interactions.md#platform-f - [ ] **Automatic transitions are avoided or controllable** - System-initiated screen, state, or content changes should be paused, slowed, or dismissible. Common offenders: onboarding carousels, auto-advancing tutorials. Per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). - [ ] **Opening external content is announced** - - "Opens in browser" or "Opens in a new window" warnings prevent disorientation, especially when leaving an app for a web view. + - "Opens in browser" or "Opens in a new window" warnings prevent disorientation, especially when leaving the app for the device browser. - [ ] **Time limits can be turned off, adjusted, or extended** - Exceptions: real-time events (auctions, live games) or time limits beyond 20 hours. Per [SC 2.2.1 Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html). - [ ] **Cognitive function tests have an accessible alternative** - - CAPTCHA puzzles, math challenges, and memory checks need an alternate path. Per [SC 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html). Note: passwords used to unlock the underlying platform (device passcode, biometric unlock) are out of scope for this requirement at the app level. + - CAPTCHA puzzles, math challenges, and memory checks need an alternate path. Per [SC 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html). Device-level passcodes and biometric unlocks are out of scope for this requirement. ### Annotations that can help - [Platform function (User Interactions)](../tutorials/user-interactions.md#platform-function): Loading, Automatic transition, Open in new tab, Time limit, Cognitive puzzle From fe8368492e3b0b75567a0a2966ea8aad37d3a3af Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 15:55:33 -0700 Subject: [PATCH 12/17] Fix typo --- checklists/mobile-checklist.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 379fa18..15ba62a 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -4,7 +4,7 @@ This checklist summarizes accessibility considerations specific to iOS and Andro Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. -Across both platforms, the underlying user needs are the same: people must be able to perceive, operate, and understand the experience equivalently, even when the patterns and conventions differ. Differences in *how* something is implemented across iOS and Android are expected and fine. Differences in *whether* a user can access information, complete a task, or form an understanding are not. +Across both platforms, the underlying fuser needs are the same: people must be able to perceive, operate, and understand the experience equivalently, even when the patterns and conventions differ. Differences in *how* something is implemented across iOS and Android are expected and fine. Differences in *whether* a user can access information, complete a task, or form an understanding are not. The one exception: if part of your app uses a **web view**, apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. Examples of web view content are an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content. @@ -105,7 +105,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Functional images and icon-only buttons have an accessible label** - Decorative images should be hidden from screen readers, not given empty labels that still get focused. - [ ] **Important text is not baked into images** - - It can't be translated, scaled with Dynamic Type, or copied. + - It can't be translated, scaled up, or copied. - [ ] **Video and audio include captions, transcripts, or audio descriptions where applicable** - [ ] **Auto-playing or scrolling content can be paused, stopped, or hidden** - Includes auto-advancing carousels, looping animations, and live previews. From 300a7607fd652f644b97db7b3fe2509d4e2c7545 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 16:31:19 -0700 Subject: [PATCH 13/17] Revise introduction and fix typo --- checklists/mobile-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 15ba62a..401b6db 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -4,7 +4,7 @@ This checklist summarizes accessibility considerations specific to iOS and Andro Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. -Across both platforms, the underlying fuser needs are the same: people must be able to perceive, operate, and understand the experience equivalently, even when the patterns and conventions differ. Differences in *how* something is implemented across iOS and Android are expected and fine. Differences in *whether* a user can access information, complete a task, or form an understanding are not. +Web and native mobile look different, but they're chasing the same goal: people must be able to perceive, operate, and understand the experience regardless of platform. The patterns, APIs, and conventions diverge, but the underlying user needs don't. This checklist focuses on how that goal gets met on native — where stock controls, system settings, and gesture conventions do a lot of the work that markup and ARIA do on the web. The one exception: if part of your app uses a **web view**, apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. Examples of web view content are an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content. From bcbaf74b1b69a1d71ec6800ff287bc57df91cdd3 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 18:26:35 -0700 Subject: [PATCH 14/17] Refine title guidance grammar Clarified the explanation of screen titles and their application in mobile accessibility. --- checklists/mobile-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 401b6db..1885338 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -48,7 +48,7 @@ Remove the element in question from the design. If the rest still makes sense an ## 2. Hierarchy - [ ] **Each screen has at most one Title** - - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. Note: in WCAG terms, [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) applies to the application as a whole on native, but the per-screen title is still the right pattern for orientation. + - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) technically applies to the whole app, but per-screen titles are still the right pattern for orientation. - [ ] **If a screen has no title bar, include a prominent heading near the top of the content** - Screens without a top app bar (Android) or navigation bar (iOS) should still orient users — a clear, prominent heading at or near the top of the visible content gives screen reader users and everyone else a place to land. - [ ] **Headings are used sparingly and only when they help structure the screen** From 93998856b32141d944b5e8da26cf9657320847c3 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Wed, 6 May 2026 19:10:46 -0700 Subject: [PATCH 15/17] Refine grammar and punctuation --- checklists/mobile-checklist.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 1885338..4d75831 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -4,7 +4,7 @@ This checklist summarizes accessibility considerations specific to iOS and Andro Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. -Web and native mobile look different, but they're chasing the same goal: people must be able to perceive, operate, and understand the experience regardless of platform. The patterns, APIs, and conventions diverge, but the underlying user needs don't. This checklist focuses on how that goal gets met on native — where stock controls, system settings, and gesture conventions do a lot of the work that markup and ARIA do on the web. +Web and native mobile look different, but they're chasing the same goal: people must be able to perceive, operate, and understand the experience regardless of platform. The patterns, APIs, and conventions diverge, but the underlying user needs don't. This checklist focuses on how that goal is met in native apps where stock controls, system settings, and gesture conventions do a lot of the work that markup and ARIA do on the web. The one exception: if part of your app uses a **web view**, apply the web checklists to that content. Flag those areas with a [View Context Stamp](../tutorials/mobile-annotations.md#view-context-stamps-and-details) so the handoff is explicit. Examples of web view content are an in-app browser, an OAuth flow, embedded docs, or any HTML-rendered content. @@ -38,7 +38,7 @@ For audit work, refer to the [Mobile-WCAG Mapping (Internal only)](https://githu Remove the element in question from the design. If the rest still makes sense and is usable without it, the element may not need to meet contrast requirements. ### Suggested Tools -- [Accessibility Scanner - Google](https://support.google.com/accessibility/android/answer/6376570) — Detects color contrast issues on Android, among other accessibility checks +- [Accessibility Scanner - Google](https://support.google.com/accessibility/android/answer/6376570) - [Check color contrast - Figma Docs](https://help.figma.com/hc/en-us/articles/360041003774-Apply-paints-with-the-color-picker#h_01JQF1T71AC72G6VDXN27B77V0) - [Web Color Contrast Checker - WebAIM](https://webaim.org/resources/contrastchecker/) - [Colour Contrast Analyzer for Mac and Windows - Vispero](https://vispero.com/lp/color-contrast-checker/) @@ -50,7 +50,7 @@ Remove the element in question from the design. If the rest still makes sense an - [ ] **Each screen has at most one Title** - Not every screen needs a title, but if one is needed, only one is used. Titles live in the top app bar (Android) or navigation bar (iOS) and are announced on view transition. [SC 2.4.2 Page Titled](https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) technically applies to the whole app, but per-screen titles are still the right pattern for orientation. - [ ] **If a screen has no title bar, include a prominent heading near the top of the content** - - Screens without a top app bar (Android) or navigation bar (iOS) should still orient users — a clear, prominent heading at or near the top of the visible content gives screen reader users and everyone else a place to land. + - Screens without a top app bar (Android) or navigation bar (iOS) should still orient users. A clear, prominent heading at or near the top of the visible content gives screen reader users and everyone else a place to land. - [ ] **Headings are used sparingly and only when they help structure the screen** - Unlike the web, mobile screens often don't need headings. Use them when content has clear sections that benefit from rotor or [TalkBack](https://support.google.com/accessibility/android/answer/6283677) heading navigation. - [ ] **Layouts favor a simple, predictable flow** @@ -75,7 +75,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Every interactive element has a Label** - Labels help people understand the purpose of a control. They're useful for everyone and especially important for people with cognitive disabilities. - For [Voice Control](https://support.apple.com/guide/iphone/use-voice-control-iph2c21a3c88/ios) and [Voice Access](https://support.google.com/accessibility/android/answer/6151848) users, the visible label text must be programmatically associated with the control so users can speak the name they see. Per [SC 2.5.3 Label in Name](https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html). - - On iOS, alternate .accessibilityInputLabels let Voice Control users activate a control with multiple spoken names. For example, a trash icon labeled "Delete" could also accept "trash" or "garbage" — useful when the primary label is long or technical. + - On iOS, alternate `.accessibilityInputLabels` let Voice Control users activate a control with multiple spoken names. For example, a trash icon labeled "Delete" could also accept "trash" or "garbage". This is useful when the primary label is long or technical. - For elements without visible text (icon-only buttons, avatars, etc.), be explicit in your annotations about which label belongs to which control. - [ ] **Stateful controls have a Value** - Toggles, sliders, segmented controls, and inputs need a current value (e.g., "On", "75%", "@octocat"). @@ -84,15 +84,15 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Hints are used only for non-obvious interactions** - Don't put critical info in hints. Users can disable them, and they're announced last. - [ ] **Directionality is not used in content** - - Avoid wording like "see below" or "to the left/right" — content positions shift across orientations, screen sizes, and reading order. Use "first/last" or "previous/next" instead. + - Avoid wording like "see below" or "to the left/right". Content positions shift across orientations, screen sizes, and reading order. Use "first/last" or "previous/next" instead. - [ ] **Truncation is only used when unavoidable** - Truncated text hides information and can break when text is scaled up. Prefer reflowing, wrapping, or progressive disclosure (expand/collapse) over truncation. When truncation is unavoidable, ensure the full content is reachable some other way. - [ ] **Content is written in plain language** - Aim for an 8th-grade reading level. Explain abbreviations on first use. Avoid complex metaphors, regional phrases, idioms, and jargon. This helps people with cognitive disabilities, non-native speakers, and anyone reading on a small screen in a distracted context. - [ ] **Decorative elements are hidden from assistive tech** - - Mark with `.accessibilityHidden(true)` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) — most images aren't truly decorative. + - Mark with `.accessibilityHidden(true)` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/). Most images aren't truly decorative. - [ ] **Language of the app is set, and any sections in a different language are identified** - - On native, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). For implementation details across native frameworks, see [Appt's SC 3.1.2 guidance](https://appt.org/en/guidelines/wcag/success-criterion-3-1-2). + - In native apps, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). For implementation details across native frameworks, see [Appt's SC 3.1.2 guidance](https://appt.org/en/guidelines/wcag/success-criterion-3-1-2). ### Annotations that can help - [Mobile Details](../tutorials/mobile-annotations.md#mobile-details) @@ -155,7 +155,7 @@ The [User Interactions tutorial](../tutorials/user-interactions.md#touch-gesture Use this section to verify each tier is used appropriately. - [ ] **Primary actions use Basic gestures** - - Single tap is the foundational, most accessible touch gesture. Interactive elements assume single tap unless otherwise specified — reach for Specialized or Advanced gestures only when there's a strong reason and an alternative path exists. + - Single tap is the foundational, most accessible touch gesture. Interactive elements assume single tap unless otherwise specified. Reach for Specialized or Advanced gestures only when there's a strong reason and an alternative path exists. - [ ] **Specialized gestures are used sparingly and have a single-tap alternative** - Pinch-to-zoom, swipe-to-delete, swipe-to-reveal-actions, and tap-and-hold all need a button or menu equivalent. Required by [SC 2.5.1 Pointer Gestures](https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html). - [ ] **Advanced gestures are avoided unless essential** @@ -163,7 +163,7 @@ Use this section to verify each tier is used appropriately. - [ ] **Drag-and-drop has a non-dragging alternative** - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html). Reorder lists with up/down buttons, move items with a menu, etc. - [ ] **Custom components support the VoiceOver scrub gesture (iOS)** - - On iOS, the two-finger scrub (Z-shape) gesture acts as a back/dismiss for VoiceOver users — it can navigate backward, dismiss modals, and collapse components. Stock components handle this automatically. Custom components that should be dismissible or collapsible need scrub support wired up manually. + - On iOS, the two-finger scrub (Z-shape) gesture acts as a back/dismiss for VoiceOver users. It can navigate backward, dismiss modals, and collapse components. Stock components handle this automatically. Custom components that should be dismissible or collapsible need scrub support wired up manually. - [ ] **Custom Actions are also exposed to other accessibility services** - Alternatives to gestures are needed by users of speech recognition (Voice Control / Voice Access), Switch Control / Switch Access, and external keyboard navigation, not just screen reader users. - [ ] **Animations and transitions respect [Reduce Motion](https://support.apple.com/guide/iphone/customize-onscreen-motion-iph0b691d3ed/ios)** @@ -190,7 +190,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Reduce Motion is honored** - Annotate any motion-heavy transition with the Reduced motion device setting so engineering knows to gate it. - [ ] **Voice Control labels match visible text** - - Voice Control (iOS) and Voice Access (Android) let users speak the name of a control. The visible text and programmatic label must match — if they don't, voice users have to fall back on workarounds. On iOS, alternate .accessibilityInputLabels can serve voice control users when a single label can't do both jobs. + - Voice Control (iOS) and Voice Access (Android) let users speak the name of a control. The visible text and programmatic label must match. If they don't, voice users have to fall back on workarounds. On iOS, alternate .accessibilityInputLabels can serve voice control users when a single label can't do both jobs. - [ ] **Functionality does not require device motion to operate** - Shake-to-undo, tilt-to-scroll, and similar interactions need a button equivalent and should be possible to disable. Per [SC 2.5.4 Motion Actuation](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html). @@ -225,11 +225,11 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Layouts adapt across device sizes** - Cover small phones, large phones, foldables, and tablets. Verify safe areas, notches, and home indicators don't obscure content. - [ ] **Content reflows without loss of information or functionality** - - On native, [SC 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) applies through WCAG2ICT guidance: when users resize text via Dynamic Type or font scaling, content should reflow without requiring scrolling in two dimensions for primary content. Tables, image galleries, and similar are reasonable exceptions. + - In native apps, [SC 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) applies through WCAG2ICT guidance: when users resize text via Dynamic Type or font scaling, content should reflow without requiring scrolling in two dimensions for primary content. - [ ] **Persistent UI (nav, help, status) appears in consistent locations across screens** - Per [SC 3.2.3 Consistent Navigation](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) and [SC 3.2.6 Consistent Help](https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html). - [ ] **Web view content (only) supports text spacing overrides** - - [SC 1.4.12 Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) applies only inside a web view on native. For embedded HTML content, verify line height up to 1.5x font size, paragraph spacing up to 2x, letter spacing up to 0.12x, and word spacing up to 0.16x. Native UI is governed by Dynamic Type / font scaling instead (see §7). + - [SC 1.4.12 Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) applies only inside a web view in native apps. For embedded HTML content, verify line height up to 1.5x font size, paragraph spacing up to 2x, letter spacing up to 0.12x, and word spacing up to 0.16x. Native UI is governed by Dynamic Type / font scaling instead (see §7). --- @@ -240,8 +240,8 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). - [ ] **Focus order is annotated for complex layouts when needed** - - Default focus order works fine for simple, top-to-bottom screens — don't override it. Avoid prescribing focus order on screens where it isn't necessary. - - For complex layouts (cards with multiple actions, side-by-side groups, custom controls), annotate the intended focus order so engineering knows where overrides are needed. + - Default focus order works fine for simple, top-to-bottom screens, so don't override it. Avoid prescribing focus order on screens where it isn't necessary. + - For complex layouts (cards with multiple actions, side-by-side groups, custom controls), annotate the intended focus order so engineering knows where overrides are needed. - [ ] **There are no focus traps** - Modals, sheets, and overlays must let users dismiss and return focus to a logical place. Per [SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html). - [ ] **Custom controls expose proper accessibility actions** From 53f3994c809ea132efcf601854516bb3ab50f2a8 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Thu, 7 May 2026 00:42:12 -0700 Subject: [PATCH 16/17] Refine mobile checklist Updated checklist items for clarity and consistency in wording, including links and emphasis on accessibility standards. --- checklists/mobile-checklist.md | 58 ++++++++++++++++++---------------- 1 file changed, 31 insertions(+), 27 deletions(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index 4d75831..aed744f 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -1,6 +1,6 @@ # Mobile Checklist -This checklist summarizes accessibility considerations specific to iOS and Android, drawing from [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), the [W3C Guidance on Applying WCAG 2.2 to Mobile Applications](https://www.w3.org/TR/wcag2mobile-22/), and best practices identified by GitHub. +This checklist summarizes accessibility considerations specific to iOS and Android, drawing from [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), the W3C's guidance on [Applying WCAG 2.2 to Mobile Applications](https://www.w3.org/TR/wcag2mobile-22/), and best practices identified by GitHub. Native mobile has its own set of accessibility patterns, APIs, and user expectations that don't map cleanly to the web. Use this checklist when designing or building **native mobile experiences** on iOS and Android. You don't need to also run through the [Designer Checklist](./designer-checklist.md) or [Engineering Checklist](./engineering-checklist.md) for a native app. @@ -91,12 +91,13 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - Aim for an 8th-grade reading level. Explain abbreviations on first use. Avoid complex metaphors, regional phrases, idioms, and jargon. This helps people with cognitive disabilities, non-native speakers, and anyone reading on a small screen in a distracted context. - [ ] **Decorative elements are hidden from assistive tech** - Mark with `.accessibilityHidden(true)` (iOS) or `importantForAccessibility="no"` (Android). If you're not sure whether something is decorative, walk through the [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/). Most images aren't truly decorative. -- [ ] **Language of the app is set, and any sections in a different language are identified** +- [ ] **App language is set and any sections in a different language are identified** - In native apps, [SC 3.1.1 Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) applies to the application as a whole, not individual screens. For inline text in a different language, identify it programmatically per [SC 3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html). For implementation details across native frameworks, see [Appt's SC 3.1.2 guidance](https://appt.org/en/guidelines/wcag/success-criterion-3-1-2). ### Annotations that can help - [Mobile Details](../tutorials/mobile-annotations.md#mobile-details) - [View Context Stamps and Details](../tutorials/mobile-annotations.md#view-context-stamps-and-details) for web views, user-generated content, and non-native content +- [Language]() --- @@ -104,16 +105,17 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, - [ ] **Functional images and icon-only buttons have an accessible label** - Decorative images should be hidden from screen readers, not given empty labels that still get focused. -- [ ] **Important text is not baked into images** +- [ ] **Important text is not located inside an image** - It can't be translated, scaled up, or copied. -- [ ] **Video and audio include captions, transcripts, or audio descriptions where applicable** +- [ ] **Alternative media is included** + - Video and audio include captions, transcripts, or audio descriptions where applicable. - [ ] **Auto-playing or scrolling content can be paused, stopped, or hidden** - Includes auto-advancing carousels, looping animations, and live previews. - [ ] **Nothing flashes more than 3 times per second** ### Resources -- [Alt Text Guide - GitHub Workplace Accessibility](https://github.com/github/workplace-accessibility/blob/main/resources/content-accessibility/alt-text-guide.md) +- [Alt Text Guide - GitHub Workplace Accessibility (Internal only)](https://github.com/github/workplace-accessibility/blob/main/resources/content-accessibility/alt-text-guide.md) - [W3C alt-text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) --- @@ -121,7 +123,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, ## 5. Interactivity and touch targets - [ ] **Touch targets are at least 44x44 pt (iOS) / 48x48 dp (Android)** - - This meets [WCAG 2.2 SC 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) of 24x24 CSS pixels with healthy margin, and aligns with both platforms' HIG guidance. + - This meets [SC 2.5.8 Target Size](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) of 24x24 CSS pixels with healthy margin, and aligns with both platforms' HIG guidance. - Targets that let users select a value spatially based on position within the target (sliders, color pickers, map pins inside a draggable region) are considered a single target for this SC. - [ ] **Adjacent targets have enough spacing** - Aim for at least 8 pt/dp between tappable elements to prevent mis-taps. @@ -161,7 +163,7 @@ Use this section to verify each tier is used appropriately. - [ ] **Advanced gestures are avoided unless essential** - Multi-finger taps, two-finger rotation, and path-based gestures should not be the only way to do something. If they are essential, document the [accessible alternatives](https://tetralogical.com/blog/2023/03/17/foundations-pointer-gestures/#examples-of-accessible-alternatives). - [ ] **Drag-and-drop has a non-dragging alternative** - - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html). Reorder lists with up/down buttons, move items with a menu, etc. + - Per [SC 2.5.7 Dragging Movements](https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html), reorder lists with up/down buttons, move items with a menu, etc. - [ ] **Custom components support the VoiceOver scrub gesture (iOS)** - On iOS, the two-finger scrub (Z-shape) gesture acts as a back/dismiss for VoiceOver users. It can navigate backward, dismiss modals, and collapse components. Stock components handle this automatically. Custom components that should be dismissible or collapsible need scrub support wired up manually. - [ ] **Custom Actions are also exposed to other accessibility services** @@ -172,8 +174,10 @@ Use this section to verify each tier is used appropriately. - Per [SC 2.5.2 Pointer Cancellation](https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation.html), trigger actions on the up-event so users can drag off a control to cancel. ### Annotations that can help -- [Touch gesture (User Interactions)](../tutorials/user-interactions.md#touch-gesture) -- [User Interactions tutorial](https://gh.io/annotation-tutorial-user-interactions) +[User Interactions (Touch gesture)](../tutorials/user-interactions.md#touch-gesture) + +### Resources +[User Interactions tutorial](https://gh.io/annotation-tutorial-user-interactions) --- @@ -182,7 +186,7 @@ Use this section to verify each tier is used appropriately. Mobile users rely heavily on system-level settings to make their device usable. The [Device setting annotations](../tutorials/user-interactions.md#device-setting) cover the most common ones. Designs need to respect these settings, not fight them. - [ ] **Both portrait and landscape orientations are supported** - - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's essential (e.g., a piano app). Many users mount their device in a fixed orientation for accessibility reasons. _All functionality and content must remain available across orientations._ + - Per [SC 1.3.4 Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html), don't lock orientation unless it's _essential_. Many users mount their device in a fixed orientation for accessibility reasons. _All functionality and content must remain available across orientations._ - [ ] **Layouts adapt to [iOS' Dynamic Type](https://developer.apple.com/documentation/uikit/scaling-fonts-automatically) and [Android's Font Size Scaling](https://support.google.com/accessibility/android/answer/11183305)** - Test at the largest accessibility text sizes per [SC 1.4.4 Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html). Content should reflow without truncation or overlap. - [ ] **Viewport zoom and viewport resize don't break the layout** @@ -192,10 +196,10 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Voice Control labels match visible text** - Voice Control (iOS) and Voice Access (Android) let users speak the name of a control. The visible text and programmatic label must match. If they don't, voice users have to fall back on workarounds. On iOS, alternate .accessibilityInputLabels can serve voice control users when a single label can't do both jobs. - [ ] **Functionality does not require device motion to operate** - - Shake-to-undo, tilt-to-scroll, and similar interactions need a button equivalent and should be possible to disable. Per [SC 2.5.4 Motion Actuation](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html). + - Shake-to-undo, tilt-to-scroll, and similar interactions need a button equivalent and should be possible to disable per [SC 2.5.4 Motion Actuation](https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html). ### Annotations that can help -[Device setting (User Interactions)](../tutorials/user-interactions.md#device-setting): Reduced motion, Viewport zoom, Voice input, Viewport resize, Orientation, Shake device +[User Interactions (Device setting)](../tutorials/user-interactions.md#device-setting) --- @@ -210,7 +214,7 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Errors are announced, indicated with text, and tied to the field** - Identify what went wrong using text, not just color or an icon. - Place inline errors next to or below the field with the error. For form-level errors (e.g., a submission summary), surface them at the top or bottom of the form. - - When the fix is determinable, also suggest how to correct it (e.g., "Email must include @"). Per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). + - When the fix is determinable, also suggest how to correct it (e.g., "Email must include @"), per [SC 3.3.1 Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html) and [SC 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html). - Use live accessibility announcements or accessibility focus so screen reader users hear errors when they're announced. - [ ] **Legal, financial, or test submissions can be reviewed, corrected, or reversed** - Per [SC 3.3.4 Error Prevention (Legal, Financial, Data)](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html). @@ -226,10 +230,10 @@ Mobile users rely heavily on system-level settings to make their device usable. - Cover small phones, large phones, foldables, and tablets. Verify safe areas, notches, and home indicators don't obscure content. - [ ] **Content reflows without loss of information or functionality** - In native apps, [SC 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) applies through WCAG2ICT guidance: when users resize text via Dynamic Type or font scaling, content should reflow without requiring scrolling in two dimensions for primary content. -- [ ] **Persistent UI (nav, help, status) appears in consistent locations across screens** - - Per [SC 3.2.3 Consistent Navigation](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) and [SC 3.2.6 Consistent Help](https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html). +- [ ] **Persistent UI appears in consistent locations across screens** + - Applies to things like navigation, help, status, etc. Per [SC 3.2.3 Consistent Navigation](https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html) and [SC 3.2.6 Consistent Help](https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html). - [ ] **Web view content (only) supports text spacing overrides** - - [SC 1.4.12 Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) applies only inside a web view in native apps. For embedded HTML content, verify line height up to 1.5x font size, paragraph spacing up to 2x, letter spacing up to 0.12x, and word spacing up to 0.16x. Native UI is governed by Dynamic Type / font scaling instead (see §7). + - [SC 1.4.12 Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) applies only inside a web view in native apps. For embedded HTML content, verify line height up to 1.5x font size, paragraph spacing up to 2x, letter spacing up to 0.12x, and word spacing up to 0.16x. Native UI is governed by Dynamic Type / font scaling instead. --- @@ -238,22 +242,22 @@ Mobile users rely heavily on system-level settings to make their device usable. - [ ] **Every touch interaction is reachable and operable with an external keyboard** - Bluetooth keyboards, [iOS Switch Control](https://support.apple.com/en-us/119835), and [Android Switch Access](https://support.google.com/accessibility/android/answer/6122836) all rely on a sensible focus order. Per [SC 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html), the keyboard interface here means any keyboard or keyboard substitute, not just a physical device. - [ ] **A visible focus indicator appears when navigating with a keyboard or switch** - - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). + - Per [SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) and [SC 2.4.11 Focus Not Obscured](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html). - [ ] **Focus order is annotated for complex layouts when needed** - Default focus order works fine for simple, top-to-bottom screens, so don't override it. Avoid prescribing focus order on screens where it isn't necessary. - For complex layouts (cards with multiple actions, side-by-side groups, custom controls), annotate the intended focus order so engineering knows where overrides are needed. - [ ] **There are no focus traps** - - Modals, sheets, and overlays must let users dismiss and return focus to a logical place. Per [SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html). + - Modals, sheets, and overlays must let users dismiss and return focus to a logical place, per [SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html). - [ ] **Custom controls expose proper accessibility actions** - For example, a custom slider should respond to increment/decrement actions, not just drag. - [ ] **Keyboard shortcuts don't override platform or assistive tech shortcuts** - Check against VoiceOver, TalkBack, Switch Control, and Voice Control shortcut tables before claiming a key combo. See the [Keyboard shortcut annotation guidance](../tutorials/user-interactions.md#keyboard-shortcut). - [ ] **No single-character shortcuts are introduced for new features** - - Per [SC 2.1.4 Character Key Shortcuts](https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html). If you must, allow users to remap or disable them. Note: long-press gestures and platform-provided accessibility features don't meet WCAG's definition of a keyboard shortcut, so they're not in scope here. + - Per [SC 2.1.4 Character Key Shortcuts](https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html), if you must, allow users to remap or disable them. **Note:** long-press gestures and platform-provided accessibility features _do not_ meet WCAG's definition of a keyboard shortcut. ### Annotations that can help - [Ordering](https://gh.io/annotation-tutorial-ordering) (Focus Order, Arrow Stop) -- [Keyboard shortcut (User Interactions)](../tutorials/user-interactions.md#keyboard-shortcut) +- [User Interactions (Keyboard shortcut)](../tutorials/user-interactions.md#keyboard-shortcut) ### Resources [Mobile keyboard navigation and testing - Workday Accessibility](https://github.com/workday-accessibility/accessibility-eval/blob/main/keyboard.md) @@ -282,18 +286,18 @@ Mobile users rely heavily on system-level settings to make their device usable. The [Platform function annotations](../tutorials/user-interactions.md#platform-function) flag built-in behaviors that can disorient users if they're not designed carefully. - [ ] **Loading states have clear visual and programmatic feedback** - - Use live accessibility announcements, not just a spinner. Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). + - Use live accessibility announcements and not just a spinner, per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). - [ ] **Automatic transitions are avoided or controllable** - - System-initiated screen, state, or content changes should be paused, slowed, or dismissible. Common offenders: onboarding carousels, auto-advancing tutorials. Per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). + - System-initiated screen, state, or content changes should be paused, slowed, or dismissible. Common offenders: onboarding carousels, auto-advancing tutorials, per [SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html) and [SC 3.2.2 On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html). - [ ] **Opening external content is announced** - "Opens in browser" or "Opens in a new window" warnings prevent disorientation, especially when leaving the app for the device browser. - [ ] **Time limits can be turned off, adjusted, or extended** - - Exceptions: real-time events (auctions, live games) or time limits beyond 20 hours. Per [SC 2.2.1 Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html). + - Exceptions: real-time events (auctions, live games) or time limits beyond 20 hours, per [SC 2.2.1 Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html). - [ ] **Cognitive function tests have an accessible alternative** - - CAPTCHA puzzles, math challenges, and memory checks need an alternate path. Per [SC 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html). Device-level passcodes and biometric unlocks are out of scope for this requirement. + - CAPTCHA puzzles, math challenges, and memory checks need an alternate path, per [SC 3.3.8 Accessible Authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html). Device-level passcodes and biometric unlocks are out of scope for this requirement. ### Annotations that can help -- [Platform function (User Interactions)](../tutorials/user-interactions.md#platform-function): Loading, Automatic transition, Open in new tab, Time limit, Cognitive puzzle +- [User Interactions (Platform function)](../tutorials/user-interactions.md#platform-function): Loading, Automatic transition, Open in new tab, Time limit, Cognitive puzzle - [Mobile Live Region Announcement](../tutorials/mobile-annotations.md#mobile-live-region-announcement): The Figma component helps annotate live accessibility announcements and is named 'Mobile Live Region Announcement' for cross-platform familiarity. --- @@ -301,7 +305,7 @@ The [Platform function annotations](../tutorials/user-interactions.md#platform-f ## 13. Notifications and live updates - [ ] **Status changes are announced via live accessibility announcements** - - Search results, form validation, toast notifications, and async updates need an accessibility announcement so screen reader users don't miss them. Per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). + - Search results, form validation, toast notifications, and async updates need an accessibility announcement so screen reader users don't miss them, per [SC 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). - [ ] **`polite` vs `assertive` is chosen intentionally** - Use `assertive` only for critical info (errors, blocking states). Default to `polite`. - [ ] **Off-screen and dynamically appearing content has defined accessibility behavior** @@ -324,7 +328,7 @@ The [Platform function annotations](../tutorials/user-interactions.md#platform-f - [ ] **Tested with Voice Control (iOS) and Voice Access (Android)** - [ ] **Tested with an external keyboard or Switch Control / Switch Access** -### Suggested Tools +### Suggested tools - [Accessibility Inspector - Apple](https://developer.apple.com/documentation/accessibility/accessibility-inspector) - [Accessibility Scanner - Google](https://support.google.com/accessibility/android/answer/6376570) From 75426d9c852fbfcc4ca9007a0a8aedaa7d9a98e9 Mon Sep 17 00:00:00 2001 From: Jan Maarten <83665577+janmaarten-a11y@users.noreply.github.com> Date: Thu, 7 May 2026 11:13:42 -0700 Subject: [PATCH 17/17] Add link to metadata tutorial --- checklists/mobile-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/checklists/mobile-checklist.md b/checklists/mobile-checklist.md index aed744f..796c262 100644 --- a/checklists/mobile-checklist.md +++ b/checklists/mobile-checklist.md @@ -97,7 +97,7 @@ Sketch out the focus order with arrows before annotating. If the line zig-zags, ### Annotations that can help - [Mobile Details](../tutorials/mobile-annotations.md#mobile-details) - [View Context Stamps and Details](../tutorials/mobile-annotations.md#view-context-stamps-and-details) for web views, user-generated content, and non-native content -- [Language]() +- [Metadata (Language)](../tutorials/metadata.md#language) ---