GitHub không còn sử dụng Toasts nữa

 (primer.style)
16 điểm bởi GN⁺ 2025-12-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • UI thông báo Toast không còn được GitHub khuyến nghị do các vấn đề về khả năng tiếp cận
  • Cấu trúc thông báo tạm thời tự động biến mất có nguy cơ vi phạm các tiêu chí về khả năng tiếp cận thị giác và chức năng (WCAG)
  • GitHub đề xuất các phương thức phản hồi bền vững và dễ tiếp cận hơn như banner và dialog làm giải pháp thay thế
  • Toast cũng tồn tại nhiều vấn đề về tính khả dụng như màn hình lớn, đa nhiệm, hiện tượng người dùng bỏ qua banner
  • Để đảm bảo khả năng tiếp cận và trải nghiệm người dùng nhất quán, GitHub ngừng sử dụng Toast trên toàn bộ hệ thống thiết kế Primer

Tổng quan về Toasts

  • Toast là cửa sổ thông báo hình chữ nhật nhỏ xuất hiện tạm thời ở góc dưới màn hình, được kích hoạt bởi hành động của người dùng hoặc hệ thống
  • Với cơ chế tự động biến mất sau một khoảng thời gian nhất định, Toast tiềm ẩn các vấn đề về khả năng tiếp cận và tính khả dụng
  • Vì những lý do này, GitHub khuyến nghị các phương thức giao tiếp ổn định và dễ tiếp cận hơn

Giải pháp thay thế Toast

  • Cần chọn UI phù hợp theo mục đích sử dụng
    • Với thông báo thành công đơn giản, có thể xác nhận ngay trên chính màn hình kết quả mà không cần phản hồi riêng
    • Với tác vụ phức tạp, truyền đạt trạng thái thành công bằng banner hoặc hiển thị nội dung theo từng bước
    • Với tác vụ thất bại, cung cấp thông tin lỗi thông qua banner hoặc dialog
  • Trong trường hợp gửi biểu mẫu, biểu mẫu đơn giản không cần xác nhận riêng; biểu mẫu phức tạp nên dùng trang xác nhận trung gian hoặc banner
  • Với kiểm tra dữ liệu nhập, sử dụng các thành phần xác thực biểu mẫu hiện có của Primer
  • Với tác vụ kéo dài, thông báo trạng thái hoàn tất qua banner hoặc kênh khác như email hay thông báo đẩy
  • Khi xảy ra mất đồng bộ phiên, dùng dialog hoặc banner để thông báo cần làm mới trang

Các lưu ý về khả năng tiếp cận (Accessibility Considerations)

  • UI Toast có thể vi phạm nhiều tiêu chí thành công của WCAG
    • 2.2.1 Timing Adjustable (A) : phải được duy trì cho đến khi người dùng tự đóng
    • 1.3.2 Meaningful Sequence (A) : sự không khớp giữa thứ tự DOM và thứ tự hiển thị trực quan có thể gây nhầm lẫn khi dùng công nghệ hỗ trợ
    • 2.1.1 Keyboard (A) : phải có khả năng điều khiển các tương tác trong toast bằng bàn phím
    • 4.1.3 Status Messages (AA) : phải thông báo sự hiện diện của nó cho công nghệ hỗ trợ theo cách không gây cản trở
  • Ngoài ra còn có các tiêu chí có khả năng bị vi phạm
    • 1.4.4 Resize text (AA) : khi thay đổi cỡ chữ có nguy cơ che khuất màn hình hoặc gây tràn nội dung
    • 1.4.10 Reflow (AA) : cần đảm bảo khả năng truy cập bằng bàn phím khi cuộn ngang
    • 2.4.3 Focus Order (A) : có thể gây rối thứ tự focus
    • 3.2.4 Consistent Identification (AA) : cần duy trì tính nhất quán trong mã

Các lưu ý về tính khả dụng (Usability Considerations)

  • Trên màn hình lớn, toast có thể nằm ngoài tầm nhìn nên không được nhận ra
  • Khi tự động biến mất, nếu người dùng đang làm việc khác thì có nguy cơ bỏ lỡ thông điệp
  • Hiện tượng che khuất UI: toast có thể đè lên các thành phần quan trọng như nút ở dưới cùng
  • Người dùng phóng to màn hình có thể không nhìn thấy toast nằm ngoài vùng phóng to
  • Vấn đề trí nhớ làm việc: thông tin không thể được kiểm tra lại do tự động biến mất
  • Hiện tượng bỏ qua banner: khi bị lạm dụng quá mức, người dùng có xu hướng phớt lờ
  • Vị trí không đồng nhất: khoảng cách vật lý giữa UI được kích hoạt và toast có thể gây nhầm lẫn về mối liên hệ
  • Hành vi đóng sai: phím Esc có thể vô tình đóng cả các UI khác

