Accessibility Trait: esensya, anong mga uri ang mayroon at paano gumagana sa pag-develop

Ano ang Accessibility Trait

Accessibility Trait — isang flag na itinatakda sa elemento ng UIView upang ipahiwatig ang semantikong papel nito para sa VoiceOver. Ang trait ay isa sa tatlong bahagi ng accessibility triad ng Apple: Label (pangalan), Hint (paglalarawan), Trait (papel). Gumagamit ang iOS ng bit mask na UIAccessibilityTraits (UInt64), kung saan ang bawat bit ay tumutugma sa isang tiyak na papel. Binabasa ng VoiceOver ang papel pagkatapos ng Label at Hint: “Button Ipadala. Magbubukas ng form” — “Button” ay idinagdag dahil sa trait na UIAccessibilityTraitButton.

Bilang default, ang UIButton ay nakakakuha ng UIAccessibilityTraitButton, UILabel — UIAccessibilityTraitStaticText, UIImageView — UIAccessibilityTraitImage. Kapag gumagamit ng mga custom na kontrol, obligado ang developer na manu-manong itakda ang trait. Tinatawag ito ng Apple Human Interface Guidelines, 2024, na “isa sa pinaka kritikal na hakbang sa pagtiyak ng accessibility”.

Kung walang tamang trait, hindi alam ng user kung aling kilos ang gagamitin: iisang pagtapik (pag-activate ng button), dobleng pagtapik (pag-zoom) o kilos ng pag-swipe (switch). Tinutukoy ng trait kung aling mga kilos ang i-activate ng VoiceOver sa elemento.

Teknikal na implementasyon ng UIAccessibilityTraits

UIAccessibilityTraits — ay isang typealias UInt64. Ang bawat trait ay isang constant kung saan eksaktong isang bit ang itinatakda. Halimbawa UIAccessibilityTraitButton = 0x0000000000000001, UIAccessibilityTraitLink = 0x0000000000000002, UIAccessibilityTraitHeader = 0x0000000000000008. Ang kombinasyon ay nakakamit sa pamamagitan ng bitwise OR: 0x0001 | 0x0008 = 0x0009. Sinusuri ng VoiceOver ang mask at tinutukoy ang pag-uugali.

Mga pangunahing uri ng iOS traits

Ang iOS ay nagbibigay ng higit sa 15 trait constants. Tingnan natin ang mga pangunahing, na ginagamit sa 90% ng mga senaryo:

Ang mga constant ay available sa UIKit mula noong iOS 3.0. Sa iOS 14+ idinagdag ang suporta para sa UIAccessibilityTraits sa SwiftUI sa pamamagitan ng modifier na .accessibilityAddTraits().

Mga bihirang ngunit kapaki-pakinabang na trait

UIAccessibilityTraitAdjustable — para sa mga adjustable na halaga (slider, picker, volume slider). Pinapayagan ng VoiceOver ang pag-swipe pataas/pababa upang baguhin ang halaga na may hakbang na tinukoy sa pamamagitan ng accessibilityIncrement at accessibilityDecrement. UIAccessibilityTraitUpdatesFrequently — para sa mga elemento na may madalas na nagbabagong halaga (timer, loading indicator). Hindi binabasa ng VoiceOver ang halaga sa bawat pagbabago, kundi nag-pa-pause. UIAccessibilityTraitAllowsDirectInteraction — para sa mga elemento na maaaring direktang makipag-ugnayan ang user (keyboard, tool sa pagguhit), na nilalampasan ang mga kilos ng VoiceOver.

Pagsasama ng mga trait

Ang isang elemento ay maaaring magkaroon ng maraming trait nang sabay-sabay — ang kombinasyon ay tinutukoy sa pamamagitan ng bitwise OR (|). Halimbawa: isang button na kasalukuyang napili — Button | Selected. Sasabihin ng VoiceOver: “Napili. Na-filter ayon sa presyo. Button”.

Pagtatakda ng mga trait sa code:

filterButton.accessibilityTraits.insert(.button)
filterButton.accessibilityTraits.insert(.selected)

// O sa pamamagitan ng mask:
filterButton.accessibilityTraits = [.button, .selected]

