บทนำการเข้าถึงแอป Windows — เตรียม UI Automation และข้อกำหนดการปรับที่สมเหตุสมผล

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

ฉากหลังหนึ่งคือกรอบกฎหมาย การแก้ไขปี 2021 ของกฎหมายว่าด้วยการขจัดเลือกปฏิบัติต่อผู้พิการมีผลวันที่ 1 เมษายน 2024 และการ “ให้การปรับที่สมเหตุสมผล” แก่ผู้พิการกลายเป็นข้อผูกพันของธุรกิจด้วย¹ ต่อไป ความสัมพันธ์พนักงาน–บริษัทเช่นตอนเปิด (สนามการจ้างงาน) คืออาณาเขตของกฎหมายส่งเสริมการจ้างงานผู้พิการ ซึ่งผูกพันนายจ้างให้การปรับที่สมเหตุสมผลตั้งแต่เมษายน 2016² ความคิดที่ว่า “การเข้าถึงเป็นหัวข้อเว็บไซต์และไม่มีอะไรเกี่ยวกับแอป Windows ในองค์กร” ไม่ตั้งอยู่อีก ทั้งทางกฎหมายและทางปฏิบัติ

ในทางกลับกัน จากพื้นพัฒนา “ไม่รู้จะทำอะไร” เป็นที่ตรงไปตรงมา การเข้าถึงของแอปเดสก์ท็อป Windows มีข้อมูลน้อยกว่าเว็บ และไม่มีทางแก้เวทมนตร์หลังเกิด ไม่ต้องมองร้ายด้วย หากเข้าใจกลไกที่โปรแกรมอ่านหน้าจออ่านแอป (UI Automation) และรับพื้นฐานของชื่อ แป้น และสี การใช้งานของแอปธุรกิจดีขึ้นอย่างมาก และส่วนใหญ่เป็นการปรับปรุงที่เพิ่มผลิตภาพของผู้ใช้ทุกคน ไม่ว่าจะมีหรือไม่มีความพิการ

มุ่งไปที่นักพัฒนาแอปธุรกิจญี่ปุ่นและเจ้าหน้าที่ไอที บทความนี้เชื่อมในเที่ยวเดียวจากการจัดระเบียบขั้นต่ำของกรอบกฎหมายและมาตรฐาน ผ่านกลไก UI Automation การอิมพลีเมนต์ใน WinForms/WPF การใช้แป้น สีและคอนทราสต์ และเครื่องมือยืนยัน ถึงวิธีตั้งลำดับความสำคัญที่สมจริง

flowchart TB
    accTitle: ไหลของบทความนี้
    accDescr: โครงของบทความนี้ เชื่อมตามลำดับจากการจัดระเบียบกรอบกฎหมายและมาตรฐาน ผ่านกลไก UI Automation การอิมพลีเมนต์ใน WinForms และ WPF การใช้แป้น สีและคอนทราสต์ เครื่องมือยืนยัน และวิธีตั้งลำดับความสำคัญ
    law["จัดระเบียบกรอบกฎหมายและมาตรฐาน"] --> uia["กลไก UI Automation"]
    uia --> impl["อิมพลีเมนต์ใน WinForms/WPF"]
    impl --> kb["การใช้แป้น"]
    kb --> color["สีและคอนทราสต์"]
    color --> verify["เครื่องมือยืนยัน"]
    verify --> prio["วิธีตั้งลำดับความสำคัญ"]

ภาพ 1: บทความนี้เชื่อมกรอบกฎหมายผ่านกลไก การอิมพลีเมนต์ การยืนยัน และลำดับความสำคัญในไหลเดียว

1. สรุปก่อนเลย

• การให้การปรับที่สมเหตุสมผลเป็นข้อผูกพันของธุรกิจด้วยตั้งแต่วันที่ 1 เมษายน 2024 เมื่อผู้พิการแสดงเจตนาให้ถอดกำแพง ต้องตอบภายในขอบที่ไม่เป็นภาระเกิน สนามการจ้างงานอยู่ใต้กฎหมายส่งเสริมการจ้างงานผู้พิการ และนั่นเป็นข้อผูกพันของนายจ้างตั้งแต่เมษายน 2016¹²
• การปรับที่สมเหตุสมผลคือกระบวนการ “ตอบคำร้องเฉพาะผ่านบทสนทนาเชิงสร้างสรรค์” การทำให้แอปใช้ง่ายล่วงหน้าคือ “การปรับปรุงสภาพแวดล้อม” (ข้อผูกพันด้านความพยายาม) การรองรับล่วงหน้าสมบูรณ์ไม่ใช่ข้อผูกพัน สิ่งที่สำคัญคือไม่ปฏิเสธบทสนทนาฝ่ายเดียว¹
• เกณฑ์เทคนิคของการเข้าถึงกระจุกใน WCAG (JIS X 8341-3:2016) JIS X 8341-3:2016 เป็นมาตรฐานที่สอดคล้องเนื้อหาเดียวกับ WCAG 2.0 และ WCAG2ICT ของ W3C ให้แนวทางประยุกต์กับซอฟต์แวร์ที่ไม่ใช่เว็บ แอปเดสก์ท็อปตรวจด้วยความคิดเดียวกันได้³⁴
• โปรแกรมอ่านหน้าจออ่านแอปผ่าน UI Automation (UIA) คุณสมบัติที่แต่ละองค์ประกอบบนต้นไม้ UIA ถือ — Name, ControlType และคล้ายกัน — และแพตเทิร์นควบคุมอย่าง Invoke, Value และ SelectionItem คือวัสดุของการประกาศและการปฏิบัติการ⁵
• ปุ่มที่ Name ว่างถูกประกาศเพียงเป็น “ปุ่ม” การแก้ลำดับสูงสุดคือการตั้งชื่อ WinForms ใช้ AccessibleName และการผูก Label กับลำดับแท็บ WPF ใช้ AutomationProperties.Name/LabeledBy⁶⁷
• การถึงทุกฟังก์ชันจากแป้นอย่างเดียวเป็นเกณฑ์ความสำเร็จ WCAG (2.1.1) และในเวลาเดียวกันคือความเร็วป้อนของผู้ปฏิบัติที่ชำนาญเอง การวางลำดับแท็บ แป้นลัดเข้าถึง และการบ่งชี้โฟกัสเชื่อมตรงกับประสิทธิภาพของผู้ใช้ทุกคน⁸
• ถืออัตราส่วนคอนทราสต์ข้อความ 4.5:1 ขึ้นไปเป็นแนวทาง และอย่าสื่อสารข้อมูลด้วยสีอย่างเดียว ในธีมคอนทราสต์ (คอนทราสต์สูง) เคารพสีระบบแทนสีที่ฮาร์ดโค้ด⁸⁹
• รวมการยืนยันด้วย FastPass ใน Accessibility Insights for Windows และการตรวจด้วยมือด้วยโปรแกรมอ่านหน้าจอ เพราะนั่งบนรากฐาน UIA เดียวกัน งานนี้ยังคืนทุนร่วมกับสินทรัพย์ทดสอบอัตโนมัติของ UI อย่าง FlaUI¹⁰
• ไม่ต้องแก้ทุกหน้าจอพร้อมกัน ลำดับที่สมจริงคือ (1) จากหน้าจอที่ผู้ใช้นั้นใช้ (2) การพัฒนาใหม่เป็นไปตามมาตรฐาน (3) ขยายข้างโดยแก้ตัวควบคุมร่วม

ในหนึ่งประโยค: การรองรับการเข้าถึงคือ “เปิดเผยชื่อและการปฏิบัติการที่ถูกบนต้นไม้ UIA และรักษาพื้นฐานของแป้นและสี”

2. จัดระเบียบกรอบกฎหมายและมาตรฐาน — สิ่งที่ “กลายเป็นข้อผูกพัน” เปลี่ยนอะไร

2.1. กฎหมายว่าด้วยการขจัดเลือกปฏิบัติต่อผู้พิการ — จากเมษายน 2024 ธุรกิจก็ผูกพันให้การปรับที่สมเหตุสมผล

กฎหมายว่าด้วยการขจัดเลือกปฏิบัติต่อผู้พิการเป็นกฎหมายที่ห้าม “การปฏิบัติที่เลือกปฏิบัติอย่างไม่เป็นธรรม” ต่อผู้พิการโดยหน่วยงานบริหารและธุรกิจ และกำหนด “การให้การปรับที่สมเหตุสมผล” ในการแก้ไขปี 2021 (เรวะ 3) การให้การปรับที่สมเหตุสมผลโดยธุรกิจ ซึ่งเคยเป็นข้อผูกพันด้านความพยายาม กลายเป็นข้อผูกพัน และกฎหมายแก้ไขมีผลวันที่ 1 เมษายน 2024 (เรวะ 6)¹

