Mobile Checklist

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.

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 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
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, 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.

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.
• 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").

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.

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 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. Most images aren't truly decorative.

App language is set and any sections in a different language are identified
In native apps, SC 3.1.1 Language of Page 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. For implementation details across native frameworks, see Appt's SC 3.1.2 guidance.

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 located inside an image
It can't be translated, scaled up, or copied.

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.

Touch targets are at least 44x44 pt (iOS) / 48x48 dp (Android)

• This meets SC 2.5.8 Target Size 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
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.

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.

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.

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.

Drag-and-drop has a non-dragging alternative
Per SC 2.5.7 Dragging Movements, 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
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
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, trigger actions on the up-event so users can drag off a control to cancel.

Both portrait and landscape orientations are supported
Per SC 1.3.4 Orientation, 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 and Android's Font Size Scaling
Test at the largest accessibility text sizes per SC 1.4.4 Resize Text. 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. 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.

Inputs have a persistent visible label, not just a placeholder
Per SC 3.3.2 Labels or Instructions.

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 and SC 1.3.5 Identify Input Purpose.

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 and SC 3.3.3 Error Suggestion.
• 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).

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
In native apps, SC 1.4.10 Reflow 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 appears in consistent locations across screens
Applies to things like navigation, help, status, etc. Per SC 3.2.3 Consistent Navigation and SC 3.2.6 Consistent Help.

Web view content (only) supports text spacing overrides
SC 1.4.12 Text Spacing 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.

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, 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 and SC 2.4.11 Focus Not Obscured.

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.

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.

No single-character shortcuts are introduced for new features
Per SC 2.1.4 Character Key Shortcuts, 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.

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 and SC 3.2.3 Consistent Navigation 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 so testers know where annotation handoff happens. For web view content specifically, run it through the Designer and Engineering checklists.

Loading states have clear visual and programmatic feedback
Use live accessibility announcements and not just a spinner, per SC 4.1.3 Status Messages.

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 and SC 3.2.2 On Input.

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.

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. Device-level passcodes and biometric unlocks are out of scope for this requirement.

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.

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.