Bài 57 — A11y Trong AI / LLM Era

Mở đầu — vì sao bài này quan trọng

Trong suốt 56 bài trước, chúng ta đã học accessibility như một tập hợp kỹ năng thủ công: viết alt text bằng tay, kiểm tra tương phản màu bằng công cụ, tự bấm phím Tab để kiểm thử keyboard, tự bật screen reader để nghe. Đó là nền tảng không thể thiếu. Nhưng năm 2026, có một sự thật bạn không thể phớt lờ: AI — đặc biệt là các mô hình ngôn ngữ lớn (LLM) và mô hình đa phương thức (multimodal) — đã bước vào giữa quy trình accessibility, vừa như một trợ thủ đắc lực, vừa như một nguồn rủi ro mới.

Bài này quan trọng vì nó nằm ở giao điểm của hai làn sóng đang thay đổi nghề của bạn. Một mặt, AI giúp bạn làm những việc từng tốn hàng chục giờ chỉ trong vài phút: sinh alt text cho 5.000 ảnh sản phẩm, tạo phụ đề cho video, viết lại nội dung khó đọc thành ngôn ngữ đơn giản. Mặt khác, chính các sản phẩm AI mà bạn và đồng nghiệp đang xây — chatbot, trợ lý giọng nói, giao diện sinh nội dung động — lại đặt ra những bài toán accessibility hoàn toàn mới mà WCAG viết từ 2018 chưa lường hết.

Nếu bạn hiểu đúng vai trò của AI ở đây, bạn sẽ tăng tốc công việc gấp nhiều lần mà vẫn giữ chất lượng. Nếu bạn hiểu sai — tin AI một cách mù quáng — bạn sẽ vô tình đẩy hàng nghìn người khuyết tật ra khỏi sản phẩm của mình mà không hề hay biết. Mục tiêu của bài này là giúp bạn dùng AI như một người chuyên nghiệp có kiểm soát, chứ không phải như một người dùng cả tin.

Khái niệm cốt lõi

Có ba góc nhìn bạn cần tách bạch rõ ràng khi nói về "A11y trong kỷ nguyên AI". Nhầm lẫn giữa chúng là lý do nhiều đội làm sai.

1. AI như một công cụ hỗ trợ accessibility (AI as a tool)

Đây là góc nhìn quen thuộc nhất: dùng AI để tự động hóa các tác vụ a11y tốn công.

• Auto-alt text: Các mô hình vision như GPT-4V, Claude (với khả năng đọc ảnh), hay Gemini có thể "nhìn" ảnh và mô tả nội dung. Bạn đưa vào 1.000 ảnh, nhận về 1.000 câu mô tả nháp. Nhưng nhớ bài 14 — alt text tốt phụ thuộc vào ngữ cảnh, không chỉ nội dung ảnh. AI không biết ảnh này đang nằm cạnh đoạn văn nào, nên nó chỉ cho bạn điểm khởi đầu, không phải kết quả cuối.
• Auto-caption và transcript: Whisper của OpenAI và các engine tương tự chuyển giọng nói thành văn bản với độ chính xác cao. Đây là bước nhảy khổng lồ so với nhập phụ đề thủ công. Nhưng chúng vẫn vấp ở tên riêng, thuật ngữ chuyên ngành, tiếng Việt có dấu, và đặc biệt là phân biệt người nói.
• Viết lại ngôn ngữ đơn giản (plain language): LLM rất giỏi rút gọn câu phức tạp thành câu dễ đọc — hỗ trợ trực tiếp cho nhóm khuyết tật nhận thức (liên hệ bài 34, 35).
• Sinh mã có sẵn a11y: Khi bạn yêu cầu AI viết một component, nó có thể tự thêm ARIA, label, focus management — nhưng chất lượng dao động rất mạnh.

2. AI như một trợ lý cho chính người khuyết tật (AI as assistive tech)

Góc nhìn này ít người trong nghề design để ý nhưng cực kỳ quan trọng. Người dùng khuyết tật đang dùng AI để vượt qua các rào cản mà sản phẩm chưa xử lý tốt.

Ví dụ: Be My Eyes tích hợp GPT-4V (tính năng "Be My AI") cho phép người khiếm thị chụp ảnh bất cứ thứ gì — hạn sử dụng trên hộp sữa, màn hình lỗi, biểu đồ — và nghe AI mô tả tức thì. Người khiếm thị dùng ChatGPT giọng nói để điều hướng thông tin. Điều này có nghĩa: kể cả khi sản phẩm của bạn thiếu alt text, người dùng vẫn có thể xoay xở nhờ AI của họ.