ตามแผ่นพับสำนักคณะรัฐมนตรี การให้การปรับที่สมเหตุสมผลคือการตอบ ภายในขอบที่ไม่เป็นภาระเกิน เมื่อผู้พิการแสดงเจตนาว่าต้องการการตอบบางอย่างเพื่อถอดกำแพงในสังคม และเพราะเนื้อหาต่างตามลักษณะความพิการ ฉาก และสถานการณ์ จึงเน้น “บทสนทนาเชิงสร้างสรรค์” ที่ผู้พิการและธุรกิจซ้อนบทสนทนาและพิจารณการตอบด้วยกัน การปฏิเสธบทสนทนาเชิงสร้างสรรค์ฝ่ายเดียวถูกระบุว่าอาจเป็นการละเมิดข้อผูกพันให้การปรับที่สมเหตุสมผล¹

การแยกเชิงปฏิบัติสองอย่างสำคัญที่นี่

1. “การมีทุกอย่างพร้อมล่วงหน้า” ไม่ใช่สิ่งที่กลายเป็นข้อผูกพัน มาตรการปรับปรุงล่วงหน้าที่มุ่งไปยังผู้พิการจำนวนไม่ระบุ — ฝั่งอ่อนอย่างทบทวนคู่มือและฝึกอบรม ฝั่งแข็งอย่างทำให้สถานที่ไร้กำแพง — เรียก “การปรับปรุงสภาพแวดล้อม” และนี่เป็นข้อผูกพันด้านความพยายาม¹ การวางแอปธุรกิจให้อยู่ในสถานะใช้กับโปรแกรมอ่านหน้าจอได้ล่วงหน้าคิดได้ว่าเป็นความพยายามปรับปรุงสภาพแวดล้อม ยิ่งการปรับปรุงสภาพแวดล้อมไปไกล ภาระของการให้การปรับที่สมเหตุสมผลเฉพาะก็เบาลง
2. สนามการจ้างงานไม่อยู่ใต้กฎหมายว่าด้วยการขจัดเลือกปฏิบัติต่อผู้พิการ แต่ใต้กฎหมายส่งเสริมการจ้างงานผู้พิการ แผ่นพับเดียวกันยังระบุว่าการจ้างงานและการทำงานตามบทบัญญัติของกฎหมายส่งเสริมการจ้างงานผู้พิการ¹ และใต้กฎหมายนั้น โดยการแก้ไขที่มีผลเมษายน 2016 (เฮเซ 28) การห้ามเลือกปฏิบัติด้วยความพิการในการจ้างงาน และการให้การปรับที่สมเหตุสมผลภายในขอบที่ไม่เป็นภาระเกิน ถูกผูกพันกับนายจ้าง² คำปรึกษาเปิดของ “พนักงานใช้แอปธุรกิจไม่ได้” ในความเป็นจริงอยู่ในอาณาเขตข้อผูกพันนานก่อน 2024

flowchart TB
    accTitle: ตำแหน่งของการปรับที่สมเหตุสมผลและการปรับปรุงสภาพแวดล้อม
    accDescr: ความสัมพันธ์ระหว่างธุรกิจทั่วไปกับผู้พิการอยู่ใต้กฎหมายขจัดเลือกปฏิบัติต่อผู้พิการ และการให้การปรับที่สมเหตุสมผลโดยตอบคำร้องเฉพาะผ่านบทสนทนาเชิงสร้างสรรค์เป็นข้อผูกพันตั้งแต่เมษายน 2024 สนามการจ้างงานเป็นข้อผูกพันของนายจ้างตั้งแต่เมษายน 2016 ใต้กฎหมายส่งเสริมการจ้างงานผู้พิการ การทำให้แอปใช้ง่ายล่วงหน้าคือการปรับปรุงสภาพแวดล้อม ข้อผูกพันด้านความพยายาม
    scene{"ฉากใด"}
    scene -->|"ธุรกิจ + ความพิการ"| kaisho["กฎหมายขจัดเลือกปฏิบัติ"]
    scene -->|"การจ้างงาน / งาน"| koyou["กฎหมายการจ้างงาน"]
    kaisho --> moushide["คำร้องผ่านบทสนทนา"]
    moushide --> hairyo["ให้การปรับ"]
    hairyo -.-> hairyoN["ข้อผูกพันตั้งแต่ 2024"]
    koyou --> koyougimu["ให้การปรับ"]
    koyougimu -.-> koyouN["ข้อผูกพันตั้งแต่ 2016"]
    kaisho -.-> kankyo["แอปที่ใช้ง่ายล่วงหน้า"]
    kankyo -.-> kankyoN["ปรับปรุงสภาพแวดล้อม"]
    kankyoN -.-> kankyoN2["ข้อผูกพันด้านความพยายาม"]
    kankyo -.-> moushide

ภาพ 2: กฎหมายที่กำกับแยกตามฉาก การปรับที่สมเหตุสมผลเป็นข้อผูกพัน และการแก้ล่วงหน้าคือการปรับปรุงสภาพแวดล้อม ข้อผูกพันด้านความพยายาม

ว่ากรณีเฉพาะถูกปฏิบัติในกฎหมายอย่างไรขึ้นกับสถานการณ์ บทความนี้ไม่ก้าวเข้าการตีความกฎหมาย มันเดินจากมุมมองว่าวิศวกรทำอะไรได้เมื่อมีการขอการตอบ สำหรับแหล่งปฐมภูมิ ดูวัสดุสำนักคณะรัฐมนตรีและกระทรวงสาธารณสุข แรงงาน และสวัสดิการ¹²

2.2. JIS X 8341-3 และ WCAG — “เกณฑ์เว็บ” ขยายถึงซอฟต์แวร์ด้วย

ฝั่งเกณฑ์เทคนิคกระจุกใน JIS X 8341-3:2016 มาตรฐานนี้เป็นมาตรฐานที่สอดคล้องของ ISO/IEC 40500:2012 และตัวมาตรฐานมีเนื้อหาเดียวกับ WCAG 2.0 ของ W3C³ หากอยากรู้รูปธรรมว่า “การรองรับการเข้าถึง” ประกอบด้วยอะไร การอ่านเกณฑ์ความสำเร็จ WCAG (ตอนนี้ขยายใน WCAG 2.1/2.2) คือเส้นทางสั้นสุด และการแปลญี่ปุ่นโดย WAIC ก็เผยแพร่⁸

คำถาม “WCAG เป็นเกณฑ์สำหรับเนื้อหาเว็บหรือไม่” เป็นธรรม แต่ W3C ได้จัดใน Group Note ที่เรียก WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies) ว่าจะประยุกต์เกณฑ์ความสำเร็จ WCAG 2.0/2.1/2.2 กับเอกสารและซอฟต์แวร์ที่ไม่ใช่เว็บอย่างไร⁴ กล่าวคือ ความคิดอย่าง “ข้อความทางเลือก” “คอนทราสต์” “การใช้แป้น” และ “สีไม่ใช่ทางเดียว” ประยุกต์กับแอปเดสก์ท็อป Windows ในกรอบเดียวกับเว็บได้ บทที่ 3 เป็นต้นไปของบทความนี้ทิ้งความคิดนั้นลงการอิมพลีเมนต์ WinForms/WPF รูปธรรม

flowchart TB
    accTitle: ความสัมพันธ์ระหว่าง JIS X 8341-3 และ WCAG
    accDescr: JIS X 8341-3:2016 เป็นมาตรฐานที่สอดคล้องเนื้อหาเดียวกับ WCAG 2.0 และ WCAG2ICT แสดงวิธีประยุกต์เกณฑ์ความสำเร็จ WCAG กับซอฟต์แวร์ที่ไม่ใช่เว็บ ดังนั้นแอปเดสก์ท็อป Windows ตรวจในกรอบเดียวกันได้
    wcag["WCAG 2.0（W3C）"] ---|"มาตรฐานที่สอดคล้องเนื้อหาเดียว"| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["ประยุกต์กับซอฟต์แวร์ที่ไม่ใช่เว็บ"]
    soft --> app["แอปเดสก์ท็อป Windows"]

ภาพ 3: JIS X 8341-3:2016 เป็นมาตรฐานที่สอดคล้องของ WCAG 2.0 และ WCAG2ICT ขยายเกณฑ์เดียวกันถึงแอปเดสก์ท็อป

3. เทคโนโลยีช่วยอ่านแอปอย่างไร — สามอย่างของ UI Automation

3.1. ต้นไม้ UIA คุณสมบัติ และแพตเทิร์นควบคุม

