Lời dối trá của chế độ văn bản: Vì sao TUI hiện đại là cơn ác mộng đối với khả năng truy cập

 (xogium.me)
6 điểm bởi GN⁺ 2026-05-04 | 2 bình luận | Chia sẻ qua WhatsApp
  • Giả định rằng ứng dụng terminal vốn dĩ dễ tiếp cận chỉ vì dựa trên văn bản bị phá vỡ trong các TUI hiện đại; các framework như Ink, Bubble Tea, tcell có thể tạo ra môi trường còn thù địch hơn với người dùng trình đọc màn hình
  • CLI xuất ra dưới dạng luồng tuyến tính của stdin/stdout, nơi nội dung tích lũy theo thời gian; còn TUI xử lý terminal như một lưới 2D dựa trên các ô ký tự, khiến trình đọc màn hình khó theo dõi luồng hơn
  • gemini-cli có thể khiến Ink liên tục vẽ lại cây component React để khớp với lưới terminal, di chuyển con trỏ giữa spinner, bộ đếm thời gian và lịch sử hội thoại, từ đó gây đọc lặp lại, crash và độ trễ nhập liệu cho Speakup và NVDA
  • Những công cụ cũ như nano, vim, menuconfig, Irssi giảm nhiễu cập nhật tọa độ và hạn chế can thiệp vào dòng nhập bằng cách ẩn con trỏ, giữ tiêu điểm một cột duy nhất và tận dụng vùng cuộn của VT100
  • Để tạo công cụ terminal có khả năng truy cập tốt, cần tránh các framework UI khai báo xử lý terminal như canvas và việc vẽ lại quá mức, đồng thời đảm bảo hành vi gần với luồng CLI đơn giản, tuyến tính

Hiểu lầm rằng “vì là văn bản nên sẽ dễ tiếp cận”

  • Giả định rằng các ứng dụng chạy trong terminal vốn dĩ có khả năng truy cập tốt là điều không phù hợp với môi trường sử dụng thực tế
  • Kỳ vọng rằng trình đọc màn hình có thể dễ dàng diễn giải văn bản ASCII thô vì không có đồ họa, DOM phức tạp hay canvas WebGL bị phá vỡ trong TUI hiện đại
  • Các framework terminal UI như Ink (JS/React), Bubble Tea (Go), tcell cố gắng cải thiện trải nghiệm lập trình viên (DX), nhưng với người dùng khiếm thị, chúng có thể tạo ra môi trường còn thù địch hơn
  • Trong nhiều trường hợp, TUI hiện đại còn tệ hơn về mặt khả năng truy cập so với một giao diện đồ họa được triển khai kém

Khác biệt cấu trúc giữa CLI và TUI

  • CLI: luồng tuyến tính

    • CLI hoạt động dựa trên stdin/stdout; khi nhập lệnh, kết quả được thêm xuống dưới và con trỏ đi xuống
    • Vì đầu ra có tính tuyến tính và tích lũy theo thời gian, nó phù hợp với các trình đọc màn hình ở cấp kernel như Speakup

  • TUI: lưới 2D

    • TUI không xem cửa sổ terminal là luồng văn bản mà là một lưới 2D, nơi từng ô ký tự được dùng như pixel
    • Khi từ bỏ dòng chảy theo thời gian để ưu tiên bố cục không gian, nó tạo ra cấu trúc mà trình đọc màn hình khó bám theo
Quảng cáo