Cạm bẫy ở đây: đừng bao giờ lấy điều này làm cái cớ để lười. "Người ta có AI riêng rồi, ta không cần làm alt text nữa" là một lập luận sai về đạo đức lẫn pháp lý. AI của người dùng đoán ngữ cảnh kém hơn bạn, tốn pin, tốn dữ liệu, và không phải ai cũng đủ khả năng chi trả hay am hiểu công nghệ. Accessibility vẫn là trách nhiệm của người tạo ra sản phẩm.

3. Accessibility CỦA chính các sản phẩm AI (A11y OF AI products)

Đây là mảng mới nhất và bị bỏ quên nhiều nhất. Khi đội bạn xây một chatbot, một giao diện sinh ảnh, một trợ lý giọng nói, thì bản thân giao diện AI đó phải accessible.

• Nội dung streaming: LLM trả lời từng từ (token) một. Screen reader xử lý nội dung thay đổi liên tục thế nào? Nếu bạn để cả khối văn bản trong một vùng aria-live="assertive", screen reader sẽ đọc lắp bắp, ngắt quãng loạn xạ, gây hoảng loạn cho người dùng.
• Nội dung không xác định trước: Bạn không kiểm soát được AI sẽ trả về gì. Nó có thể trả về bảng, danh sách, đoạn code, ảnh — mỗi loại cần cấu trúc ngữ nghĩa riêng.
• Trạng thái "đang suy nghĩ": Người dùng screen reader cần biết AI đang xử lý (liên hệ bài 22 về loading indicator).

Tình huống thực tế

Tình huống 1 — Sàn thương mại điện tử Việt tự động hóa alt text và trả giá

Một sàn TMĐT lớn tại Việt Nam (giả định là "ChợViệt") có hơn 2 triệu sản phẩm, phần lớn ảnh không có alt text. Đội design system quyết định dùng mô hình vision để sinh alt text hàng loạt. Sau một tuần chạy, họ có 2 triệu câu mô tả — nghe như một chiến thắng.

Nhưng khi đội a11y kiểm tra ngẫu nhiên 200 mẫu, họ phát hiện vấn đề. AI mô tả một chiếc áo dài là "a woman wearing a traditional long dress" — bằng tiếng Anh, trong khi giao diện là tiếng Việt, khiến screen reader tiếng Việt đọc sai ngữ điệu. Với ảnh có chữ khuyến mãi "Giảm 50%", AI bỏ qua hoàn toàn con số — thông tin bán hàng quan trọng nhất biến mất. Tệ hơn, nhiều ảnh trang trí thuần túy (họa tiết nền) lại bị AI mô tả dài dòng, làm screen reader đọc lê thê những thứ vô nghĩa, đáng ra phải là alt="".

Bài học: AI xử lý được quy mô, nhưng không thay được phán đoán ngữ cảnh. Đội đã điều chỉnh quy trình: dùng AI sinh nháp, ép output ra tiếng Việt qua prompt, rồi cho nhân viên duyệt nhanh theo lô, ưu tiên ảnh sản phẩm chính. Ảnh trang trí được lọc bằng quy tắc trước khi đưa vào AI. Kết quả: giảm 80% thời gian so với viết tay thủ công hoàn toàn, nhưng vẫn giữ được một vòng người kiểm.

Tình huống 2 — Chatbot ngân hàng và cơn ác mộng aria-live

Một ngân hàng số ở Đông Nam Á ra mắt trợ lý AI trong app để trả lời câu hỏi về giao dịch. Đội frontend bọc toàn bộ khu vực chat trong aria-live="assertive" để screen reader "đọc câu trả lời ngay". Trên demo với người sáng mắt thì mượt.

Khi một người dùng khiếm thị thử nghiệm thật, thảm họa xảy ra. Vì LLM stream từng token, mỗi token mới kích hoạt aria-live đọc lại từ đầu, tạo ra tiếng "đọc chồng" liên tục — người dùng chỉ nghe được những mảnh câu vụn vặt, không bao giờ nghe trọn một câu. Cộng thêm assertive ngắt mọi thứ đang đọc, trải nghiệm hoàn toàn không dùng được.

Đội sửa bằng cách: dùng aria-live="polite" thay vì assertive; chỉ công bố câu trả lời hoàn chỉnh sau khi stream xong (giữ hiệu ứng streaming trực quan cho người sáng mắt nhưng chỉ đẩy vào live region ở trạng thái cuối); thêm thông báo trạng thái "Trợ lý đang soạn câu trả lời" khi bắt đầu, và cho phép người dùng bấm phím tắt để nghe lại toàn bộ câu trả lời. Sau khi sửa, thời gian hoàn thành tác vụ của người dùng screen reader giảm từ trung bình 4 phút xuống dưới 1 phút.