Windows มีรากฐานการเข้าถึงที่เรียก UI Automation (UIA) สร้างใน UIA เป็นกลไกที่ให้เทคโนโลยีช่วยอย่างโปรแกรมอ่านหน้าจอได้ข้อมูล UI และปฏิบัติการ UI ด้วยทางอื่นนอกจากอินพุตมาตรฐาน และมันสื่อกลางระหว่างฝั่งแอป (ผู้ให้) กับฝั่งเทคโนโลยีช่วย (ไคลเอนต์)⁵

โลกของ UIA เข้าใจได้เป็นสามอย่างต่อไปนี้⁵

เมื่อโปรแกรมอ่านหน้าจอโฟกัสปุ่ม การประกาศ “ปุ่มยืนยันคำสั่ง” โดยคร่าวคือการรวมของ Name + ชนิดควบคุม เมื่อผู้ใช้ทำการปฏิบัติการ “ดำเนินการ” เทคโนโลยีช่วยกดปุ่มนั้นผ่านแพตเทิร์น Invoke กล่าวคือ หาก Name และแพตเทิร์นถูกเปิดเผยถูก มันอ่านและปฏิบัติการได้ หากไม่ถูกเปิดเผย มันเหมือนไม่มีอยู่แม้เห็นบนหน้าจอ

flowchart TB
    accTitle: สามอย่างของ UI Automation
    accDescr: แอปในฐานะผู้ให้เปิดเผยคุณสมบัติและแพตเทิร์นควบคุมของแต่ละองค์ประกอบบนต้นไม้ UIA โปรแกรมอ่านหน้าจอในฐานะไคลเอนต์ประกาศ Name และ ControlType และปฏิบัติการผ่านแพตเทิร์นอย่าง Invoke
    app["แอป（ผู้ให้）"] --> tree["ต้นไม้ UIA"]
    tree --> prop["คุณสมบัติ（Name, ControlType และคล้ายกัน）"]
    tree --> pat["แพตเทิร์น（Invoke, Value และคล้ายกัน）"]
    sr["โปรแกรมอ่านหน้าจอ（ไคลเอนต์）"] -->|"ประกาศ"| prop
    sr -->|"ปฏิบัติการ"| pat

ภาพ 4: โปรแกรมอ่านหน้าจอใช้คุณสมบัติและแพตเทิร์นที่แอปเปิดเผยบนต้นไม้ UIA สำหรับการประกาศและการปฏิบัติการ

3.2. โปรแกรมอ่านหน้าจอคือไคลเอนต์ UIA

โปรแกรมอ่านหน้าจอหลักที่ใช้บน Windows รวม Narrator ที่มากับ Windows NVDA¹¹ ซึ่งฟรีและโอเพนซอร์ส และ PC-Talker ผลิตภัณฑ์เชิงพาณิชย์ที่ใช้กว้างในญี่ปุ่น สไตล์การประกาศต่างกัน แต่เส้นทางหลักสำหรับอ่าน UI ของแอปเดสก์ท็อปคือ UIAในทุกกรณี นั่นคือเหตุที่การตอบฝั่งแอปไม่ใช่ “การรองรับโปรแกรมอ่านหน้าจอเฉพาะ” แต่กระจุกที่ การเปิดเผยข้อมูลที่ถูกให้ UIA

