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

 (xogium.me)
6 คะแนน โดย GN⁺ 2026-05-04 | 2 ความคิดเห็น | แชร์ทาง 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 ที่ “ฉลาด” ซึ่งหน่วง เทข้อมูลให้อ่านไม่หยุด และทำให้เคอร์เซอร์กระจายไปทั่วหน้าจออย่างมาก

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

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

 
GN⁺ 2026-05-05
ความคิดเห็นจาก Hacker News

  • พอได้เห็น UI การเรนเดอร์ของ Claude Code ก็เพิ่งตระหนักเป็นครั้งแรกว่า TUI มันใกล้เคียงกับ ระบบ UI แบบ DOS หรือ Borland มากกว่าจะเป็นอินเทอร์เฟซบรรทัดคำสั่ง
    ตอนดูการตั้งค่า CLAUDE_CODE_NO_FLICKER=1 ก็เห็นว่า TUI นี้มีโครงสร้างแบบซ้อนหลายเลเยอร์ขึ้นมาด้วย terminal control code
    เลยไปอ่าน implementation ของ Ink สำหรับ React บนเทอร์มินัลด้วย: https://github.com/vadimdemedes/ink
    มันน่าสนใจที่สิ่งนี้ไม่ได้เป็นกราฟิกแบบพิกเซล แต่กลับทำให้ดูเหมือน WordPerfect หรือ WordStar ในอดีต และจากมุมมองของผู้ใช้ที่มีความบกพร่องทางการมองเห็น ความใช้งานได้ก็คล้ายกันด้วย เพียงแต่จำได้ว่า แป้นเบรลล์ 80x25 สำหรับเครื่องมือ DOS เคยทำงานได้ดีกว่า screen reader รุ่นหลัง ๆ

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

    • ของพวกนี้ไม่ใช่ terminal UI เท่าไรนัก แต่ใกล้เคียงกับ ความพยายามเลียนแบบกราฟิก UI แบบ Windows ภายในเทอร์มินัลมากกว่า
      มันเป็นแนวเดียวกับของที่เคยทำบน DOS ในยุคที่ Windows ยังไม่แพร่หลายหรือยังไม่ดีพอ เลยไม่น่าแปลกใจถ้ามันจะกลายเป็นหายนะ หรือถูกสร้างขึ้นโดยไม่เข้าใจความสามารถของเทอร์มินัลที่รันมันอยู่

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

    • TUI กระแสใหม่อย่าง Claude Code, OpenCode, Crush ไม่ได้ขับเคลื่อนด้วยการประกอบร่วมกันหรือ text streaming เป็นหลัก แต่ใกล้เคียงกับผลลัพธ์ของ แรงหนุนหลายอย่าง ที่มารวมกันมากกว่า
      มีกลุ่มวิศวกรจำนวนไม่น้อยที่ใช้ Vim/Neovim/tmux/zellij และใช้ชีวิตอยู่ในเทอร์มินัลอยู่แล้ว และงานพัฒนาจำนวนมากก็เป็นการรันสคริปต์ในเทอร์มินัล จึงมีความต้องการย้ายงานให้มาอยู่ฝั่งนั้นให้มากที่สุด
      บนแพลตฟอร์มหลักอย่าง macOS และ Linux การแจกจ่ายผ่าน package manager แทบจะเป็นปัญหาที่แก้แล้ว แต่การแจกจ่าย native app แบบข้ามแพลตฟอร์มยังคงกระจัดกระจาย
      ความต้องการเหล่านี้รวมกับข้อได้เปรียบด้านการแจกจ่าย ทำให้ องค์ประกอบ TUI อย่าง Ink for React และ Bubble Tea for Go ดีขึ้นมาก ขณะเดียวกัน Electron ก็มีภาพจำว่าเชื่อมโยงกับแอปที่ช้าและเทอะทะ นักพัฒนาเลยค่อนข้างหลีกเลี่ยง
      สุดท้ายแล้วผลิตภัณฑ์ที่ประสบความสำเร็จก็อาจขยับไปสู่รูปแบบอื่นได้ อย่าง Claude Code ที่ต่อยอดเป็น Claude Cowork และ OpenCode ที่เพิ่ม OpenCode Web แต่การทดลองหา product-market fit ของเครื่องมือสำหรับนักพัฒนาด้วย TUI ทำได้ง่ายกว่า และแม้จะออก UI แบบอื่นมาแล้ว ผู้ใช้จำนวนมากก็น่าจะยังอยู่ในเทอร์มินัลต่อไป
    • มันเหมาะกับของพื้นฐานอย่าง vim แต่เกือบทั้งหมดนอกนั้นผมคิดว่า เครื่องมือบรรทัดคำสั่ง ทั่วไปหรือเว็บอินเทอร์เฟซน่าจะดีกว่า ความนิยมส่วนใหญ่ดูเหมือนมาจากความอยากรู้สึกเหมือนแฮ็กเกอร์ที่เปิดหน้าต่างเทอร์มินัล 10 อัน แต่จริง ๆ แล้วต้องการประสบการณ์แบบกราฟิก UI
    • ตอนนี้กระแสหายไปหมดแล้ว แต่ทำให้นึกถึง TN3270 ได้ มันเป็นแบบฟอร์มมากกว่าสตรีมมิง และเน้นคีย์บอร์ดเป็นหลัก
      กราฟิก UI เองก็คงเลียนแบบได้ไม่ยาก แต่แป้นลัดคีย์บอร์ดกลับกลายเป็นเรื่องรองในภายหลัง
      ทุกวันนี้ก็ยังเจอผู้ใช้ที่โหยหาวิธีทำงานแบบเก่า ๆ นั้น และพวกเขาเรียกมันว่า “อินเทอร์เฟซข้อความแบบเก่า” หรือก็คือ TUI พอฟังลึก ๆ แล้ว สิ่งที่พวกเขาต้องการจริง ๆ คือเวิร์กโฟลว์ที่เร็วระดับพริบตาและเน้นคีย์ลัด เวลาใส่ข้อมูล สิ่งสำคัญคือ ความเร็ว ไม่ใช่อนิเมชัน
      มือใหม่ชอบความสวยตระการตา แต่ผู้ชำนาญไม่ค่อยสนใจสิ่งนั้นอีกต่อไป
    • TUI ทำงานได้ ผ่าน ssh โดยไม่ต้องมีงานเพิ่ม
      ข้อจำกัดที่เทอร์มินัลกำหนดทำให้แอปส่วนใหญ่มักหน้าตาคล้ายกันและทำงานคล้ายกัน ในโลกภายนอก เรื่องมาตรฐานประสบการณ์ผู้ใช้มักถูกละเลยทั้งที่มันทำได้ แต่ TUI อยู่ตรงจุดที่เรียกได้ว่ามีความน่าประหลาดใจน้อยที่สุด
    • จุดแข็งของ TUI อยู่หลายด้าน: ใช้ทรัพยากรต่ำ, พึ่งเมาส์น้อยกว่า, เอา key binding ตาม muscle memory แบบ vi ไปใช้กับงานอื่นได้มากขึ้น และจัดระเบียบได้ลึกกว่า
      ด้วยเครื่องมือ TUI ผมเลยสร้าง IDE ส่วนตัวที่มองไม่เห็นได้เวลาต้องการ ซ่อนได้ด้วย guake และ yakuake และจัดเป็นโปรเจ็กต์กับแท็บได้ด้วย zellij มันเข้ากับงานทุกวันนี้ที่หลายบทบาทปะปนกันได้อย่างสมบูรณ์
      แต่ก็คงไม่มีใครเรียกมันว่าสวยหรูอย่างเห็นได้ชัด

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

    • gemini-cli ไม่ใช่โปรเจ็กต์โอเพนซอร์สที่มีอาสาสมัครเป็นผู้ดูแล
      โดยทั่วไปแล้ว Google ค่อนข้างใส่ใจเรื่อง การเข้าถึง และยังเผยแพร่รายงานความสอดคล้องสำหรับผลิตภัณฑ์ส่วนใหญ่ด้วย: https://belonging.google/accessibility-conformance-reports/

  • เห็นด้วยกับการประเมินนี้ และไปไกลกว่านั้นอีกว่าคงจะง่ายกว่ามากถ้านักพัฒนายึดตามและทำให้เป็นมาตรฐานมากขึ้นสำหรับ CUA หรือมาตรฐานอินเทอร์เฟซ Common User Access ของ IBM ซึ่งครั้งหนึ่งเคยทำให้นักพัฒนาพอใจ: https://en.wikipedia.org/wiki/IBM_Common_User_Access
    ถ้านักพัฒนาอยากทดลองรูปแบบ UI หลายแบบก็ปล่อยให้ทำไปได้ แต่ยังคงมี CUA ไว้ด้านหลังเพื่อให้ทั้งเครื่องและคนเรียกใช้งานได้ น่าเสียดายที่มนุษยปัจจัยไม่เคยเป็นจุดแข็งของนักพัฒนา

  • นี่เป็นปัญหาที่มีการบันทึกไว้อย่างดีระหว่าง TUI กับ Windows
    ในยุค 90 ตอนที่ระบบ SAP ส่วนใหญ่ย้ายจากเทอร์มินัล AS/400 ไปสู่ Windows NT มีคนตอบสนองกันมากว่าประสิทธิภาพการทำงานตกลงอย่างมาก
    ผมไม่เคยทำงานที่ SAP แต่แม่ของผมทำ และเวิร์กโฟลว์ที่เดิมเป็นตารางล้วนและใช้ function key เป็นหลัก ถูกเปลี่ยนให้ต้องจับเมาส์ เลื่อน และคลิกเยอะขึ้น หลายฟังก์ชันไม่มีการเลื่อนแท็บและไม่มีปุ่ม F อีกต่อไป
    แม่เคยโชว์ให้ดูว่าท่องไปทั่วทั้งระบบได้เร็วมหาศาลด้วยแค่ ESC ESC F4 F3 TAB TAB ทั้งที่มันไม่ใช่ระบบจริงด้วยซ้ำ แต่เป็นเทอร์มินัล
    สรุปคือ แอปบน Windows เหมาะกับการค้นพบฟังก์ชันและเหมาะกับผู้ใช้ใหม่ ส่วนแอปบนเทอร์มินัลเร็วกว่าและเหมาะกับการนำทางแบบอาศัยความจำและเหมาะกับ ผู้ใช้ระดับสูง

    • นั่นเป็นปัญหาของกราฟิก UI แบบใดแบบหนึ่ง ไม่ใช่ปัญหาของแนวคิดกราฟิก UI โดยตัวมันเอง framework กราฟิก UI ที่ดีควรมีทั้งความคาดเดาได้และ เส้นทางลัดที่เน้นคีย์บอร์ด เป็นค่าเริ่มต้น เพื่อไม่ให้แต่ละแอปต้องมาตัดสินใจเรื่องนี้ใหม่เอง
      ที่จริงแล้วแอปที่ประสบความสำเร็จสำหรับผู้เชี่ยวชาญหรือผู้ใช้ระดับสูงล้วนถูกสร้างโดยคำนึงถึงเส้นทางลัดอยู่แล้ว แม้แต่ ribbon ของ Microsoft ที่มักโดนเกลียดโดยไม่มีเหตุผลก็เป็นตัวอย่างหนึ่ง มันใช้คีย์บอร์ดได้ ปรับแต่งได้ และยังค้นพบฟังก์ชันได้ด้วยในเวลาเดียวกัน
    • ไม่มีเหตุผลอะไรเลยที่ความสามารถนั้นจะถูกเก็บรักษาไว้ในเวอร์ชันกราฟิก UI ไม่ได้ นี่เป็น ความล้มเหลวในการออกแบบประสบการณ์ผู้ใช้ ที่มักเกิดขึ้นเมื่อคนที่ไม่เคยใช้และไม่ได้ใช้ระบบเลยถูกสั่งให้ออกแบบเวอร์ชันถัดไป แต่แทบไม่เกี่ยวอะไรกับว่าเป็นกราฟิก UI หรือ TUI
      กราฟิก UI แค่ทำให้ข้อจำกัดหลวมลง และเพราะอย่างนั้นจึงทำให้ทำประสบการณ์ผู้ใช้ให้พังได้ง่ายขึ้น

  • เดิมที TUI ควรเป็นตัวเลือกที่เรียบง่าย แต่ตอนนี้มันกลายเป็น เว็บแอปที่แต่งชุดเทอร์มินัล ไปแล้ว

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

  • ถ้าจะพูดถึงมายาคติที่ว่า “เป็นข้อความเลยเข้าถึงได้” ก็ไม่ใช่แบบนั้น ไม่มีใครเชื่ออย่างนั้นหรอก
    เวลานักพัฒนาพูดแบบนั้น พวกเขาหมายถึง เอกสารข้อความ และในบางเงื่อนไขก็รวมถึงแอปเทอร์มินัลแบบคำสั่งเดี่ยวอย่าง grep, cut, ls ด้วย คงยากจะบอกว่าพวกเขาพูดแบบนั้นกับ TUI

  • ปัญหาไม่ได้อยู่ที่การใช้ declarative UI framework เอง แต่อยู่ที่ rendering engine ที่ framework พวกนี้สร้างขึ้นมาไม่คำนึงถึงการเข้าถึง

    • จากบทความเห็นชัดว่า declarative UI ก็ทำได้ ถ้าทำให้ถูกต้องและมีตัวเลือกปิดสัญญาณรบกวน
      แต่ดูเหมือนจะไม่มีใครใส่ใจเรื่องนั้น และจบลงที่แค่ “เป็นเทอร์มินัล งั้นมาทำให้มันสวยกันเถอะ”
    • เดิมทีเทอร์มินัลมี การรองรับการเข้าถึง อยู่แล้วหรือเปล่า?

  • TUI จะถูกค้นพบใหม่อีกครั้งโดยไม่มีองค์ประกอบอย่างหน้าต่างแล้ว แม้ยังมีคนตระหนักถึงเรื่องนี้น้อยอยู่ แต่มีโอกาสที่มันจะกลายเป็นแบบ อิงสไปรต์ เหมือนคอนโซล C64 อาจมีใครบางคนทำอยู่แล้วที่ไหนสักแห่งก็ได้
    ถึงเวลาบอกลาหน้าต่างและแพเนลได้แล้ว สภาพแวดล้อมข้อความที่สงบนิ่งยังคงเป็นส่วนหนึ่งของ DNA ทางวัฒนธรรมของมนุษยชาติแม้ในปี 2026 และสื่อแบบนี้ยังถูกสำรวจไปน้อยมาก
    ความก้าวร้าวต่อการรับรู้ของเว็บสมัยใหม่ สำหรับผมแล้วแทบจะเป็นฝันร้ายยิ่งกว่าอีก ในความหมายที่หลอนประสาทมากจากการผสมกันของภาพ วิดีโอ และโฆษณาอย่างไร้บริบท
 
GN⁺ 2026-05-04
ความคิดเห็นจาก 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% แล้วค้างไปตลอด พร้อมวาดประวัติแชตยาว ๆ ซ้ำไปมา น่าเสียดาย