Mobile Patterns that Break (and Make) Accessibility: Bottom Sheets, Gestures, and Infinite Scroll

Mobile accessibility patterns present unique challenges that desktop-focused accessibility thinking doesn't address. Bottom sheets, swipe gestures, infinite scroll, and touch-first interactions dominate mobile UX—yet these patterns frequently exclude users who can't see, can't gesture, or interact differently than designers assumed.

The mobile-first design movement produced beautiful, intuitive interfaces for some users while creating barriers for others. A swipe-to-delete action is elegant until you can't swipe. A bottom sheet smoothly animates into view until VoiceOver users can't find it. Infinite scroll loads content seamlessly until keyboard users can't reach the footer.

Understanding WCAG mobile requirements and implementing accessible mobile UX patterns isn't about limiting creativity—it's about ensuring that innovative mobile interfaces work for everyone.

Mobile UX Patterns Under the Microscope

The Accessibility Gap in Mobile Design

What makes mobile accessibility different? Mobile interfaces rely heavily on gestures, touch targets, and spatial patterns that may exclude users of assistive technologies. Mobile accessibility requires touch target sizing, gesture alternatives, proper focus management for dynamic content, and compatibility with mobile screen readers.

Mobile platforms introduced interaction paradigms that weren't designed with accessibility in mind:

Touch assumption: Interfaces assume users can tap, swipe, pinch, and drag. Users with motor disabilities may not be able to perform these gestures.

Small targets: Mobile screens encourage small touch targets. Users with motor impairments or limited dexterity struggle with precision.

Hidden information: Gestures and hover states hide functionality. Users of assistive technologies may not discover these interactions.

Screen reader differences: Mobile screen readers (VoiceOver, TalkBack) work differently than desktop screen readers. Patterns that work on desktop may fail on mobile.

The Regulatory Landscape

WCAG 2.2 includes criteria specifically addressing mobile challenges:

2.5.1 Pointer Gestures: Functionality using multipoint or path-based gestures must also be operable with single-point gestures.

2.5.2 Pointer Cancellation: Single-point activation can be aborted or reversed.

2.5.5 Target Size (Enhanced): Touch targets at least 44x44 CSS pixels.

2.5.8 Target Size (Minimum): Touch targets at least 24x24 CSS pixels with adequate spacing.

These criteria reflect accessibility community feedback about mobile-specific barriers.

Problematic Mobile Patterns

Bottom Sheets and Modals

Bottom sheets—panels that slide up from the bottom of the screen—are ubiquitous in mobile apps and increasingly in mobile web. They fail accessibility in predictable ways:

Focus management: When a bottom sheet opens, focus should move to it. Often, focus stays on the underlying page, leaving screen reader users unaware the sheet exists.

Focus trapping: Users should be able to navigate within the bottom sheet without focus escaping to content behind it. Many implementations fail this.

Dismissal: Bottom sheets often dismiss on swipe-down gesture only. Users who can't swipe need an explicit close button or Escape key support.

Screen reader announcements: Opening the sheet should be announced. Content changes within should be communicated.

Behind-sheet interactions: When the bottom sheet is open, content behind it should be inert—not focusable or interactive.

// Accessible bottom sheet considerations
function BottomSheet({ isOpen, onClose, children }) {
  const sheetRef = useRef();

  useEffect(() => {
    if (isOpen) {
      // Move focus to sheet
      sheetRef.current?.focus();
      // Make background inert
      document.body.setAttribute('aria-hidden', 'true');
    } else {
      document.body.removeAttribute('aria-hidden');
    }
  }, [isOpen]);

  return (
    <div
      ref={sheetRef}
      role="dialog"
      aria-modal="true"
      aria-label="Options menu"
      tabIndex={-1}
    >
      {/* Close button - doesn't rely on gesture */}
      <button onClick={onClose} aria-label="Close">×</button>
      {children}
    </div>
  );
}

Gesture-Only Controls

How do you make gesture controls accessible? Provide visible button alternatives for all gesture-based actions. If users can swipe to delete, also provide a delete button. Ensure single-tap alternatives exist for complex gestures like pinch-zoom or multi-finger actions.

Gesture-dependent interactions exclude users who can't perform gestures:

