Văn bản thay thế (alt text) đạt chuẩn tự động chưa chắc đã hữu ích

Chúng tôi đã xây dựng một plugin cho GitHub Accessibility Scanner để đảm bảo văn bản thay thế (alt text) của bạn thực sự hữu ích cho người dùng. Dưới đây là cách thức hoạt động của nó.

24 tháng 8, 2026

9 phút

Hơn một phần tư số hình ảnh trên các trang chủ phổ biến nhất trên web có văn bản thay thế bị thiếu, mơ hồ hoặc được sao chép từ các hình ảnh liền kề.

Thông tin này được trích từ báo cáo WebAIM Million năm 2026 của WebAIM, cho thấy văn bản thay thế – một thuộc tính HTML chứa văn bản mô tả nội dung của hình ảnh – bị thiếu trên 16,2% số hình ảnh trên một triệu trang chủ hàng đầu. Trong số những hình ảnh có văn bản thay thế, có thêm 10,8% cung cấp thuộc tính không mang tính mô tả, chẳng hạn như alt="image", tên tệp gốc hoặc mô tả trùng lặp từ hình ảnh lân cận.

Mặc dù các công cụ tự động gắn cờ khá tin cậy đối với các trường hợp thiếu văn bản thay thế, nhưng chúng lại không hiệu quả trong việc sửa lỗi văn bản thay thế được viết kém. Hầu hết các trình kiểm tra văn bản thay thế chỉ kiểm tra xem tên truy cập được cho hình ảnh có tồn tại hay không, chứ không kiểm tra xem văn bản thay thế được cung cấp có nói lên điều gì hữu ích về hình ảnh liên quan hay không. Đây là một lựa chọn thiết kế có chủ đích: một quy tắc hướng đến chất lượng nhưng có nhiều kết quả dương tính giả (false positive) là quy tắc mà các nhóm sẽ tắt đi. Vì vậy, alt="IMG_2847.png" vẫn vượt qua kiểm tra. Tương tự với alt="3/5 stars" trên năm biểu tượng hình ngôi sao khác nhau.

Chúng tôi đã xây dựng một plugin văn bản thay thế cho GitHub Accessibility Scanner để giúp cải thiện văn bản thay thế của bạn. Bài viết này đề cập đến ranh giới mà chúng tôi đã vạch ra giữa những gì trình kiểm tra có thể chứng minh và những gì nó chỉ có thể nghi ngờ, tại sao lỗi tồi tệ nhất của chúng tôi lại hóa ra là vấn đề về bố cục thay vì phân tích cú pháp, và những gì đã thay đổi khi chúng tôi đưa một mô hình AI vào quy trình.

Nếu bạn đang tự xây dựng các kiểm tra tự động, cho mục đích hỗ trợ tiếp cận (accessibility) hoặc các mục đích khác, những đánh đổi này cũng sẽ áp dụng tương tự.

Chứng minh một chuỗi văn bản là sai mà không nhìn thấy hình ảnh

Sự hiện diện của văn bản thay thế là một thực tế khách quan; thuộc tính đó có ở đó hay không. Chất lượng thường là một vấn đề mang tính đánh giá. Máy tính không thể chứng minh liệu một câu có mô tả đầy đủ một hình ảnh trong ngữ cảnh từ mã đánh dấu (markup) hay không.

Tuy nhiên, không phải tất cả chất lượng đều mang tính chủ quan. Có một số kiểm tra bạn có thể thực hiện chỉ dựa trên văn bản thay thế mà không cần tham khảo nội dung hình ảnh:

Mỗi kiểm tra đó đều là một khẳng định về một chuỗi văn bản, và đó đã trở thành ranh giới phân chia của chúng tôi. Năm quy tắc tất định (deterministic) chạy theo mặc định mà không cần thông tin xác thực để chạy các mô hình AI hoặc thực hiện các lệnh gọi mạng. Một quy tắc tùy chọn (opt-in) sẽ gọi một mô hình với nội dung hình ảnh được cung cấp và ngữ cảnh xung quanh, dành cho các đánh giá mà một chuỗi văn bản thay thế không thể tự mình hỗ trợ.

Đầu tiên, chúng tôi phải xác định những hình ảnh nào cần đánh giá trên một trang web được quét. Chúng tôi sử dụng bộ định vị dựa trên vai trò (role-based locator) của Playwright thay vì querySelectorAll('img'), vì vậy bất kỳ thứ gì không có trong cây hỗ trợ tiếp cận (accessibility tree) của trình duyệt sẽ bị loại bỏ, bao gồm cả bất kỳ thứ gì có alt="". Việc loại trừ cuối cùng đó là quan trọng nhất. Một alt trống là cách tác giả khẳng định rõ ràng rằng hình ảnh đó chỉ mang tính trang trí, và việc gắn cờ nó sẽ trừng phạt chính hành vi mà bạn muốn khuyến khích.

