VoiceOver: การควบคุมด้วยท่าทางและคุณสมบัติบน iOS

VoiceOver คืออะไร?

VoiceOver เป็นโปรแกรมอ่านหน้าจอที่ฝังอยู่ในระบบปฏิบัติการของ Apple ออกแบบมาสำหรับผู้ใช้ที่ตาบอดและมีปัญหาทางสายตา และให้การโต้ตอบกับอุปกรณ์อย่างเต็มรูปแบบโดยไม่ต้องมองเห็น VoiceOver จะอ่านออกเสียงทุกองค์ประกอบของอินเทอร์เฟซ: ปุ่ม ลิงก์ ข้อความ รูปภาพ การแจ้งเตือน และองค์ประกอบของระบบ

เทคโนโลยีนี้ถูกนำเสนอครั้งแรกในปี 2005 สำหรับ macOS และมาถึง iOS พร้อมกับ iPhone 3GS ในปี 2009 ตั้งแต่นั้นมา VoiceOver ได้กลายเป็นส่วนสำคัญของระบบนิเวศของ Apple และเป็นหนึ่งในข้อโต้แย้งหลักที่สนับสนุนการเข้าถึงของแพลตฟอร์ม VoiceOver ถูกฝังอยู่ในระดับระบบ — หมายความว่ามันทำงานในแอปพลิเคชันใดก็ได้โดยไม่ต้องมีการผสานรวมเพิ่มเติมจากนักพัฒนา แม้ว่าคุณภาพของการอ่านออกเสียงจะขึ้นอยู่กับว่าแอปพลิเคชันใช้ API การเข้าถึงของ iOS ได้ดีเพียงใด

VoiceOver รองรับมากกว่า 40 ภาษาด้วยการสังเคราะห์เสียงที่เป็นธรรมชาติและปรับตามการตั้งค่าเสียงในภูมิภาค บน iOS VoiceOver ใช้ระบบเสียงของ Siri สำหรับภาษาไทยและภาษาอื่นๆ อีกหลายภาษา เพื่อให้ได้เสียงที่เป็นธรรมชาติที่สุดและการออกเสียงที่ถูกต้องตามเครื่องหมายวรรคตอนและบริบท

VoiceOver ทำงานอย่างไร?

VoiceOver จะสกัดกั้นเหตุการณ์การสัมผัสและแปลความหมายแตกต่างจากการป้อนข้อมูลมาตรฐานของ iOS เมื่อผู้ใช้สัมผัสหน้าจอ VoiceOver จะไม่เปิดใช้งานองค์ประกอบใต้นิ้ว แต่จะอ่านออกเสียงก่อน หลังจากแตะสองครั้งเท่านั้น องค์ประกอบจึงจะถูกเปิดใช้งาน ความแตกต่างที่สำคัญนี้ช่วยให้ผู้ใช้ตาบอดสามารถสำรวจอินเทอร์เฟซได้โดยไม่เสี่ยงต่อการคลิกโดยไม่ตั้งใจ

ลำดับการอ่านและการนำทาง

VoiceOver อ่านองค์ประกอบของอินเทอร์เฟซตามลำดับตรรกะ: จากซ้ายไปขวา จากบนลงล่าง ลำดับการอ่านสืบทอดมาจากลำดับชั้นของวิวใน iOS แต่นักพัฒนาสามารถเปลี่ยนได้ผ่านคุณสมบัติ accessibilityElements สำหรับเลย์เอาต์ที่ซับซ้อน ผู้ใช้สามารถย้ายระหว่างองค์ประกอบโดยการปัดไปทางขวา (ถัดไป) และไปทางซ้าย (ก่อนหน้า) รวมถึงการแตะองค์ประกอบที่ต้องการให้อ่านออกเสียง