Swipe-to-delete: Common in list interfaces. Users with motor impairments may not be able to swipe accurately. Users of switch controls can't swipe at all.

Pull-to-refresh: Requires specific gesture that screen reader users can't perform in the same way.

Pinch-to-zoom: Users who can't perform multi-finger gestures lose zoom functionality.

Hidden menus revealed by swipe: Content that only appears via gesture is invisible to many users.

Drag-and-drop reordering: Requires precise motor control that many users lack.

For every gesture, provide an alternative:

• Swipe-to-delete → Edit mode with delete buttons
• Pull-to-refresh → Refresh button
• Pinch-to-zoom → Zoom controls (+/- buttons)
• Swipe menus → Long-press or button-triggered menus (with keyboard equivalents)
• Drag-and-drop → Move buttons or reorder controls

Infinite Scroll and Endless Feeds

Infinite scroll creates multiple accessibility barriers:

No end point: Users can't reach footer content containing navigation, legal links, or contact information.

Disorientation: Screen reader users lose track of position in long content lists. There's no way to know "I'm 200 items into an infinite list."

Focus loss: When content loads dynamically, focus management becomes complex. Focus may be lost or placed unexpectedly.

Memory consumption: Endless content loading can crash browsers or exhaust device resources—particularly affecting users of older assistive technologies.

No pagination reference: Users can't bookmark, share, or return to specific positions.

Alternatives and mitigations:

• Provide "Load more" buttons instead of automatic loading
• Implement pagination with URL state
• Keep footer accessible (sticky or after reasonable content limit)
• Announce new content loading to screen readers
• Provide "return to top" controls
• Set reasonable limits on loaded content

Redesigning Patterns for Accessibility

Provide Redundant, Discoverable Controls

Every interaction should have multiple paths:

Visible alternatives: If functionality exists via gesture, also show a button or menu option.

Discoverable actions: Don't hide essential functionality behind gestures that users must discover by accident.

Consistent interaction models: Use the same patterns throughout the app. If some lists have swipe-to-delete and others don't, users can't build reliable mental models.

Clear affordances: When gestures are available, indicate them visually—but never as the only way to access functionality.

Focus and State Management

Mobile dynamic content requires careful focus management:

Bottom sheets and modals:

• Move focus on open
• Trap focus within
• Return focus on close
• Make background inert

Content additions:

• Announce new content via aria-live
• Optionally move focus to new content
• Maintain logical reading order

Content removals:

• Move focus to appropriate element before removing focused item
• Announce removal if significant

State changes:

• Announce expanded/collapsed states
• Update aria-expanded attributes
• Ensure visual state matches programmatic state

Touch Target Sizing

WCAG 2.5.8 requires minimum 24x24 CSS pixel targets with spacing, while 2.5.5 recommends 44x44:

/* Minimum touch targets */
.touch-target {
  min-width: 44px;
  min-height: 44px;
  /* Or ensure adequate spacing with smaller targets */
}

/* Ensure spacing between targets */
.button-group .button {
  margin: 8px; /* Provides spacing if buttons are smaller */
}

Small icons should have larger touch areas:

.icon-button {
  /* Visual icon is 24px */
  font-size: 24px;
  /* Touch area is 44px */
  padding: 10px;
  /* Or use explicit dimensions */
  width: 44px;
  height: 44px;
  display: flex;
  align-items: center;
  justify-content: center;
}

Testing Mobile Accessibility Across Devices

Screen Reader Testing on iOS and Android

Mobile screen readers work differently than desktop:

VoiceOver (iOS):

• Swipe gestures navigate between elements
• Double-tap activates
• Rotor provides navigation options
• Test with both iPhone and iPad

TalkBack (Android):

• Similar swipe navigation
• Double-tap to activate
• Local context menu for element actions
• Test across Android versions

Testing checklist:

• [ ] Can navigate to all interactive elements?
• [ ] Are elements announced with correct roles and states?
• [ ] Are dynamic content changes announced?
• [ ] Can activate all controls via AT commands?
• [ ] Is focus management correct for dialogs/sheets?
• [ ] Do custom gestures have AT-accessible alternatives?

Switch Control and Voice Control Testing

Beyond screen readers, test with:

