Accessibility — mga batayan, VoiceOver at TalkBack para sa mga bulag na gumagamit

Ano ang Accessibility (a11y) sa mga mobile app?

Accessibility(pinaikling a11y — 11 titik sa pagitan ng «a» at «y») — ang praktika ng pag-develop ng mga app na naa-access ng mga taong may kapansanan sa paningin, pandinig, motor at cognitive. Sa mobile development, sumasaklaw ang accessibility ng apat na pangunahing sitwasyon: mga bulag na gumagamit (screen reader), may mahinang paningin (pag-scale, contrast), bingi at mahina ang pandinig (subtitle, visual na alternatibo sa tunog), mga gumagamit na may limitadong motor (voice control, Switch Control, malaking touch area).

Mga legal na pangangailangan — sa maraming bansa, ang accessibility ay sapilitan ayon sa batas. USA: Section 508 at ADA. EU: European Accessibility Act (2025). UK: Equality Act 2010. Kung walang suporta sa accessibility, ang app ay maaaring maging target ng demanda — sa USA noong 2023, mahigit 4,000 kaso ang isinampa tungkol sa hindi pagiging naa-access ng mga digital na produkto. Sinusuri ng Apple at Google ang accessibility sa pag-moderate ng apps: App Store Review Guidelines (4.2) at Google Play Store ay nangangailangan ng minimal na suporta sa pagiging naa-access.

Argumento sa negosyo — ang pagiging naa-access ay nagpapalaki ng audience. Ayon sa Return on Disability (2021), ang mga taong may kapansanan ay kumokontrol ng $13 trilyon na disposable income bawat taon. Ang mga naa-access na app ay mas mahusay din ang ranggo sa paghahanap (semantic HTML, alt-texts), may mas mataas na rating ng gumagamit at mas kaunting review tungkol sa mga problema sa UX. Sa IT Sectr isinasama namin ang accessibility sa definition of done ng lahat ng proyekto — ito ay pamantayan ng kalidad, hindi opsyonal na pagpapahusay.

Accessibility sa iOS: VoiceOver at UIAccessibility

VoiceOver — Apple screen reader, naka-embed sa iOS, iPadOS at macOS. Iginagalaw ng gumagamit ang kanyang daliri sa screen, binabasa ng VoiceOver ang pangalan ng elemento sa ilalim ng daliri. Doble-tap — pag-activate ng elemento. VoiceOver sumusuporta ng mahigit 40 kilos: tatlong daliri pag-swipe (pag-scroll), dalawang daliri doble-tap (pagtigil), Z-kilos (pagbalik). Kinokontrol ng developer kung ano at paano binabasa ng VoiceOver sa pamamagitan ng UIAccessibility protocol at mga property na accessibilityLabel, accessibilityTraits, accessibilityHint.

class CustomButton: UIButton {

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

    // override accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Button ng pagpapadala ng form" }
        set {}
    }

    // override accessibilityHint
    override var accessibilityHint: String? {
        get { return "Doble-tap upang magpadala ng datos" }
        set {}
    }

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

// Dynamic Type — pag-scale ng teksto
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Dynamic na tipograpiya — Dynamic Type sa iOS ay nagpapahintulot sa gumagamit na pumili ng laki ng teksto (mula XS hanggang XXXL). Gumagamit ang developer ng UIFontMetrics.scaledFont para sa awtomatikong pag-scale. Ang teksto ay dapat maipakita nang tama sa lahat ng laki: hindi dapat maputol ang mga linya, dapat lumaki ang mga button nang proporsyonal sa teksto. Awtomatikong ina-update ng UITableView ang taas ng cell kapag nagbago ang laki ng teksto. Ang pagbalewala sa Dynamic Type ay nangangahulugang gawing hindi naa-access ang app para sa mga may mahinang paningin.

Accessibility sa SwiftUI

SwiftUI ay nagbibigay ng mga modifier para sa accessibility: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Bilang default, ang lahat ng standard na SwiftUI element (Text, Button, Image) ay accessibility element na may awtomatikong label. Para sa custom na View, gamitin ang .accessibilityElement(children: .combine) para pagsamahin ang mga child element sa isa. Awtomatikong sinusuportahan ng SwiftUI ang Dynamic Type at VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Tanggalin ang elemento"))
    Text("Basurahan")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Tinatanggal ang napiling elemento nang walang posibilidad ng pagpapanumbalik"))

Accessibility sa Android: TalkBack at contentDescription

TalkBack — Google screen reader, naka-pre-install sa karamihan ng Android device (available sa Google Play para sa lahat ng bersyon ng Android 5+). Gumagamit ang TalkBack ng parehong kilos gaya ng VoiceOver: swipe para sa nabigasyon, doble-tap para sa pag-activate. Itinatakda ng developer ang paglalarawan ng mga elemento sa pamamagitan ng android:contentDescription attribute sa XML o sa pamamagitan ng setContentDescription() sa code. Para sa ImageView, ang contentDescription ay sapilitan — kung wala ito, mag-uulat ang TalkBack ng «hindi naka-label» o babasahin ang pangalan ng file.

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