flowchart TB
    accTitle: เส้นทางร่วมของโปรแกรมอ่านหน้าจอหลัก
    accDescr: หากแอปเปิดเผยข้อมูลที่ถูกให้ UIA Narrator, NVDA และ PC-Talker อ่าน UI ด้วยเส้นทางเดียวกันได้ทั้งหมด ดังนั้นการตอบฝั่งแอปไม่มุ่งโปรแกรมอ่านหน้าจอเฉพาะ แต่กระจุกที่การเปิดเผยให้ UIA
    app["แอป"] -->|"เปิดเผยข้อมูล"| uia["UI Automation（UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["การตอบกระจุกที่การเปิดเผยให้ UIA"]

ภาพ 5: โปรแกรมอ่านหน้าจอหลักทั้งหมดถือ UIA เป็นเส้นทาง ดังนั้นการตอบของแอปกระจุกที่การเปิดเผยให้ UIA

3.3. “ปุ่มที่ Name ว่าง” ถูกประกาศเป็นอะไร

ตัวอย่างรูปธรรมหนึ่ง สมมติแถบเครื่องมือมีปุ่มเซฟที่แสดงเพียงไอคอนฟลอปปีดิสก์ ต่อผู้ใช้ที่มองเห็น ไอคอนสื่อความหมาย แต่หากปล่อย Name ว่าง โปรแกรมอ่านหน้าจอประกาศปุ่มนี้เพียงเป็น “ปุ่ม” หาก “เปิด” และ “พิมพ์” ที่ข้างเคียงเหมือนกัน ผู้ใช้ได้ยินเพียง “ปุ่ม ปุ่ม ปุ่ม” และไม่มีทางรู้ว่าอันใดคืออันใด คู่มือแก้การเข้าถึงของ Microsoft ยังระบุปุ่มที่ไม่มี Name และภาพที่ประกาศเพียงเป็น “Image” เป็นปัญหาตัวแทนที่หยุดงานของผู้ใช้⁷

โชคดีที่ทั้งตัวควบคุมมาตรฐาน WinForms และ WPF มีการรองรับ UIA ตั้งแต่ต้น และในหลายกรณี Name ถูกตัดสินอัตโนมัติจากข้อความหรือป้าย สิ่งที่พังมักเป็นอย่างใดอย่างหนึ่งใน (1) มีเพียงไอคอน ไม่มีวัสดุสำหรับชื่อ (2) ไม่มีการผูกกับป้าย หรือ (3) การวาดกำหนดเองที่ไม่ใส่ข้อมูลบนต้นไม้ UIA สองบทถัดไปดูวิธีแก้ต่อเฟรมเวิร์ก

flowchart TB
    accTitle: สามทางแบบฉบับที่การประกาศพัง
    accDescr: การประกาศพังเมื่อไม่มีวัสดุสำหรับชื่อเพราะมีเพียงไอคอน เมื่อไม่มีการผูกกับป้าย หรือเมื่อการวาดกำหนดเองไม่ใส่ข้อมูลบนต้นไม้ UIA และลงเอยถูกประกาศเพียงเป็นปุ่ม
    c1["มีเพียงไอคอน ไม่มีวัสดุ"] --> broken["Name ว่าง"]
    c2["ไม่มีการผูกกับป้าย"] --> broken
    c3["การวาดกำหนดเองไม่ส่งข้อมูล"] --> broken
    broken --> result["ประกาศเพียงเป็นปุ่ม"]

ภาพ 6: การประกาศพังมักลงที่สามแพตเทิร์น: วัสดุชื่อไม่พอ การผูกไม่พอ หรือการวาดกำหนดเอง

4. การอิมพลีเมนต์ใน WinForms — AccessibleName และลำดับแท็บ

4.1. ตัวควบคุมที่ Text กลายเป็น Name อัตโนมัติ และตัวที่ Text ไม่กลายเป็น

ใน WinForms ตัวควบคุมที่แสดงข้อความ เช่น Button หรือ CheckBox ใช้ค่าของคุณสมบัติ Text เป็น Name ของ UIA ในทางกลับกัน ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView และคล้ายกันไม่ทำให้ Text เป็น Name พวกนี้ต้องการชื่อด้วยทางอื่น⁶

ทางที่บำรุงรักษาง่ายสุดคือ วาง Label อธิบายในลำดับแท็บทันทีก่อนตัวควบคุมเป้าหมาย หากตั้ง TabIndex ของตัวควบคุมเป้าหมายให้มาทันทีหลัง TabIndex ของ Label ข้อความของ Label นั้นถูกใช้เป็น Name ของ UIA อัตโนมัติ ป้ายที่เห็นบนหน้าจอและการประกาศตรงกัน และคุณไม่ต้องจัดการถ้อยคำสองครั้ง⁶¹²

หากวาง Label ไม่ได้ ตั้ง AccessibleName ชัด คุณยังตั้ง AccessibleDescription ได้หากต้องการคำอธิบายเสริม และ AccessibleRole หากบทบาทต่างจากลักษณะ¹³

flowchart TB
    accTitle: ชื่อของตัวควบคุม WinForms ถูกตัดสินอย่างไร
    accDescr: สำหรับ Button และคล้ายกัน Text กลายเป็น Name ของ UIA ตามที่เป็น สำหรับตัวควบคุมอย่าง TextBox ที่ Text ไม่ถูกใช้ซ้ำ ข้อความของ Label ที่วางในลำดับแท็บทันทีก่อนถูกใช้ หากวาง Label ไม่ได้ ตั้ง AccessibleName ชัด
    ctrl["ตัวควบคุม"] --> qtext{"ชนิดที่ Text กลายเป็น Name หรือไม่"}
    qtext -->|"ใช่"| usetext["Text กลายเป็น Name ตามที่เป็น"]
    qtext -->|"ไม่"| qlabel{"มี Label ในลำดับแท็บทันทีก่อนหรือไม่"}
    qlabel -->|"ใช่"| uselabel["ข้อความของ Label ถูกใช้เป็น Name"]
    qlabel -->|"ไม่"| explicit["ตั้ง AccessibleName ชัด"]

ภาพ 7: สำหรับ Name ของ WinForms เลือกวิธีตัดสินตามลำดับ Text, Label ในลำดับแท็บทันทีก่อน, AccessibleName

// An icon-only toolbar button: state the name for announcement explicitly
saveToolStripButton.AccessibleName = "Save";

// An image-only button: name + a supplementary explanation
btnSearchCustomer.AccessibleName = "Search customer";
btnSearchCustomer.AccessibleDescription = "Search the customer master by customer code or name";

// Set it directly on an input field where you cannot place a Label in the immediately preceding tab order
txtOrderNo.AccessibleName = "Order number";

// A PictureBox reused as a chart display: match the role to the reality as well
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Monthly order-count chart";

ข้อควรระวัง หากตั้ง AccessibleName ครั้งหนึ่งในแผง Properties ของ Visual Studio แล้วล้าง การตั้งสตริงว่างอาจเหลือในไฟล์ดีไซเนอร์และรบกวนการแก้ชื่อเริ่มต้น ลบบรรทัดที่สอดคล้องจากไฟล์ดีไซเนอร์⁶

flowchart TB
    accTitle: ปัญหาของ AccessibleName สตริงว่างที่เหลือ
    accDescr: หากตั้ง AccessibleName ครั้งหนึ่งในแผง Properties แล้วล้าง การตั้งสตริงว่างเหลือในไฟล์ดีไซเนอร์และรบกวนการแก้ชื่อเริ่มต้น จึงแก้โดยลบบรรทัดที่สอดคล้องจากไฟล์ดีไซเนอร์
    set["ตั้ง AccessibleName"] --> erase["ล้างในแผง Properties"]
    erase --> remain["การตั้งสตริงว่างเหลือ"]
    remain --> block["รบกวนการแก้ชื่อเริ่มต้น"]
    block -.-> fix["ลบบรรทัดที่สอดคล้องจากไฟล์ดีไซเนอร์"]

ภาพ 8: การล้างในแผง Properties ยังเหลือสตริงว่าง จึงแก้โดยลบบรรทัดที่สอดคล้องจากไฟล์ดีไซเนอร์

4.2. การปรับปรุงร่วมบนหน้าจอรับคำสั่ง

ที่ที่เรามักแก้จริงในแอปธุรกิจสรุปเป็นเช็กลิสต์

แต่ละอย่างเป็นการแก้ไม่กี่บรรทัด แต่สำหรับผู้ใช้โปรแกรมอ่านหน้าจอ มันคือทางแยกระหว่าง “หน้าจอที่ใช้ไม่ได้” กับ “หน้าจอที่ใช้ได้”

5. การอิมพลีเมนต์ใน WPF — AutomationProperties และ AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

ใน WPF ตัวควบคุมที่ Content เป็นสตริง เช่น Button ใช้เนื้อหานั้นเป็น Name ของ UIA ปุ่มที่มีเพียงไอคอน (Image หรือ Path) ไม่มีวัสดุสำหรับ Name จึงระบุด้วย AutomationProperties.Name หรือหากมีข้อความแสดงใกล้เคียง ผูกด้วย AutomationProperties.LabeledBy⁷

TextBox มีข้อควรระวังสำคัญ Text ของ TextBlock ถูกใช้ซ้ำเป็น Name แต่ Text ของ TextBox ถูกเปิดเผยฝั่งคุณสมบัติ Value ของ UIA และไม่กลายเป็น Name สำหรับช่องป้อน การผูก TextBlock ป้ายแสดงกับ LabeledBy คือตัวเลือกแรก การประกาศและการแสดงบนหน้าจอตรงกัน และคุณยังหลีกการจัดการถ้อยคำสองครั้ง¹⁴

<!-- An input field: associate the display label with LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Order number" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- An icon-only button: state the name, and a supplement if needed -->
<Button
    AutomationProperties.Name="Confirm order"
    AutomationProperties.HelpText="Confirm the order being entered and allocate inventory">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: ชื่อของตัวควบคุม WPF ถูกตัดสินอย่างไร
    accDescr: ตัวควบคุมที่ Content เป็นสตริงใช้เนื้อหานั้นเป็น Name มิฉะนั้นการผูกป้ายแสดงใกล้เคียงกับ LabeledBy คือตัวเลือกแรก หากนั้นก็ไม่มี ระบุ AutomationProperties.Name Text ของ TextBox ถูกเปิดเผยฝั่ง Value ไม่ใช่เป็น Name
    ctrl["ตัวควบคุม"] --> qc{"Content เป็นสตริงหรือไม่"}
    qc -->|"ใช่"| auto["เนื้อหากลายเป็น Name"]
    qc -->|"ไม่"| ql{"มีป้ายแสดงใกล้เคียงหรือไม่"}
    ql -->|"ใช่"| lb["ผูกด้วย LabeledBy"]
    ql -->|"ไม่"| nm["ตั้ง Name ชัด"]
    tbx["Text ของ TextBox"] -.-> val["เปิดเผยเป็น Value ไม่ใช่ Name"]

ภาพ 9: สำหรับ Name ของ WPF ตัดสินตามลำดับสตริง Content, LabeledBy, การตั้งชัด Text ของ TextBox ไม่กลายเป็น Name

ข้อมูลเสริมที่ไม่พอใน Name เปิดเผยด้วย AutomationProperties.HelpText ได้⁷ นอกจากนี้ AutomationId คือตัวระบุที่ใช้ระบุองค์ประกอบในการทดสอบอัตโนมัติของ UI ดังนั้นการตัดสินแบบแผนการตั้งชื่อตอนออกแบบหน้าจอคืนทุนภายหลัง (ครอบคลุมลึกใน “การทดสอบอัตโนมัติของ UI สำหรับแอปเดสก์ท็อป Windows”)

5.2. ตัวควบคุมกำหนดเองต้องการ AutomationPeer

ตัวควบคุมกำหนดเองที่คุณวาดเอง ตามที่เป็น ไม่สามารถเปิดเผยข้อมูลที่มีความหมายบนต้นไม้ UIA ใน WPF คุณโอเวอร์ไรด์ OnCreateAutomationPeer บนคลาสที่สืบจาก UIElement และคืนคลาสที่สืบจาก AutomationPeer เพื่อเปิดเผยชื่อ ชนิด และแพตเทิร์น หากสืบทอดตัวควบคุมที่มีอยู่ การสืบทอด Peer ที่สอดคล้อง (ButtonBaseAutomationPeer สำหรับ ButtonBase) ให้คุณรับพฤติกรรมที่อิมพลีเมนต์แล้วต่อ¹⁵

flowchart TB
    accTitle: ข้อมูลถูกเปิดเผยผ่าน AutomationPeer อย่างไร
    accDescr: ตัวควบคุมกำหนดเองเปิดเผยชื่อ ชนิด และแพตเทิร์นโดยโอเวอร์ไรด์ OnCreateAutomationPeer และคืนคลาสที่สืบจาก AutomationPeer หากสืบทอดตัวควบคุมที่มีอยู่ สืบทอด Peer ที่สอดคล้องและรับพฤติกรรมที่อิมพลีเมนต์แล้วต่อ
    custom["ตัวควบคุมกำหนดเอง"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["คืนคลาสที่สืบจาก Peer"]
    peer --> pub["เปิดเผยชื่อ ชนิด และแพตเทิร์น"]
    inherit["สืบทอดตัวควบคุมที่มีอยู่"] -.-> basepeer["สืบทอด Peer ที่สอดคล้อง"]
    basepeer -.-> reuse["รับพฤติกรรมที่อิมพลีเมนต์แล้วต่อ"]

ภาพ 10: ตัวควบคุมกำหนดเองคืน Peer จาก OnCreateAutomationPeer และเปิดเผยข้อมูลให้ UIA

// An example of a control that custom-draws line status as a coloured lamp
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "Line status: online" : "Line status: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Raise a UIA property-changed event the moment the value changes. Without this,
        // a screen reader keeps the old name and cannot notice the change of state
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Text-equivalent if it is a status display with no operation

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

การคืนชื่อไม่พอ การบอกด้วยอีเวนต์ในขณะที่มันเปลี่ยน ก็เป็นงานของ Peer ด้วย เทคโนโลยีช่วยไม่มีจังหวะของตัวเองในการดึงค่าใหม่ ดังนั้นการอิมพลีเมนต์ที่ไม่ยกอีเวนต์เปลี่ยนอยู่ในสถานะ “ถูกเฉพาะเมื่อถูกถามอีก” และผู้ใช้โปรแกรมอ่านหน้าจอไม่ถูกบอกการเปลี่ยนสถานะ

sequenceDiagram
    accTitle: ไหลของการบอกโปรแกรมอ่านหน้าจอเรื่องการเปลี่ยนสถานะ
    accDescr: ในขณะที่ค่าของตัวควบคุมเปลี่ยน AutomationPeer ยกอีเวนต์คุณสมบัติ Name ที่เปลี่ยน เทคโนโลยีช่วยไม่ดึงใหม่เอง ดังนั้นหากไม่มีอีเวนต์มันค้างที่ชื่อเก่าและสังเกตการเปลี่ยนไม่ได้
    participant c as ตัวควบคุม
    participant p as AutomationPeer
    participant s as โปรแกรมอ่านหน้าจอ
    c->>p: ค่า IsOnline เปลี่ยน
    p->>s: ยกอีเวนต์คุณสมบัติ Name ที่เปลี่ยน
    s->>s: ประกาศสถานะใหม่
    Note over s: หากไม่มีอีเวนต์มันค้างที่ชื่อเก่า

ภาพ 11: การเปลี่ยนค่าถึงโปรแกรมอ่านหน้าจอเฉพาะเมื่อ AutomationPeer บอกด้วยอีเวนต์เปลี่ยน

หากตัวควบคุมกำหนดเองมีการปฏิบัติการ (กดได้ เปลี่ยนค่าได้ เลือกได้) คุณโอเวอร์ไรด์ GetPattern และให้ส่วนต่อประสานแพตเทิร์นอย่าง IInvokeProvider หรือ IRangeValueProvider¹⁵ จุดคือ หากคุณสร้าง Peer ด้วยฝั่งไลบรารีตัวควบคุมร่วม ทุกหน้าจอที่ใช้มันถูกรองรับอัตโนมัติ นั่นคือรากฐานของ “ขยายข้าง” ในบทที่ 9

6. ถึงทุกฟังก์ชันจากแป้นอย่างเดียวได้หรือไม่

เกณฑ์ความสำเร็จ WCAG 2.1.1 (Keyboard) กำหนดว่าฟังก์ชันทั้งหมดของเนื้อหาปฏิบัติการผ่านส่วนต่อประสานแป้นได้⁸ ผู้ใช้โปรแกรมอ่านหน้าจอโดยหลักไม่ใช้เมาส์ ดังนั้น ฟังก์ชันที่ถึงจากแป้นไม่ได้เหมือนฟังก์ชันที่ไม่มีอยู่ มุมตรวจมีดังนี้

วอล์กทรูการเข้าถึงของ WinForms ยังระบุเป็นพื้นฐาน การวางป้ายในลำดับแท็บทันทีก่อนช่องป้อน และการใส่แป้นลัดเข้าถึงบนตัวควบคุมและเมนูที่ผู้ใช้ต้องการไป¹²

สิ่งที่เราอยากเน้นคือ นี่ไม่ใช่ “ต้นทุนพิเศษสำหรับการรองรับความพิการ” ในงานประจำอย่างการรับคำสั่ง ว่าคุณป้อนให้เสร็จโดยไม่ยกมือจากตำแหน่งบ้านได้หรือไม่ คือสิ่งที่ตัดสินอัตราของผู้ปฏิบัติตามที่เป็น ลำดับแท็บที่ไร้ระเบียบหรือปฏิบัติการที่ต้องเมาส์คือข้อบกพร่องที่โกนผลิตภาพของผู้ใช้ทุกคนทุกวันเล็กน้อย การรองรับการเข้าถึงและประสิทธิภาพแป้นเป็นเพียงสองชื่อของงานเดียวกัน (สำหรับลำดับความสำคัญตามสภาพแวดล้อมการใช้ ดู “การออกแบบ UX ของแอป Windows”)

flowchart TB
    accTitle: ผลคู่ของการจัดแป้นให้เป็นระเบียบ
    accDescr: การวางลำดับแท็บ แป้นลัดเข้าถึง และการบ่งชี้โฟกัสให้ผลสองอย่างพร้อมกัน ผู้ใช้เทคโนโลยีช่วยถึงฟังก์ชันได้ และความเร็วป้อนของผู้ปฏิบัติทุกคน และฟังก์ชันที่ใช้ได้เฉพาะด้วยเมาส์เหมือนฟังก์ชันที่ไม่มีอยู่
    seibi["จัดแป้นให้เป็นระเบียบ"] --> a11y["ผู้ใช้เทคโนโลยีช่วย"]
    seibi --> speed["ความเร็วของผู้ปฏิบัติทุกคน"]
    mouse["ฟังก์ชันเฉพาะเมาส์"] -.-> none["เหมือนไม่มีอยู่"]

ภาพ 12: การจัดการใช้แป้นให้เป็นระเบียบทำให้การรองรับเทคโนโลยีช่วยและประสิทธิภาพของผู้ใช้ทุกคนเกิดพร้อมกัน ฟังก์ชันเฉพาะเมาส์เหมือนไม่มีอยู่

7. สีและคอนทราสต์ — 4.5:1 และ “สีไม่ใช่ทางเดียว”

7.1. แนวทางของอัตราส่วนคอนทราสต์คือ 4.5:1

เกณฑ์ความสำเร็จ WCAG 1.4.3 (Contrast (Minimum)) กำหนดอัตราส่วนคอนทราสต์ อย่างน้อย 4.5:1 สำหรับข้อความและภาพของข้อความ และอย่างน้อย 3:1 สำหรับข้อความใหญ่⁸ การออกแบบสมัยใหม่ที่วางข้อความเทาอ่อนบนพื้นขาวไม่ใช่เรื่องหายากที่ตกต่ำกว่าเกณฑ์นี้ ผู้ใช้แอปธุรกิจรวมคนที่สายตาและการเห็นสีเปลี่ยนตามอายุ และคนที่ใช้ในสภาพแวดล้อมแสงน้อยอย่างโรงงาน ทำให้เป็นนิสัยวัดด้วยตัวตรวจคอนทราสต์ตอนตรวจทานการออกแบบ

7.2. อย่าสื่อสารข้อมูลด้วยสีอย่างเดียว

เกณฑ์ความสำเร็จ 1.4.1 (Use of Color) คือสีต้องไม่เป็นทางภาพเดียวของการสื่อสารข้อมูล⁸ ตัวอย่างแบบฉบับในแอปธุรกิจมีดังนี้

• แสดงแถวข้อผิดพลาดด้วยข้อความแดงอย่างเดียว → ให้ไอคอนข้อผิดพลาดและคอลัมน์ข้อความด้วย
• แสดงช่องบังคับด้วยสีป้ายอย่างเดียว → เพิ่ม “*” หรือถ้อยคำ “บังคับ”
• แสดงสถานะด้วยสีโคมอย่างเดียว → ทำให้เป็นสี + รูปทรง หรือถ้อยคำ (“กำลังรัน” “หยุด”)

เมื่อพิจารณาความหลากหลายของการเห็นสี นี่ก็ไม่ใช่ “การตอบพิเศษ” แต่เป็นพื้นฐานของการออกแบบการแสดง

flowchart TB
    accTitle: แทนข้อมูลที่สื่อด้วยสีอย่างเดียว
    accDescr: การแสดงที่แสดงข้อผิดพลาดด้วยข้อความแดงอย่างเดียวถูกแทนด้วยไอคอนข้อผิดพลาดบวกคอลัมน์ข้อความ การแสดงที่แสดงช่องบังคับด้วยสีป้ายอย่างเดียวถูกแทนด้วยการเพิ่มถ้อยคำบังคับ การแสดงที่แสดงสถานะด้วยสีโคมอย่างเดียวถูกแทนด้วยการรวมรูปทรงหรือถ้อยคำ
    err["ข้อผิดพลาดด้วยข้อความแดงอย่างเดียว"] --> erra["ให้ไอคอนและถ้อยคำด้วย"]
    req["บังคับด้วยสีป้ายอย่างเดียว"] --> reqa["เพิ่มถ้อยคำบังคับ"]
    lamp["สถานะด้วยสีโคมอย่างเดียว"] --> lampa["รวมสีกับรูปทรงหรือถ้อยคำ"]

ภาพ 13: ตัวอย่างแบบฉบับของการสื่อด้วยสีอย่างเดียวถูกแทนด้วยการรวมไอคอน ถ้อยคำ และรูปทรงหรือข้อความ

7.3. ตามธีมคอนทราสต์ (คอนทราสต์สูง)

Windows มีธีมคอนทราสต์ (เดิมคอนทราสต์สูง) ที่สลับไปสคีมสีที่มีการแยกพื้นหน้าและพื้นหลังแรง ผู้ใช้เลือกและแก้ไขธีมที่สร้างในซึ่งออกแบบให้อัตราส่วนคอนทราสต์โดยทั่วไป 7:1 ขึ้นไปได้⁹ หลักฝั่งแอปเรียบง่าย: อย่าฮาร์ดโค้ดสี เคารพสีระบบ

• WinForms: หากปล่อย ForeColor/BackColor ที่ค่าเริ่มต้น การตั้งสีของผู้ใช้ถูกใช้ ที่ที่คุณใส่สีของตัวเอง ตัดสินด้วย SystemInformation.HighContrast สลับไปสคีมฐาน SystemColors และตามการเปลี่ยนการตั้งด้วยอีเวนต์ UserPreferenceChanged¹²
• WPF/WinUI: หากอ้างทรัพยากรคลาส SystemColors คุณตามการสลับธีม ที่ที่คุณเติมด้วยแปรงของตัวเองกลายเป็นสาเหตุของการพัง⁹

flowchart TB
    accTitle: การตามธีมคอนทราสต์
    accDescr: ที่ที่สีถูกฮาร์ดโค้ดพังตอนสลับไปธีมคอนทราสต์ จึงสลับไปสคีมฐาน SystemColors และตามด้วยอีเวนต์การเปลี่ยนการตั้ง หากอ้างสีระบบ คุณตามสีของผู้ใช้อัตโนมัติได้
    theme["สลับไปธีมคอนทราสต์"] --> qh{"สีถูกระบุอย่างไร"}
    qh -->|"ฮาร์ดโค้ด"| broken["สคีมสีพัง"]
    qh -->|"อ้างสีระบบ"| ok["ตามสีของผู้ใช้อัตโนมัติ"]
    broken -.-> fix["สลับไป SystemColors"]
    fix -.-> ev["ตามด้วยอีเวนต์การเปลี่ยนการตั้ง"]

ภาพ 14: เฉพาะที่ที่สีถูกฮาร์ดโค้ดพังใต้ธีมคอนทราสต์ การอ้างสีระบบตามอัตโนมัติ

นอกจากนี้ ผู้ใช้สายตาต่ำมักใช้การขยาย OS สูง (การสเกล DPI) ดังนั้น การรองรับ DPI สูงก็เป็นส่วนของการรองรับการเข้าถึง แอปที่เลย์เอาต์พังที่ 125%–200% ใช้ไม่ได้ ณ จุดนั้น ดู “การรองรับ DPI สูงใน WinForms” และ “การรองรับ DPI สูงของ WPF” สำหรับรายละเอียด

8. การยืนยันในทางปฏิบัติ — Accessibility Insights และการตรวจด้วยมือด้วยโปรแกรมอ่านหน้าจอ

8.1. Accessibility Insights for Windows

Microsoft ให้ Accessibility Insights for Windows เป็นเครื่องมือยืนยันการเข้าถึงสำหรับแอป Windows มีการใช้หลักสามอย่าง¹⁰

• Live Inspect: เพียงโฮเวอร์เมาส์เหนือองค์ประกอบหรือโฟกัสด้วยแป้น และคุณยืนยันคุณสมบัติ UIA ของมันได้ (Name, ControlType, แพตเทิร์น และคล้ายกัน) ทางสั้นสุดที่จะเห็น “Name ของปุ่มนี้คืออะไร”
• FastPass: การตรวจเบาที่ตรวจปัญหาการเข้าถึงผลกระทบสูงในไม่ถึงห้านาที ปัญหาที่ตัดสินเชิงกลไกได้ เช่น Name ที่ขาด ทำรายการต่อหน้าจอใหม่ได้
• Troubleshooting: ช่วยวินิจฉัยและแก้ปัญหาเฉพาะ จากปัญหาที่ตรวจ คุณเดินตรงไปคู่มือแก้ต่อเฟรมเวิร์กที่บทความนี้ยังอ้างได้

Inspect.exe และ AccEvent ที่รวมใน Windows SDK ยืนยันต้นไม้ UIA และคุณสมบัติได้เช่นกัน แต่ถูกวางเป็นเครื่องมือมรดก และการย้ายไป Accessibility Insights ถูกแนะนำตอนนี้¹⁰

flowchart TB
    accTitle: สามการใช้ของ Accessibility Insights
    accDescr: Accessibility Insights for Windows ให้การยืนยันคุณสมบัติ UIA ด้วย Live Inspect การตรวจเบาของปัญหาผลกระทบสูงด้วย FastPass และการช่วยวินิจฉัยและแก้ปัญหาด้วย Troubleshooting การย้ายจากเครื่องมือมรดกอย่าง Inspect.exe ถูกแนะนำ
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["ยืนยันคุณสมบัติ UIA"]
    fast --> fastf["ตรวจปัญหาผลกระทบสูง"]
    ts --> tsf["ช่วยวินิจฉัยและแก้"]
    legacy["Inspect.exe และคล้ายกัน"] -.->|"แนะนำให้ย้าย"| ai

ภาพ 15: Accessibility Insights มีสามการใช้คือยืนยัน ตรวจ และวินิจฉัย และเป็นปลายทางของการย้ายจากเครื่องมือมรดก

8.2. การตรวจด้วยมือด้วยโปรแกรมอ่านหน้าจอ

สิ่งที่การตรวจอัตโนมัติของเครื่องมือตรวจได้มีเพียงปัญหาที่ตัดสินเชิงกลไกได้ ท้ายสุด เดินการปฏิบัติงานจริงด้วยโปรแกรมอ่านหน้าจอเสมอ Narrator ที่มากับ Windows สตาร์ตทันทีด้วย Ctrl+ปุ่ม Windows+Enter และ NVDA นำเข้าฟรีได้¹¹ เคล็ดของการตรวจคือลอง โดยไม่มองหน้าจอ (หรือปิดจอ) พึ่งเพียงการประกาศ ว่าคุณทำงานจริงอย่าง “ป้อนคำสั่งหนึ่งและยืนยัน” ให้เสร็จได้หรือไม่ ปัญหาอย่างมีชื่อแต่ลำดับประกาศไม่ต่อเนื่อง หรือโฟกัสหลุดนอกโมดอล พบได้เฉพาะด้วยมือ

flowchart TB
    accTitle: รวมการยืนยันด้วยเครื่องมือและการตรวจด้วยมือ
    accDescr: สิ่งที่การตรวจอัตโนมัติอย่าง FastPass ตรวจได้มีเพียงปัญหาที่ตัดสินเชิงกลไกได้ ส่วนที่เหลือพบด้วยมือโดยเดินการปฏิบัติงานจริงด้วยโปรแกรมอ่านหน้าจอและหาปัญหาลำดับประกาศและโฟกัส
    tool["การตรวจอัตโนมัติของเครื่องมือ"] --> kikai["ปัญหาที่ตัดสินเชิงกลไกได้"]
    tool -.-> nokori["ปัญหาที่ตรวจไม่ได้เหลือ"]
    nokori --> sr["การตรวจด้วยมือด้วยโปรแกรมอ่านหน้าจอ"]
    sr --> task["เดินการปฏิบัติงาน"]
    task --> mieru["ปัญหาลำดับประกาศและโฟกัส"]

ภาพ 16: ทำรายการปัญหาเชิงกลไกด้วยการตรวจอัตโนมัติ และหาส่วนที่เหลือด้วยการตรวจด้วยมือด้วยโปรแกรมอ่านหน้าจอ

8.3. สร้างเข้าไหลพัฒนา และการคืนทุนร่วมกับการทดสอบอัตโนมัติของ UI

เพื่อให้การยืนยันไม่ขึ้นกับคน เราแนะนำให้สร้างเช็กลิสต์ต่อไปนี้เข้าข้อตรวจทานสำหรับหน้าจอใหม่

และอีกอย่างหนึ่ง การทดสอบอัตโนมัติของ UI ด้วย FlaUI และคล้ายกันสร้างบน UIA เดียวกันที่โปรแกรมอ่านหน้าจอใช้ Name และแพตเทิร์นที่คุณวางเพื่อการเข้าถึงกลายเป็นชิ้นของโค้ดทดสอบ และ AutomationId ที่ออกแบบสำหรับทดสอบทำให้การดีบักใน Live Inspect ง่ายขึ้น ในทางกลับกัน UI ที่ไม่ปรากฏในต้นไม้ UIA มองไม่เห็นทั้งต่อการทดสอบและต่อเทคโนโลยีช่วย การเข้าถึงและความสามารถทดสอบเป็นสองด้านของการลงทุนเดียวกัน (“การทดสอบอัตโนมัติของ UI สำหรับแอปเดสก์ท็อป Windows”)

flowchart TB
    accTitle: การคืนทุนร่วมของการเข้าถึงและการทดสอบอัตโนมัติของ UI
    accDescr: โปรแกรมอ่านหน้าจอและการทดสอบอัตโนมัติของ UI อย่าง FlaUI สร้างบน UIA เดียวกัน ดังนั้น Name และแพตเทิร์นที่คุณวางใช้จากทั้งคู่ได้ และ UI ที่ไม่ปรากฏในต้นไม้ UIA มองไม่เห็นจากฝ่ายใด
    uia["จัดต้นไม้ UIA ให้เป็นระเบียบ"] --> sr["โปรแกรมอ่านหน้าจออ่านได้"]
    uia --> test["ใช้ในการทดสอบอัตโนมัติของ UI ได้"]
    sr -.-> both["สองด้านของการลงทุนเดียวกัน"]
    test -.-> both
    hidden["UI ที่ไม่ปรากฏใน UIA"] -.-> invisible["มองไม่เห็นจากฝ่ายใด"]

ภาพ 17: เพราะนั่งบนรากฐาน UIA เดียวกัน การจัดต้นไม้ UIA ให้เป็นระเบียบคืนทุนทั้งต่อเทคโนโลยีช่วยและต่อการทดสอบอัตโนมัติของ UI

9. วิธีตั้งลำดับความสำคัญ — อย่าแก้ทุกหน้าจอพร้อมกัน

การแก้ระบบหลักหลายร้อยหน้าจอพร้อมกันไม่สมจริงทั้งต้นทุนและคุณภาพ แนวทางที่เราแนะนำคือสามชั้นต่อไปนี้

1. แก้จากหน้าจอที่ผู้ใช้นั้นใช้ในงาน การปรับที่สมเหตุสมผลคือกระบวนการตอบเฉพาะต่อคำร้องจากผู้เกี่ยวข้อง¹ ก่อนอื่นให้ผู้คนปฏิบัติงานจริงด้วยโปรแกรมอ่านหน้าจอ และระบุด้วยกันว่าติดตรงไหน ในหลายกรณีหน้าจอที่ใช้ในงานประจำวันแคบเหลือไม่กี่หน้าถึงสิบกว่า และปัญหาถึงตายในนั้น (ปุ่มไม่มีชื่อ ปุ่มยืนยันที่กดจากแป้นไม่ได้) แก้ได้ในการแก้ไม่กี่วัน
2. ทำให้การพัฒนาใหม่เป็นไปตามมาตรฐาน เพิ่มเช็กลิสต์ของบทที่ 8 เข้า Definition of Done และสร้างหน้าจอใหม่ให้รองรับตั้งแต่ต้น ต่างจากการแก้หลังเกิด การเพิ่มต้นทุนของการสร้างเข้าตอนออกแบบเล็กน้อย
3. ขยายข้างโดยแก้ตัวควบคุมร่วม หากอิมพลีเมนต์ AccessibleName เริ่มต้นหรือ AutomationPeer บนชิ้นส่วนในองค์กรร่วมอย่างกล่องโต้ตอบค้นหา กริด หรือการป้อนวันที่ มันมีผลเป็นชุดบนทุกหน้าจอที่ใช้มัน มันเป็นการเคลื่อนที่ที่คุ้มต้นทุนกว่าการแตะหน้าจอเฉพาะทีละอันมาก

flowchart TB
    accTitle: สามชั้นของลำดับความสำคัญการแก้
    accDescr: แก้จากหน้าจอที่ผู้ใช้ใช้ในงาน ทำให้การพัฒนาใหม่เป็นไปตามมาตรฐานด้วยเช็กลิสต์ และขยายถึงทุกหน้าจอโดยแก้ตัวควบคุมร่วม
    s1["1. แก้จากหน้าจอที่ผู้ใช้ใช้"] --> s2["2. งานใหม่เป็นไปตามมาตรฐาน"] --> s3["3. ขยายข้างด้วยตัวควบคุมร่วม"]
    s3 -.-> all["มีผลเป็นชุดบนทุกหน้าจอที่ใช้มัน"]

ภาพ 18: ก้าวไม่ด้วยการแก้ทุกหน้าจอพร้อมกัน แต่ในสามชั้นของหน้าจอที่ใช้อยู่ งานใหม่ และชิ้นส่วนร่วม

และ บันทึกของบทสนทนา สำคัญเท่าการตอบทางเทคนิค การปรับที่สมเหตุสมผลคือกระบวนการ “สนทนาและปรับเฉพาะ” ไม่ใช่การตอบทุกคำร้องเต็ม การพิจารณทางเลือกกับผู้คน (ทำงานนั้นบนหน้าจออื่น เตรียมการส่งออก CSV ครอบคลุมในการดำเนินงาน) และตกลง สำหรับการแก้ที่ภาระหนักเกินไป ก็เป็นผลลัพธ์ชอบธรรมของบทสนทนาเชิงสร้างสรรค์¹ การบันทึกว่าขออะไร ตอบอะไร และทำให้เป็นทางเลือกอะไร กลายเป็นหลักฐานความสุจริตขององค์กร

flowchart TB
    accTitle: ไหลของบทสนทนาเชิงสร้างสรรค์และบันทึก
    accDescr: ตอบคำร้องจากผู้พิการผ่านบทสนทนาเชิงสร้างสรรค์ ทำการแก้ที่ตอบได้ สำหรับการแก้ที่ภาระหนักเกินไป พิจารณทางเลือกกับผู้คนและตกลง บันทึกว่าขออะไร ตอบอะไร และทำให้เป็นทางเลือกอะไร
    req["คำร้อง"] --> talk["บทสนทนาเชิงสร้างสรรค์"]
    talk --> q{"ภาระหนักเกินไปหรือไม่"}
    q -->|"ไม่"| kaishu["ตอบด้วยการแก้"]
    q -->|"ใช่"| alt["พิจารณทางเลือกและตกลง"]
    kaishu --> rec["บันทึกประวัติ"]
    alt --> rec

ภาพ 19: ในบทสนทนาเชิงสร้างสรรค์คุณตกลงกับผู้คนเรื่องการแก้หรือทางเลือก และเหลือประวัตินั้นในบันทึก

10. สรุป

• ด้วยกฎหมายแก้ไขว่าด้วยการขจัดเลือกปฏิบัติต่อผู้พิการที่มีผลเมษายน 2024 การให้การปรับที่สมเหตุสมผลกลายเป็นข้อผูกพันของธุรกิจด้วย สนามการจ้างงานเป็นข้อผูกพันของนายจ้างตั้งแต่ 2016 ใต้กฎหมายส่งเสริมการจ้างงานผู้พิการ การทำให้แอปใช้ง่ายล่วงหน้าคือ “การปรับปรุงสภาพแวดล้อม” (ข้อผูกพันด้านความพยายาม) และยิ่งไปไกล การตอบเฉพาะก็เบาลง
• เกณฑ์เทคนิคกระจุกใน WCAG (JIS X 8341-3:2016) และความคิดเดียวกันประยุกต์กับแอปเดสก์ท็อปผ่าน WCAG2ICT ได้
• โปรแกรมอ่านหน้าจออ่านแอปผ่าน UI Automation สามอย่างของต้นไม้ UIA คุณสมบัติ (Name/ControlType/AutomationId) และแพตเทิร์นควบคุมคือรากฐาน
• ลำดับสูงสุดคือ Name WinForms ใช้ AccessibleName และการผูก Label กับลำดับแท็บ WPF ใช้ AutomationProperties.Name/LabeledBy ตัวควบคุมกำหนดเองใช้ AutomationPeer
• การถึงทุกฟังก์ชันจากแป้นอย่างเดียวเป็นเกณฑ์ความสำเร็จ WCAG และในเวลาเดียวกันคือผลิตภาพของผู้ปฏิบัติทุกคน จัดลำดับแท็บ แป้นลัดเข้าถึง และการบ่งชี้โฟกัสให้เป็นระเบียบ
• สามพื้นฐานของสีคืออัตราส่วนคอนทราสต์ 4.5:1 สีไม่ใช่ทางเดียว และการเคารพสีระบบในธีมคอนทราสต์
• รวมการยืนยันด้วย FastPass+Live Inspect ใน Accessibility Insights และการตรวจด้วยมือด้วย Narrator/NVDA และสร้างเข้าไหลพัฒนาเป็นเช็กลิสต์สำหรับหน้าจอใหม่
• อย่าแก้ทุกหน้าจอพร้อมกัน ก้าวตามลำดับหน้าจอที่ผู้ใช้ใช้ → การรองรับมาตรฐานสำหรับงานใหม่ → การขยายข้างของตัวควบคุมร่วม การปรับที่สมเหตุสมผลคือกระบวนการบทสนทนา และบันทึกประวัติปกป้ององค์กร

เป็นก้าวแรก เราแนะนำให้เลือกหนึ่งในหน้าจอหลักของคุณ รัน FastPass ใน Accessibility Insights for Windows แล้วเดินงานด้วยปุ่ม Tab อย่างเดียว ในสามสิบนาที ตำแหน่งปัจจุบันของแอปคุณเองกลายเป็นรูปธรรมอย่างน่าประหลาด

บทความที่เกี่ยวข้อง

• การทดสอบอัตโนมัติของ UI สำหรับแอปเดสก์ท็อป Windows — UI Automation ทำงานอย่างไร และการสร้างการทดสอบที่แข็งด้วย FlaUI
• การออกแบบ UX ของแอป Windows - ลำดับความสำคัญตามสภาพแวดล้อมการใช้
• การรองรับ DPI สูงใน WinForms — ทำไม UI จึงเบลอหรือพังบนจอ 4K และการแก้ปฏิบัติ
• การรองรับ DPI สูงของ WPF — ทำไมยังเบลอและเลือดแม้ “ควรจะรู้ DPI” และวิธีแก้
• ทำไม KomuraSoft จึงสร้างเว็บไซต์บนระบบออกแบบของสำนักงานดิจิทัล — ต้นทุนต่ำและคุณภาพสูงอยู่ร่วมได้
• กับดักแบบอักษรและอักขระญี่ปุ่น — จัดการ JIS2004, IVS และไกจิในแอปธุรกิจ

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับการแก้การเข้าถึงของแอปธุรกิจ WinForms/WPF (การรองรับโปรแกรมอ่านหน้าจอ การจัดการใช้แป้นให้เป็นระเบียบ การรองรับธีมคอนทราสต์) การอิมพลีเมนต์ AutomationPeer บนตัวควบคุมร่วม และการปรึกษาเรื่องการวินิจฉัยสถานะปัจจุบันและการตั้งลำดับความสำคัญด้วย Accessibility Insights เริ่มจากขั้น “อยากยืนยันว่าพนักงานใช้แอปเราด้วยโปรแกรมอ่านหน้าจอได้หรือไม่” ก็ได้

• การพัฒนาแอปพลิเคชัน Windows
• ที่ปรึกษาด้านเทคนิคและการตรวจทานการออกแบบ
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

การรองรับการเข้าถึงของแอปธุรกิจเป็นข้อผูกพันทางกฎหมายหรือไม่

การแก้ไขปี 2021 ของกฎหมายว่าด้วยการขจัดเลือกปฏิบัติต่อผู้พิการมีผลวันที่ 1 เมษายน 2024 และการให้การปรับที่สมเหตุสมผลแก่ผู้พิการกลายเป็นข้อผูกพันของธุรกิจด้วย การปรับที่สมเหตุสมผลคือการตอบเมื่อผู้พิการร้องขอ ที่ถอดกำแพงเฉพาะภายในขอบที่ไม่เป็นภาระเกิน การทำให้แอปใช้ง่ายล่วงหน้าถูกวางเป็นข้อผูกพันด้านความพยายามที่เรียก "การปรับปรุงสภาพแวดล้อม" การจ้างงาน เช่น ความสัมพันธ์ระหว่างพนักงานกับบริษัท ไม่อยู่ใต้กฎหมายนั้นแต่ใต้กฎหมายส่งเสริมการจ้างงานผู้พิการ ซึ่งผูกพันนายจ้างให้การปรับที่สมเหตุสมผลตั้งแต่การแก้ไขที่มีผลเมษายน 2016 กล่าวคือสถานการณ์ "พนักงานใช้แอปธุรกิจไม่ได้" อยู่ในอาณาเขตข้อผูกพันมานานแล้ว ว่าจะไปไกลแค่ไหนในแต่ละกรณีขึ้นกับสถานการณ์เฉพาะ จึงยืนยันแหล่งปฐมภูมิจากสำนักคณะรัฐมนตรีและกระทรวงสาธารณสุข แรงงาน และสวัสดิการ และตัดสินผ่านบทสนทนากับผู้เกี่ยวข้อง

โปรแกรมอ่านหน้าจออ่านแอปเดสก์ท็อป Windows อย่างไร

โปรแกรมอ่านหน้าจออย่าง Narrator และ NVDA อ่าน UI ของแอปผ่านรากฐานการเข้าถึงที่เรียก UI Automation (UIA) ฝั่งแอปเปิดเผยองค์ประกอบบนหน้าจอในโครงที่เรียกต้นไม้ UIA แต่ละองค์ประกอบมีคุณสมบัติเช่น Name (จุดประสงค์) และ ControlType (ชนิด) และแพตเทิร์นควบคุมเช่น Invoke (กด) และ Value (ค่า) โปรแกรมอ่านหน้าจอประกาศข้อมูลนี้เป็น "ปุ่มยืนยันคำสั่ง" และปฏิบัติการผ่านแพตเทิร์น ตัวควบคุมมาตรฐานของ WinForms และ WPF มีกลไกนี้ตั้งแต่ต้น ดังนั้นงานหลักของนักพัฒนาคือไม่ปล่อย Name ว่าง ทำให้ UI ใช้จากแป้นได้ และอิมพลีเมนต์ข้อมูลบนตัวควบคุมกำหนดเอง

บนแอป WinForms ที่มีอยู่แล้ว ควรเริ่มจากอะไร

เส้นทางสั้นสุดคือรัน FastPass ใน Accessibility Insights for Windows กับหน้าจอเป้าหมาย และทำรายการตัวควบคุมที่ Name ว่างกับปัญหาลำดับแท็บ การแก้เริ่มจากตั้ง AccessibleName บนปุ่มที่มีเพียงไอคอน ผูก Label ในลำดับแท็บทันทีก่อนช่องป้อน และจัด TabIndex ให้ตรงลำดับภาพ จากนั้นสตาร์ต Narrator หรือ NVDA และเดินการปฏิบัติงานจริงโดยไม่มองหน้าจอ เพื่อยืนยันว่าติดตรงไหน ไม่ต้องแก้ทุกหน้าจอพร้อมกัน เริ่มจากหน้าจอที่ใครใช้จริง และทำให้หน้าจอใหม่เป็นไปตามมาตรฐานด้วยเช็กลิสต์ คือสมจริง

ควรทำอย่างไรสำหรับการรองรับคอนทราสต์สูง (ธีมคอนทราสต์)

เส้นฐานคือไม่ฮาร์ดโค้ดสีและเคารพสีระบบ ใน WinForms ปล่อย ForeColor/BackColor ที่ค่าเริ่มต้นหรือใช้ SystemColors ตัดสินสถานะด้วย SystemInformation.HighContrast และตามการสลับด้วยอีเวนต์ UserPreferenceChanged ใน WPF และ WinUI เช่นกัน หากอ้างทรัพยากรคลาส SystemColors คุณตามการสลับธีมอัตโนมัติ ในเวลาเดียวกัน หยุดสื่อสารข้อมูล "ด้วยสีอย่างเดียว" เช่น แสดงข้อผิดพลาดเป็นแดงอย่างเดียว และรวมกับไอคอนหรือถ้อยคำ แม้ในธีมธรรมดา การถือเกณฑ์ WCAG ของอัตราส่วนคอนทราสต์ข้อความ 4.5:1 ขึ้นไปเป็นแนวทางยังทำให้ UI อ่านง่ายขึ้นสำหรับพื้นโรงงานแสงน้อยและผู้ใช้สูงวัย

การรองรับการเข้าถึงช่วยการทดสอบอัตโนมัติของ UI ด้วยหรือไม่

ช่วย เครื่องมือทดสอบอัตโนมัติของ UI อย่าง FlaUI สร้างบน UI Automation เดียวกันที่โปรแกรมอ่านหน้าจอใช้ Name, ControlType และแพตเทิร์นควบคุมที่คุณวางเพื่อการเข้าถึงใช้จากโค้ดทดสอบได้ตามที่เป็น และการออกแบบ AutomationId สำหรับทดสอบทำให้การระบุองค์ประกอบเสถียร ในทางกลับกัน UI ที่วาดกำหนดเองซึ่งไม่ปรากฏในต้นไม้ UIA มองไม่เห็นทั้งต่อโปรแกรมอ่านหน้าจอและต่อการทดสอบ การเข้าถึงและการทดสอบอัตโนมัติเป็นการลงทุนในรากฐานเดียวกัน ดังนั้นการวางอย่างใดอย่างหนึ่งยังลดต้นทุนของอีกอย่าง

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก