คำโกหกของโหมดข้อความ: ทำไม TUI ยุคใหม่จึงเป็นฝันร้ายสำหรับการเข้าถึง

 (xogium.me)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สมมติฐานที่ว่าแอปเทอร์มินัลซึ่งอิงข้อความนั้นเข้าถึงได้โดยธรรมชาติใช้ไม่ได้อีกต่อไปใน TUI สมัยใหม่ และเฟรมเวิร์กอย่าง Ink, Bubble Tea, tcell อาจสร้างสภาพแวดล้อมที่เป็นปฏิปักษ์ต่อผู้ใช้โปรแกรมอ่านหน้าจอมากขึ้น
  • CLI สะสมเอาต์พุตเป็นสตรีมเชิงเส้นตามลำดับเวลาผ่าน stdin/stdout แต่ TUI ปฏิบัติต่อเทอร์มินัลเป็น กริด 2 มิติ แบบเซลล์อักขระ ทำให้โปรแกรมอ่านหน้าจอติดตามลำดับการไหลได้ยากขึ้น
  • gemini-cli ทำให้ React component tree ถูกวาดใหม่ให้พอดีกับกริดเทอร์มินัลผ่าน Ink โดยเลื่อนเคอร์เซอร์ไปมาระหว่าง spinner, timer และประวัติการสนทนา ซึ่งอาจทำให้ Speakup และ NVDA อ่านซ้ำ, แครช และเกิดความหน่วงในการป้อนข้อมูล
  • เครื่องมือรุ่นเก่าอย่าง nano, vim, menuconfig, Irssi ใช้ การซ่อนเคอร์เซอร์, โฟกัสคอลัมน์เดียว และ scroll region ของ VT100 เพื่อลดเสียงรบกวนจากการอัปเดตพิกัดและลดการรบกวนกับบรรทัดป้อนข้อมูลให้เหลือน้อยที่สุด
  • หากต้องการสร้างเครื่องมือเทอร์มินัลที่เข้าถึงได้ ควรหลีกเลี่ยงเฟรมเวิร์ก UI แบบประกาศที่ปฏิบัติต่อเทอร์มินัลเหมือนแคนวาสและหลีกเลี่ยงการวาดใหม่อย่างรุนแรง โดยต้องรับประกันพฤติกรรมที่ใกล้เคียงกับสตรีม CLI แบบเรียบง่ายและเชิงเส้น

ความเข้าใจผิดที่ว่า “เป็นข้อความจึงเข้าถึงได้”

  • สมมติฐานที่ว่าแอปพลิเคชันที่รันในเทอร์มินัลเข้าถึงได้โดยธรรมชาตินั้นไม่สอดคล้องกับสภาพการใช้งานจริง
  • ความคาดหวังว่าโปรแกรมอ่านหน้าจอจะตีความข้อความ ASCII ดิบได้ง่ายเพราะไม่มีกราฟิก, DOM ที่ซับซ้อน หรือแคนวาส WebGL นั้นใช้ไม่ได้กับ TUI สมัยใหม่
  • เฟรมเวิร์ก UI สำหรับเทอร์มินัลอย่าง Ink (JS/React), Bubble Tea (Go), tcell พยายามปรับปรุงประสบการณ์นักพัฒนา (DX) แต่สำหรับผู้ใช้ที่มีความบกพร่องทางการมองเห็น กลับอาจสร้างสภาพแวดล้อมที่เป็นปฏิปักษ์มากขึ้น
  • หลายครั้ง TUI สมัยใหม่แย่กว่าอินเทอร์เฟซกราฟิกที่ทำไม่ดีเสียอีกในแง่การเข้าถึง

ความต่างเชิงโครงสร้างระหว่าง CLI กับ TUI

  • CLI: สตรีมเชิงเส้น

    • CLI ทำงานบนพื้นฐาน stdin/stdout เมื่อป้อนคำสั่ง ผลลัพธ์จะถูกเพิ่มต่อด้านล่างและเคอร์เซอร์จะเลื่อนลง
    • เพราะเอาต์พุตเป็นเชิงเส้นและสะสมตามลำดับเวลา จึงเหมาะกับโปรแกรมอ่านหน้าจอระดับเคอร์เนลอย่าง Speakup

  • TUI: กริด 2 มิติ

    • TUI ปฏิบัติต่อหน้าต่างเทอร์มินัลไม่ใช่เป็นสตรีมข้อความ แต่เป็นกริด 2 มิติที่แต่ละเซลล์อักขระถูกใช้งานเหมือนพิกเซล
    • เมื่อทิ้งลำดับเวลาและให้ความสำคัญกับเลย์เอาต์เชิงพื้นที่ก่อน ก็จะกลายเป็นโครงสร้างที่โปรแกรมอ่านหน้าจอตามได้ยาก

ปัญหาที่เห็นได้ใน gemini-cli

  • gemini-cli เป็นเครื่องมือที่เขียนด้วย Node.js และเฟรมเวิร์ก Ink และภายนอกดูเหมือนอินเทอร์เฟซแชตธรรมดา
  • แต่ภายใน Ink พยายามปรับ React component tree ให้เข้ากับกริดของเทอร์มินัล
  • เมื่อใช้งานกับ Speakup (Linux) หรือ NVDA (Windows) ปัญหาไม่ได้มีแค่แอปทำงานล้มเหลว แต่แอปยังเทข้อมูลที่โปรแกรมอ่านหน้าจอต้องอ่านออกมาอย่างต่อเนื่อง

  • หน้าจอที่ทำงานเหมือนแคนวาสแบบ responsive

    • เพราะเฟรมเวิร์กปฏิบัติต่อหน้าจอเหมือนแคนวาสแบบ responsive ทุกการอัปเดตจึงกระตุ้นให้เกิดการวาดใหม่
    • ตอนที่ AI “กำลังคิด” มันจะย้ายฮาร์ดแวร์เคอร์เซอร์ไปยังตำแหน่ง timer เพื่ออัปเดต timer หรือ spinner เขียนเวลาใหม่ แล้วจึงย้ายกลับไปยังตำแหน่งเดิม
    • สำหรับผู้ใช้ที่มองเห็น การเคลื่อนไหวนี้ผ่านไปทันที แต่สำหรับผู้ใช้โปรแกรมอ่านหน้าจอ มันจะถูกอ่านซ้ำเป็น “Responding... Time elapsed 1s... Responding... Time elapsed 2s...”
    • เมื่อเคอร์เซอร์กระโดดไปมาชั่วขณะระหว่างส่วนแสดงสถานะ, spinner และประวัติการสนทนา Speakup จะพยายามอ่านสิ่งที่อยู่ใต้เคอร์เซอร์ในขณะนั้น
    • ผลคือเสียงอ่านของการอัปเดต timer และชิ้นส่วนบทสนทนาปะปนกัน จนโฟกัสกับสิ่งที่กำลังพิมพ์จริงได้ยาก

  • ความไม่เสถียรที่เกิดกับ NVDA และการวางข้อความ

    • บน Windows หากเปิดเทอร์มินัลด้วย NVDA แล้ว SSH เข้าเครื่อง Linux จากนั้นเข้า screen session แล้ววางข้อความ NVDA อาจแครชทันทีหรือทำให้ทั้งระบบไม่เสถียรอย่างมาก
    • ทุกครั้งที่พิมพ์อักขระหรือวางข้อความ สถานะของแอปพลิเคชันจะเปลี่ยน และเฟรมเวิร์กจะตัดสินว่าต้องเรนเดอร์อินเทอร์เฟซใหม่
    • หากประวัติการสนทนารวมอยู่ใน state มันจะพยายามวาดใหม่หรือคำนวณเลย์เอาต์ของข้อความหลายพันบรรทัดในทันที
    • ยิ่งมีข้อความสนทนามาก ปัญหานี้ยิ่งเกิดบ่อย
    • แม้ใช้คีย์ลัด Insert+5 เพื่อหลีกเลี่ยงการแจ้งเตือนเนื้อหาแบบไดนามิกก็ยังไม่สามารถเลี่ยงปัญหานี้ได้

  • วงจรความหน่วงของการป้อนข้อมูล

    • เมื่อเฟรมเวิร์กอย่าง Ink ทำงานในสภาพแวดล้อมเธรดเดียวอย่าง Node.js ประสิทธิภาพจะยิ่งแย่ลงเมื่อประวัติเพิ่มมากขึ้น
    • หากวางบล็อกข้อความขนาดใหญ่ ระบบต้องคำนวณความแตกต่างของหลายพันบรรทัด
    • ระบบจึงมัวแต่คำนวณว่าจะวาดหน้าจอใหม่อย่างไร ทำให้การประมวลผลอินพุตล่าช้า
    • แม้กดเพียงหนึ่งปุ่ม ก็อาจต้องรอนานถึง 10 วินาที กว่าตัวอักษรจะถูกแสดงอีกครั้ง

