Content Description: ano ito, mga prinsipyo at paano itakda para sa accessibility

Ano ang Content Description sa accessibility

Content Description — isang katangian ng string ng elemento ng interface na naghahatid ng tekstuwal na representasyon ng biswal na nilalaman sa mga pantulong na teknolohiya. Binabasa ng screen reader (VoiceOver sa iOS, TalkBack sa Android) ang paglalarawan sa halip na subukang biswal na kilalanin ang elemento. Ang paglalarawan ay inilalapat sa mga imaheng walang tekstuwal na layer, mga icon, graph, custom na kontrol at anumang hindi-tekstuwal na elemento.

Ayon sa Google Material Design, 2024, ang mga elementong walang contentDescription ay lumalabag sa panuntunang WCAG 1.1.1 (Non-text Content). Ang pagsusuri ng Accessibility Scanner ay nagpapakita na hanggang 40% ng mga icon sa mga app ng tindahan ay walang paglalarawan. Ang gumagamit ng VoiceOver ay nakakarinig lamang ng “larawan” o “button” nang walang pagtutukoy — ang ganitong interface ay nagiging hindi magamit para sa nabigasyon.

Ang Content Description ay hindi pumapalit sa nakikitang teksto ng elemento. Kung ang button ay naglalaman ng tekstuwal na label na “Ipadala”, hindi kailangan ang karagdagang paglalarawan — babasahin ng screen reader ang teksto. Para sa mga imahe, icon at input field, ang paglalarawan ay sapilitan.

Ang mga tool na Accessibility Scanner (Android) at Xcode Accessibility Inspector (iOS) ay awtomatikong sinusuri ang pagkakaroon ng mga paglalarawan. Inirerekomenda na gawin ang mga pagsusuring ito sa bawat screen bago ang release.

Bakit kailangan ang Content Description: mga senaryo ng gumagamit

Ang gumagamit na may kapansanan sa paningin ay umaasa sa VoiceOver upang maunawaan ang interface. Kung ang icon ng cart ay walang paglalarawan, naririnig lamang niya ang “button”. Upang malaman kung ano ang ginagawa ng button, kailangan niya itong pindutin nang bulag — panganib ng hindi maibabalik na aksyon. Ang paglalarawang “Alisin ang produkto mula sa cart” ay lumulutas sa problemang ito sa isang segundo.

Ang gumagamit na may pansamantalang limitasyon (matinding sikat ng araw sa labas, sirang screen) ay gumagamit din ng VoiceOver. Ayon sa Apple Accessibility Report, 2023, humigit-kumulang 20% ng mga gumagamit ng VoiceOver ay walang permanenteng kapansanan sa paningin — binubuksan nila ang feature na ito ayon sa sitwasyon.

WCAG 1.1.1: Non-text Content

Ang pamantayang WCAG 1.1.1 (antas A) ay nangangailangan na ang bawat hindi-tekstuwal na nilalaman ay may tekstuwal na alternatibo. Ang pagbubukod: nilalaman na pampalamuti, ginagamit lamang para sa biswal na disenyo o hindi nagdadala ng impormasyon. Pagsusuri sa pagiging pampalamuti: kung aalisin ang elemento, nagbabago ba ang kahulugan ng pahina? Kung hindi — maaari itong itago mula sa screen reader.

Pagkakaiba ng Content Description sa Label

Accessibility Label (accessibilityLabel sa iOS) — ang pangalan ng elemento na binibigkas ng screen reader kapag naka-focus. Ang Content Description (accessibilityHint sa iOS) — karagdagang paliwanag na binibigkas pagkatapos ng pangalan at nag-uulat ng resulta ng aksyon.

Ang pagkakaiba ay makikita sa halimbawa ng button na “Cart”. Label: “Cart”. Description: “Bubuksan ang screen ng pag-order”. VoiceOver ay nagsasabing: “Cart. Bubuksan ang screen ng pag-order”. Kung Label lamang ang itinakda, hindi malalaman ng gumagamit kung ano ang mangyayari pagkatapos pindutin.

Talahanayan: Label versus Description