Bài học: Accessibility của sản phẩm AI đòi hỏi tư duy về thời gian và nhịp công bố, không chỉ cấu trúc tĩnh. Streaming đẹp cho mắt có thể là địa ngục cho tai.

Tình huống 3 — Startup edtech dùng LLM viết lại nội dung cho người khó đọc

Một startup edtech Việt xây tính năng "Đọc dễ hơn": học viên bấm nút, LLM viết lại đoạn bài giảng phức tạp thành ngôn ngữ đơn giản, hỗ trợ người mắc chứng khó đọc (dyslexia) và người học tiếng Việt là ngôn ngữ thứ hai. Tính năng được đón nhận nồng nhiệt — cho đến khi một giảng viên phát hiện AI đôi khi "đơn giản hóa" đến mức sai kiến thức: một định nghĩa hóa học bị viết lại làm mất đi điều kiện quan trọng, khiến học viên hiểu sai.

Đội xử lý bằng cách thêm nhãn rõ ràng "Bản diễn giải do AI tạo, có thể chưa chính xác tuyệt đối", giữ nút chuyển về bản gốc luôn hiển thị, và với các môn có kiến thức nhạy cảm thì cho giảng viên duyệt trước bản viết lại. Họ cũng bảo đảm nút "Đọc dễ hơn" có label rõ ràng cho screen reader và trạng thái loading accessible.

Bài học: AI hỗ trợ nhóm khuyết tật nhận thức là điều tuyệt vời, nhưng "dễ đọc" không được đánh đổi bằng "sai thông tin". Luôn giữ lối thoát về nội dung gốc và minh bạch về nguồn gốc AI.

Hướng dẫn từng bước

Đây là quy trình dùng AI cho công việc a11y một cách có kiểm soát, áp dụng được ngay tuần này.

Bước 1 — Xác định tác vụ phù hợp để giao cho AI. AI mạnh ở quy mô lớn, mẫu lặp lại, và bản nháp đầu tiên: alt text hàng loạt, phụ đề video, viết lại plain language, phát hiện lỗi a11y sơ bộ trong code. AI yếu ở phán đoán ngữ cảnh tinh tế, quyết định "ảnh này là trang trí hay có nghĩa", và mọi thứ liên quan đến an toàn hay pháp lý. Đừng giao những việc thuộc nhóm sau cho AI một mình.

Bước 2 — Viết prompt có ràng buộc a11y rõ ràng. Với alt text, đừng chỉ nói "mô tả ảnh này". Hãy nêu ngữ cảnh: "Đây là ảnh sản phẩm trên trang thương mại điện tử tiếng Việt. Viết alt text bằng tiếng Việt, dưới 125 ký tự, tập trung vào thông tin người mua cần, bỏ qua chi tiết trang trí, nêu rõ mọi chữ xuất hiện trong ảnh." Prompt tốt quyết định 80% chất lượng đầu ra.

Bước 3 — Luôn giữ một vòng con người kiểm (human-in-the-loop). Với dữ liệu lớn, không cần duyệt 100% — hãy lấy mẫu ngẫu nhiên đại diện (ví dụ 5%), đo tỷ lệ lỗi. Nếu tỷ lệ chấp nhận được và lỗi không nghiêm trọng, chấp nhận phần còn lại nhưng ưu tiên duyệt kỹ nội dung quan trọng (ảnh chính, nội dung pháp lý, thông tin an toàn).

Bước 4 — Với sản phẩm AI bạn xây, thiết kế accessibility cho nội dung động. Dùng aria-live="polite" cho câu trả lời chatbot, công bố ở trạng thái hoàn chỉnh chứ không theo từng token. Thông báo trạng thái "đang xử lý". Bảo đảm output có cấu trúc ngữ nghĩa đúng (bảng thành <table>, danh sách thành <ul>). Cho phép dừng, đọc lại, sao chép câu trả lời bằng bàn phím.

Bước 5 — Kiểm thử thật với screen reader và bàn phím. Đây là bước không AI nào thay được. Bật NVDA hoặc VoiceOver, dùng thử sản phẩm AI của bạn như một người khiếm thị. Bấm Tab đi hết luồng. Nghe xem streaming có đọc loạn không (liên hệ bài 38, 39).

Bước 6 — Ghi tài liệu và minh bạch. Nếu nội dung do AI sinh, hãy cân nhắc gắn nhãn khi phù hợp, và ghi lại quy trình trong tài liệu a11y của đội (liên hệ bài 56 về VPAT).

Lỗi thường gặp & mẹo

