Accessibility Label — ano ito, mga batayan at kung paano gamitin para sa iOS at Android

Ano ang Accessibility Label

Accessibility Label ay isang string property na tumutukoy sa pangalan ng elemento para sa mga pantulong na teknolohiya. Kapag ang user ay nag-swipe ng daliri sa screen na naka-on ang VoiceOver, binabasa ng screen reader ang Label ng elemento na may focus. Kung walang label, ang user ay nakakarinig lamang ng uri ng elemento: “button”, “larawan” — nang hindi sinasabi ang layunin.

Ayon sa Google I/O 2024, “Accessibility Testing”, 35% ng mga kritikal na paglabag sa accessibility sa mga app ng tindahan ay nauugnay sa kawalan o hindi tamang Label. Ang Accessibility Scanner sa Android ay nakakakita ng kawalan ng label bilang isang error na may pinakamataas na kalubhaan.

Pangunahing limitasyon: Ang Label ay hindi dapat maglaman ng uri ng elemento. Ang VoiceOver at TalkBack ay awtomatikong nagdaragdag ng papel (button, header, link) sa anunsyo. Kung ang Label ay naglalaman ng “Button ng pagpapadala”, maririnig ng user: “Button ng pagpapadala, button” — pagdodoble.

Label at WCAG 4.1.2: Name, Role, Value

Ang WCAG 4.1.2 (antas A) ay nangangailangan na ang bawat elemento ng user interface ay may pangalan (name), papel (role), at halaga (value) na matutukoy nang programmatically. Ang Accessibility Label ay nagbibigay ng pangalan. Kung wala ang Label, ang criterion ay itinuturing na nilabag at ang application ay hindi pumasa sa pangunahing sertipikasyon.

iOS: property na accessibilityLabel

Sa iOS, ang accessibilityLabel ay minamana ng lahat ng UIView mula sa UIAccessibility protocol. Kung ang elemento ay naglalaman ng teksto (UIButton na may title, UILabel na may text), ang Label ay awtomatikong itinatakda sa tekstong ito. Para sa UIImageView, mga custom na kontrol, at mga container, ang Label ay kailangang itakda nang manu-mano.

Halimbawa para sa custom na table cell:

class CustomTableViewCell: UITableViewCell {
    let titleLabel = UILabel()
    let priceLabel = UILabel()

    override func awakeFromNib() {
        super.awakeFromNib()
        self.isAccessibilityElement = true
        self.accessibilityLabel =
            "\(titleLabel.text ?? "") - \(priceLabel.text ?? "")"
    }
}

Para sa mga custom na UIView, maaaring i-override ang getter ng accessibilityLabel:

class RatingView: UIView {
    var rating: Int = 5

    override var accessibilityLabel: String? {
        get { return "Rating: \(rating) sa 5" }
        set {}
    }
}

Apple HIG, 2024 ay nagpapayo: kung ang elemento ay binubuo ng maraming sub-elemento (halimbawa, card ng produkto na may pangalan at presyo), pagsamahin ang mga ito sa isang accessibility element na may composite Label. Itakda ang isAccessibilityElement = true sa magulang at false sa mga anak.

NSAttributedString at accessibilityLabel

Kung ang UILabel ay gumagamit ng NSAttributedString, ang accessibilityLabel ay default na katumbas ng .string (plain text). Kung kailangan mong magpasa ng semantically ibang halaga (halimbawa, icon-simbolo na binabasa bilang “Bituin” sa halip na simbolong ★), itakda nang tahasan ang accessibilityLabel. Hindi binabasa ng VoiceOver ang mga Unicode na simbolo nang makahulugan.

Android: Label sa pamamagitan ng contentDescription

Sa Android, ang contentDescription ay gumaganap bilang Label para sa ImageView, ImageButton, at custom na Views. Para sa TextView at Button na may nakapaloob na teksto, hindi kailangang itakda ang contentDescription — awtomatikong binabasa ng TalkBack ang teksto.

Programmatic na pagtatakda sa pamamagitan ng Kotlin:

