Accessibility — fundamentals, VoiceOver and TalkBack for blind users

What is Accessibility (a11y) in Mobile Apps?

Accessibility (abbreviated a11y — 11 letters between "a" and "y") — the practice of developing applications that are usable by people with vision, hearing, motor, and cognitive impairments. In mobile development, accessibility covers four main scenarios: blind users (screen readers), partially sighted users (scaling, contrast), deaf and hard-of-hearing users (subtitles, visual alternatives to sound), and users with limited motor control (voice control, Switch Control, large touch targets).

Legal Requirements — in many countries, accessibility is legally mandatory. USA: Section 508 and ADA. EU: European Accessibility Act (2025). UK: Equality Act 2010. Without accessibility support, an app can become the target of lawsuits — in the US in 2023, over 4,000 lawsuits were filed regarding inaccessible digital products. Apple and Google check accessibility during app moderation: App Store Review Guidelines (4.2) and Google Play Store require minimum accessibility support.

Business Case — accessibility expands your audience. According to Return on Disability (2021), people with disabilities control $13 trillion in disposable income annually. Accessible apps also rank better in search (semantic HTML, alt texts), have higher user ratings, and fewer reviews about UX issues. At IT Sectr, we include accessibility in the definition of done for all projects — it's a quality standard, not an optional enhancement.

Accessibility in iOS: VoiceOver and UIAccessibility

VoiceOver — Apple's screen reader built into iOS, iPadOS, and macOS. The user drags their finger across the screen, VoiceOver reads the element name under their finger. Double-tap activates the element. VoiceOver supports over 40 gestures: three-finger swipe (scrolling), two-finger double-tap (stop), Z-gesture (go back). Developers control what and how VoiceOver reads through the UIAccessibility protocol and the accessibilityLabel, accessibilityTraits, and accessibilityHint properties.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // override accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Form submit button" }
        set {}
    }

    // override accessibilityHint
    override var accessibilityHint: String? {
        get { return "Double-tap to submit data" }
        set {}
    }

    // override accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — text scaling
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Dynamic Typography — Dynamic Type in iOS lets users choose text size (from XS to XXXL). Developers use UIFontMetrics.scaledFont for automatic scaling. Text must display correctly at all sizes: lines must not be clipped, buttons must grow proportionally with text. UITableView automatically updates cell heights when text size changes. Ignoring Dynamic Type means making your app inaccessible to users with low vision.

Accessibility in SwiftUI

SwiftUI provides accessibility modifiers: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). By default, all standard SwiftUI elements (Text, Button, Image) are already accessibility elements with automatic labels. For custom Views, use .accessibilityElement(children: .combine) to combine child elements into one. SwiftUI automatically supports Dynamic Type and VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Delete item"))
    Text("Trash")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Deletes the selected item permanently"))

Accessibility in Android: TalkBack and contentDescription

TalkBack — Google's screen reader, pre-installed on most Android devices (available on Google Play for all Android 5+ versions). TalkBack uses the same gestures as VoiceOver: swipe for navigation, double-tap to activate. Developers set element descriptions through the android:contentDescription attribute in XML or via setContentDescription() in code. For ImageView, contentDescription is mandatory — without it, TalkBack will say "unlabeled" or read the file name.

// XML: contentDescription for ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin: programmatic assignment
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (custom)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Delete button"
        info.contentDescription = "Delete selected item"
        info.className = Button::class.java.name
    }
}

// Live Regions for dynamic updates
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — Android's mechanism for notifying TalkBack about content changes without focus. The android:accessibilityLiveRegion attribute accepts three values: none (no notifications), polite (announce after current), assertive (announce immediately). Use polite for loading status updates, assertive for critical errors. Overusing assertive will create chaos for the user — TalkBack will constantly interrupt the current action.

Accessibility Scanner

Accessibility Scanner — a free app from Google for testing Android app accessibility without access to source code. The scanner checks: text contrast, touch target size (minimum 48×48dp per Android Accessibility Guidelines), contentDescription for ImageView, and correct element hierarchy. For automated tests, use AccessibilityChecks from Espresso — they integrate into CI/CD and check accessibility with every build.

WCAG 2.1: Contrast, Size, and Touch Targets

WCAG 2.1 (Web Content Accessibility Guidelines) — the international accessibility standard developed by W3C. Version 2.1 (2018) includes 13 additional criteria for mobile applications. Conformance levels: A (minimum), AA (mandatory for most organizations), AAA (maximum). Apple and Google recommend level AA as the minimum for publishing apps. WCAG 2.2 was released in 2023 with refinements for focus and input.

Key Criteria for mobile development: text contrast of at least 4.5:1 (AA) or 7:1 (AAA), touch target size of at least 44×44pt (iOS) or 48×48dp (Android), support for both landscape and portrait orientations without loss of functionality, ability to disable animation (prefers-reduced-motion), captions for multimedia, and compatibility with voice control (Voice Control on iOS, Voice Access on Android).

Contrast Checking Tools — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). At IT Sectr, we check contrast at the design stage (Figma + Stark) and again at the development stage (Accessibility Inspector / Accessibility Scanner). The minimum requirement is 4.5:1 for all text under 18pt (14pt bold). Logos and decorative elements are not required to have contrast.

Accessibility Testing: Tools and Checklist

iOS Testing — Accessibility Inspector in Xcode (Xcode → Open Developer Tool → Accessibility Inspector) checks label, traits, and hint for each element. VoiceOver can be enabled in Settings or via the Accessibility Shortcut (triple-click the button). For automated tests, use XCUITest with XCTAssertTrue(app.staticTexts["label"].isAccessibilityElement). Apple recommends testing all app screens with VoiceOver enabled.

Android Testing — Accessibility Scanner (Play Store) checks contrast, touch target size, and contentDescription. For automation: Espresso AccessibilityChecks (import: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Google recommends the following checklist: every ImageView has a contentDescription, touch targets are at least 48×48dp, text scales to 200% without clipping, and all elements are reachable via TalkBack swipe.

IT Sectr Checklist — before release, we verify: (1) VoiceOver/TalkBack correctly reads all elements, (2) text scales to maximum size without loss of functionality, (3) all ImageViews have contentDescription, (4) text contrast ≥4.5:1 in all themes, (5) touch targets ≥44pt/48dp, (6) no context menu accessible only via long press, (7) support for Reduce Motion / Remove Animations in system settings. This checklist is part of the definition of done for every sprint.