Para sa mga custom na UIView kung saan ang trait ay hindi itinatakda bilang default:

class CustomToggle: UIControl {
    override var accessibilityTraits: UIAccessibilityTraits {
        get {
            if isOn {
                return [.button, .selected]
            } else {
                return .button
            }
        }
        set {}
    }
}

Panuntunan ng pagsasama: hindi hihigit sa 3-4 na trait bawat elemento. Ang mga labis na trait (hal. Button + Link + Header) ay gumagawa ng anunsyo ng VoiceOver na masyadong mahaba at nakakalito. Ayon sa Apple, “bawat karagdagang property ay nagpapataas ng cognitive load ng user”.

SwiftUI: mga modifier ng trait

Sa SwiftUI, ang mga trait ay itinatakda sa pamamagitan ng mga modifier na .accessibilityAddTraits() at .accessibilityRemoveTraits(). Halimbawa: Text(“Header”).font(.largeTitle).accessibilityAddTraits(.isHeader). Ang modifier na .isHeader ay nagdaragdag ng UIAccessibilityTraitHeader. Listahan ng SwiftUI traits: .isButton, .isHeader, .isLink, .isSelected, .isImage, .isSearchField, .isKeyboardKey, .isStaticText, .isSummaryElement, .isToggle, .playsSound, .startsMediaSession, .updatesFrequently, .allowsDirectInteraction, .causesPageTurn, .isModal, .tabBar.

Mga karaniwang pagkakamali sa pagpili ng trait

StaticText sa halip na Button — isang custom na kontrol na biswal na mukhang button ay nakakakuha ng default na trait na StaticText. Hindi nag-aalok ang VoiceOver ng kilos ng pag-activate, hindi maaaring “pindutin” ng user ang elemento. Solusyon: eksplicitong itakda ang .button.

Image na walang trait — UIImageView na may naka-enable na accessibility ay nakakakuha ng trait na Image, kahit na ito ay talagang button para palakihin ang larawan. Itakda ang .button at Label “Palakihin ang larawan”. Ayon sa WWDC 2023, “Deliver an Exceptional Accessibility Experience”, 40% ng accessibility regressions sa mga bagong bersyon ng apps ay sanhi mismo ng hindi pagtutugma ng trait.

Header sa bawat elemento — ang trait na Header ay para sa mga structural header ng screen. Kung gagawin mong header ang bawat UILabel, ang VoiceOver rotor sa mode na “Header” ay magiging walang silbi — hihinto ito sa bawat salita.

Paano ayusin: checklist

• Bawat interactive na custom na elemento ay nakakakuha ng trait na Button, Link o Adjustable
• Ang mga header ng seksyon ay nakakakuha ng trait na Header (hindi StaticText)
• Ang mga larawan-button ay nakakakuha ng trait na Button + Selected sa status na selected
• Mga elementong walang kilos — StaticText o Image (babasahin lang)

Mga bug ng regression kapag pinalitan ang UIButton ng UIControl

Karaniwang dahilan ng pagkawala ng trait — refactoring: pinapalitan ng developer ang UIButton ng UIControl para sa custom na display. Ang UIButton ay awtomatikong nakakakuha ng trait na Button, ang UIControl — hindi. Pagkatapos ng refactoring dapat eksplicitong itakda ang accessibilityTraits = .button. Magdagdag ng pagsusuri sa code review: “Kung pinalitan mo ang UIButton ng UIControl — suriin ang trait”.

Mga trait at dinamikong status

Para sa mga elemento na may nagbabagong status (hal. like button) ang trait ay dapat magbago nang dinamiko. Sa status na “hindi nagustuhan” — Button, sa status na “nagustuhan” — Button + Selected + Image (kung may icon). Binabago ng VoiceOver ang anunsyo: “Nagustuhan. Button” vs “Napili. Nagustuhan. Button”. Gamitin ang accessibilityValue para iparating ang status kung hindi sapat ang trait na Selected. Naaangkop para sa subscribe, paborito, filter at switch na mga button.

Katumbas sa Android: role at className

Sa Android walang direktang katumbas ang mga trait. Sa halip na bit mask ay ginagamit:

