Thiết kế AI chatbot dễ tiếp cận cho người khuyết tật

Khung chat thường được đặt ở góc phải mọi trang web, nhưng không phải ai cũng mở được nó. Người chỉ dùng bàn phím có thể không Tab tới được nút mở chat. Người dùng trình đọc màn hình gửi câu hỏi xong mà không biết bot đã trả lời hay chưa. Người thị lực kém không đọc được chữ xám nhạt trên nền trắng. Với họ, chatbot không phải kênh hỗ trợ mà là một ô vuông im lặng.

Làm chatbot dễ tiếp cận (accessibility) không phải là tính năng thêm vào cuối dự án. Phần lớn công việc nằm ở giao diện khung chat và cách viết câu trả lời, và nếu tính từ đầu thì chi phí không lớn. Bài viết trình bày những điểm cần thiết kế, cách kiểm thử và những giới hạn cần nói rõ. Các tiêu chí WCAG được nhắc đến như chuẩn tham khảo; mức tuân thủ cụ thể của một khung chat chỉ xác định được sau khi kiểm tra thực tế.

1. Khả năng tiếp cận của chatbot gồm những gì

Một chatbot có hai phần mà người dùng cảm nhận: khung chat (nút mở, ô nhập, danh sách tin, nút gợi ý, biểu mẫu) và nội dung (câu bot trả lời). Khả năng tiếp cận phải đúng ở cả hai. Khung chat đẹp nhưng không dùng được bằng bàn phím thì người dùng không vào được; khung chat chuẩn mà câu trả lời dài dằng dặc, đầy thuật ngữ thì người dùng vào được nhưng không hiểu.

Nhóm người cần tính đến rộng hơn “người khiếm thị”: người mù dùng trình đọc màn hình, người thị lực kém phóng to trang, người mù màu, người vận động tay khó khăn chỉ dùng bàn phím hoặc công tắc, người điếc hoặc nghe kém khi bot có giọng nói, người có khó khăn về nhận thức hay đọc hiểu, và cả người cao tuổi. Một thiết kế tốt cho các nhóm này thường cũng dễ dùng hơn cho mọi người.

Nếu chatbot được nhúng vào website có sẵn, nhiều quyết định về widget nằm ở khâu tích hợp; những điểm kỹ thuật chung khi nhúng được bàn ở bài tích hợp AI Agent vào website.

2. Các yếu tố cần thiết kế

1. Bàn phím

Mọi thao tác phải làm được chỉ bằng bàn phím: Tab tới nút mở chat, Enter để mở, con trỏ nhảy vào ô nhập, Tab qua các nút gợi ý và nút gửi, Esc để đóng và quay lại đúng chỗ đang đứng trên trang. Hai lỗi hay gặp là khung chat mở ra nhưng con trỏ vẫn ở trang phía sau, và khung chat bẫy con trỏ không cho thoát. Vòng viền khi phần tử được chọn (focus) phải nhìn thấy rõ, không bị CSS xóa đi vì lý do thẩm mỹ.

2. Trình đọc màn hình

Đây là phần khó nhất của chatbot vì nội dung thay đổi liên tục. Khi bot trả lời, trình đọc màn hình phải được báo có tin mới, thường qua một vùng thông báo động (aria-live ở mức lịch sự, không ngắt lời người dùng). Nếu câu trả lời hiện dần từng chữ, không nên đọc từng mảnh; chỉ báo khi câu trả lời đã xong. Nút chỉ có biểu tượng như micro, đính kèm, gửi phải có nhãn văn bản. Danh sách tin nên có cấu trúc để người dùng nhảy giữa các tin và biết tin nào của bot, tin nào của mình.

3. Tương phản

Chữ trong bong bóng chat, chữ gợi ý trong ô nhập, nút gợi ý và thời gian gửi đều cần đủ tương phản với nền. Màu nhạt cho “chữ phụ” là chỗ hay trượt nhất. Không dùng màu làm tín hiệu duy nhất: tin lỗi không chỉ đỏ mà còn có chữ “Không gửi được”. Khung chat phải vẫn dùng được khi người dùng phóng to trang lên nhiều lần, không bị cắt chữ hay che mất ô nhập.

4. Văn bản thay thế

Khi bot gửi ảnh sản phẩm, sơ đồ đường đi hay biểu đồ, cần có văn bản thay thế mô tả nội dung chính. Với ảnh từ kho sản phẩm, lấy mô tả có sẵn; với ảnh do người dùng gửi lên, không bắt người dùng tự mô tả. Thẻ sản phẩm hay băng chuyền (carousel) nên có phiên bản đọc được dạng danh sách, vì băng chuyền tự trượt gần như không dùng được với trình đọc màn hình.

5. Ngôn ngữ rõ

Phần này thuộc về nội dung. Câu trả lời nên đưa ý chính lên đầu, câu ngắn, tránh viết tắt nội bộ và thuật ngữ không giải thích. Câu trả lời dài nên chia thành danh sách ngắn và cho người dùng hỏi tiếp nếu cần chi tiết. Đây là chỗ prompt và mẫu câu trả lời phải được viết có chủ ý; cách thiết kế luồng và giọng hội thoại nói chung có ở bài conversation design cho chatbot.