ในการเคลื่อนที่แต่ละครั้ง VoiceOver จะพูดประเภทขององค์ประกอบ (ปุ่ม, ลิงก์, หัวข้อ), ชื่อ (accessibilityLabel), สถานะ (เลือก, ปิดใช้งาน) และคำแนะนำ (accessibilityHint) หากองค์ประกอบมีค่า — ตัวอย่างเช่น แถบเลื่อนระดับเสียง — VoiceOver จะอ่านออกเสียงด้วย Accessibility Traits (UIAccessibilityTraits) จะแจ้งให้ผู้ใช้ทราบเพิ่มเติมเกี่ยวกับพฤติกรรมขององค์ประกอบ: เป็นปุ่ม, สวิตช์, ช่องค้นหา หรือแป้นพิมพ์

โรเตอร์ของ VoiceOver

โรเตอร์เป็นแป้นปรับแต่งเสมือนที่เปลี่ยนโหมดการนำทางของ VoiceOver ผู้ใช้หมุนโรเตอร์ด้วยสองนิ้ว (เหมือนปุ่มปรับระดับเสียง) และเลือกโหมด: คำ, ตัวอักษร, หัวข้อ, ลิงก์, จุดเข้า, แถวตาราง และอื่นๆ โหมดหัวข้อ ช่วยให้สลับระหว่าง H1-H6 บนหน้าเว็บและในแอปพลิเคชันได้อย่างรวดเร็ว ในขณะที่โหมดตัวอักษรจะพูดข้อความทีละตัวอักษร ซึ่งมีประโยชน์เมื่อกรอกแบบฟอร์มหรือป้อนรหัสยืนยัน

นักพัฒนาสามารถเพิ่มโหมดที่กำหนดเองลงในโรเตอร์ผ่าน API UIAccessibilityCustomRotor ตัวอย่างเช่น ในแอปพลิเคชันโน้ต สามารถเพิ่มโรเตอร์ “โน้ตโปรด” หรือ “การเปลี่ยนแปลงล่าสุด” ได้ โรเตอร์ที่กำหนดเอง ช่วยเพิ่มความเร็วในการนำทางในแอปพลิเคชันเฉพาะได้อย่างมาก และถือเป็นแนวปฏิบัติที่ดีที่สุดสำหรับการเข้าถึงบน iOS

การควบคุมด้วยท่าทางของ VoiceOver

VoiceOver ใช้ชุดท่าทางของตัวเองซึ่งไม่ตรงกับท่าทางมาตรฐานของ iOS ท่าทางส่วนใหญ่ใช้สามนิ้วแทนที่จะเป็นหนึ่งนิ้ว — เพื่อป้องกันการขัดแย้งกับการทำงานปกติ และช่วยให้ VoiceOver ทำงานพร้อมกันกับการป้อนข้อมูลมาตรฐาน

ท่าทาง แตะสองครั้ง เป็นวิธีหลักในการเปิดใช้งานองค์ประกอบใน VoiceOver หากองค์ประกอบต้องการการกระทำพิเศษ (เช่น การลาก) VoiceOver จะใช้ลำดับ “แตะ — แตะสองครั้งและค้างไว้” เพื่อเข้าสู่โหมดการเคลื่อนที่ ซึ่งช่วยให้สามารถทำท่าทางที่ซับซ้อน เช่น ลากและวาง โดยไม่ต้องมองหน้าจอ VoiceOver ยังรองรับท่าทาง “แตะสองครั้งด้วยสองนิ้ว” เพื่อยกเลิกการกระทำ และ “แตะสามครั้ง” เพื่อเปิด/ปิด ม่านหน้าจอ (Screen Curtain)

VoiceOver ในการพัฒนาแอปบนมือถือ

นักพัฒนาแอปพลิเคชัน iOS สามารถปรับปรุงการโต้ตอบกับ VoiceOver ได้อย่างมีนัยสำคัญผ่าน API UIAccessibility การตั้งค่าการเข้าถึงพื้นฐานถูกเพิ่มใน Interface Builder (Identity Inspector → Accessibility) แต่อินเทอร์เฟซที่ซับซ้อนต้องมีการกำหนดค่าผ่านโค้ด

ป้ายกำกับการเข้าถึงและ Traits