ทำไมเครื่องมือรุ่นเก่าจึงใช้งานได้

  • เครื่องมืออย่าง nano, vim, menuconfig ไม่ได้ถูกใช้เพราะมันสมบูรณ์แบบด้านการเข้าถึงเสมอไป
  • ประเด็นสำคัญคือเครื่องมือเหล่านี้สามารถซ่อนเคอร์เซอร์ทั้งหมด หรือลดเสียงรบกวนที่เกิดจากการติดตามตำแหน่งเคอร์เซอร์ได้

  • nano และ vim: การซ่อนเคอร์เซอร์

    • หากรัน nano ด้วยตัวเลือกที่แสดงตำแหน่งเคอร์เซอร์อย่าง --constantshow หรือใช้ vim โดยไม่ปรับตั้งค่าบางอย่าง ความสามารถในการใช้งานอาจพังได้
    • เมื่อเคอร์เซอร์มองเห็นได้และมีการติดตามตำแหน่ง Speakup จะให้ความสำคัญกับการอัปเดตตำแหน่งเคอร์เซอร์มากกว่าการ echo ตัวอักษร
    • เมื่อผู้ใช้พิมพ์ “a” ก็จะได้ยิน “Column 2” แทน “a” และเมื่อพิมพ์ “b” ก็จะได้ยิน “Column 3”
    • เครื่องมือเก่าเหล่านี้สามารถตั้งค่าให้ยับยั้งการอัปเดต visual cursor หรือ status bar ได้ ทำให้โปรแกรมอ่านหน้าจออาศัยสตรีมของการป้อนอักขระแทนการอัปเดตพิกัด
    • แต่เฟรมเวิร์กสมัยใหม่มักไม่มีโหมด “no-cursor” หรือ “headless” และตั้งสมมติฐานว่า visual cursor เป็นสิ่งจำเป็น

  • menuconfig: โฟกัสคอลัมน์เดียว

    • menuconfig ของเคอร์เนล Linux ทำงานได้เพราะรักษาโฟกัสแบบคอลัมน์เดียวอย่างเคร่งครัด
    • แม้จะมีกรอบและหัวเรื่อง แต่พื้นที่ที่ใช้งานจริงคือรายการแนวตั้ง และเคอร์เซอร์จะยึดอยู่กับรายการนั้น
    • เคอร์เซอร์จะไม่เคลื่อนแบบย้ายไปมุมล่างขวาเพื่ออัปเดตนาฬิกาแล้วกลับไปมุมซ้ายบนเพื่ออัปเดตหัวเรื่อง
    • ความซับซ้อนเชิงพื้นที่จึงอยู่ในระดับต่ำ ทำให้โปรแกรมอ่านหน้าจอไม่หลงทาง

  • Irssi: การใช้ scroll region

    • Irssi ไม่ได้เข้าถึงได้เพียงเพราะโชคดี แต่เป็นเครื่องมือแชตที่ใช้ scroll region ของ VT100 ผ่านเอนจินเรนเดอร์แบบกำหนดเองมานานกว่า 20 ปี
    • เมื่อมีข้อความใหม่เข้ามา มันจะสั่งไดรเวอร์เทอร์มินัลว่า “ให้กำหนดแถว 1 ถึง 23 เป็น scroll region”
    • จากนั้นจะส่งคำสั่ง “เลื่อนขึ้น” เพื่อให้เทอร์มินัลเลื่อนเนื้อหาขึ้น แล้ววาดข้อความใหม่ที่ด้านล่างของพื้นที่นั้น
    • วิธีนี้ช่วยลดการรบกวนกับบรรทัดป้อนข้อมูลให้เหลือน้อยที่สุด
    • แทนที่จะเขียนอักขระทุกตัวบนหน้าจอใหม่ด้วยมือ มันพึ่งพาความสามารถของฮาร์ดแวร์ในตัวเทอร์มินัล
    • แต่เฟรมเวิร์กสมัยใหม่กลับเมินความสามารถระดับฮาร์ดแวร์นี้ แล้วเลือกคำนวณความต่างของสถานะหน้าจอเพื่อเขียนอักขระใหม่ ซึ่งมีต้นทุนการคำนวณสูงกว่าและเป็นปฏิปักษ์ต่อการเข้าถึง