Panuntunan: Sinasagot ng Label ang tanong na “Ano ito?”, ng Description — “Ano ang mangyayari?”. Sa Android, maaaring gampanan ng contentDescription ang parehong papel, ngunit sa praktika mas mainam na paghiwalayin ang mga ito: gamitin ang concatenation na “[pangalan], [paliwanag]”.

Kailan mas mahalaga ang Description kaysa Label

Para sa mga komplikadong kilos (pag-swipe para tanggalin, mahabang pagpindot para sa context menu) ay sapilitan ang accessibilityHint. Hindi alam ng gumagamit ng VoiceOver ang tungkol sa mga nakatagong kilos kung hindi ito nailarawan. Ipahiwatig: “Mag-swipe pakaliwa upang tanggalin” sa hint ng elemento.

iOS: attribute na accessibilityHint

Sa platform ng iOS, ang accessibilityHint ay itinatakda sa pamamagitan ng katangian ng UIView o NSObject. Halaga — string hanggang 80 character. Binabasa ng VoiceOver ang hint pagkatapos ng label kung naka-enable ang mode ng mga detalyadong paglalarawan (sa mga setting ng VoiceOver — “Verbosity”).

Halimbawa ng pagtatakda ng hint para sa custom na button:

import UIKit

class CustomButton: UIButton {
    override func awakeFromNib() {
        super.awakeFromNib()
        self.accessibilityLabel = "Idagdag sa mga paborito"
        self.accessibilityHint = "I-save ang produkto sa listahan ng mga paborito"
    }
}

Para sa UIImageView na walang tekstuwal na nilalaman, sapilitang itakda ang isAccessibilityElement = true at accessibilityHint:

let imageView = UIImageView(image: UIImage(named: "chart-sales"))
imageView.isAccessibilityElement = true
imageView.accessibilityHint = "Graph ng benta sa nakaraang quarter"

Binabasa ng VoiceOver: “Graph ng benta sa nakaraang quarter”. Kung walang laman ang hint — “larawan” lamang. Apple HIG, 2024 ay nagrerekomenda na huwag gumamit ng mga pandiwa tulad ng “pindutin” o “harapin” sa hint — awtomatikong nagdaragdag ang VoiceOver ng instruksyon sa kilos.

SwiftUI: modifier na accessibilityHint

Sa SwiftUI, ang hint ay itinatakda sa pamamagitan ng chain modifier:

Image(systemName: "trash")
    .accessibilityLabel("Tanggalin")
    .accessibilityHint("Permanenteng tatanggalin ang napiling elemento")

Ang SwiftUI ay awtomatikong pinagsasama ang mga modifier para sa mga pinagsamang view. Kung ang Image ay nasa loob ng Button, ginagamit ng SwiftUI ang label ng button bilang pangunahing accessibilityLabel.

Android: katangian ng contentDescription

Sa Android, ang contentDescription ay itinatakda sa XML markup o programmatically sa pamamagitan ng setContentDescription(). Binibigkas ng TalkBack ang paglalarawan kapag naka-focus ang elemento.

Halimbawa sa XML:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_search"
    android:contentDescription="Paghahanap ng mga produkto" />

Programmatic na pagtatakda para sa mga dinamikong elemento:

binding.iconSearch.contentDescription =
    "Paghahanap. Bubuksan ang screen ng paghahanap gamit ang mga filter"

Para sa mga larawang pampalamuti (mga separator, background, pampalamuting icon) itakda ang contentDescription = "@null" o setContentDescription(null) — lalaktawan ng TalkBack ang naturang elemento. Sa XML: android:contentDescription="@null". Hindi gumagana ang walang laman na string "" — sasabihin pa rin ng TalkBack na “larawan”.

Android: mahahalagang detalye para sa ImageButton at CheckBox

Para sa ImageButton palaging itakda ang contentDescription — hindi nakikita ng TalkBack ang teksto sa larawan. Para sa CheckBox, ang paglalarawan ay dapat dinamikong magbago: “Napili” / “Hindi napili” sa halip na isang static na paglalarawan. Gamitin ang setContentDescription sa tagapakinig ng estado.

Mga panuntunan sa pagsulat ng mga paglalarawan

Nagbibigay-kaalaman — ang paglalarawan ay dapat maghatid ng kahulugan, hindi ang panlabas na anyo. Hindi “Asul na icon na may check”, kundi “Idinagdag ang produkto sa cart”. Ang screen reader ay hindi interesado sa mga kulay — interesado ito sa resulta.

