Văn bản thay thế và AI: vì sao kiểm toán tự động là chưa đủ

Ngày 24 tháng 8 năm 2026, GitHub đã giới thiệu một mô-đun mới nhằm kiểm tra chất lượng văn bản thay thế trong công cụ quét khả năng truy cập của mình. Thông báo này nhắc lại một giới hạn quan trọng: kiểm tra xem thuộc tính alt có tồn tại hay không tương đối đơn giản, nhưng xác định liệu thuộc tính đó có mô tả đúng hình ảnh trong ngữ cảnh hay không vẫn là một công việc biên tập. AI có thể giúp tập trung việc rà soát của con người; nó không biến kiểm toán tự động thành bằng chứng về sự tuân thủ.

Điểm cần nhớ: một hệ thống vững chắc phải tách biệt ba cấp độ. Các quy tắc xác định phát hiện những lỗi chắc chắn, AI đánh dấu các trường hợp đáng ngờ, còn một người xác nhận ý đồ, ngữ cảnh và trải nghiệm thực tế. Trộn lẫn các cấp độ này sẽ tạo ra quá nhiều dương tính giả hoặc sự tự tin quá mức vào một kết quả chưa đầy đủ.

1. Vì sao chủ đề này lại trở thành ưu tiên

Báo cáo WebAIM Million 2026 đã phân tích một triệu trang chủ và hơn 66,6 triệu hình ảnh. Báo cáo cho biết 16,2% hình ảnh không có văn bản thay thế, chưa tính các hình ảnh trang trí có chủ ý với alt="". Trong số những hình ảnh có văn bản thay thế, 10,8% có nội dung bị đánh giá là đáng ngờ hoặc lặp lại: tên tệp, một từ chung chung, mô tả sao chép hoặc nội dung giống hệt một hình ảnh ở gần.

Những con số này cho thấy hai vấn đề khác nhau. Vấn đề thứ nhất mang tính kỹ thuật: thông tin bị thiếu. Vấn đề thứ hai mang tính ngữ nghĩa: một giá trị tồn tại nhưng không giúp ích cho người dùng. Công cụ quét thông thường xử lý tốt trường hợp đầu tiên và kém hơn nhiều ở trường hợp thứ hai.

Đối với một tổ chức chịu sự điều chỉnh của chính sách về khả năng truy cập, rủi ro nằm ở việc biến một chỉ số về độ bao phủ thành kết luận về sự tuân thủ. Một chiến dịch có thể hiển thị 100% thuộc tính alt đã được điền, nhưng vẫn để lại các liên kết không có tên hữu ích, biểu đồ khó hiểu và mô tả dư thừa. Tự động hóa vì vậy phải cải thiện việc lựa chọn các thành phần cần rà soát, chứ không loại bỏ việc rà soát.

2. Sự hiện diện, chất lượng và chức năng: ba kiểm tra khác nhau

Văn bản thay thế không phải lúc nào cũng dùng để mô tả hình ảnh thể hiện điều gì. Nó phụ thuộc vào chức năng của thành phần trên trang.

Một hình ảnh thông tin truyền tải nội dung không có trong phần văn bản xung quanh. Văn bản thay thế phải truyền đạt thông tin hữu ích đó mà không kể lại mọi chi tiết trực quan. Một hình ảnh có chức năng, được đặt riêng trong một liên kết hoặc nút, thường phải gọi tên hành động hoặc đích đến. Hình ảnh trang trí không nên được công bố cho người dùng và thường sử dụng thuộc tính rỗng. Cuối cùng, một biểu đồ phức tạp có thể cần phần tóm tắt ngắn trong văn bản thay thế và phần giải thích có cấu trúc ở nơi khác trên trang.

Sự phân biệt này giải thích vì sao một mô tả có vẻ chính xác vẫn có thể sai. “Mũi tên màu xanh hướng sang phải” mô tả hình thức của một biểu tượng, nhưng “Bước tiếp theo” có thể là văn bản thay thế phù hợp khi biểu tượng đó là toàn bộ nội dung của một nút. Ngược lại, tự động tạo một câu cho mọi hình minh họa trang trí sẽ làm giảm chất lượng trải nghiệm vì thêm nhiễu.

Vì vậy, quy tắc thiết kế đầu tiên là xác định chức năng trước khi viết văn bản. Đây cũng là điểm đầu tiên mà một cuộc kiểm toán phải kiểm tra.

3. Các quy tắc xác định thực sự có thể chứng minh điều gì

GitHub đã chọn năm kiểm tra có thể chạy mà không cần mô hình bên ngoài: thiếu thuộc tính hoặc thuộc tính chỉ gồm các khoảng trắng, dùng tên tệp làm văn bản thay thế, dấu tạm thời như “TODO”, từ chung chung như “hình ảnh” hoặc “biểu đồ”, và lặp lại cùng một văn bản thay thế trên các hình ảnh gần nhau.

Ưu điểm của các quy tắc này là tính dễ dự đoán. Chúng tạo ra những phát hiện mà nhóm có thể giải thích, tái hiện và sửa chữa. Có thể bật chúng trong mọi pull request mà không phát sinh chi phí suy luận hay phải chuyển ảnh chụp màn hình tới một nhà cung cấp AI.