Tài liệu tham khảo bổ sung

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-12-12
Ý kiến trên Hacker News
  • Khi đang giảng về khả năng tiếp cận, có người đã gặp tình huống sau khi nhấp thì bị trễ 3 giây, tạo cảm giác như không có phản hồi gì
    • Nhấp vào banner rồi chỉ phải chờ mà không có bất kỳ dấu hiệu nào, sau đó lại bị chuyển sang một trang không liên quan nên rất khó chịu
    • Họ cho rằng vấn đề nằm ở việc thiếu phản hồi để cho biết là đang tải
    • Có người nói đó chỉ là một liên kết `` đơn giản, và độ trễ chỉ là do trang quá nặng một cách không cần thiết
    • Một người khác thì cho rằng trên 4G chậm nó vẫn phản hồi ngay, nên có thể là vấn đề ở trình duyệt hoặc mạng
  • Có người thấy tài liệu GitHub Primer rất đáng quan tâm
    • Dù không đồng ý với mọi thứ, vẫn có nhiều điều để học và cảm giác tốt hơn rất nhiều so với làm theo cảm tính
    • Tham khảo thêm, Apple và Android cũng đều có hướng dẫn thiết kế riêng
  • Mong rằng xu hướng này cuối cùng sẽ lan rộng
    • Đã có quá nhiều thông báo bị bỏ lỡ vì toast
    • Người khác hoàn toàn đồng ý với câu “không khuyến nghị dùng toast do vấn đề về khả năng tiếp cận”, đồng thời nhấn mạnh rằng nếu có trung tâm thông báo thì còn đỡ hơn, nhưng vẫn là một cách làm tệ
  • Tôi thích toast cho mục đích xác nhận không gây gián đoạn, nhưng cho rằng nó không phù hợp để truyền đạt thông tin quan trọng
    • Một người khác phân chia khá cụ thể các ngữ cảnh sử dụng toast
      • Phản hồi ngay sau khi bấm nút → tốt hơn là đưa phản hồi ngay trên chính nút đó
      • Phản hồi cho phím tắt → ổn
      • Thông báo hoàn tất tác vụ mất nhiều thời gian → ổn, nhưng cần có khu thông báo lưu trữ lâu dài
      • Hiển thị cảnh báo khi vào trang → nếu quan trọng thì nên hiển thị như thông báo thường trực ngay trong trang
    • Trong React, việc gọi toàn cục toast() quá dễ nên có xu hướng bị lạm dụng, nhưng họ đề xuất chuyển sang cấu trúc như useAlerts() sẽ tốt hơn nhiều
  • Với tôi, toast giống như một garô cầm máu
    • Hữu ích để tạm thời chặn một vấn đề cấp bách, nhưng không nên duy trì lâu dài
    • Khi dự án mới thiếu phản hồi, có thể gắn tạm vào, rồi dần gỡ bỏ từng cái khi cải thiện UI
    • Một tổ chức lớn như GitHub có lẽ không cần kiểu giải pháp tạm thời này, nhưng đội nhỏ thì có thể khác
  • Có người thích phần trong tài liệu GitHub nói rằng “khi tạo hàng loạt Issue thì cần thêm phản hồi”
    • Họ cũng muốn GitHub Actions có kiểu phản hồi này, vì sau khi chạy thì phải chờ quá lâu mới thấy kết quả
  • Có người thích ý tưởng dùng toast như nhật ký hành động cho toàn bộ UI
    • Thay vì phản hồi biến mất mỗi lần nhấp, có những ví dụ được triển khai tốt như Sonner
  • Có vẻ đã đến lúc cân nhắc hỗ trợ toast ở mức native của trình duyệt
    • Có thể cải thiện khả năng tiếp cận như điều chỉnh thời gian, trung tâm thông báo, tích hợp với trình đọc màn hình
    • Về mặt thị giác thì ổn, nhưng thường biến mất quá nhanh nên rất dễ bỏ lỡ
    • Dù khó tự mình hiểu trực tiếp những vấn đề mà người khiếm thị gặp phải, họ vẫn muốn nghe cách để cải thiện khả năng tiếp cận cho nhóm này
  • Ưu điểm của toast là dễ triển khai và ít gánh nặng thiết kế
    • Nhược điểm là dễ bị bỏ lỡ và có nguy cơ che lên thông tin khác
    • Nếu có dư thời gian, có người cho rằng tốt hơn là loại bỏ toàn bộ toast
    • Người khác chỉ ra rằng “vì dễ làm nên nó thường bị lạm dụng như một biện pháp vá víu giả làm giải quyết vấn đề”
    • Một người nữa nói họ từng dùng toast đơn thuần như phản hồi trấn an
    • Ngược lại, có người cho rằng “toast là công cụ hữu ích để đưa ra phản hồi tức thời cho những sự kiện ít quan trọng”, hiệu quả hơn modal hay vùng cố định
    • Họ phê phán kiểu tư duy trắng đen khi loại bỏ hoàn toàn một công cụ chỉ vì nó dễ bị lạm dụng
  • Có người đã đọc một bài viết nói rằng “việc GitHub loại bỏ toast là tin xấu cho khả năng tiếp cận”
    • Có người thấy lập luận đó khá kỳ lạ
      • Họ cho rằng việc nói GitHub lẽ ra phải bỏ toast nhưng thay vào đó phải tạo chuẩn trình duyệt thông qua W3C là một bước nhảy lập luận quá xa
      • Chỉ cần mục đã được tạo xuất hiện trong danh sách cũng đã là phản hồi đủ tốt
    • Một người khác nói rằng “vừa bảo toast có hại cho khả năng tiếp cận và UX, vừa chỉ trích GitHub vì không chuẩn hóa nó trong trình duyệt” là một mâu thuẫn