ปัญหาในการจัดการ issue ของ gemini-cli

  • Google และผู้ดูแล gemini-cli ดูเหมือนจะใส่ใจเรื่องการเข้าถึง แต่ในรีโพซิทอรีกลับปล่อยให้ regression สำคัญด้านการเข้าถึงถูกละเลย
  • regression ด้านการเข้าถึงอย่าง Issue #3435 และ Issue #11305 ไม่มีทั้งการอภิปราย roadmap หรือการแก้ไข
  • Issue #1553 ถูกสร้างขึ้นเพื่อติดตามความล้มเหลวด้านการเข้าถึงลักษณะนี้ แต่ไม่ได้รับการแก้ไข และถูกบอตปิดอัตโนมัติ
  • บอตปิด issue ด้วยข้อความทั่วไปว่าไม่มีความเคลื่อนไหวมานานและเพื่อจัดการ backlog
  • การปิดรายงานด้านการเข้าถึงเพียงเพราะผู้ดูแลไม่ได้แตะต้องมาหลายเดือนไม่ใช่การเก็บกวาด แต่แทบไม่ต่างจากการซ่อนหลักฐาน
  • มันส่งสัญญาณว่าหากเพิกเฉยต่อบั๊กนานพอ บั๊กนั้นก็จะเหมือนไม่มีอยู่ ทั้งที่ซอฟต์แวร์จริงยังคงใช้งานไม่ได้สำหรับผู้ใช้ที่มีความบกพร่องทางการมองเห็น
  • ตัวชี้วัด “Closed Issues” ของโปรเจ็กต์อาจดูดีขึ้น แต่ปัญหาการเข้าถึงไม่ได้ถูกแก้ไข