Những vấn đề bộc lộ trong gemini-cli

  • gemini-cli là công cụ được viết bằng Node.js và framework Ink, bề ngoài trông như một giao diện chat đơn giản
  • Nhưng bên trong, Ink cố gắng điều chỉnh cây component React để khớp với lưới terminal
  • Khi dùng với Speakup (Linux) hoặc NVDA (Windows), ứng dụng không chỉ đơn thuần thất bại mà còn liên tục dội nội dung để trình đọc màn hình đọc lên

  • Màn hình vận hành như một canvas phản ứng

    • Vì framework xử lý màn hình như một canvas phản ứng, mọi cập nhật đều kích hoạt vẽ lại
    • Khi AI đang “suy nghĩ”, để cập nhật bộ đếm hay spinner, nó di chuyển con trỏ phần cứng tới vị trí bộ đếm, ghi thời gian mới rồi đưa con trỏ về vị trí ban đầu
    • Với người dùng nhìn thấy màn hình, đó là hành vi thoáng qua; nhưng với người dùng trình đọc màn hình, nó lặp đi lặp lại như “Responding... Time elapsed 1s... Responding... Time elapsed 2s...”
    • Khi con trỏ tức thời nhảy giữa chỉ báo trạng thái, spinner và lịch sử hội thoại, Speakup sẽ cố đọc nội dung nằm dưới con trỏ tại thời điểm đó
    • Kết quả là cập nhật bộ đếm và các mảnh hội thoại bị trộn lẫn, khiến rất khó tập trung vào nội dung thực sự đang nhập

  • Sự bất ổn với NVDA và thao tác dán

    • Trên Windows, khi mở terminal bằng NVDA, SSH vào máy Linux rồi gắn vào một session screen và dán văn bản, NVDA có thể crash ngay lập tức hoặc khiến cả hệ thống trở nên rất bất ổn
    • Mỗi lần nhập ký tự hay dán văn bản, trạng thái ứng dụng thay đổi và framework kết luận rằng phải render lại giao diện
    • Nếu lịch sử hội thoại nằm trong state, nó sẽ cố vẽ lại hoặc tính toán lại bố cục của hàng nghìn dòng văn bản ngay lập tức
    • Càng nhiều tin nhắn trong hội thoại, vấn đề này càng xảy ra thường xuyên hơn
    • Ngay cả tổ hợp Insert+5, vốn dùng để tránh thông báo nội dung động, cũng không thể né được vấn đề này

  • Vòng lặp độ trễ nhập liệu

    • Khi các framework như Ink chạy trong môi trường đơn luồng như Node.js, hiệu năng sẽ giảm mạnh khi lịch sử ngày càng dài
    • Nếu dán một khối văn bản lớn, nó phải tính diff cho hàng nghìn dòng
    • Hệ thống bận tính toán cách vẽ lại màn hình nên việc xử lý nhập liệu bị chậm lại
    • Chỉ cần nhấn một phím cũng có thể phải đợi tới 10 giây trước khi ký tự hiện lại

Vì sao các công cụ cũ vẫn hoạt động được

  • Không phải các công cụ như nano, vim, menuconfig luôn hoàn hảo về khả năng truy cập nên mới được dùng
  • Điểm cốt lõi là chúng có thể ẩn hoàn toàn con trỏ hoặc giảm nhiễu phát sinh từ việc theo dõi vị trí con trỏ

  • nano và vim: ẩn con trỏ

    • Nếu chạy nano với tùy chọn hiển thị vị trí con trỏ như --constantshow, hoặc dùng vim mà không có cấu hình thích hợp, khả năng sử dụng có thể bị phá vỡ
    • Khi con trỏ hiển thị và việc theo dõi được bật, Speakup sẽ ưu tiên thông báo cập nhật vị trí con trỏ hơn là echo ký tự
    • Khi người dùng nhập “a”, thay vì nghe “a” họ sẽ nghe “Column 2”; nhập “b” thì nghe “Column 3”
    • Các công cụ cũ này có thể được cấu hình để hạn chế cập nhật con trỏ thị giác hoặc thanh trạng thái, nhờ đó buộc trình đọc màn hình dựa vào luồng ký tự nhập thay vì các cập nhật tọa độ
    • Các framework hiện đại thường không cung cấp chế độ “no-cursor” hay “headless”, mà mặc định cho rằng con trỏ thị giác là bắt buộc
    Quảng cáo

  • menuconfig: tiêu điểm một cột duy nhất

    • menuconfig của nhân Linux hoạt động được vì nó duy trì nghiêm ngặt tiêu điểm một cột duy nhất
    • Dù có viền và tiêu đề, vùng hoạt động vẫn là một danh sách dọc, và con trỏ được cố định trong danh sách đó
    • Con trỏ không chạy xuống góc phải dưới để cập nhật đồng hồ rồi lại nhảy lên góc trái trên để cập nhật tiêu đề
    • Độ phức tạp không gian được giữ thấp nên trình đọc màn hình không bị lạc hướng

  • Irssi: tận dụng vùng cuộn

    • Irssi không vô tình mà dễ tiếp cận; đó là một công cụ chat hơn 20 năm nay đã tận dụng vùng cuộn của VT100 thông qua engine render tùy biến
    • Khi có tin nhắn mới đến, nó ra lệnh cho terminal driver “hãy đặt từ dòng 1 đến dòng 23 làm vùng cuộn”
    • Sau đó nó gửi lệnh “cuộn lên”, terminal sẽ đẩy nội dung lên trên rồi vẽ văn bản mới ở cuối vùng đó
    • Cách này giảm can thiệp vào dòng nhập xuống mức tối thiểu
    • Thay vì tự tay ghi lại mọi ký tự trên màn hình, nó dựa vào khả năng phần cứng của terminal
    • Các framework hiện đại bỏ qua những khả năng phần cứng như vậy và chọn cách tính diff trạng thái màn hình rồi ghi lại ký tự, điều này tốn chi phí tính toán hơn và thù địch với khả năng truy cập