// Kotlin: programatikong pagtatakda
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (kustom)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Button ng pagtanggal"
        info.contentDescription = "Tanggalin ang napiling elemento"
        info.className = Button::class.java.name
    }
}

// Live Regions para sa dinamikong pag-update
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — mekanismo ng Android para ipaalam sa TalkBack ang pagbabago sa nilalaman nang walang focus. Ang android:accessibilityLiveRegion attribute ay may tatlong value: none (walang abiso), polite (ipahayag pagkatapos ng kasalukuyan), assertive (ipahayag agad). Gamitin ang polite para sa pag-update ng katayuan ng pag-load, assertive — para sa kritikal na error. Ang pag-abuso sa assertive ay magdudulot ng kaguluhan para sa gumagamit — patuloy na iinterrupt ng TalkBack ang kasalukuyang aksyon.

Accessibility Scanner

Accessibility Scanner — libreng app mula sa Google para sa pagsubok ng pagiging naa-access ng Android apps nang walang access sa source code. Sinusuri ng scanner ang: contrast ng teksto, laki ng touch area (minimum 48×48dp ayon sa Android Accessibility Guidelines), pagkakaroon ng contentDescription para sa ImageView, kawastuhan ng hierarchy ng elemento. Para sa automated na pagsubok, gamitin ang AccessibilityChecks mula sa Espresso — nagsasama ang mga ito sa CI/CD at sinusuri ang accessibility sa bawat build.

WCAG 2.1: contrast, laki at mga touch area

WCAG 2.1 (Web Content Accessibility Guidelines) — internasyonal na pamantayan ng pagiging naa-access na binuo ng W3C. Ang bersyon 2.1 (2018) ay may kasamang 13 karagdagang pamantayan para sa mga mobile app. Mga antas ng pagsunod: A (minimal), AA (sapilitan para sa karamihan ng organisasyon), AAA (maksimal). Inirerekomenda ng Apple at Google ang antas AA bilang minimum para sa pag-publish ng apps. Ang WCAG 2.2 ay inilabas noong 2023 na may mga paglilinaw para sa focus at input.

Mga pangunahing pamantayan para sa mobile development: contrast ng teksto na hindi bababa sa 4.5:1 (AA) o 7:1 (AAA), laki ng touch area na minimum 44×44pt (iOS) o 48×48dp (Android), suporta para sa landscape at portrait orientation nang walang pagkawala ng functionality, kakayahang i-off ang animation (prefers-reduced-motion), pagkakaroon ng subtitle para sa multimedia, compatibility sa voice control (Voice Control sa iOS, Voice Access sa Android).

Mga kasangkapan sa pagsuri ng contrast — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). Sa IT Sectr sinusuri namin ang contrast sa yugto ng disenyo (Figma + Stark) at muli sa yugto ng pag-develop (Accessibility Inspector / Accessibility Scanner). Minimum na pangangailangan — 4.5:1 para sa lahat ng tekstong mas maliit sa 18pt (14pt bold). Para sa mga logo at dekoratibong elemento, hindi kinakailangan ang contrast.

Pagsubok ng pagiging naa-access: mga kasangkapan at checklist

Pagsubok sa iOS — Accessibility Inspector sa Xcode (Xcode → Open Developer Tool → Accessibility Inspector) sinusuri ang label, traits, hint para sa bawat elemento. Maaaring i-activate ang VoiceOver sa mga setting o sa pamamagitan ng Accessibility Shortcut (tatlong beses na pagpindot ng button). Para sa automated na pagsubok, gamitin ang XCUITest na may XCTAssertTrue(app.staticTexts["label"].isAccessibilityElement). Inirerekomenda ng Apple na subukan ang lahat ng screen ng app na naka-activate ang VoiceOver.

Pagsubok sa Android — Accessibility Scanner (Play Store) sinusuri ang contrast, laki ng touch area, contentDescription. Para sa automation: Espresso AccessibilityChecks (import: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Inirerekomenda ng Google ang checklist: bawat ImageView ay may contentDescription, touch area ay hindi bababa sa 48×48dp, ang teksto ay naka-scale hanggang 200% nang walang pagputol, lahat ng elemento ay maaabot sa pamamagitan ng TalkBack swipe.

IT Sectr checklist — bago ang release sinusuri namin: (1) VoiceOver/TalkBack ay wastong nagbabasa ng lahat ng elemento, (2) ang teksto ay naka-scale sa maximum na laki nang walang pagkawala ng functionality, (3) lahat ng ImageView ay may contentDescription, (4) contrast ng teksto ≥4.5:1 sa lahat ng tema, (5) touch area ≥44pt/48dp, (6) walang context menu na accessible lamang sa pamamagitan ng long press, (7) suporta para sa Reduce Motion / Remove Animations sa system settings. Ang checklist na ito ay bahagi ng definition of done ng bawat sprint.