บทสรุปเพื่อสร้างเครื่องมือเทอร์มินัลที่เข้าถึงได้

  • หากให้ความสำคัญกับการเข้าถึงในแอปพลิเคชันสำหรับเทอร์มินัล ควรหยุดใช้เฟรมเวิร์ก UI แบบประกาศที่ปฏิบัติต่อเทอร์มินัลเหมือนแคนวาส
  • สแตก TUI ที่ “ทันสมัย” ถูกปรับให้เหมาะกับการทำให้นักพัฒนาเขียนโค้ดได้แบบ React มากขึ้น และแลกมาด้วยความสามารถของเครื่องในการเรนเดอร์ข้อความอย่างมีประสิทธิภาพ
  • หากแอปพลิเคชันไม่สามารถรับประกันได้ว่าผู้ใช้จะซ่อนเคอร์เซอร์ได้ หรือยังพึ่งพาการวาดใหม่อย่างรุนแรงเพื่อแสดง spinner และ timer มันก็จะกลายเป็นเครื่องมือที่เข้าถึงไม่ได้
  • สำหรับผู้ใช้ที่มีความบกพร่องทางการมองเห็น สตรีม CLI แบบเรียบง่ายและเชิงเส้นนั้นดีกว่า TUI ที่ “ฉลาด” ซึ่งหน่วง เทข้อมูลให้อ่านไม่หยุด และทำให้เคอร์เซอร์กระจายไปทั่วหน้าจออย่างมาก

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

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Lobste.rs

  • บทความนี้เหมือนโพสต์บล็อกอื่น ๆ ตรงที่มีกลิ่นแรงมากว่าเป็นงานเขียนที่มี AI ช่วยร่าง
    LLM ชอบพาดหัวแบบนี้: “The Architectural Flaw”, “The Lag Loop”, “Why The ‘Old Guard’ Works”, “The Lost Art of Scrolling Regions”, “The ‘Stale Bot’ excuse: A Case Study in Neglect”

    • แค่อ่านชื่อก็ให้ความรู้สึกเหมือนบทความสายผลิตโดย AI แล้ว ตัวประเด็นเองก็ใหม่อยู่ เลยอาจจะเกินไปหน่อยถ้าจะกดรายงานว่าเป็นสแปม แต่ 1) ทนสไตล์ซ้ำ ๆ ที่เจอไปทั่วไม่ไหวแล้ว และ 2) มันทำให้เริ่มสงสัยแม้กระทั่งความถูกต้องของเนื้อหา
      มันน่าจะเป็นโพสต์บล็อกที่ดีได้ แต่ถ้าดูเหมือนผู้เขียนแค่โยนโครงร่างให้ ChatGPT แล้วจบ ก็เสียทั้งกับคนอ่านและคนเขียน
    • อย่างหนึ่งที่เกลียดมากในงานเขียนจาก LLM คือชอบเขียนแบบ “The <แนวคิดที่ไม่ได้เป็นที่ยอมรับจริง ๆ>” ให้ดูเหมือนเป็นคำศัพท์ทางการ
      การเรียกปัญหาเฉพาะทางแบบเกิดครั้งเดียวว่าเป็นปัญหา “คลาสสิก” ก็เข้าข่ายเดียวกัน

  • เศร้ามาก สรุปคือมี TUI ที่เข้าถึงได้ อย่าง Irssi อยู่แล้ว แต่เฟรมเวิร์ก TUI สมัยใหม่กลับเมินแบบอย่างเหล่านั้น แล้วไปพึ่งการคำนวณ diff แบบกริดกับการย้ายเคอร์เซอร์
    โปรแกรมอ่านหน้าจอจะอ่านเนื้อหาตรงตำแหน่งที่เคอร์เซอร์ขยับไป ทำให้ผลลัพธ์ออกมามั่ว ๆ หรือกลายเป็นสแปมการอ่านจำนวนมหาศาล

  • ไม่แน่ใจว่าคำอธิบายทางเทคนิคในนี้ถูกต้องทั้งหมดหรือเปล่า
    โดยเฉพาะ Ink นั้นไม่รองรับ incremental rendering อยู่เป็นเวลานานมาก และแอปส่วนใหญ่ที่ใช้ Ink ก็ยังไม่ได้เปิดใช้มัน แม้แต่ incremental rendering นั้นก็เป็นแบบอิงตามบรรทัด จึงไม่ได้ย้ายเคอร์เซอร์ไปยังตำแหน่งตัวจับเวลาจริง ๆ
    Gemini CLI ต้องใช้ alternate bufferเพื่อเปิด incremental rendering และมันจะถูกปิดใช้งานเมื่อเปิด โหมดที่เป็นมิตรกับโปรแกรมอ่านหน้าจอ ในตัว เอกสารของตัวเลือกที่เกี่ยวข้องอยู่ที่นี่
    เพิ่มเติมคือ rich/textual ของ Python แม้อยู่บนภาษาที่ช้ากว่าและส่วนใหญ่เป็น single-threaded ก็มักเร็วกว่า Ink มาก การคำนวณ diff หลายพันบรรทัดไม่จำเป็นต้องช้าขนาดนั้น และไม่ควรถึงขั้นใช้เวลา 10 วินาที
    ไม่สงสัยเลยว่าประสบการณ์ใช้งานนั้นอึดอัดและพังจริง แต่สาเหตุที่ระบุไว้อย่างเฉพาะเจาะจงดูเหมือนอาจเป็นการหลอนของ LLM หรืออิงจากข้อมูลที่ไม่ครบ Ink แบบ incremental rendering ต่อให้เปิดอยู่ก็ไม่ได้ทำงานแบบที่อธิบายไว้
    ในความเป็นจริง มีโอกาสมากกว่าที่การวาดทั้งหน้าจอใหม่จะทำให้โปรแกรมอ่านหน้าจอสับสน และการวาดใหม่แบบอิงตามบรรทัดก็อาจทำให้มันอ่านเศษข้อความขาด ๆ ที่ไม่เกี่ยวกับการเปลี่ยนแปลงนั้นซ้ำอีก

  • โทษแต่ TUI อย่างเดียวก็ไม่ยุติธรรมหรอก
    ปัญหาจริงคือแทบทั้งสแตกมี การรองรับการเข้าถึง ที่ย่ำแย่มาก
    อย่างแรก terminal emulator ที่เรนเดอร์ด้วย GPU ส่วนใหญ่ไม่ใช้ accessibility API ที่ระบบมีให้เลย พอข้อความถูกเรนเดอร์ด้วย GPU เครื่องมือช่วยการเข้าถึงก็ “อ่าน” ไม่ได้ และเห็นเป็นแค่ภาพเท่านั้น Kitty, Alacritty, WezTerm เป็นแบบนี้ ส่วน Ghostty ที่ฉันทำอยู่สามารถอ่านผ่าน accessibility API บน macOS ได้ และ iTerm2 กับ Terminal.app ก็ทำได้เหมือนกัน
    อย่างที่สอง ไม่มี terminal sequence หรือรูปแบบมาตรฐานใดเลยที่ให้ TUI ส่งข้อมูลด้าน accessibility ไปยัง terminal emulator ได้ เราต้องการอะไรสักอย่างที่เทียบได้กับคอมเมนต์แบบ ARIA สำหรับ terminal cell, run, และ region แต่ยังไม่มีความพยายามแบบนั้น ต่อให้ TUI จัดการเคอร์เซอร์ได้ดี ปัญหาก็ยังจะโผล่ในหลายกรณีการใช้งาน
    ตัวอย่างเช่น ใน Ghostty มีการทำงานเพื่อผสาน OSC133 กับ accessibility API เพื่อเปิดเผยแต่ละ shell prompt, input และ command เป็นองค์ประกอบที่มีความหมายเชิงโครงสร้าง ไม่ใช่แค่กล่องข้อความธรรมดา สิ่งนี้แสดงให้เห็นว่าสเปกของ terminal, TUI และ terminal emulator ต้องทำงานประสานกัน
    ทั้งสแตกมันเน่า และแทบไม่มีใครอยากแก้อย่างจริงจัง ฉันเองก็มีเวลาจำกัด ทำได้แค่พยายามเต็มที่ แต่นี่เป็นเรื่องใหญ่มากที่ต้องอาศัยการเมืองของทั้ง ecosystem ด้วย เลยยากจะรับมือ
    แถมความจริงที่ทั้งเท่และน่ากลัวคือ AI กำลังช่วยให้ accessibility ดีขึ้นในเรื่องนี้ เครื่องมือ AI จำนวนมากใช้หรือใช้ accessibility API เกินขอบเขตเพื่ออ่านรายการหน้าต่างและป้อนข้อมูล เลยทำให้แอปจำนวนมากเริ่มจริงจังกับการผสาน accessibility มากขึ้นเพราะกรณีใช้งานฝั่ง AI

    • terminal กำลังกลายเป็น เบราว์เซอร์ขนาดเล็ก จริง ๆ

  • ฉันหงุดหงิดทุกวันกับการที่ Claude Code และ gemini-cli ไม่ได้ อิง readline
    พวกเขาใส่คีย์ลัดที่คล้ายกันมาบางส่วน แต่คีย์ลัด readline ที่คุ้นเคยแบบยาว ๆ หายไป
    Anthropic จะยอมรับก็ได้ว่าการตัดสินใจทำให้มัน “เหมือนเว็บดีเวลอปเมนต์” เป็นความผิดพลาด แล้วเริ่มใหม่ด้วย readline
    ความคิดที่ว่าประสบการณ์การพัฒนาที่คุ้นมือสำหรับนักพัฒนาที่สร้างเครื่องมือ สำคัญกว่าประสบการณ์ผู้ใช้ที่คุ้นเคยสำหรับคนที่ใช้เครื่องมือ เป็นความคิดที่ผิด

    • เท่าที่เข้าใจ ปัญหาส่วนใหญ่ของเรื่องนี้คือ Ink พอใจกับการเป็นแค่ แบ็กเอนด์การเรนเดอร์ และไม่ได้มีวิดเจ็ตสำหรับรับอินพุตให้
      ในทางปฏิบัติก็แทบไม่มีโซลูชัน third-party ชื่อดังที่ดูแลรักษาอย่างดีด้วย ถ้าต้องการกล่องอินพุตที่ยืดหยุ่น ก็ต้องสร้างเองตั้งแต่ต้น
      ตรงข้ามกับInput widget ที่ยอดเยี่ยมของ Textual หรือไลบรารีอีกตัวใน ecosystem ฝั่ง JS อย่าง OpenTUI
    • readline ไม่ใช่ไลเซนส์ GNU เหรอ? มีใครทำเวอร์ชันที่ไม่ใช่ GPL ได้สักทีแล้วหรือ?
      ฉันไม่ได้ชอบ LLM อยู่แล้ว ดังนั้น UI ที่แย่สำหรับฉันถือเป็นข้อดีอย่างหนึ่ง แต่การไม่ใช้ readline อาจมีเหตุผลบางอย่างก็ได้

  • โปรแกรมแก้ไขใน terminal อย่าง kakoune, helix ดูจะผ่าน เกณฑ์การเข้าถึง ได้ยาก เว้นแต่จะใช้เทคนิค “ซ่อนเคอร์เซอร์”
    ถึงอย่างนั้นก็น่าจะยังเข้าถึงได้ไม่เท่า VS Code
    ถ้าไม่ใช่ VS Code แล้วมี IDE-lite หรือ IDE แบบข้ามแพลตฟอร์มตัวไหนที่เข้าถึงได้บ้าง? ฉันไม่ชอบท่าทีที่เป็นปฏิปักษ์มากขึ้นเรื่อย ๆ ของ VS Code เลย อาจจะเป็น IDE ของ JetBrains ก็ได้

    • มี emacspeak ซึ่งให้ส่วนติดต่อที่เข้าถึงได้ดีมากสำหรับ Emacs
      ข้อเสียคือแม้ Emacs เองจะข้ามแพลตฟอร์ม แต่ emacspeak อาจพึ่งพา Linux อยู่พอสมควรเพราะเรื่อง TTS หรืออาจจะไม่ก็ได้ ฉันไม่เคยลองบน Windows
    • ต้องถามก่อนว่ากำลังพูดถึง accessibility สำหรับใคร ถ้าเป็นเพื่อผู้พิการทางการได้ยิน ก็ต้องมีข้อความในภาษาท้องถิ่นและภาษามือท้องถิ่น เช่นในสหรัฐก็มักเป็น ASL
      ถ้าเป็น accessibility สำหรับผู้พิการทางสายตา ก็ต้องใช้ emacspeak หรือเครื่องมือช่วยการเข้าถึงสำหรับผู้พิการทางสายตาของแพลตฟอร์มนั้น ๆ
      Accessibility เป็นสเปกตรัม ไม่ใช่เช็กบ็อกซ์

  • Links มีโหมด terminal สำหรับอักษรเบรลล์ แยกต่างหาก ซึ่งจะเปลี่ยนองค์ประกอบ GUI จำลองให้เป็นเมนูเต็มหน้าจอที่เรียบง่ายกว่า และเปลี่ยนการนำทางด้วยปุ่มลูกศรให้เป็นแบบทีละบรรทัด
    อีกกรณีที่น่าสนใจคือ edbrowse เป็นเบราว์เซอร์โหมดข้อความที่ Karl Dahlke ซึ่งเป็นผู้พิการทางสายตาสร้างขึ้น และต่างจากเบราว์เซอร์เว็บโหมดข้อความที่ดัง ๆ กว่าตรงที่มันไม่ใช้ TUI แต่ใช้ส่วนติดต่อบรรทัดคำสั่งแบบสไตล์ ed

  • ถ้าเป็น เฟรมเวิร์ก Ink ก็อาจอธิบายได้ว่าทำไม CLI ถึงกิน CPU 100% แล้วค้างไปตลอด พร้อมวาดประวัติแชตยาว ๆ ซ้ำไปมา น่าเสียดาย