binding.iconStar.contentDescription = "Produkto sa mga paborito"

// Para sa custom na view na may maraming elemento
binding.customCard.setContentDescription(
    "\(title) na nagkakahalaga ng \(price)")

Sa XML para sa mga elementong pampalamuti:

<ImageView
    android:contentDescription="@null"
    android:src="@drawable/divider"
    android:importantForAccessibility="no" />

Ang property na importantForAccessibility = "no" ay ganap na nag-aalis ng elemento mula sa accessibility tree. Sa iOS, ang katumbas nito ay isAccessibilityElement = false.

Compose: semantics at contentDescription

Sa Jetpack Compose, ang Label ay itinatakda sa pamamagitan ng semantics modifier:

Image(
    painter = painterResource(R.drawable.ic_search),
    contentDescription = "Paghahanap ng produkto",
    modifier = Modifier.semantics {
        contentDescription = "Paghahanap ng produkto"
    }
)

Sa Compose, ang contentDescription ay isang sapilitang parameter para sa Image — kung wala nito, hindi magko-compile ang code (babala). Pilit nitong pinapabuti ang accessibility sa pamamagitan ng disenyo ng API.

Label at Hint: pagkakaiba ng papel

Accessibility Label ay sumasagot sa tanong na “Anong elemento ito?”. Hint (accessibilityHint sa iOS, karagdagang teksto sa contentDescription sa Android) — “Ano ang mangyayari sa pakikipag-ugnayan?”. Ang VoiceOver ay nagsasalita ng mga ito nang sunud-sunod: una ang Label, pagkatapos ang Hint.

Halimbawa para sa button ng pagtanggal:

• Label: “Tanggalin”
• Hint: “Permanenteng tatanggalin ang napiling larawan”
• VoiceOver: “Tanggalin. Permanenteng tatanggalin ang napiling larawan”

Ayon sa Deque University, 2024, ang tamang paghihiwalay ng Label at Hint ay nagpapataas ng rate ng tagumpay ng pagkumpleto ng gawain para sa mga gumagamit ng VoiceOver ng 28%. Ang mga user na may kapansanan sa pag-iisip ay partikular na umaasa sa Hint: sa panganib na pindutin ang “Tanggalin” nang walang paliwanag, 40% ang tumatangging kumilos.

Kailan hindi kailangan ang Hint

• Elemento na may intuitively naiintindihan na aksyon (“Bumalik”, “Isara” — sapat na ang Label)
• Label ay naglalarawan na ng resulta (“Magpadala ng mensahe” — pandiwa sa mismong pangalan)
• Mga kontrol ng system (UISwitch, UIButton na may system type) — ang kanilang pag-uugali ay pamantayan

Mga pagkakamali mula sa praktika: Label sa halip na Hint

Isang karaniwang pagkakamali: sa Label ay isinusulat ang “Button ng pagtanggal” sa halip na “Tanggalin”. Ang uri ng elemento (button) ay idinaragdag ng VoiceOver nang awtomatiko sa pamamagitan ng trait. Bilang resulta, naririnig ng user: “Button ng pagtanggal, button” — pagdodoble. Tamang Label: “Tanggalin”, Hint: “Tatanggalin ang napiling larawan”.

Lokalisasyon at pinakamahuhusay na kasanayan

Ang lokalisasyon ng mga label ay sapilitan — ginagawa sa pamamagitan ng mga karaniwang mekanismo: NSLocalizedString sa iOS, mga mapagkukunan ng string @string/ sa Android. Huwag kailanman itakda ang Label sa pamamagitan ng pagsasama-sama sa Ingles nang walang lokalisasyon.

Mga panuntunan ng mabuting Label, batay sa W3C WCAG 2.2:

• Magsimula sa keyword — “Paghahanap ng produkto”, hindi “Field para sa paghahanap ng produkto”
• Huwag isama ang salitang “button”, “field”, “larawan” — ang papel ay idinaragdag nang awtomatiko
• Gumamit ng natural na wika, nauunawaan ng target na madla
• Iwasan ang mga pagdadaglat (maliban sa karaniwang tinatanggap: “pcs.”, “kg.”) — binabasa ito ng screen reader nang literal
• Para sa mga input element, magdagdag ng halimbawa: “Email (example@domain.com)”