6. Lỗi biểu mẫu

Chatbot hay xin thông tin: số điện thoại, email, ngày hẹn. Khi người dùng nhập sai, thông báo lỗi phải nói rõ sai ở đâu và sửa thế nào, được trình đọc màn hình đọc lên, và không xóa những gì người dùng đã nhập. Chọn ngày bằng lịch bấm chuột nên có lựa chọn gõ ngày trực tiếp. Không đặt giới hạn thời gian ngắn cho phiên chat; nếu buộc phải có, cảnh báo trước và cho kéo dài.

7. Voice

Nhập bằng giọng nói giúp người khó gõ phím, nhưng không được là cách duy nhất. Nếu bot đọc câu trả lời thành tiếng, phải có nút tắt và không tự phát âm thanh khi người dùng chưa yêu cầu, vì âm thanh đè lên trình đọc màn hình. Với người nghe kém, mọi nội dung bằng giọng nói cần có chữ đi kèm. Khi kênh chính là điện thoại, các vấn đề khác hẳn và được bàn ở bài Voice AI Agent cho tổng đài.

8. Kiểm thử người dùng

Công cụ kiểm tra tự động bắt được thiếu nhãn, thiếu tương phản, nhưng không biết người dùng trình đọc màn hình có hiểu được cuộc hội thoại hay không. Cần ít nhất một vòng thử với người dùng thật: người mù dùng trình đọc màn hình trên máy tính và điện thoại, người chỉ dùng bàn phím, người thị lực kém dùng phóng to. Giao cho họ vài nhiệm vụ thật như hỏi giờ mở cửa, đặt lịch, chuyển sang nhân viên, rồi quan sát chỗ họ bị kẹt.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và mức mục tiêu

Liệt kê các nền tảng mà chatbot xuất hiện (website máy tính, website di động, ứng dụng) và các luồng quan trọng nhất. Chọn chuẩn tham khảo và mức mục tiêu mà doanh nghiệp muốn hướng tới, rồi ghi rõ đó là mục tiêu, không phải cam kết đã đạt.

Bước 2: Rà khung chat hiện tại

Chạy công cụ kiểm tra tự động, sau đó thử tay với bàn phím và ít nhất hai trình đọc màn hình phổ biến trên máy tính và điện thoại. Ghi lỗi theo mức nghiêm trọng: chặn hoàn toàn (không mở được chat), gây khó (không biết bot đã trả lời), và khó chịu (thiếu nhãn phụ).

Bước 3: Sửa giao diện và viết lại mẫu câu trả lời

Sửa lỗi chặn trước. Song song, rà lại prompt và mẫu câu trả lời theo nguyên tắc ngôn ngữ rõ: độ dài, cấu trúc, cách trình bày danh sách và liên kết. Thêm lối chuyển sang nhân viên và các kênh liên hệ khác vào mọi luồng; cách chuyển người đúng lúc có ở bài chuyển chatbot sang nhân viên.

Bước 4: Thử với người dùng thật rồi đưa vào kiểm thử hồi quy

Tổ chức buổi thử với người dùng, sửa theo kết quả, và đưa các ca kiểm tra khả năng tiếp cận vào bộ kiểm thử mỗi lần đổi giao diện. Nếu không, một lần đổi màu thương hiệu hay thêm hiệu ứng là đủ làm hỏng những gì đã sửa. Bộ kiểm thử chung của chatbot được bàn ở bài kiểm thử AI chatbot.

4. Ví dụ giả định

Một doanh nghiệp bảo hiểm có chatbot trên website hỗ trợ tra cứu hợp đồng và hướng dẫn thủ tục. Một khách hàng khiếm thị phản ánh rằng sau khi gửi câu hỏi, chatbot “không trả lời gì”. Kiểm tra lại, bot vẫn trả lời, nhưng câu trả lời hiện dần từng chữ trong một vùng không được khai báo cho trình đọc màn hình, nên khách không hề biết.

Đội dự án sửa bốn điểm: thêm vùng thông báo đọc câu trả lời khi đã hoàn tất; thêm nhãn cho nút đính kèm và nút gửi; đổi màu chữ gợi ý cho đủ tương phản; và rút câu trả lời hướng dẫn thủ tục từ một đoạn dài thành các bước đánh số, mỗi bước một câu. Sau đó họ mời vài người dùng trình đọc màn hình thử ba nhiệm vụ. Một phát hiện bất ngờ là nút gợi ý “Bạn muốn hỏi gì tiếp?” hiện ra sau mỗi câu trả lời và bị đọc lên liên tục, gây mệt; nhóm chuyển các gợi ý này thành một danh sách chỉ đọc khi người dùng Tab tới.

5. Rủi ro và giới hạn

• Đạt tiêu chí kỹ thuật nhưng người dùng thật vẫn không dùng được
• Câu trả lời do AI sinh ra khó kiểm soát độ dài và cấu trúc
• Một lần cập nhật giao diện làm hỏng những gì đã sửa
• Chatbot bị coi là kênh duy nhất, cắt mất lối liên hệ khác