Switch Control (iOS) / Switch Access (Android): Users navigate via external switches. Tests whether all functionality is reachable through sequential focus navigation.

Voice Control (iOS): Users speak commands to interact. Tests whether controls have visible, speakable labels.

Testing reveals: Gesture-only interactions fail switch users. Unlabeled icons fail voice control users.

Automated Scanning of Mobile Web

TestParty scans responsive layouts and mobile web experiences:

Responsive breakpoint scanning: Test accessibility at mobile viewport sizes, catching issues that only appear in responsive layouts.

Touch target analysis: Identify elements that fail minimum target size requirements.

Gesture detection: Flag patterns that may rely on gestures without alternatives.

Dynamic content evaluation: Test how content loads and changes affect accessibility.

How TestParty Bridges Mobile and Web

Scanning Responsive Breakpoints

Desktop-passing sites often fail at mobile sizes:

Viewport-specific issues: Layout changes at breakpoints can introduce accessibility problems—elements overlapping, focus order changing, content hiding.

Touch vs. hover: Desktop hover states may not have mobile equivalents, hiding functionality.

Content parity: Ensure mobile views don't hide content that's accessible on desktop.

TestParty scans at multiple viewport sizes, identifying issues specific to mobile experiences.

Shared Codebase Monitoring

Many organizations share code between web and mobile:

React Native Web / Flutter Web: Single codebase serving multiple platforms means accessibility issues may propagate.

Responsive web: Same HTML/CSS serves desktop and mobile, but accessibility implications differ.

Progressive Web Apps: PWAs behave like mobile apps but are built with web technologies.

TestParty provides visibility across these shared codebases, ensuring fixes in one context apply appropriately to others.

Frequently Asked Questions

Do WCAG requirements apply differently to mobile?

WCAG applies equally to mobile, but certain success criteria are more relevant: 2.5.x criteria address touch/pointer interactions; responsive design implications affect many criteria. Mobile doesn't get different standards—it gets the same standards applied to different interaction patterns.

How do we handle swipe-to-delete accessibly?

Provide a non-gesture alternative. Options include: edit mode that reveals delete buttons, long-press menu with delete option, swipe that reveals button (not direct delete), or visible delete buttons. VoiceOver and TalkBack provide "actions" menus that can include delete—implement using accessibility APIs.

Are bottom sheets inherently inaccessible?

No, but they require careful implementation. Accessible bottom sheets: move focus on open, trap focus within, return focus on close, have explicit close mechanism (not just swipe), announce to screen readers, and make background content inert. Most implementations skip several of these requirements.

How do we test infinite scroll accessibility?

Test with screen reader to verify: content additions are announced, focus is managed appropriately, orientation is maintainable. Test with keyboard to verify: all loaded content is reachable, footer is accessible (or alternative navigation provided). Consider providing pagination option as alternative.

What's the minimum touch target size?

WCAG 2.5.8 (Level AA) requires 24x24 CSS pixels minimum, with adequate spacing from other targets. WCAG 2.5.5 (Level AAA) recommends 44x44 CSS pixels. Apple Human Interface Guidelines recommend 44pt; Google Material Design recommends 48dp. Aim for the larger sizes—users will thank you.

Conclusion – Give Mobile Users Full Control

Mobile accessibility patterns require rethinking desktop assumptions. Touch isn't universal. Gestures exclude many users. Screen real estate constraints don't justify inaccessible shortcuts.

Building accessible mobile interfaces means:

• Gesture alternatives for every swipe, pinch, or drag interaction
• Adequate touch targets meeting at least 24x24px minimum, ideally 44x44px
• Proper focus management for dynamic content like bottom sheets and infinite scroll
• Screen reader compatibility testing with VoiceOver and TalkBack, not assumptions
• Discoverable functionality not hidden behind gestures users may never find
• Consistent patterns users can learn and rely on

The best mobile experiences work for everyone—touch, switch, voice, or screen reader. Patterns that exclude users aren't innovative; they're incomplete.

Want to find risky mobile patterns across your digital properties? Start with a multi-device accessibility scan from TestParty.

Related Articles:

• Carousels, Sliders, and Auto-Playing Nightmares: An Engineer's Guide