Pagkakapare-pareho ng Label sa loob ng brand

Gumamit ng unipormeng glossary para sa Label sa application. Kung sa isang screen ay nakasulat ang “Paborito” at sa isa naman ay “Bookmark”, nalilito ang user. Gumawa ng talahanayan ng mga termino ng accessibility — makipag-ugnayan sa mga designer at localizer.

Label para sa mga elemento ng form

Para sa mga input field (UITextField, EditText), ang Label ay dapat tumugma sa placeholder o pamagat ng field. Ngunit ang placeholder ay madalas na nawawala pagkatapos mag-input ng teksto. Gamitin ang accessibilityLabel para sa permanenteng pangalan at accessibilityValue para sa kasalukuyang nilalaman ng field — ito ang pamantayang WCAG 4.1.2. Solusyon: itakda ang accessibilityLabel nang statically (katumbas ng pamagat ng field), at ang accessibilityValue nang dynamically (katumbas ng na-input na teksto). Sa iOS ito ay awtomatiko, ngunit para sa mga custom na field — manu-mano sa pamamagitan ng pag-override ng accessibilityValue. Suriin na binabasa ng VoiceOver: “Email, example@domain.com, text field” sa halip na “, text field”.

Paano subukan ang mga label ng accessibility

Ang automated na pagsubok ay ang tanging paraan upang garantiya ang kawastuhan ng Label sa lahat ng screen. Ang iOS ay nagbibigay ng XCUIApplication na may access sa .label, Android — AccessibilityCheckRule at setContentDescription.

Halimbawa ng test para sa iOS:

func testLabelsAreUnique() {
    let app = XCUIApplication()
    app.launch()
    let allButtons = app.buttons.allElementsBoundByIndex
    let labels = allButtons.compactMap { $0.label }
    let uniqueLabels = Set(labels)
    XCTAssertEqual(labels.count, uniqueLabels.count,
        "Natagpuan ang mga dobleng Label")
}

Halimbawa para sa Android na may Espresso:

@Test
fun testButtonHasAccessibilityLabel() {
    onView(withId(R.id.btnSubmit))
        .check(matches(
            withContentDescription(containsString("Ipadala"))
        ))
}

Manu-manong pagsubok: i-on ang VoiceOver (iOS) o TalkBack (Android) at mag-swipe pakanan sa lahat ng elemento ng screen. Ang bawat elemento ay dapat makatanggap ng makabuluhang anunsyo. Kung nakakarinig ka lang ng “button” o “larawan” — wala ang Label.

VoiceOver rotor at mabilis na nabigasyon

Pagkatapos i-configure ang Label, ang gumagamit ng VoiceOver ay maaaring gumamit ng rotor para sa mabilis na nabigasyon: mga mode na “Mga Button”, “Mga Header”, “Mga Link” at iba pa. Kung ang Label ay naitakda nang tama, isasama ng VoiceOver ang elemento sa kaukulang mode ng rotor. Suriin na ang lahat ng button ay nakikita sa mode na “Mga Button” at lahat ng header sa “Mga Header”.

Ang Label ay nakakaapekto rin sa paghahanap ng VoiceOver. Ang user ay maaaring magpasok ng isang salita sa search mode, at ililipat ng VoiceOver ang focus sa elemento na may katugmang Label. Kaya naman, ang Label ay dapat maglaman ng mga keyword na gagamitin ng user sa paghahanap ng elemento.

Integrasyon sa CI/CD pipeline

Idagdag ang pagsusuri ng Label sa pipeline. Sa iOS, gamitin ang XCUITest na may fastlane scan. Sa Android — Accessibility Test Framework na may panuntunang AccessibilityCheckRule na nakakakita ng mga walang laman na contentDescription. Ito ay pumipigil sa mga regression kapag nagmi-merge ng mga bagong screen.