คุณสมบัติ accessibilityLabel กำหนดข้อความที่ VoiceOver พูดสำหรับองค์ประกอบ หากไม่ได้ตั้งป้ายกำกับ VoiceOver จะใช้ข้อความของปุ่มหรือข้อความตัวแทนของช่องข้อความ สำหรับองค์ประกอบที่ไม่มีข้อความ (ไอคอน, วิวที่กำหนดเอง) ป้ายกำกับเป็นสิ่งจำเป็น คุณสมบัติ accessibilityTraits กำหนดประเภทขององค์ประกอบ: ปุ่ม, หัวข้อ, สวิตช์, ช่องค้นหา, แป้นพิมพ์, ค่าเปลี่ยนแปลง, ลิงก์ และอื่นๆ

let profileButton = UIButton(type: .custom)
profileButton.setImage(UIImage(named: "avatar"), for: .normal)
profileButton.isAccessibilityElement = true
profileButton.accessibilityLabel = "โปรไฟล์ผู้ใช้"
profileButton.accessibilityTraits = .button
profileButton.accessibilityHint = "เปิดหน้าจอการตั้งค่าโปรไฟล์"

แฟล็ก isAccessibilityElement เปิดใช้งานการรองรับ VoiceOver สำหรับวิวที่กำหนดเอง — โดยค่าเริ่มต้นจะเป็นจริงเฉพาะองค์ประกอบมาตรฐาน (UIButton, UILabel, UITextField) เท่านั้น พารามิเตอร์ accessibilityHint เพิ่มคำแนะนำ: VoiceOver จะพูดหลังจากหยุดชั่วคราวหากผู้ใช้หยุดอยู่ที่องค์ประกอบ คำแนะนำควรอธิบายผลลัพธ์ของการกระทำ ไม่ใช่คำสั่ง: “เปิดหน้าจอการตั้งค่า” แทนที่จะเป็น “กดเพื่อเปิด”

การจัดกลุ่มและลำดับองค์ประกอบ

สำหรับหน้าจอที่ซับซ้อนซึ่งกลุ่มตรรกะขององค์ประกอบไม่ตรงกับลำดับภาพ จะใช้ accessibilityElements — อาร์เรย์ที่กำหนดลำดับการอ่าน ตัวอย่างเช่น การ์ดสินค้าประกอบด้วยรูปภาพ ชื่อ ราคา และปุ่ม “เพิ่มในตะกร้า” หากองค์ประกอบเหล่านี้ถูกจัดเรียงอย่างไม่เป็นระเบียบในลำดับชั้นของวิว accessibilityElements จะกำหนดลำดับที่ถูกต้องสำหรับ VoiceOver

let productCard = UIView()
let productImage = UIImageView()
let productName = UILabel()
let productPrice = UILabel()
let addToCartButton = UIButton()

productCard.accessibilityElements = [
    productImage, productName, productPrice, addToCartButton
]

เพื่อรวมหลายองค์ประกอบเป็นองค์ประกอบที่เข้าถึงได้เดียว ใช้ UIAccessibilityContainer หรือ accessibilityFrame เพื่อแทนที่พื้นที่สัมผัส ซึ่งมีประโยชน์เมื่อเซลล์ตารางมีส่วนประกอบ UI หลายอย่างแต่ในทางตรรกะเป็นตัวแทนขององค์ประกอบเดียว — VoiceOver ควรอ่านออกเสียงทั้งเซลล์โดยรวม ไม่ใช่ทีละส่วน

การตั้งค่าการเข้าถึงสำหรับ VoiceOver

การกำหนดค่าการเข้าถึงที่ถูกต้องสำหรับ VoiceOver ต้องใส่ใจหลายด้าน: มาร์กอัปเชิงความหมาย, การอัปเดตแบบไดนามิก, การจัดการองค์ประกอบที่กำหนดเอง และการทดสอบกับโปรแกรมอ่านหน้าจอจริง

มาร์กอัปเชิงความหมายใน SwiftUI