Vấn đề trong cách xử lý issue của gemini-cli

  • Google và những người bảo trì gemini-cli có vẻ như quan tâm tới khả năng truy cập, nhưng trong kho mã, các hồi quy nghiêm trọng về khả năng truy cập vẫn bị bỏ mặc
  • Các hồi quy về khả năng truy cập như Issue #3435 và Issue #11305 không có thảo luận, lộ trình hay bản sửa lỗi nào
  • Issue #1553 từng là issue để theo dõi những thất bại về khả năng truy cập như vậy, nhưng cũng không được giải quyết và đã bị bot tự động đóng
  • Bot kết thúc issue bằng lời nhắn chung chung rằng do lâu không có hoạt động và để quản lý backlog nên issue bị đóng
  • Việc đóng các báo cáo khả năng truy cập chỉ vì người bảo trì không đụng tới chúng trong nhiều tháng không phải là dọn dẹp mà giống như che giấu bằng chứng
  • Nó phát đi tín hiệu rằng nếu một lỗi bị phớt lờ đủ lâu thì coi như nó không còn tồn tại, trong khi phần mềm thực tế vẫn không thể dùng được với người dùng khiếm thị
  • Chỉ số “Closed Issues” của dự án có thể đẹp hơn, nhưng vấn đề khả năng truy cập thì không được giải quyết

Kết luận để xây dựng công cụ terminal có khả năng truy cập tốt

  • Nếu thực sự coi trọng khả năng truy cập trong ứng dụng terminal, cần ngừng dùng các framework UI khai báo xem terminal như một canvas
  • Stack TUI “hiện đại” được tối ưu để giúp lập trình viên viết code theo kiểu React dễ hơn, nhưng đánh đổi bằng khả năng render văn bản hiệu quả cho máy
  • Nếu ứng dụng không bảo đảm cho người dùng có thể ẩn con trỏ, hoặc phụ thuộc vào việc vẽ lại quá mức để hiển thị spinner và bộ đếm thời gian, thì đó là một công cụ không thể truy cập được
  • Với người dùng khiếm thị, một luồng CLI đơn giản và tuyến tính tốt hơn nhiều so với một TUI “thông minh” nhưng chậm, liên tục tuôn nội dung để đọc và làm con trỏ nhảy khắp màn hình

Bài viết liên quan

