Accessibility in Mobile Development: What It Is, Standards, and How to Implement

What is Accessibility?

Accessibility (abbreviated a11y — letter a + 11 letters + y) is the property of a product being usable by people with disabilities. In the context of mobile applications, this means: support for screen readers (VoiceOver, TalkBack), adequate text size, high contrast, correct focus order for keyboard navigation, and the absence of animated elements that cause dizziness.

Inclusivity is not only an ethical but also a legal obligation. Many countries have digital accessibility laws: ADA (USA), Section 508, European Accessibility Act (EU, mandatory for apps from 2025). According to the Business Disability Forum, companies investing in accessibility increase their audience by 15–20% and reduce legal risks.

At IT Sectr, we check accessibility at every stage of development. Our experience shows that fixing accessibility issues at the design stage is 10 times cheaper than after release. Accessibility is not a feature — it is a basic requirement for a modern application.

iOS: VoiceOver, Accessibility Label, Trait

The Apple ecosystem offers powerful accessibility tools. VoiceOver is a built-in screen reader that vocalizes everything happening on the screen. The user controls the device with gestures: swipe right — next element, swipe left — previous element, double tap — activation.

Accessibility Label is the text that VoiceOver reads for an element. By default, iOS uses the button text or label, but for icons and graphical elements you need to set the label explicitly. Accessibility Trait is a property describing the element type: button, header, link, image. Correct traits help the user understand how to interact with an element.

VoiceOver and Accessibility Label

VoiceOver supports over 40 languages and works on all Apple devices. For a developer, the main thing is to set correct accessibilityLabel and accessibilityTraits for each interface element. If an element should not be accessible (decorative image), set isAccessibilityElement = false.

// Swift — accessibility setup for a button
let shareButton = UIButton()
shareButton.setImage(UIImage(named: "share-icon"), for: .normal)
shareButton.accessibilityLabel = "Share this article"
shareButton.accessibilityHint = "Opens a dialog for choosing a sharing method"
shareButton.accessibilityTraits = .button

// SwiftUI — even simpler
struct ShareButtonView: View {
    var body: some View {
        Button(action: share) {
            Image(systemName: "square.and.arrow.up")
        }
        .accessibilityLabel("Share")
        .accessibilityHint("Opens the sharing menu")
    }
}

The code shows accessibility setup for a button without text (icon only). AccessibilityLabel is what the user will hear. AccessibilityHint is an additional hint about the result of the action. Do not use phrases like "button for" in the label — Trait already indicates it is a button.

Android: TalkBack, Content Description

TalkBack is the screen reader from Google for Android, part of the Android Accessibility Suite package. Like VoiceOver, it vocalizes interface elements and is controlled by gestures. TalkBack supports over 100 languages and works on all devices with Google Play Services.

Content Description is the equivalent of accessibilityLabel on Android. It is set via the android:contentDescription attribute in XML or via the setContentDescription() method in code. For non-focusable elements (decorative ImageView), use importantForAccessibility="no".

TalkBack and Focus Order

Focus Order is the sequence in which TalkBack moves between elements when swiping. By default, Android uses the order of elements in the layout, but it can be changed via the accessibilityTraversalBefore and accessibilityTraversalAfter attributes. This is important for complex screens with custom components.

At IT Sectr, we check Focus Order on every screen. Focus order errors are among the most common accessibility issues. For example, if after a header the user goes to comments instead of the article text — that is an accessibility bug.

WCAG and Standards

WCAG (Web Content Accessibility Guidelines) is an international accessibility standard developed by W3C. The current version is WCAG 2.2 (2023). The standard is divided into 4 principles: Perceivable, Operable, Understandable, Robust — abbreviated as POUR.

WCAG Levels: A (minimum), AA (medium, legally required in the EU), AAA (maximum). For mobile applications, level AA is sufficient: text contrast of at least 4.5:1, screen reader support, minimum target size of 44x44 pixels, subtitles for video.

WCAG Levels

Level A — basic requirements: text alternatives for images, keyboard control, contrast of at least 3:1. Level AA — medium: contrast 4.5:1, support for scaling up to 200%, correct headings and labels. Level AAA — high: contrast 7:1, sign language for video, full voice control. In practice, most companies aim for AA.

Table 2. Comparison of iOS and Android accessibility APIs. Despite different names, the concepts are identical: label, type, focus order, and text adaptation support.

Accessibility Testing

Accessibility testing is checking an application for compliance with WCAG standards and correct operation with screen readers. The minimum set of tests: enable VoiceOver/TalkBack and navigate through all screens of the application. Listen to check that all elements are announced, the focus order is logical, and inappropriate elements (decorative) are ignored.

Automated tools: Xcode Accessibility Inspector (audit in Xcode for iOS), Android Accessibility Scanner (scans the screen and finds issues), Axe DevTools, WAVE. These tools check contrast, target size, presence of labels, and other parameters.

At IT Sectr, we conduct an accessibility review before every release. The process includes: automated audit (Accessibility Inspector), manual testing with VoiceOver and TalkBack, contrast and text scaling checks. We log issues in Jira and assign them to a sprint. This allows us to maintain WCAG AA level across all projects.