Collaborate With Development Partners to Create Accessible Native Applications

Consider the Following Guidelines During Documentation for Development Handover

Introduction

Ensuring accessibility is not just a technical requirement but a fundamental aspect of user experience. It allows all users, regardless of their abilities, to comprehend, explore, and operate native applications. These guidelines benefit not only individuals with disabilities but also a wide range of people who can utilise these features. Accessibility for native applications differs significantly from that of the web.

Touch Targets

What

A touch target is an area a user can click or tap on to activate an interactive element, such as a link, button, or input.

Who

Implementing minimum touch target sizes benefits users:

• With mobility impairments (e.g., hand tremors).
• Using devices in unstable environments (e.g., public transportation).
• With difficulty in fine motor movements.
• With only one arm or hand.
• With large fingers
• Navigating with a part of their finger or knuckle.
• Who are visually impaired.

Why

Small touch targets can significantly slow interactions or make them difficult to locate, leading to user frustration and potentially causing them to abandon the app. You can ensure a smoother and more efficient user experience by adhering to the recommended minimum touch target sizes.

How

Ensure minimum touch target sizes:

• iOS: 44x44px.
• Android: 48x48px.

Separate touch targets by at least 8px for usability and information density. For small elements like inline text links or icons, increase the touch target size by adding padding or a clickable container with minHeight.

export const adminFeeHyperlinkStyles = StyleSheet.create<IAdminFeeStyles>({
 adminFeeContainer: {
 minHeight: IS_IOS ? 44 : 48,
 justifyContent: ‘center’,
 },
 adminFeeLink: {
 …textVariantStyles.finePrintRegular,
 textDecorationLine: ‘underline’,
 },
})

Fig 1.1 — Increased touch target for admin fee inline text link with minHeight adjusted.

Resources

• Human Interface Guidelines — interactions
• Material Design — touch target

VoiceOver/TalkBack

What

VoiceOver (iOS) and TalkBack (Android) are built-in screen readers that provide spoken feedback.

Who

Primary users include individuals who are visually impaired or blind.

Why

These tools enable users to navigate using gestures and spoken prompts without visual input, working seamlessly with touch targets.

How

Tweaking the accessibility attributes of elements is a simple way to add more meaning and context for assistive technology users. Designers can collaborate with content designers (if this resource is available) to determine what content to read to users using VoiceOver or Talkback.

Fig 2.1 — Defining content for VoiceOver and TalkBack.

Fig 2.2 — Simulator (Accessibility Inspector), targeted element: shop by shape car card.

Fig 2.3 — VoiceOver enabled on the cinch app homepage “recently viewed” component.

Common SwiftUI Accessibility Attributes

• Label: Identifies the element (e.g., “Play button”).
• Hint: Provides additional action context (e.g., “Sends your message.”).
• Text Value: Describes the control’s value (e.g., “Slider at 50%.”).

Tips for Spoken Output

• Read page title and section headings as “heading.”
• Interactive elements include the action type (e.g., “Search all cars button.”).
• Carousels inform users how to navigate (e.g., “Swipe gesture to navigate between items.”).

Resources

SwiftUI Accessibility Attributes by Rob Whitaker

Dynamic Type

What

Dynamic Type allows users to adjust text sizes via system settings.

Who

Users with vision impairments or preferences for larger text sizes benefit significantly.

Why

A PDF Viewer App Team study showed that ~27% of users select non-default text sizes. Supporting this enhances inclusivity.

How

Set limits for scaling to prevent UI breakages:

• Minimum scaling: x1.
• Maximum scaling: x2 (200%).

Fig 2.1 — Dynamic text size via iOS system settings.

// Restrict dynamic text to x2 maximum
Text.defaultProps = Text.defaultProps || {}
Text.defaultProps.maxFontSizeMultiplier = 2

Conduct audits to identify breakages across scaling ranges. Restrict scaling for elements like native headers and footers.

Fig 2.2 — cinch app homepage with restricted text scaling at x2.

Resources

WCAG resize text guidelines

Display Orientation

What

Apps should support both portrait and landscape orientations.

Who

Users with specific needs may require fixed device orientations (e.g., wheelchair users mounting devices).

Why

Supporting orientation enhances accessibility, complies with WCAG 2.1, and accommodates diverse user preferences.

// iOS - lock to portrait (not a11y compliant).
<key>UISupportedInterfaceOrientations</key>
    <array>
        <string>UIInterfaceOrientationPortrait</string>
    </array>
<key>UISupportedInterfaceOrientations~ipad</key>
    <array>
        <string>UIInterfaceOrientationPortrait</string>
    </array>

How

Ensure user interfaces adapt across orientations. Avoid locking orientations unless required by functionality.

Survey insights: A cinch potential customer survey of 50 tablet owners revealed:

• 73% use a stylus often, favouring landscape mode.
• 63% use landscape mode for shopping apps like Amazon or eBay.

Summary

Developers and designers share the responsibility of delivering accessibility-focused documentation and features. This collaborative effort is crucial in ensuring platforms are accessible to all users. Before release, simulations ensure implementation accuracy. Accessibility enhancements improve usability and expand the app’s marketability and user satisfaction.