Vậy, mức độ nghiêm ngặt nên là bao nhiêu? Một trình kiểm tra chất lượng sẽ thành bại dựa trên các kết quả dương tính giả, vì vậy chúng tôi chọn các tập hợp đóng thay vì các phương pháp suy nghiệm (heuristic) thông minh. Quy tắc "văn bản thay thế mơ hồ" sẽ chuẩn hóa một chuỗi văn bản, sau đó kiểm tra nó dựa trên một danh sách các từ được chọn lọc không mang thông tin gì. Nó chỉ kích hoạt khi có sự trùng khớp chính xác:

Các quy tắc cứng nhắc như vậy sẽ bỏ sót rất nhiều văn bản thay thế tồi. Chúng tôi chấp nhận việc bỏ sót thay vì nhận kết quả dương tính giả, bởi vì một trình kiểm tra đáng tin cậy mà các nhà phát triển bật lên sẽ tốt hơn một trình kiểm tra bị họ tắt đi.

Sự lặp lại là vấn đề về bố cục, không phải vấn đề về DOM

Văn bản thay thế lặp lại là một vấn đề thú vị. Hãy hình dung một hàng gồm năm biểu tượng hình ngôi sao, mỗi biểu tượng đều ghi "3/5 stars". Người dùng trình đọc màn hình (screen reader) sẽ nghe thấy cùng một nội dung năm lần và không học được gì mới từ bốn lần sau.

Phiên bản đầu tiên của chúng tôi duyệt qua các hình ảnh theo thứ tự tài liệu và gắn cờ bất kỳ chuỗi nào chia sẻ cùng một văn bản thay thế đã chuẩn hóa. Nó đã bắt được những thứ không nên bắt. Ví dụ, logo "GitHub" ở chân trang và logo "GitHub" ở tiêu đề có thể nằm cạnh nhau trong danh sách được trích xuất nhưng thực tế lại nằm rất xa nhau trên màn hình, vì vậy không ai trải nghiệm chúng như một nhóm.

Điều quan trọng là vị trí của hình ảnh trên màn hình, không phải vị trí của chúng trong mã đánh dấu. Vì vậy, quy tắc hiện tại kiểm tra bố cục trang và chỉ mở rộng phạm vi kiểm tra khi khoảng cách giữa hai hộp bao (bounding box) nhỏ so với chính các hộp đó:

Hai chi tiết đáng lưu ý:

Khiến mô hình hành động như một người đánh giá, không phải một nhà phê bình

Các quy tắc tất định chỉ cần chuỗi văn bản thay thế. Bất cứ thứ gì thông minh hơn đều cần biết trang web nói về cái gì, và không có thông tin nào trong số đó được theo dõi bởi phần tử hình ảnh. Việc alt="a smiling person" (một người đang cười) có ổn hay không phụ thuộc hoàn toàn vào những gì xung quanh nó: trên một bức ảnh tâm trạng chung chung, nó có thể ổn. Nhưng dưới một tiêu đề nơi một người cụ thể được nêu tên, nó lại không cung cấp đủ chi tiết.

Trong tính năng alt-text-qualitycheck tùy chọn của chúng tôi, chúng tôi trích xuất ngữ cảnh trang cùng với mỗi hình ảnh: tiêu đề gần nhất, tiêu đề trang, bất kỳ thẻ <figcaption> nào, liệu hình ảnh có nằm bên trong một liên kết hoặc nút hay không, và tối đa 600 ký tự văn bản gần đó.

Tín hiệu liên kết là quan trọng nhất, bởi vì khi một hình ảnh là nội dung duy nhất của một liên kết, văn bản thay thế của nó sẽ trở thành tên truy cập được của liên kết đó. Văn bản thay thế đúng lúc này sẽ nêu tên đích đến thay vì mô tả hình ảnh.

Một lưu ý: Plugin chỉ ghi lại việc một hình ảnh nằm bên trong một liên kết. Chúng tôi không kiểm tra xem đó có phải là nội dung duy nhất của liên kết hay không, đây chính là phần thực sự biến văn bản thay thế thành tên liên kết. Vì vậy, hiện tại cả hai trường hợp đều trông giống hệt nhau đối với mô hình.

Ngữ cảnh đó, văn bản thay thế và hình ảnh được gửi đến một mô hình thị giác (vision model) thông qua GitHub Models. Các chế độ lỗi của chúng tôi hiếm khi là do mô hình đọc sai hình ảnh. Chúng là do mô hình có "ý kiến riêng". Với văn bản thay thế hoàn hảo, phiên bản kiểm tra đầu tiên của chúng tôi sẽ gợi ý một văn bản thay thế khác, bởi vì "liệu cái này có thể tốt hơn không?" là câu hỏi mà một mô hình ngôn ngữ luôn trả lời là có. Mọi hình ảnh đều trở thành một phát hiện, vì vậy tín hiệu hữu ích bị mất đi.