Rủi ro lớn nhất là tuyên bố quá mức. Doanh nghiệp không nên ghi “chatbot đạt chuẩn tiếp cận” khi chưa kiểm tra đầy đủ và định kỳ; lời hứa như vậy có thể bị khách hàng hoặc đối tác kiểm chứng. Rủi ro thứ hai đến từ bản chất của mô hình ngôn ngữ: dù đã hướng dẫn trong prompt, câu trả lời vẫn có lúc dài hoặc có bảng phức tạp, nên cần lớp kiểm tra định dạng trước khi hiển thị. Và dù thiết kế tốt đến đâu, vẫn có người không dùng được giao diện chat; lối sang điện thoại, email hay nhân viên phải luôn còn đó.

6. Phân chia trách nhiệm vận hành

Đội giao diện chịu trách nhiệm khung chat: bàn phím, nhãn, vùng thông báo, tương phản, phóng to. Người phụ trách nội dung chatbot chịu trách nhiệm prompt, mẫu câu trả lời và văn bản thay thế cho ảnh. Đội kiểm thử giữ bộ ca kiểm tra khả năng tiếp cận trong kiểm thử hồi quy. Bộ phận chăm sóc khách hàng ghi nhận phản ánh liên quan và chuyển cho nhóm dự án. Một người nên được giao làm đầu mối về khả năng tiếp cận để các phản ánh không rơi vào khoảng trống giữa các nhóm.

7. Chỉ số nên theo dõi

• Số lỗi chặn và lỗi gây khó còn mở theo từng nền tảng
• Tỷ lệ nhiệm vụ hoàn thành trong các buổi thử với người dùng
• Số phản ánh về khả năng tiếp cận và thời gian xử lý
• Tỷ lệ câu trả lời vượt giới hạn độ dài hoặc sai định dạng

Các chỉ số tự động (điểm kiểm tra của công cụ) hữu ích để phát hiện hồi quy, nhưng không nói lên trải nghiệm. Tỷ lệ hoàn thành nhiệm vụ của người dùng thật là thước đo gần nhất với câu hỏi “người khuyết tật có dùng được chatbot này không”.

8. Checklist trước khi vận hành

• Mở, dùng và đóng khung chat được hoàn toàn bằng bàn phím
• Trình đọc màn hình báo có câu trả lời mới và đọc đủ nội dung
• Mọi nút biểu tượng có nhãn, chữ và nút đủ tương phản
• Lỗi biểu mẫu được đọc lên và không xóa dữ liệu đã nhập
• Luôn có lối chuyển sang nhân viên và kênh liên hệ khác
• Ca kiểm tra khả năng tiếp cận đã nằm trong kiểm thử hồi quy

9. Câu hỏi thường gặp

Chatbot đã chạy trên website có cần làm lại để dễ tiếp cận không? Không nhất thiết làm lại từ đầu. Thường chỉ cần sửa phần giao diện khung chat: thứ tự phím Tab, nhãn cho nút, vùng thông báo tin mới cho trình đọc màn hình, độ tương phản và cách báo lỗi. Phần trả lời phía sau ít phải đổi, trừ cách viết câu trả lời cho dễ hiểu hơn.

Có chuẩn nào để kiểm tra khả năng tiếp cận của chatbot không? Nhiều tổ chức dùng bộ hướng dẫn WCAG làm chuẩn tham khảo cho nội dung web, và khung chat là một phần của trang nên cũng áp được. Tuy vậy, đạt các tiêu chí kỹ thuật chưa chắc người dùng thật dùng được, nên vẫn cần thử với người dùng trình đọc màn hình và người chỉ dùng bàn phím.

Câu trả lời dài của AI có gây khó cho người dùng trình đọc màn hình không? Có. Trình đọc màn hình đọc tuần tự, nên một câu trả lời dài, nhiều ký hiệu hay bảng lồng nhau rất mệt để nghe. Nên giới hạn độ dài, đưa ý chính lên đầu, dùng danh sách ngắn và cho phép người dùng hỏi tiếp để xem chi tiết.

Chatbot có thay được kênh hỗ trợ cho người khuyết tật không? Không nên coi là thay thế. Chatbot dễ tiếp cận giúp nhiều người tự tra cứu được, nhưng vẫn phải có lối chuyển sang nhân viên và các kênh khác như điện thoại hay email, vì có người không dùng được giao diện chat dù đã thiết kế tốt.

Kết luận

Một AI chatbot dễ tiếp cận cần đúng ở hai lớp: khung chat dùng được bằng bàn phím và trình đọc màn hình, và câu trả lời ngắn, rõ, có cấu trúc. Phần lớn công việc không tốn kém nếu tính từ đầu, nhưng chỉ có giá trị khi được kiểm thử với người dùng thật và giữ trong kiểm thử hồi quy. Hãy xem chuẩn như WCAG là thước đo tham khảo, còn người dùng thật là thước đo cuối cùng.

Trao đổi với Naventic để rà khả năng tiếp cận của khung chat trên website. Đọc thêm: AI Chatbot doanh nghiệp.