• Tin AI 100%, không kiểm. Đây là lỗi chết người phổ biến nhất. Alt text AI sinh có thể sai, phụ đề Whisper có thể nghe nhầm tên riêng, code AI viết có thể thiếu ARIA hoặc thừa ARIA sai. AI cho bạn tốc độ, không cho bạn sự đảm bảo.
• Dùng AI làm cái cớ bỏ qua a11y. "Người dùng có AI riêng rồi" là ngụy biện. Trách nhiệm accessibility vẫn thuộc về người làm ra sản phẩm, cả về đạo đức lẫn luật (liên hệ bài 46 về WCAG, ADA, Section 508).
• Quên rằng nội dung streaming phá vỡ screen reader. aria-live="assertive" bọc quanh vùng token liên tục là công thức tạo trải nghiệm không dùng được. Luôn công bố ở trạng thái hoàn chỉnh và ưu tiên polite.
• Prompt không ràng buộc ngôn ngữ. Với sản phẩm tiếng Việt, nếu không ép output tiếng Việt, AI thường trả về tiếng Anh, làm screen reader đọc sai và người dùng khó hiểu.
• Không đặt độ dài và bối cảnh cho alt text. Kết quả là alt dài lê thê hoặc chung chung vô dụng.
• Mẹo: Xây một "prompt template a11y" chuẩn cho đội, tái sử dụng cho mọi lô ảnh và mọi tính năng. Chất lượng đồng đều hơn hẳn việc mỗi người tự nghĩ prompt.
• Mẹo: Với video, để Whisper sinh transcript nháp rồi giao cho người sửa tên riêng và thuật ngữ — nhanh gấp nhiều lần gõ từ đầu, nhưng vẫn chính xác (liên hệ bài 30 về captions & transcripts).
• Mẹo: Coi AI như một thực tập sinh giỏi nhưng thiếu ngữ cảnh: giao việc rõ ràng, luôn review, không bao giờ để nó ký tên cuối cùng thay bạn.

Bài tập thực hành

• So sánh alt text người và máy. Chọn 5 ảnh trong một dự án thật (ảnh sản phẩm, biểu đồ, ảnh có chữ, ảnh trang trí, ảnh chân dung). Với mỗi ảnh, tự viết alt text theo chuẩn bài 14, rồi yêu cầu một mô hình vision viết alt text. So sánh: AI sai/thiếu ở đâu? Ghi lại 3 điểm AI thường bỏ sót.

• Viết prompt template a11y. Soạn một prompt tái sử dụng để sinh alt text tiếng Việt cho ảnh thương mại điện tử, có ràng buộc ngôn ngữ, độ dài, xử lý ảnh trang trí và chữ trong ảnh. Thử trên 3 ảnh khác nhau và tinh chỉnh đến khi output ổn định.

• Audit một sản phẩm AI. Tìm một chatbot công khai (trợ lý của ngân hàng, sàn TMĐT, hoặc ChatGPT). Bật screen reader (NVDA/VoiceOver) và thử: câu trả lời streaming có đọc loạn không? Có thông báo trạng thái "đang xử lý" không? Bảng và danh sách trong câu trả lời có cấu trúc đúng không? Viết một báo cáo ngắn 5 lỗi và cách sửa.

• Thiết kế live region cho chatbot. Phác thảo (bằng lời hoặc pseudo-code) cách bạn sẽ xử lý công bố cho screen reader khi LLM stream câu trả lời: dùng loại aria-live nào, công bố ở thời điểm nào, thông báo trạng thái ra sao.

Tóm tắt

AI trong kỷ nguyên 2026 vừa là công cụ a11y mạnh mẽ, vừa là một loại sản phẩm mới cần được làm accessible, vừa là trợ lý mà chính người khuyết tật đang dùng. Ba góc nhìn này phải tách bạch. AI cho bạn quy mô và tốc độ — sinh alt text, phụ đề, plain language hàng loạt — nhưng không bao giờ thay được phán đoán ngữ cảnh và trách nhiệm của con người. Luôn giữ một vòng người kiểm, viết prompt có ràng buộc a11y rõ ràng, và không bao giờ lấy AI làm cái cớ để lười.

Với sản phẩm AI bạn xây, thách thức lớn nhất là nội dung động và streaming: dùng aria-live="polite", công bố ở trạng thái hoàn chỉnh, thông báo trạng thái xử lý, và luôn kiểm thử thật bằng screen reader. Hãy coi AI như một thực tập sinh tài năng nhưng thiếu ngữ cảnh — giao việc rõ, review kỹ, và giữ chữ ký cuối cùng cho chính bạn. Đó là ranh giới giữa một chuyên gia a11y biết dùng AI và một người tin AI một cách mù quáng.