ใน SwiftUI การเข้าถึงถูกกำหนดค่าผ่านตัวดัดแปลง .accessibilityLabel(), .accessibilityValue(), .accessibilityHint() และ .accessibilityAddTraits() SwiftUI สืบทอดการเข้าถึงจากองค์ประกอบมาตรฐานโดยอัตโนมัติ แต่องค์ประกอบที่กำหนดเองต้องการการกำหนดค่าที่ชัดเจน ตัวอย่างเช่น แถบเลื่อนที่กำหนดเองต้องแจ้งค่าและรูปแบบการเปลี่ยนแปลงให้ VoiceOver ทราบ

Slider(value: $volume, in: 0...100)
    .accessibilityLabel("ระดับเสียง")
    .accessibilityValue(
        Text("\(Int(volume)) เปอร์เซ็นต์")
    )
    .accessibilityAddTraits(.adjustsAudioForAccessibility)
    .accessibilityAdjustableAction { direction in
        switch direction {
        case .increment: volume = min(volume + 5, 100)
        case .decrement: volume = max(volume - 5, 0)
        }
    }

ตัวดัดแปลง accessibilityAdjustableAction เพิ่มความสามารถในการเปลี่ยนค่าด้วยท่าทางของ VoiceOver: ปัดขึ้นเพื่อเพิ่ม, ปัดลงเพื่อลด หากไม่มีตัวดัดแปลงนี้ แถบเลื่อนจะไม่สามารถเข้าถึงได้สำหรับการควบคุมผ่านโปรแกรมอ่านหน้าจอ การกำหนดค่าเดียวกันนี้จำเป็นสำหรับสเต็ปเปอร์ที่กำหนดเอง, พิคเกอร์ และองค์ประกอบอื่นๆ ที่เปลี่ยนค่า

การอัปเดตแบบไดนามิกและการแจ้งเตือน

เมื่อเนื้อหาบนหน้าจอเปลี่ยนแปลงแบบไดนามิก (การแจ้งเตือนปรากฏขึ้น, สถานะการโหลดอัปเดต, ราคาเปลี่ยนแปลง) VoiceOver ต้องได้รับการแจ้งเตือนผ่าน UIAccessibility.post หากไม่มีการเรียกนี้ โปรแกรมอ่านหน้าจอจะไม่ทราบเกี่ยวกับการเปลี่ยนแปลงและผู้ใช้จะพลาดข้อมูลสำคัญ สำหรับ SwiftUI ใช้ตัวดัดแปลง .accessibilityAnnouncement()

UIAccessibility.post(
    notification: .announcement,
    argument: "ราคาลดลง 20 เปอร์เซ็นต์"
)

// SwiftUI
Text("ราคาถูกอัปเดต")
    .accessibilityAnnouncement(Text("ส่วนลด 20%"))

ควรใช้การแจ้งเตือน VoiceOver อย่างชาญฉลาด: การประกาศมากเกินไปทำให้ผู้ใช้รำคาญ ในขณะที่การขาดหายไปทำให้แอปพลิเคชันไม่สามารถเข้าถึงได้ กลยุทธ์ที่ดีที่สุดคือประกาศเฉพาะการเปลี่ยนแปลงที่ส่งผลต่อขั้นตอนการทำงานปัจจุบันของผู้ใช้: การอัปเดตตะกร้า, สถานะการโหลด, ข้อผิดพลาดการตรวจสอบฟอร์ม, การแจ้งเตือนแชท การเปลี่ยนแปลงเบื้องหลัง (เวลาบนแผง, อัตราแลกเปลี่ยน) ไม่ต้องการการประกาศ — ผู้ใช้จะตรวจสอบเองเมื่อจำเป็น

การทดสอบ VoiceOver ทำผ่านอุปกรณ์จริงที่เปิดโปรแกรมอ่านหน้าจอไว้หรือเครื่องจำลอง iOS ที่มีตัวเลือก Accessibility Inspector สิ่งสำคัญคือต้องทดสอบสถานการณ์การใช้งานเต็มรูปแบบ: การลงทะเบียน, การสั่งซื้อ, การค้นหาสินค้าด้วยการค้นหา โดยไม่ต้องควบคุมด้วยสายตา หากเส้นทางสามารถนำทางได้โดยไม่ต้องมีการตอบสนองทางภาพ — แสดงว่า VoiceOver ได้รับการกำหนดค่าอย่างถูกต้อง