Mobile Devices

Why this matters

Mobile devices are the primary way many people access the web. Mobile platforms have built-in accessibility features (VoiceOver on iOS, TalkBack on Android) and users may rely on alternative input methods like switch access or voice control. Content that works on desktop but not on mobile excludes a significant portion of your audience.

Overview

VoiceOver is built into iOS, and TalkBack is built into Android. Both platforms offer comprehensive accessibility features. Native mobile app developers should follow platform-specific guidelines. Web content must be responsive and touch-accessible to serve mobile users effectively.

Key Points

• Mobile accessibility is critical given high usage statistics
• Both iOS and Android provide built-in accessibility features
• Web content must be responsive and touch-accessible
• Native apps should follow platform-specific guidelines

Platform Accessibility Resources

Apple

Accessibility for Apple Developers

Apple’s accessibility documentation covers:

• VoiceOver screen reader built into iOS
• Dynamic Type for text resizing and personalization
• Switch Control for motor accessibility
• Color filters and display accommodations

Android

Accessibility for Android Developers

Android’s accessibility resources include:

• TalkBack screen reader
• Font size and display settings
• Switch Access for motor control
• Magnification and color adjustment options

Mobile Web Accessibility

Most web accessibility issues from the Digital Accessibility Checkpoints page apply equally to mobile devices. Mobile-specific considerations include:

Responsive Design

Responsive design ensures content adapts to different screen sizes and orientations. Mobile users interact with smaller viewports, so layout flexibility is essential.

Touch Targets

Touch targets should be at least 44×44 CSS pixels (WCAG 2.5.5 recommendation) to ensure users can accurately activate buttons and links with their fingers.

Hover Interactions

Avoid hover-only interactions that don’t work on touch screens. All functionality available through hover must also be available through other interaction methods.

Forms and Input

Ensure forms are usable with mobile keyboards and autocomplete features. Autocomplete can significantly improve usability for mobile users.

Screen Reader Testing

Test with mobile screen readers (VoiceOver on iOS, TalkBack on Android) to ensure content is properly labeled and navigable.

UGA-Specific Guidance

UGA CMS developers should ensure themes and custom components are tested on both iOS and Android platforms.

Testing Requirements

• Test using VoiceOver on iOS and TalkBack on Android
• Ensure all interactive elements have adequate touch target size
• Test orientation changes – content should work in both portrait and landscape
• Verify text resizing works without loss of functionality
• Check keyboard navigation on Android

Orientation and Motion

Avoid requiring content to be viewed in a specific device orientation. Allow both portrait and landscape viewing.

Testing on Mobile Devices

iOS VoiceOver

Enable VoiceOver:

1. Go to Settings > Accessibility > VoiceOver
2. Tap the toggle to enable VoiceOver

Basic VoiceOver gestures:

• Swipe right to navigate to next element
• Swipe left to navigate to previous element
• Double-tap to activate element
• Two-finger swipe up to scroll down

Android TalkBack

Enable TalkBack:

1. Go to Settings > Accessibility > TalkBack
2. Tap the toggle to enable TalkBack

Basic TalkBack gestures:

• Swipe right to navigate to next element
• Swipe left to navigate to previous element
• Double-tap to activate element
• Two-finger scroll to move through content

Testing Checklist

• Test all interactive elements receive focus
• Verify elements have accessible names and descriptions
• Check form labels are associated with inputs
• Ensure buttons and links are clearly labeled
• Test navigation in portrait and landscape

WCAG 2.1 Success Criteria

1.3.4 Orientation (Level AA)

Content is not restricted to a single display orientation (such as portrait or landscape), unless a specific orientation is essential.

2.5.1 Pointer Gestures (Level A)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

2.5.2 Pointer Cancellation (Level A)

For functionality that can be operated using a single pointer, at least one of the following is true: the down-event of the pointer is not used to execute any part of the function, or completion of the function is on the up-event, and a mechanism is available to abort or undo the function.

2.5.4 Motion Actuation (Level A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components, and responding to the motion can be disabled to prevent accidental actuation.

Common mistakes

• Touch targets too small (minimum 44×44 CSS pixels), making them difficult to tap accurately
• Gestures without alternatives, such as swipe actions that have no button equivalent
• Landscape-only orientation locking, preventing portrait viewing on phones
• Content that requires hover (which doesn’t exist on mobile), hiding essential functionality
• Not testing with mobile screen readers (VoiceOver, TalkBack) before launch
• Custom controls that don’t work with touch or screen reader gestures

Back to top

Related DASH resources

• Keyboard Accessibility
• Visible Focus Indicators
• Forms Accessibility

Getting help

If you have questions or need assistance, the Digital Accessibility Services Hub (DASH) is available to support colleges, schools, and administrative units as they build sustainable accessibility practices.

• Contact DASH at [email protected] for consultations, training, or technical assistance.

Accessibility is a shared responsibility, and every step you take makes UGA’s digital environment more inclusive.