Ba thay đổi đã khắc phục điều này:

Không có điều nào trong số đó làm cho mô hình trở nên chính xác tuyệt đối. Nó làm cho mô hình nhất quán đủ để lặp lại quá trình cải thiện. Kho lưu trữ chứa một bộ công cụ đánh giá ngoại tuyến được xây dựng từ tài liệu giảng dạy đã xuất bản: WebAIM, hướng dẫn về hình ảnh của W3C và POET. Quy tắc và bộ công cụ chia sẻ chung một câu lệnh (prompt), vì vậy những gì bạn tinh chỉnh ngoại tuyến chính là những gì chạy trong CI. Tuy nhiên, bộ công cụ đó chỉ kiểm tra khả năng đánh giá của mô hình, không phải toàn bộ quy trình. Một trường hợp có thể đạt điểm hoàn hảo ở đó nhưng không bao giờ đến được mô hình trong một lần quét thực tế.

Gửi hình ảnh đến mô hình là một quyết định về quyền riêng tư và chi phí

Ngay khi một kiểm tra gọi một mô hình bên ngoài với dữ liệu trang web, nó không còn chỉ là một quy tắc lint đơn thuần và đòi hỏi thiết kế luồng dữ liệu cẩn thận. Một vài điều rút ra từ đó:

Một lưu ý, vì danh sách đó dễ bị đọc nhầm: các phát hiện vẫn mang URL trang thực và HTML gốc vào quy trình báo cáo thông thường của máy quét. Điều này là có chủ đích, vì bạn không thể sửa một hình ảnh mà bạn không thể xác định vị trí. Việc biên tập lại chỉ thu hẹp những gì đến được với mô hình và nhật ký, không phải những gì nằm trong các vấn đề (issues) của riêng bạn. Và nếu bạn thiết lập thông tin xác thực Azure AI Vision, một bước OCR tùy chọn sẽ gửi các byte hình ảnh đến một nơi thứ hai. Không có gì bắt buộc phải dùng Azure, nhưng việc đánh giá luồng dữ liệu cần bao gồm cả hai đường dẫn.

Chi phí cũng tương tự. Trong trường hợp phổ biến, đây là một lệnh gọi mô hình cho mỗi hình ảnh trong mỗi lần quét, điều này trên một trang web có nhiều hình ảnh sẽ chiếm phần lớn chi phí của toàn bộ quá trình chạy. Đó là lý do đủ để đặt lịch quét thay vì chạy trên mỗi lần commit.

Những gì công cụ này vẫn chưa thể làm được

Những gì chúng tôi muốn nói với bạn nếu bạn đang xây dựng một thứ tương tự

Hãy tách biệt những gì bạn có thể chứng minh khỏi những gì bạn chỉ có thể nghi ngờ, và đặt cho chúng các mặc định khác nhau. Các kiểm tra chứng minh được điều gì đó nên rẻ, có thể dự đoán được và được bật theo mặc định. Các kiểm tra chỉ nghi ngờ điều gì đó nên là tùy chọn và nên được đọc như một gợi ý thay vì một phán quyết. Sau đó, hãy tự hỏi người dùng trải nghiệm những gì thay vì DOM nói gì. Mọi khoảng trống vẫn còn trong plugin này đều có hình thái thứ hai đó. Chúng tôi ghi lại rằng một hình ảnh nằm bên trong một liên kết, chứ không phải nó là liên kết đó. Chúng tôi đọc một thuộc tính, không phải một tên được tính toán.

Khoảng cách đó là ranh giới thực sự, và một mô hình tốt hơn cũng không khỏa lấp được nó. Việc quyết định chức năng của một hình ảnh là gì đối với người dùng không thể nhìn thấy vẫn đòi hỏi sự phán đoán của con người. Những gì tự động hóa mang lại cho bạn là đảm bảo rằng con người đó đang kiểm tra lại đúng những hình ảnh cần thiết.

Hãy thử plugin alt-text trong quy trình quét hỗ trợ tiếp cận của bạn. Nếu nó đưa ra thông tin sai, vui lòng báo cáo. Hãy mở một issue với phát hiện đó và, nếu công khai, hãy kèm theo liên kết đến trang bị ảnh hưởng.

Viết bởi

Taarik Ashenafi là cựu thực tập sinh kỹ thuật phần mềm trong nhóm hỗ trợ tiếp cận tại GitHub.