Maikli — pinakamainam na haba 2–4 salita (hanggang 80 character). Ang mahahabang paglalarawan ay nagpapabagal ng nabigasyon: sunod-sunod na binabasa ng VoiceOver, bawat salita ay isang segundo ng oras ng gumagamit. Ayon sa Apple WWDC 2023, “Accessibility by Design”, ang pariralang higit sa 5 segundo ng pagbasa ay nakakaabala sa daloy ng kognitibo.

Natatangi — hindi dapat magkaroon ng dalawang elemento na may parehong paglalarawan sa isang screen. Hindi matutukoy ng gumagamit kung anong resulta ang idudulot ng focus sa una at sa pangalawang elemento. Kung mayroong maraming “Bumili” na button — magdagdag ng identifier: “Bumili ng iPhone 15”, “Bumili ng iPhone 15 Pro”.

Lokalisasyon — ang Content Description ay isinasalin sa lahat ng wikang sinusuportahan ng app. Ang pagkakamali sa lokalisasyon ng paglalarawan ay isa sa mga karaniwang dahilan ng pagkabigo ng Accessibility Review sa App Store.

Haba ng paglalarawan: pananaliksik

Ang pananaliksik ng Nielsen Norman Group, 2024 ay nagpakita na ang pinakamainam na haba ng paglalarawan para sa screen reader ay 3–5 salita (hanggang 50 character). Ang mas mahahabang paglalarawan ay nagbabawas ng bilis ng nabigasyon ng 30%, dahil ang gumagamit ay kailangang maghintay na matapos ang pagbigkas bago ang susunod na hakbang.

Mga karaniwang pagkakamali sa paggamit

Kalabisan — ang paglalarawan ay inuulit ang nakikitang teksto. Kung ang button ay naglalaman ng tekstong “Ipadala”, huwag itakda ang accessibilityHint = “Button ipadala”. Awtomatikong babasahin ng VoiceOver ang teksto, at ang hint ay magdadagdag ng hindi kinakailangang ingay.

Pagkakamali sa Label — paggamit ng contentDescription sa halip na label para sa mga tekstuwal na button. Sa iOS, ang accessibilityLabel ay dapat tumugma sa teksto ng button (o walang laman kung nakikita na ang teksto), at ang hint ay nagpapaliwanag lamang ng aksyon. Ayon sa Google Testing Blog, 2024, 23% ng mga nasuring app sa Play Store ay may dobleng paglalarawan.

Pagwawalang-bahala sa dinamika — ang paglalarawan ay hindi nag-a-update kapag nagbago ang estado. Halimbawa, sa switch na “Wi-Fi” ay nananatili ang paglalarawang “I-on ang Wi-Fi” kahit na matapos i-on. Tama: dinamikong baguhin ang paglalarawan sa “I-off ang Wi-Fi” sa pamamagitan ng pagmamasid sa estado.

Mga cycle ng render at regression

Pagkatapos ng pag-update ng disenyo (pagbabago ng mga icon, muling pag-aayos ng mga elemento), ang Content Description ay madalas nawawala. Dahilan: pinapalitan ng designer ang larawan, hindi sinusuri ng developer ang mga katangian ng accessibility ng bagong asset. Solusyon: gawing sapilitang hakbang ang pagsusuri ng accessibility sa code review — magdagdag ng checklist na may puntong “Na-update ba ang Content Description?”.

Paano suriin ang Content Description

• Sa iOS: Xcode → Accessibility Inspector — piliin ang elemento, suriin ang mga field na Label at Hint
• Sa Android: i-install ang Accessibility Scanner mula sa Play Store — patakbuhin sa iyong screen
• Sa parehong platform: i-on ang VoiceOver/TalkBack at mag-navigate sa buong screen gamit ang mga kilos
• Sumulat ng UI test na sumusuri ng contentDescription para sa lahat ng ImageView

Halimbawa ng UI test para sa iOS

func testContentDescriptionExists() {
    let app = XCUIApplication()
    app.launch()
    let image = app.images["chart-sales"]
    XCTAssertNotNil(image.label)
    XCTAssertGreaterThan(image.label.count, 0)
}