Tuy nhiên, việc kiểm tra lặp lại cho thấy chỉ riêng DOM không phải lúc nào cũng đủ. Hai logo giống nhau có thể xuất hiện ở đầu trang và chân trang mà không gây khó chịu cho người dùng, trong khi năm biểu tượng cạnh nhau cùng lặp lại “ba trên năm ngôi sao” sẽ tạo ra trải nghiệm khó chịu. GitHub cho biết họ đã sử dụng vị trí trực quan của các thành phần để phân biệt những nhóm thực sự liền kề.

Đối với kiểm toán nội bộ, cách làm tốt là giữ lại một số ít quy tắc nghiêm ngặt, được lập tài liệu và kiểm thử trên các trang thực tế. Một heuristic rất tham vọng nhưng nhiều nhiễu thường sẽ bị vô hiệu hóa. Một quy tắc khiêm tốn và đáng tin cậy sẽ tiếp tục được sử dụng.

4. AI tạo ra giá trị ở đâu

Phân tích có sự hỗ trợ của AI trở nên hữu ích khi cần đối chiếu hình ảnh với ngữ cảnh của nó. Tiêu đề trang, heading gần nhất, chú thích, văn bản xung quanh và sự hiện diện của liên kết cho phép đánh giá liệu văn bản thay thế có đủ, dư thừa hay đang phục vụ sai chức năng hay không.

Không nên đưa cho mô hình chỉ dẫn mơ hồ “cải thiện văn bản thay thế này”. Cách diễn đạt đó khiến mô hình luôn đề xuất một câu khác, ngay cả khi nội dung hiện tại đã đúng. Tốt hơn là yêu cầu mô hình tuân theo một quy trình quyết định: hình ảnh có mang tính trang trí không? Thông tin đã được cung cấp trong chú thích chưa? Thành phần có chức năng không? Nếu không thuộc trường hợp nào, một người không nhìn thấy hình ảnh còn thiếu thông tin gì?

Kết quả phải vẫn là một nhận định có mức độ tin cậy và phần giải thích ngắn. Có thể dùng kết quả để ưu tiên việc rà soát, chuẩn bị đề xuất hoặc nhóm các lỗi lặp lại. Không nên tự động viết lại hàng trăm văn bản thay thế trong môi trường production.

Cũng cần xây dựng một bộ đánh giá nội bộ gồm các ví dụ đúng, sai và mơ hồ. Một mô hình thành công trong vài minh họa trực quan vẫn chưa phải là công cụ kiểm tra đáng tin cậy cho nội dung nghiệp vụ, ngôn ngữ và quy chuẩn biên tập của bạn.

5. Rủi ro về dữ liệu, chi phí và prompt injection

Ngay khi một trang, một hình ảnh và ngữ cảnh của nó được gửi tới dịch vụ phân tích hình ảnh, kiểm tra khả năng truy cập trở thành một luồng dữ liệu cần được lập tài liệu. URL có thể chứa token tạm thời, mã nhận diện phiên hoặc tham số nghiệp vụ. Ảnh chụp màn hình có thể làm lộ thông tin khách hàng, màn hình nội bộ hoặc dữ liệu cá nhân.

Mô-đun được GitHub mô tả sẽ loại bỏ các tham số và fragment khỏi URL trước khi gửi tới mô hình, đồng thời bỏ qua những thuộc tính có thể làm lộ các liên kết đã ký. Cách tiếp cận này hữu ích, nhưng không thay thế một danh mục đầy đủ: nguồn gốc hình ảnh, việc ghi nhật ký, thời hạn lưu giữ, vị trí xử lý, OCR thứ cấp nếu có và quyền truy cập vào kết quả.

Nội dung trang cũng phải được xem là không đáng tin cậy. Một câu ẩn trong tài liệu có thể cố gắng điều khiển mô hình, kể cả trong lúc kiểm toán. Định dạng đầu ra có cấu trúc giới hạn hình thức của phản hồi, nhưng không nhất thiết giới hạn được quá trình suy luận tạo ra phản hồi đó. Cần cô lập phần phân tích, cấm mọi hành động, hạn chế dữ liệu truyền đi và coi đầu ra là một đề xuất.

Cuối cùng, gọi dịch vụ một lần cho mỗi hình ảnh và mỗi lần quét sẽ nhanh chóng trở nên tốn kém. Trên một website có nhiều phương tiện, việc kiểm tra bằng AI nên được lấy mẫu, lập lịch hoặc kích hoạt đối với nội dung đã thay đổi, trong khi các quy tắc xác định vẫn chạy liên tục.

6. Tích hợp kiểm tra vào CI/CD như thế nào

Một chuỗi hiệu quả có thể hoạt động ở ba tốc độ.