2 bình luận

 
GN⁺ 2026-05-05
Ý kiến trên Hacker News

  • Khi nhìn UI dựng hình của Claude Code, tôi lần đầu nhận ra TUI gần với một hệ thống UI kiểu DOS hoặc Borland hơn là giao diện dòng lệnh
    Khi xem thiết lập CLAUDE_CODE_NO_FLICKER=1, tôi thấy TUI này có cấu trúc chồng nhiều lớp hiển thị bằng mã điều khiển terminal
    Tôi cũng đã đọc phần triển khai terminal của Ink cho React: https://github.com/vadimdemedes/ink
    Điều thú vị là nó trông không phải như đồ họa dựa trên pixel mà giống WordPerfect hay WordStar ngày xưa, và từ góc nhìn của người dùng khiếm thị thì khả năng sử dụng cũng tương tự. Tuy vậy, tôi nhớ rằng bàn phím chữ nổi 80x25 cho công cụ DOS từng hoạt động tốt hơn các trình đọc màn hình về sau

  • Càng nhìn kỹ TUI đang thịnh hành hiện nay càng thấy tệ hơn. Nó giống như gom toàn bộ những thói quen tệ nhất tích tụ từ buổi đầu lập trình, bọc lại thành một khối thạch nặng nề, khó điều khiển, chậm chạp và có vẻ sắp sụp đổ dưới chính sức nặng của mình

    • Những thứ đó không phải terminal UI, mà gần hơn với nỗ lực bắt chước GUI kiểu Windows bên trong terminal
      Chúng cùng một loại với những thứ từng được làm trên DOS thời Windows còn chưa phổ biến hoặc chưa đủ tốt, nên không lạ khi chúng là thảm họa hoặc được tạo ra mà không hiểu khả năng của terminal đang chạy chúng

  • Tôi luôn thấy hơi lạ khi TUI lại phổ biến. Sức mạnh của terminal nằm ở mô hình streaming, và các tiện ích có thể ghép nối là một lợi thế hiếm thấy hơn nhiều trong GUI
    Tôi hiểu rằng các ràng buộc của terminal có thể khiến thiết kế TUI tập trung vào mục đích của công cụ hơn là phần trang trí, nhưng cá nhân tôi không thấy đó là lý do quá thuyết phục

    • Làn sóng TUI mới như Claude Code, OpenCode, Crush không thật sự xoay quanh tính ghép nối hay luồng văn bản, mà gần hơn với kết quả của vài cơn gió thuận hội tụ
      Đã có sẵn một cộng đồng kỹ sư sống trong terminal với Vim/Neovim/tmux/zellij, và nhiều công việc phát triển vốn chạy script trong terminal nên có nhu cầu chuyển càng nhiều việc sang đó càng tốt
      Trên các nền tảng chính như macOS và Linux, việc phân phối qua trình quản lý gói về cơ bản đã được giải quyết, trong khi phân phối ứng dụng native đa nền tảng vẫn còn phân mảnh
      Nhờ nhu cầu đó và lợi thế phân phối, các thành phần TUI như Ink cho React hay Bubble Tea cho Go đã tiến bộ rất nhiều, còn Electron thì gắn với hình ảnh ứng dụng chậm và cồng kềnh nên thường bị lập trình viên né tránh
      Cuối cùng, sản phẩm thành công rồi cũng có thể chuyển sang dạng khác, như Claude Code nối tiếp bằng Claude Cowork và OpenCode bổ sung OpenCode Web, nhưng thử nghiệm độ phù hợp sản phẩm-thị trường cho công cụ dành cho lập trình viên bằng TUI thì nhanh hơn nhiều, và ngay cả sau khi có UI khác, nhiều người dùng vẫn sẽ ở lại với terminal
    • Nó hợp với những thứ cơ bản như vim, nhưng với gần như mọi thứ khác tôi nghĩ công cụ dòng lệnh thông thường hoặc giao diện web tốt hơn. Phần lớn mức độ phổ biến có vẻ đến từ việc muốn cảm thấy như một hacker mở 10 cửa sổ terminal, trong khi thực ra lại muốn một trải nghiệm giống GUI
    • Giờ thì đã hoàn toàn hết mốt, nhưng có thể nhớ đến TN3270. Nó thiên về biểu mẫu và dùng bàn phím làm trung tâm hơn là streaming
      GUI cũng có thể bắt chước điều đó khá dễ, nhưng phím tắt bàn phím lại bị để thành chuyện tính sau
      Đến giờ tôi vẫn gặp những người dùng nhớ kiểu quy trình cũ đó, và họ mô tả nó là “giao diện văn bản kiểu cũ”, tức TUI. Nghe kỹ thì điều họ thực sự muốn là luồng làm việc cực nhanh, lấy phím tắt làm trung tâm. Khi nhập dữ liệu, thứ quan trọng không phải hoạt ảnh mà là tốc độ
      Người mới thích thứ bắt mắt, còn người dùng thành thạo thì không còn bận tâm đến điều đó nữa
    • TUI hoạt động qua ssh mà không cần thêm công đoạn nào
      Những ràng buộc do terminal áp đặt khiến ứng dụng thường trông giống nhau và hoạt động na ná nhau. Ở thế giới bên ngoài, các tiêu chuẩn trải nghiệm người dùng thường bị phớt lờ dù hoàn toàn khả thi, còn TUI thì có thể xem là điểm tối ưu ít gây bất ngờ nhất
    • Sức mạnh của TUI nằm ở vài điểm: dùng ít tài nguyên, ít phụ thuộc chuột, có thể áp dụng key binding hợp với trí nhớ cơ bắp của vi vào nhiều tác vụ hơn, và cho phép tổ chức sâu hơn
      Nhờ các công cụ TUI, tôi có thể tự dựng một IDE của riêng mình mà khi không cần thì gần như vô hình. guake và yakuake giúp ẩn đi được, còn zellij giúp sắp xếp theo dự án và theo tab. Với công việc pha trộn nhiều vai trò như hiện nay thì nó cực kỳ phù hợp
      Dù vậy, chắc chẳng ai gọi nó là bóng bẩy cả

  • Từ góc nhìn của người bảo trì dự án thì có thể nhìn khác. Những người sở hữu và duy trì dự án có thể quyết định ý nghĩa của Open và Closed trong issue, và người dùng không nhất thiết phải đồng ý
    Ví dụ, có thể dùng Open theo nghĩa “chưa được phân loại hoặc đang được xử lý tích cực”, còn Closed là “chúng tôi đã xem ticket này nhưng hiện tại không có thành viên nào trong nhóm làm việc với nó”
    Nghĩa là Closed không nhất thiết phải có nghĩa “đã bị từ chối và quyết định này là cuối cùng”, mà có thể chỉ là “không phải hạng mục đang làm lúc này”. Dù không trực quan với tất cả mọi người, nếu nó giúp thành viên dự án sắp xếp khối lượng công việc thì vẫn có thể biện minh được

    • gemini-cli không phải dự án mã nguồn mở do tình nguyện viên duy trì
      Google nhìn chung khá chú trọng khả năng truy cập, và còn công bố báo cáo mức độ phù hợp cho hầu hết sản phẩm của họ: https://belonging.google/accessibility-conformance-reports/

  • Tôi đồng ý với đánh giá này. Đi xa hơn, sẽ dễ hơn rất nhiều nếu các nhà phát triển tuân thủ và chuẩn hóa hơn nữa CUA vốn từng đủ tốt với họ, tức chuẩn giao diện IBM Common User Access: https://en.wikipedia.org/wiki/IBM_Common_User_Access
    Nếu nhà phát triển muốn thử nhiều cấu hình UI khác nhau thì cứ để họ làm, miễn là phía sau vẫn giữ CUA để cả máy lẫn con người đều có thể gọi tới. Đáng tiếc là công thái học chưa bao giờ là thế mạnh của giới phát triển

  • Đây là một vấn đề đã được ghi nhận rõ giữa TUI và Windows
    Khi phần lớn hệ thống SAP chuyển từ terminal AS/400 sang Windows NT trong thập niên 90, đã có rất nhiều phản hồi rằng năng suất giảm mạnh
    Tôi chưa từng làm ở SAP nhưng mẹ tôi có, và quy trình làm việc vốn hoàn toàn dạng bảng biểu và dựa trên phím chức năng đã chuyển thành phải cầm chuột, di chuyển và bấm rất nhiều. Ở nhiều chức năng, việc di chuyển bằng tab và các phím F đã biến mất
    Bà từng cho tôi xem cách đi xuyên cả hệ thống với tốc độ khủng khiếp chỉ bằng ESC ESC F4 F3 TAB TAB, và đó thậm chí không phải hệ thống thực mà chỉ là terminal
    Tóm lại, ứng dụng dựa trên Windows tốt cho khả năng khám phá và người dùng mới, còn ứng dụng dựa trên terminal nhanh hơn và phù hợp với kiểu điều hướng dựa trên ghi nhớ cùng người dùng cao cấp

    • Đó là vấn đề của một GUI cụ thể chứ không phải của khái niệm GUI nói chung. Một framework GUI tốt nên mặc định có tính dự đoán được và đường tắt thao tác nhanh lấy bàn phím làm trung tâm, để từng ứng dụng không phải tự quyết lại chuyện đó
      Trên thực tế, các ứng dụng thành công dành cho chuyên gia hay người dùng cao cấp đều được xây với các lối tắt nhanh trong đầu. Ngay cả ribbon của Microsoft, thứ thường bị ghét quá mức, cũng là một ví dụ như vậy. Nó có thể điều khiển bằng bàn phím, tùy biến được và đồng thời vẫn dễ khám phá
    • Hoàn toàn không có lý do gì khiến các chức năng đó không thể được giữ lại trong phiên bản GUI. Đây thường là thất bại trong thiết kế trải nghiệm người dùng khi những người chưa từng dùng hệ thống, cũng không sử dụng nó, lại được giao thiết kế phiên bản tiếp theo; nó hầu như không liên quan đến chuyện là GUI hay TUI
      GUI chỉ nới lỏng các ràng buộc, nên vì thế việc làm hỏng trải nghiệm người dùng cũng dễ hơn

  • TUI ban đầu lẽ ra chỉ là một lựa chọn đơn giản, nhưng giờ nó đã thành ứng dụng web khoác áo terminal

    • Nhưng lại không có các tùy chọn trợ năng của web, không có trình biên tập văn bản tốt, tùy chọn tùy biến thì cực kỳ cơ bản, và thay vì chạy trong sandbox lại đòi hỏi môi trường điện toán đáng tin cậy
      Nó còn xa mới là ứng dụng web, và tệ hơn rất nhiều trên hầu hết các phương diện

  • Nói về huyền thoại “cứ là văn bản thì sẽ dễ tiếp cận”, thì không phải vậy. Không ai tin điều đó cả
    Khi các nhà phát triển nói vậy, họ đang nói về tài liệu văn bản, và trong chừng mực có điều kiện thì là các ứng dụng terminal một lệnh như grep, cut, ls. Khó mà nói họ từng phát biểu như vậy về TUI

  • Vấn đề không phải ở việc dùng framework UI khai báo, mà ở chỗ engine dựng hình mà các framework này tạo ra không tính đến khả năng truy cập

    • Đọc bài viết có thể thấy rõ rằng UI khai báo vẫn khả thi nếu được triển khai đúng và có tùy chọn tắt nhiễu
      Nhưng dường như chẳng ai quan tâm đến chuyện đó, mà chỉ dừng ở mức “đây là terminal, hãy làm cho nó đẹp”
    • Ngay từ đầu terminal có hỗ trợ trợ năng hay không?

  • TUI rồi sẽ được tái khám phá mà không có các yếu tố kiểu cửa sổ. Chưa nhiều người nhận ra điều này, nhưng nó có thể sẽ mang tính sprite-based như console C64. Có khi ở đâu đó đã có người làm rồi cũng nên
    Cửa sổ và panel giờ có thể cho nghỉ được rồi. Môi trường văn bản điềm tĩnh vẫn là một phần trong DNA văn hóa của loài người cả đến năm 2026, và phương tiện này vẫn còn bị khai phá quá ít
    Tôi cho rằng tính hung hãn về nhận thức của web hiện đại thực ra còn gần ác mộng hơn nhiều, theo một nghĩa rất gây ảo giác khi hình ảnh, video và quảng cáo bị trộn lẫn không theo ngữ cảnh nào cả
 
