Skip to content

Commit 498edf8

Browse files
Apply suggestions from code review
Co-authored-by: Eric Bailey <ericwbailey@users.noreply.github.com>
1 parent 6b40e70 commit 498edf8

1 file changed

Lines changed: 13 additions & 7 deletions

File tree

checklists/mobile-checklist.md

Lines changed: 13 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
# Mobile Checklist
22

3-
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.
3+
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.
44

5-
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.
5+
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.
66

7-
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.
7+
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.
88

99
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).
1010

@@ -55,7 +55,7 @@ For per-interaction annotation guidance, pair this checklist with the [User Inte
5555

5656
### Exercises
5757

58-
- Sketch out the focus order with arrows before annotating. If the line zig-zags, simplify the layout or regroup elements.
58+
Sketch out the focus order with arrows before annotating. If the line zig-zags, simplify the layout or regroup elements.
5959

6060
---
6161

@@ -125,7 +125,13 @@ For per-interaction annotation guidance, pair this checklist with the [User Inte
125125

126126
## 6. Gestures and motion
127127

128-
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.
128+
The [User Interactions tutorial](../tutorials/user-interactions.md#touch-gesture) groups touch gestures into three tiers:
129+
130+
1. **Basic** (single tap, double tap, long press),
131+
2. **Specialized** (swipe, drag, tap-and-hold), and
132+
3. **Advanced** (multi-finger, pinch, rotate, path-based).
133+
134+
Use this section to verify each tier is used appropriately.
129135

130136
- [ ] **Primary actions use Basic gestures**
131137
- 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.
154160

155161
- [ ] **Both portrait and landscape orientations are supported**
156162
- 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.
157-
- [ ] **Layouts adapt to Dynamic Type (iOS) and Font size scaling (Android)**
163+
- [ ] **Layouts adapt to iOS' Dynamic Type and Android's Font Size Scaling**
158164
- 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.
159165
- [ ] **Viewport zoom and viewport resize don't break the layout**
160166
- 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.
204210
## 10. Touch and keyboard navigation
205211

206212
- [ ] **Every touch interaction is reachable with an external keyboard**
207-
- 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.
213+
- 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.
208214
- [ ] **A visible focus indicator appears when navigating with a keyboard or switch**
209215
- 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).
210216
- [ ] **Focus order is annotated and matches the visual flow**

0 commit comments

Comments
 (0)