• className — halaga ng AccessibilityNodeInfo.className (android.widget.Button, android.widget.TextView)
• role — attribute sa XML (tinutukoy ang papel ng uri ng View)
• stateDescription — katumbas ng Selected: pagdaragdag ng paglalarawan ng status (naka-enable/naka-disable)

Para sa mga custom na View sa Android kailangang i-override ang onInitializeAccessibilityNodeInfo:

class CustomButton @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null
) : View(context, attrs) {

    override fun onInitializeAccessibilityNodeInfo(
        info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(info)
        info.className = "android.widget.Button"
        info.isClickable = true
    }
}

Ang mga developer ng Flutter ay dapat gumamit ng parameter na semanticsRole sa widget na Semantics: button, header, image, link, textField at iba pa. Karagdagan, available ang semanticsLabel at semanticsHint — kumpletong katumbas ng iOS triad na Label + Hint + Trait.

Web katumbas: WAI-ARIA role

Para sa mga web na bersyon ng mobile apps (PWA, WebView) ginagamit ang attribute na role mula sa WAI-ARIA: role="button", role="heading", role="link". Ito ang direktang katumbas ng accessibilityTraits. Sa mga hybrid app suriin kung ipinapasa ng WebView ang mga ARIA role sa native accessibility layer. Para dito gamitin ang protocol na UIAccessibilityContainerDataTable sa iOS o setAccessibilityDelegate sa Android. Ang WebView na may naka-enable na JavaScript ay maaaring hindi maayos na magpasa ng mga ARIA role — subukan nang hiwalay.

AccessibilityNodeInfo: mga karagdagang aksyon

Sa Android maaaring magdagdag ng mga custom na aksyon sa AccessibilityNodeInfo: AccessibilityNodeInfo.AccessibilityAction.ACTION_CLICK at ACTION_LONG_CLICK. Ito ang katumbas ng trait na Button na may karagdagang kilos. Para sa mga slider gamitin ang ACTION_SET_PROGRESS — katumbas ng Adjustable. Para sa Spinner at DatePicker — ACTION_SET_SELECTION, ACTION_SET_DATE at ACTION_SET_TIME.

Pagsusuri at pagsubok ng mga trait

Xcode Accessibility Inspector — pangunahing tool para sa iOS: piliin ang elemento at tingnan ang field na Traits. Ipapakita nito ang listahan ng itinakdang traits. Ang VoiceOver rotor sa mode na “Elemento” ay nagpapahintulot na dumaan sa lahat ng kontrol ng screen.

Awtomatikong pagsubok sa Swift para sa pagsusuri ng trait:

func testSubmitButtonTrait() {
    let app = XCUIApplication()
    app.launch()
    let submitButton = app.buttons["Ipadala"]
    XCTAssertTrue(submitButton.isEnabled)
    // Ang XCUIElement ay hindi nagbibigay ng direktang access sa mga trait
    // Pagsusuri sa pamamagitan ng pag-activate ng kilos
    submitButton.tap()
    XCTAssertTrue(app.staticTexts["Naipadala ang form"].exists)
}

Manu-manong pagsusuri sa pamamagitan ng VoiceOver: i-enable ang VoiceOver, ilipat ang daliri sa elemento, tapikin nang dalawang beses — ang elemento ay dapat mag-activate kung ito ay Button. Kung ang elemento ay hindi tumutugon sa dobleng pagtapik, mali ang trait. Gamitin ang kilos ng Rotor para lumipat sa pagitan ng mga mode (“Header”, “Link”, “Button”) — bawat mode ay magpapakita lamang ng mga elemento na may kaukulang trait.

Unit testing ng mga trait sa iOS

Bago ang iOS 14, ang mga unit test ay walang direktang access sa accessibilityTraits. Simula sa iOS 14, available ang property: XCTAssertEqual(customButton.accessibilityTraits, .button). Gamitin ito sa modular na pagsubok para sa pagsusuri ng mga custom na kontrol. Inirerekomenda na subukan ang bawat bagong custom na UIView para sa kawastuhan ng trait, lalo na pagkatapos ng refactoring o pagbabago ng parent class.