GN⁺ 2026-05-04
Ý kiến trên Lobste.rs

  • Bài này, cũng như nhiều bài blog khác, có mùi viết với AI hỗ trợ rất rõ
    LLM rất thích kiểu tiêu đề như thế này: “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”

    • Ngay từ tiêu đề đã đọc như bài sản xuất hàng loạt bằng AI. Chủ đề thì bản thân nó mới mẻ nên có lẽ báo spam là hơi quá tay, nhưng 1) tôi không chịu nổi cái cùng một giọng văn lặp đi lặp lại ở khắp nơi nữa và 2) điều đó còn khiến tôi nghi ngờ cả độ chính xác của nội dung
      Nó đã có thể là một bài blog rất hay, nhưng nếu trông như tác giả chỉ ném dàn ý vào ChatGPT rồi thôi thì cả độc giả lẫn tác giả đều thiệt
    • Một trong những đặc điểm tôi ghét nhất ở văn phong LLM là viết kiểu “The <một khái niệm hoàn toàn chưa từng được xác lập>” để làm như đó là một khái niệm chính thức
      Gọi một vấn đề rất đặc thù và chỉ xảy ra một lần là vấn đề “kinh điển” cũng y hệt như vậy

  • Thật sự rất buồn. Tóm lại là vẫn có những TUI có khả năng tiếp cận như Irssi, nhưng các framework TUI hiện đại lại phớt lờ những tiền lệ đó và phụ thuộc vào diff dạng lưới cùng di chuyển con trỏ
    Công cụ đọc màn hình sẽ đọc nội dung tại vị trí con trỏ khi con trỏ di chuyển, nên kết quả là mọi thứ bị đảo lộn hoặc tạo ra một đống spam đọc thành tiếng khổng lồ

  • Tôi nghi ngờ phần giải thích kỹ thuật ở đây có hoàn toàn chính xác hay không
    Đặc biệt là Ink trong thời gian dài hoàn toàn không hỗ trợ render tăng dần, và phần lớn ứng dụng dùng Ink đến giờ vẫn chưa bật nó. Ngay cả render tăng dần đó cũng là theo dòng, nên nó không thật sự đưa con trỏ tới vị trí timer như mô tả
    Gemini CLI muốn bật render tăng dần thì cần dùng alternate buffer, và điều này sẽ bị vô hiệu hóa khi bật chế độ thân thiện với trình đọc màn hình tích hợp. Tài liệu về tùy chọn liên quan ở đây
    Nói thêm thì rich/textual của Python dù chạy trên một ngôn ngữ chậm hơn và chủ yếu đơn luồng vẫn thường nhanh hơn Ink rất nhiều. Việc diff hàng nghìn dòng không nhất thiết phải chậm đến mức đó, càng không phải mất tới 10 giây
    Tôi không nghi ngờ rằng trải nghiệm người dùng là bực bội và hỏng hóc, nhưng nguyên nhân chính xác được nêu ra có vẻ có thể là do LLM bịa ra hoặc dựa trên thông tin chưa đầy đủ. Render tăng dần của Ink, ngay cả khi được bật, cũng không hoạt động như bài viết mô tả
    Trên thực tế, có lẽ việc vẽ lại toàn màn hình mới là thứ làm trình đọc màn hình bối rối, còn việc vẽ lại theo dòng thì lại khiến nó đọc lại những mảnh văn bản rời rạc ngẫu nhiên không liên quan tới thay đổi

  • Chỉ đổ lỗi cho TUI thì không công bằng
    Vấn đề thật sự là hỗ trợ khả năng tiếp cận của gần như toàn bộ stack đều tệ hại
    Thứ nhất, phần lớn terminal emulator dùng render bằng GPU hoàn toàn không dùng API khả năng tiếp cận do hệ thống cung cấp. Khi văn bản được render bằng GPU, công cụ hỗ trợ tiếp cận không thể “đọc” được và nó chỉ trông như một hình ảnh. Kitty, Alacritty, WezTerm đều thuộc nhóm này. Terminal Ghostty của tôi thì trên macOS có thể đọc qua API khả năng tiếp cận, iTerm2 và Terminal.app cũng vậy
    Thứ hai, hoàn toàn không có terminal sequence hay chuyển động chuẩn nào để TUI truyền thông tin khả năng tiếp cận cho terminal emulator. Cần một thứ tương đương chú thích kiểu ARIA cho ô terminal, đoạn chạy, vùng, nhưng chẳng có nỗ lực nào như vậy cả. Dù TUI có xử lý con trỏ tốt thì trong nhiều trường hợp sử dụng vấn đề vẫn sẽ nổ ra
    Ví dụ, ở Ghostty tôi đã làm việc để tích hợp OSC133 với API khả năng tiếp cận nhằm phơi bày từng shell prompt, input và command thành các phần tử có ý nghĩa về mặt cấu trúc chứ không chỉ là hộp văn bản đơn thuần. Điều đó cho thấy đặc tả terminal, TUI và terminal emulator phải ăn khớp với nhau
    Cả stack đều mục ruỗng, và cũng gần như không có ai thực sự muốn sửa nó. Bản thân tôi cũng chỉ cố hết sức trong giới hạn thời gian, nhưng đây là một chủ đề khổng lồ còn đòi hỏi cả chính trị trong hệ sinh thái nên rất khó gánh nổi
    Thêm nữa, một thực tế vừa thú vị vừa đáng sợ là AI đang giúp cải thiện khả năng tiếp cận ở đây. Nhiều công cụ AI dùng hoặc lạm dụng API khả năng tiếp cận để đọc danh sách cửa sổ và thực hiện nhập liệu. Vì thế ngày càng nhiều ứng dụng bắt đầu coi trọng tích hợp khả năng tiếp cận hơn nhiều vì các trường hợp sử dụng AI

    • Terminal thật sự đang dần trở thành một trình duyệt nhỏ

  • Tôi bực mỗi ngày vì Claude Code và gemini-cli không dựa trên readline
    Họ có thêm vào vài phím bấm tương tự, nhưng phần đuôi dài của những phím tắt readline quen thuộc thì lại thiếu
    Anthropic hoàn toàn có thể thừa nhận rằng quyết định “phải làm nó giống phát triển web” là một sai lầm rồi bắt đầu lại bằng readline
    Suy nghĩ rằng trải nghiệm phát triển quen thuộc với lập trình viên làm ra công cụ quan trọng hơn trải nghiệm người dùng quen thuộc với người sử dụng công cụ là sai

    • Theo tôi hiểu thì một phần lớn của vấn đề là Ink về cơ bản chỉ hài lòng làm backend render và không cung cấp widget nhập liệu
      Thực tế cũng gần như không có giải pháp bên thứ ba nổi tiếng nào được duy trì tốt. Nếu cần một ô nhập linh hoạt thì bạn phải tự làm từ đầu
      Điều này đối lập với widget Input rất tốt của Textual hay OpenTUI là một thư viện khác trong hệ sinh thái JS
    • readline chẳng phải dùng giấy phép GNU sao? Cuối cùng đã có ai làm ra phiên bản không phải GPL rồi à?
      Tôi không thích LLM nên UI tệ với cá nhân tôi lại là một điểm cộng, nhưng có lẽ cũng có lý do khiến họ không dùng readline

  • Các trình soạn thảo terminal như kakoune, helix có lẽ sẽ khó vượt qua tiêu chuẩn khả năng tiếp cận trừ khi dùng mẹo “ẩn con trỏ”
    Dù vậy, có lẽ chúng vẫn không thể tiếp cận tốt bằng VS Code
    Ngoài VS Code ra thì còn IDE-lite hay IDE đa nền tảng nào có khả năng tiếp cận tốt không? Tôi không thích thái độ ngày càng thù địch của VS Code. Có thể là IDE của JetBrains

    • Có emacspeak, và nó cung cấp giao diện rất tốt về mặt khả năng tiếp cận cho Emacs
      Điểm trừ là Emacs bản thân nó đa nền tảng, nhưng emacspeak có thể phụ thuộc phần nào vào Linux vì TTS. Hoặc cũng có thể không. Tôi chưa từng thử trên Windows
    • Trước hết phải xác định là khả năng tiếp cận cho ai. Nếu là cho người khiếm thính thì cần cung cấp chữ viết bằng ngôn ngữ địa phương và ngôn ngữ ký hiệu địa phương. Nếu ở Mỹ thì thường là ASL
      Nếu là khả năng tiếp cận cho người khiếm thị thì cần emacspeak hoặc công cụ hỗ trợ tiếp cận dành cho người khiếm thị của nền tảng đó
      Khả năng tiếp cận là một phổ, không phải một ô checkbox

  • Links có hẳn chế độ terminal chữ nổi Braille, trong đó các thành phần GUI giả được đổi thành menu toàn màn hình đơn giản hơn và điều hướng bằng phím mũi tên cũng chuyển sang theo từng dòng
    Một ví dụ thú vị khác là edbrowse. Đây là trình duyệt chế độ văn bản do Karl Dahlke, một người khiếm thị, tạo ra; khác với các trình duyệt web văn bản phổ biến hơn, nó không dùng TUI mà dùng giao diện dòng lệnh kiểu ed

  • Nếu là framework Ink thì đó có thể là lý do CLI cứ ăn 100% CPU rồi treo mãi trong khi liên tục vẽ lại lịch sử chat dài. Thật đáng tiếc