Mỗi khi có thay đổi, các bài kiểm tra nhanh sẽ kiểm tra thuộc tính bị thiếu, các giá trị rỗng ngoài ý muốn, tên tệp, placeholder và những trường hợp lặp lại rõ ràng. Chúng chỉ chặn các lỗi chắc chắn. Mỗi đêm hoặc mỗi tuần, một lần quét đầy đủ hơn sẽ render các trang, quan sát cây khả năng truy cập và phân tích một mẫu hình ảnh bằng mô hình. Kết quả được mở thành các nhiệm vụ cần xác nhận, không tự động làm gián đoạn việc phát hành.

Trước một lần đưa lên production quan trọng, con người sẽ rà soát template, các hành trình cốt lõi, biểu đồ, nút có hình minh họa và các trang biên tập có lượng truy cập cao. Việc rà soát sử dụng trình đọc màn hình, đồng thời kiểm tra thứ tự đọc, nhãn liên kết, cấu trúc heading và các trạng thái tương tác.

Các chỉ số phải dễ diễn giải: số lỗi chắc chắn, số trường hợp nghi ngờ, tỷ lệ được xác nhận sau rà soát, thời gian sửa lỗi và mức độ lặp lại theo thành phần. Một “điểm AI” tổng thể sẽ che giấu nguyên nhân và khuyến khích những so sánh sai lệch.

Cách tiếp cận này bổ sung cho các nguyên tắc trong hướng dẫn của chúng tôi về RGAA 4.1.2 và chuẩn bị cho RGAA 5: công nghiệp hóa các kiểm tra nhưng vẫn giữ lại những xác minh mà chỉ tình huống sử dụng mới có thể xác nhận.

7. Vai trò không thể thiếu của xác nhận biên tập

Tác giả nội dung hiểu ý đồ; lập trình viên hiểu cấu trúc; kiểm toán viên hiểu các tiêu chí; người dùng hiểu trải nghiệm. Không góc nhìn nào trong số này đủ nếu đứng riêng lẻ.

Với mỗi loại hình ảnh thường xuyên xuất hiện, hãy tạo một quy tắc biên tập ngắn kèm ví dụ: chân dung một người được nêu tên, ảnh chụp màn hình một tính năng, sơ đồ kiến trúc, hình minh họa không khí, biểu tượng điều hướng hoặc biểu đồ dữ liệu. Thêm một trường bắt buộc để khai báo hình ảnh là trang trí, thay vì buộc phải tạo văn bản.

Trên một website đa ngôn ngữ, văn bản thay thế phải được dịch như một nội dung độc lập. Sao chép bản tiếng Pháp vào trang tiếng Anh có thể vượt qua một kiểm tra kỹ thuật, nhưng không làm cho thông tin trở nên dễ tiếp cận. Vì vậy, việc xác nhận phải bao phủ mọi ngôn ngữ được xuất bản.

Rà soát của con người không có nghĩa là luôn làm cho câu chữ hoa mỹ hơn. Việc rà soát phải trả lời một câu hỏi đơn giản: một người không thể tiếp cận hình ảnh có hiểu được thông tin hoặc hành động cần thiết mà không phải nghe những lần lặp lại không cần thiết hay không?

8. Kế hoạch triển khai trong ba mươi ngày

Trong tuần đầu tiên, hãy lập danh mục các thành phần có chứa hình ảnh và đo các lỗi chắc chắn trong môi trường staging. Xác định những trang yêu cầu xác thực và những dữ liệu tuyệt đối không được rời khỏi hạ tầng của bạn.

Trong tuần thứ hai, thêm các quy tắc xác định vào pipeline và sửa các thành phần dùng chung trước nội dung riêng lẻ. Một sửa đổi trong template có thể giải quyết hàng trăm trường hợp.

Trong tuần thứ ba, thử nghiệm phân tích AI theo cơ chế opt-in trên một mẫu đại diện. Trước hết hãy đo các dương tính giả, các trường hợp không được phân tích và giá trị thực tế của các đề xuất. Lập tài liệu về luồng dữ liệu và giới hạn số lần gọi.

Trong tuần thứ tư, tổ chức một buổi xác nhận với các nhóm biên tập, kỹ thuật và khả năng truy cập. Quyết định kiểm tra nào sẽ chặn một lần phát hành, kiểm tra nào tạo cảnh báo và kiểm tra nào cần được rà soát định kỳ. Lưu lại các ví dụ đã được xác nhận để cải thiện bộ đánh giá.

Kết luận

AI có thể làm cho việc kiểm toán văn bản thay thế trở nên phù hợp hơn, đặc biệt khi đối chiếu hình ảnh với ngữ cảnh biên tập. Tuy nhiên, AI không giải quyết được việc xác định chức năng của hình ảnh, xác nhận trải nghiệm thực tế hay sự tuân thủ tổng thể của một trang.

Chiến lược đáng tin cậy nhất vẫn là tiến từng bước: tự động hóa những gì có thể chứng minh, dùng AI để đưa các trường hợp đáng ngờ ra xem xét và dành quyết định cho những người chịu trách nhiệm về nội dung và khả năng truy cập. Partitech đồng hành trong việc triển khai các chuỗi kiểm soát này, từ kiểm toán thành phần đến tích hợp vào pipeline kiểm thử và triển khai.