Viết checklist kiểm thử accessibility theo WCAG bằng AI
Dùng AI để phác thảo checklist accessibility từ đặc tả, rồi đối chiếu WCAG 2.2 và axe-core. Playbook tập trung vào nội dung phi văn bản, cách phân loại đúng và những điểm vẫn cần review thủ công.
Một ticket ghi: “Thêm nút gửi biểu mẫu bằng icon”. Nếu checklist chỉ có dòng “kiểm tra alt text”, QA rất dễ bỏ sót câu hỏi quan trọng hơn: người dùng công nghệ hỗ trợ có nhận biết được mục đích của nút hay không?
Đó là khoảng cách giữa WCAG và công việc hằng ngày của tester. WCAG có tiêu chí và kỹ thuật chi tiết, nhưng ticket thường ngắn. AI có thể giúp chuyển đặc tả thành bản nháp checklist nhanh hơn. Tuy vậy, đầu ra AI không phải kết luận rằng giao diện đã tuân thủ WCAG.
Mục tiêu là biến yêu cầu thành các điều kiện kiểm thử có thể quan sát, có bằng chứng và có điểm cần review rõ ràng.
Bắt đầu từ mục đích của nội dung, không phải thuộc tính HTML
Một điểm khởi đầu hữu ích là Success Criterion 1.1.1 Non-text Content trong WCAG 2.2.
Tiêu chí này yêu cầu nội dung không phải văn bản được trình bày cho người dùng có phương án thay thế bằng văn bản phục vụ mục đích tương đương, trừ các trường hợp được nêu trong tiêu chí.
Khi viết checklist, trước hết hãy phân loại nội dung theo vai trò:
Ảnh truyền tải thông tin: text alternative cần truyền đạt thông tin hoặc mục đích tương đương.
Ảnh là control hoặc nhận input: cần có tên mô tả mục đích của control.
Biểu đồ hoặc sơ đồ phức tạp: mô tả ngắn có thể chưa đủ; có thể cần mô tả dài hơn để truyền đạt thông tin.
CAPTCHA: cần text alternative mô tả mục đích và một CAPTCHA thay thế theo phương thức cảm nhận khác.
Ảnh trang trí, định dạng hoặc không hiển thị cho người dùng: cần được triển khai để công nghệ hỗ trợ có thể bỏ qua.
WCAG liệt kê nhiều kỹ thuật có thể áp dụng tùy ngữ cảnh, gồm:
alt cho phần tử img;
aria-label;
aria-labelledby;
label liên kết với form control;
aria-describedby cho mô tả dài hơn.
Điểm cần kiểm thử không chỉ là “có thuộc tính hay không”, mà là liệu cách triển khai có truyền đạt đúng mục đích của thành phần hay không.
Dùng AI như công cụ phác thảo checklist
AI phù hợp để tạo bản nháp test case từ feature spec, acceptance criteria hoặc HTML mẫu. Để đầu ra dễ review, hãy yêu cầu AI giữ đúng cấu trúc và nêu rõ giả định.
Quy trình gọn cho một user story:
Liệt kê UI thay đổi
Ghi nhận ảnh, icon, link, form input, control và nội dung mới xuất hiện.
Phân loại nội dung phi văn bản
Xác định đó là nội dung thông tin, trang trí, control, CAPTCHA hay nội dung phức tạp.
Ánh xạ tới WCAG phù hợp
Với nội dung phi văn bản, bắt đầu từ SC 1.1.1.
Nhờ AI tạo test case dạng có cấu trúc
Yêu cầu precondition, steps, expected result, bằng chứng và các điểm cần review.
Chạy kiểm tra tự động tại trạng thái UI phù hợp
axe-core khuyến nghị chèn lệnh chạy kiểm tra tại các điểm UI mới hiển thị hoặc được expose trong test.
Review phần AI và công cụ chưa thể kết luận
Không đóng test chỉ vì AI đề xuất một thuộc tính hoặc tool không báo vi phạm.
Prompt mẫu để tạo checklist
text
Bạn là QA accessibility.
Hãy chuyển đặc tả dưới đây thành checklist kiểm thử theo WCAG.
Chỉ tập trung vào thành phần có trong đặc tả; không tự giả định UI khác.
Đặc tả:
<feature spec>
Với mỗi mục, trả về:
Thành phần UI và mục đích người dùng
Phân loại nội dung: informative, decorative, control, CAPTCHA hoặc complex content
Rủi ro accessibility
Tiêu chí WCAG liên quan
Test type: automated, manual review hoặc cả hai
Preconditions
Test steps
Expected result có thể quan sát
Bằng chứng cần lưu trong test run
Giả định hoặc thông tin còn thiếu
Lưu ý:
Phân biệt ảnh thông tin, ảnh trang trí và ảnh dùng làm control.
Không kết luận pass chỉ dựa vào sự tồn tại của alt hoặc aria-label.
Nêu rõ các điểm cần review thủ công.
Prompt này giúp QA có một bản nháp nhất quán để review, thay vì nhận một danh sách chung chung như “kiểm tra accessibility”.
Ví dụ: nút gửi chỉ có icon
Giả sử đặc tả ghi:
> Biểu mẫu có nút gửi bằng icon. Có ảnh minh họa bên cạnh biểu mẫu, chỉ phục vụ trang trí.
Checklist nên tách hai đối tượng thay vì gộp chung thành “kiểm tra alt text”.
| Thành phần | Điều cần xác minh |
|---|---|
| Nút gửi bằng icon | Có tên mô tả đúng mục đích của control |
| Ảnh minh họa trang trí | Được triển khai để công nghệ hỗ trợ có thể bỏ qua |
Theo SC 1.1.1, một control hoặc nội dung nhận input cần có tên mô tả mục đích. WCAG nêu các kỹ thuật như aria-label, aria-labelledby và label liên kết với form control trong những tình huống phù hợp.
Với ảnh trang trí, WCAG nêu kỹ thuật dùng null alt và không có thuộc tính title để công nghệ hỗ trợ bỏ qua ảnh đó.
Một expected result tốt không nên chỉ ghi:
> Nút có aria-label.
Thay vào đó, hãy viết theo mục đích:
> Nút gửi bằng icon có tên thay thế bằng văn bản mô tả mục đích gửi biểu mẫu.
Cách viết này giúp test case bám vào trải nghiệm cần đạt, đồng thời không khóa chặt team vào một cách triển khai duy nhất.
Đưa axe-core vào điểm UI mới xuất hiện
Theo README của dự án, axe-core là accessibility testing engine cho website và giao diện dựa trên HTML. Dự án cho biết axe-core có thể phát hiện tự động trung bình 57% vấn đề WCAG.
axe-core cũng trả về các phần tử ở trạng thái incomplete khi công cụ không thể chắc chắn và cần review thủ công. Vì vậy, kết quả không có violations không đồng nghĩa với việc có thể tự động kết luận toàn bộ giao diện đã đáp ứng WCAG.
README công bố cách cài đặt:
console
npm install axe-core --save-dev
Hoặc:
console
pnpm add --save-dev axe-core
Tài liệu hướng dẫn đưa file JavaScript vào fixture hoặc hệ thống test:
html
<script src="nodemodules/axe-core/axe.min.js"></script>
Sau đó, chạy kiểm tra tại thời điểm UI mới hiển thị hoặc được expose:
js
axe
.run()
.then(results => {
if (results.violations.length) {
throw new Error('Accessibility issues found');
}
})
.catch(err => {
console.error('Something bad happened:', err.message);
});
Với automation, hãy xác định các trạng thái cần quét thay vì chỉ quét trang ban đầu. Ví dụ: sau khi một vùng UI mới được hiển thị, hãy chạy check tại chính trạng thái đó.
README cũng lưu ý rule color-contrast hiện không hoạt động với JSDOM. Nếu suite dùng JSDOM, không nên diễn giải việc rule này không báo lỗi thành kết luận contrast đã đạt yêu cầu.
Review đầu ra AI và kết quả axe-core
Trước khi đưa checklist AI tạo ra vào test run, hãy kiểm tra các điểm sau:
Thiếu thành phần: AI có bỏ qua icon, ảnh trang trí hoặc nội dung phi văn bản nào không?
Phân loại sai: ảnh trông có vẻ trang trí nhưng thực tế có thể chứa thông tin.
Expected result quá kỹ thuật: “có alt” hoặc “có aria-label” chưa mô tả được mục đích cần truyền đạt.
Giả định không có trong đặc tả: AI có tự thêm control, trạng thái hoặc luồng người dùng không?
Bỏ qua incomplete: đây là mục cần review, không phải mục có thể đóng ngay.
Mẫu ghi nhận lỗi
Khi phát hiện vấn đề, hãy mô tả tác động và hành vi quan sát được, không chỉ nêu thuộc tính thiếu.
text
Title: Nút gửi bằng icon không có tên mô tả mục đích
Environment:
<môi trường test>
Steps:
<mở biểu mẫu>
<xác định nút gửi bằng icon>
<kiểm tra tên thay thế bằng văn bản của control>
Actual:
<những gì được quan sát>
Expected:
<Nút cần có tên mô tả mục đích gửi biểu mẫu>
WCAG reference:
SC 1.1.1 Non-text Content
Evidence:
<kết quả axe-core / DOM snippet / bằng chứng phù hợp>
Checklist trước khi đóng ticket
[ ] Đã phân loại nội dung phi văn bản theo mục đích.
[ ] Đã đối chiếu các mục liên quan với SC 1.1.1.
[ ] Đã review giả định trong checklist do AI tạo.
[ ] Đã chạy axe-core tại các trạng thái UI cần kiểm tra.
[ ] Đã xem cả violations và incomplete.
[ ] Đã viết expected result theo mục đích người dùng, không chỉ theo thuộc tính HTML.
[ ] Đã lưu bằng chứng phù hợp cho kết quả test.
AI giúp khởi tạo checklist nhanh hơn. WCAG giúp QA có tiêu chí để đối chiếu. Còn axe-core giúp phát hiện sớm một phần vấn đề tự động. Kết hợp cả ba theo đúng vai trò sẽ tạo ra test case rõ hơn và dễ review hơn trong mỗi sprint.