Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một website đặt vé xem phim rất đẹp: hình ảnh rực rỡ, hiệu ứng mượt mà, nút bấm bo tròn xinh xắn. Nhưng có một nhóm người dùng hoàn toàn không thể mua được vé — người khiếm thị dùng trình đọc màn hình (screen reader), người khiếm thính không nghe được video hướng dẫn, người bị run tay không thể click chính xác vào nút nhỏ xíu, và cả người bị mù màu không phân biệt được nút "Xác nhận" màu xanh với nút "Hủy" màu đỏ. Với họ, website "đẹp" của bạn thực chất là một bức tường.
Accessibility Testing (kiểm thử khả năng tiếp cận) là công việc đảm bảo sản phẩm số có thể được sử dụng bởi tất cả mọi người, bao gồm người khuyết tật về thị giác, thính giác, vận động và nhận thức. Đây không phải chuyện "làm cho tử tế" mà là yêu cầu bắt buộc ở nhiều thị trường. Tại Mỹ có luật ADA (Americans with Disabilities Act) và Section 508; tại châu Âu có European Accessibility Act (bắt buộc từ tháng 6/2025); tại Việt Nam, các cơ quan nhà nước và doanh nghiệp xuất khẩu dịch vụ số ngày càng phải tuân thủ. Theo WHO, khoảng 16% dân số thế giới sống với một dạng khuyết tật nào đó — đó là hơn 1,3 tỷ người, một thị trường khổng lồ mà nhiều sản phẩm đang vô tình bỏ rơi.
Trong khóa học này, các bài khác đã dạy bạn về usability (Bài 18) hay compatibility (Bài 20). Bài 19 tập trung riêng vào WCAG 2.1 — bộ tiêu chuẩn quốc tế do W3C ban hành, kim chỉ nam cho mọi hoạt động kiểm thử accessibility. Hết bài này, bạn sẽ hiểu bốn nguyên tắc POUR, ba cấp độ tuân thủ, và biết cách kiểm thử thực tế bằng công cụ lẫn thao tác tay.
Khái niệm cốt lõi
WCAG 2.1 là gì
WCAG (Web Content Accessibility Guidelines) là bộ hướng dẫn do nhóm WAI (Web Accessibility Initiative) thuộc W3C phát triển. Phiên bản 2.1 ra đời năm 2018, kế thừa 2.0 và bổ sung 17 tiêu chí mới chủ yếu liên quan đến thiết bị di động, người khiếm thị nhẹ và người có khó khăn về nhận thức. (Lưu ý: WCAG 2.2 đã ra mắt cuối 2023, nhưng 2.1 vẫn là mốc tuân thủ phổ biến nhất trong hợp đồng và luật định hiện nay, nên chúng ta học 2.1 làm nền tảng.)
Cấu trúc WCAG có 4 tầng:
- 4 nguyên tắc (Principles) — chính là POUR.
- 13 hướng dẫn (Guidelines) — mục tiêu chung dưới mỗi nguyên tắc.
- 78 tiêu chí thành công (Success Criteria) — đây là thứ tester thực sự kiểm, vì mỗi tiêu chí "đạt/không đạt" rõ ràng.
- Kỹ thuật (Techniques) — cách triển khai cụ thể để đáp ứng tiêu chí.
Bốn nguyên tắc POUR
Toàn bộ WCAG xoay quanh bốn chữ cái POUR. Đây là "xương sống" bạn phải thuộc lòng.
P — Perceivable (Có thể nhận thức được). Thông tin và giao diện phải được trình bày sao cho người dùng nhận biết được bằng ít nhất một giác quan. Ví dụ điển hình: mọi hình ảnh có ý nghĩa phải có văn bản thay thế (alt text) để screen reader đọc lên; video phải có phụ đề (captions); văn bản phải có độ tương phản màu đủ cao so với nền.
O — Operable (Có thể thao tác được). Mọi chức năng phải thao tác được bằng nhiều phương thức, đặc biệt là bàn phím — không được bắt buộc phải dùng chuột. Người khiếm thị hoặc người bị liệt tay thường điều hướng hoàn toàn bằng phím Tab, Enter, mũi tên. Nguyên tắc này cũng cấm các nội dung nhấp nháy quá 3 lần/giây (nguy cơ gây động kinh) và yêu cầu cho người dùng đủ thời gian đọc, thao tác.
U — Understandable (Có thể hiểu được). Nội dung và cách vận hành phải dễ hiểu. Thông báo lỗi phải rõ ràng và gợi ý cách sửa ("Số điện thoại phải có 10 chữ số" thay vì "Lỗi 402"). Giao diện phải nhất quán, không đánh đố người dùng.
R — Robust (Vững chắc). Nội dung phải đủ vững để nhiều loại công nghệ hỗ trợ (assistive technology) khác nhau hiểu được, hôm nay và cả tương lai. Điều này đòi hỏi HTML hợp lệ, dùng đúng thẻ ngữ nghĩa (semantic HTML), và gắn thuộc tính ARIA đúng cách để screen reader nhận diện được vai trò từng thành phần.
Ba cấp độ tuân thủ: A, AA, AAA
Mỗi tiêu chí thành công gắn với một cấp độ:
- Level A — tối thiểu, bắt buộc. Nếu không đạt, một số nhóm người dùng hoàn toàn không dùng được sản phẩm.
- Level AA — mục tiêu tiêu chuẩn của hầu hết doanh nghiệp và luật pháp. Khi ai đó nói "chúng tôi tuân thủ WCAG", thường ngầm hiểu là AA.
- Level AAA — mức cao nhất, lý tưởng nhưng khó đạt toàn bộ; thường chỉ áp dụng cho dịch vụ công thiết yếu.
Công nghệ hỗ trợ (Assistive Technology) mà tester cần biết
Để kiểm thử tốt, bạn phải hiểu người khuyết tật dùng gì: screen reader (NVDA, JAWS trên Windows; VoiceOver trên macOS/iOS; TalkBack trên Android) đọc màn hình thành giọng nói; screen magnifier phóng to; điều hướng chỉ bằng bàn phím; phần mềm nhận diện giọng nói để ra lệnh. Là tester, bạn không cần khuyết tật thật, nhưng phải biết mô phỏng cách họ dùng sản phẩm.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Việt Nam bị "mù" ở khâu thanh toán
Một sàn TMĐT giả định tên "ShopViet" có lượng truy cập 2 triệu lượt/tháng. Nhóm QA nhận yêu cầu kiểm thử accessibility trước khi ký hợp đồng với một đối tác Nhật Bản (thị trường Nhật rất khắt khe về accessibility). Khi test bằng screen reader NVDA, tester phát hiện: ở bước cuối thanh toán, nút "Đặt hàng" được code bằng thẻ <div> gắn sự kiện click bằng JavaScript, không phải <button>. Kết quả: NVDA không đọc được nút này, và người dùng bàn phím nhấn Tab không bao giờ tới được nó. Tức là người khiếm thị có thể chọn hàng, thêm giỏ, nhập địa chỉ, nhưng không thể bấm nút cuối để trả tiền.
Diễn giải: đây là lỗi vi phạm nguyên tắc Operable (không thao tác được bằng bàn phím) và Robust (không dùng semantic HTML). Nhóm phải đổi <div> thành <button>, và ngay lập tức vấn đề được giải quyết vì thẻ <button> gốc đã có sẵn khả năng focus bằng Tab và kích hoạt bằng Enter/Space.
Bài học: rất nhiều lỗi accessibility nghiêm trọng đến từ việc lập trình viên "vẽ" nút bằng div/span cho dễ style, thay vì dùng thẻ HTML đúng. Là tester, hãy luôn thử "rút chuột ra, chỉ dùng bàn phím" — đây là bài test đơn giản mà phát hiện được vô số lỗi.
Ví dụ 2 — Ngân hàng số và cái bẫy tương phản màu
Một ngân hàng số ở Đông Nam Á ra mắt app với thiết kế "sang chảnh": chữ xám nhạt (#A0A0A0) trên nền trắng cho phần điều khoản và số dư phụ. Trên màn hình designer đắt tiền trong phòng máy lạnh, nó trông rất tinh tế. Nhưng khi khách hàng lớn tuổi dùng điện thoại ngoài trời nắng, họ không đọc nổi số dư. Nhóm QA đo bằng công cụ và phát hiện tỷ lệ tương phản chỉ 2.6:1, thấp hơn nhiều so với ngưỡng AA là 4.5:1.
Diễn giải: vi phạm nguyên tắc Perceivable (tiêu chí 1.4.3 Contrast Minimum). Vấn đề càng nghiêm trọng vì đây là thông tin tài chính. Nhóm QA lập bug với severity cao, kèm ảnh chụp và số đo cụ thể. Design chỉnh chữ xuống #595959, đạt tỷ lệ 7:1 (vừa qua cả AAA), mà mắt thường vẫn thấy nhẹ nhàng.
Bài học: "đẹp" theo cảm quan designer và "đọc được" theo tiêu chuẩn là hai chuyện khác nhau. Tester cần một công cụ đo tương phản khách quan (như tính năng trong Chrome DevTools hay tiện ích WebAIM Contrast Checker), không tranh cãi bằng cảm tính.
Ví dụ 3 — Form đăng ký thiếu nhãn khiến screen reader "câm"
Một startup edtech Việt Nam (đặt tên "HocTot") có form đăng ký khóa học với các ô nhập chỉ dùng placeholder ("Nhập họ tên", "Nhập email") mà không có thẻ <label> thật. Khi người khiếm thị Tab vào ô, screen reader chỉ đọc "edit, blank" — họ không biết ô này để nhập gì, vì placeholder biến mất ngay khi bắt đầu gõ. Ngoài ra, khi để trống rồi submit, thông báo lỗi hiện màu đỏ nhưng không được gắn với ô tương ứng, nên screen reader không đọc lỗi.
Diễn giải: vi phạm cả Perceivable (thiếu label — tiêu chí 1.3.1, 4.1.2) lẫn Understandable (lỗi không được thông báo rõ — tiêu chí 3.3.1 Error Identification). Cách sửa: thêm <label> gắn với mỗi input qua thuộc tính for/id, và dùng ARIA aria-describedby để nối thông báo lỗi vào ô.
Bài học: placeholder KHÔNG thay thế được label. Đây là một trong những lỗi phổ biến nhất và dễ sửa nhất, nhưng ảnh hưởng trực tiếp đến khả năng dùng form — mà form thì có mặt ở mọi sản phẩm.
Hướng dẫn từng bước
Dưới đây là quy trình kiểm thử accessibility bạn có thể áp dụng ngay cho một trang web.
Bước 1 — Xác định phạm vi và cấp độ mục tiêu. Hỏi rõ: sản phẩm cần đạt WCAG 2.1 cấp A hay AA? Kiểm những trang/luồng nào (thường ưu tiên luồng cốt lõi: đăng nhập, tìm kiếm, thanh toán). Ghi rõ vào test plan.
Bước 2 — Chạy công cụ quét tự động. Dùng axe DevTools (tiện ích Chrome/Firefox miễn phí), WAVE của WebAIM, hoặc Lighthouse tích hợp sẵn trong Chrome DevTools. Chúng phát hiện nhanh các lỗi máy đọc được: thiếu alt, tương phản thấp, thiếu label, thiếu thuộc tính lang. Lưu ý quan trọng: công cụ tự động chỉ bắt được khoảng 30–40% lỗi accessibility. Đừng bao giờ dừng ở đây.
Bước 3 — Kiểm thử bằng bàn phím. Cất chuột đi. Dùng Tab để di chuyển tới, Shift+Tab để lùi, Enter/Space để kích hoạt, mũi tên cho menu và dropdown. Kiểm tra ba điều: (1) có tới được mọi phần tử tương tác không, (2) thứ tự focus có hợp lý không, (3) có nhìn thấy viền focus (focus indicator) rõ ràng không. Đặc biệt cảnh giác "keyboard trap" — Tab vào một component rồi không thoát ra được.
Bước 4 — Kiểm thử bằng screen reader. Bật NVDA (Windows, miễn phí) hoặc VoiceOver (Mac: Cmd+F5). Nhắm mắt lại và cố hoàn thành một tác vụ. Nghe xem screen reader đọc gì: hình ảnh có được mô tả không, nút có được gọi đúng tên và vai trò không, tiêu đề (heading) có được thông báo cấp bậc không.
Bước 5 — Kiểm tra các khía cạnh cảm quan cụ thể. Đo tương phản màu ở các cặp chữ/nền. Phóng to trang lên 200% xem nội dung có bị vỡ hay mất không (tiêu chí 1.4.4 Resize Text). Kiểm tra: thông tin có bao giờ chỉ truyền tải bằng màu sắc đơn thuần không (ví dụ ô bắt buộc chỉ tô đỏ mà không có dấu * hay chữ).
Bước 6 — Ghi nhận và báo cáo. Mỗi lỗi ghi rõ: tiêu chí WCAG bị vi phạm (ví dụ "1.4.3 Contrast — Level AA"), mô tả, cách tái hiện, ảnh/đo lường, và mức độ nghiêm trọng. Việc gắn đúng số tiêu chí giúp dev tra cứu cách sửa nhanh.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin tưởng tuyệt đối vào công cụ tự động. Như đã nói, chúng chỉ bắt được 1/3 vấn đề. Một trang có thể "100% pass Lighthouse" nhưng screen reader vẫn không dùng được. Luôn kết hợp test tay.
Lỗi 2 — Dùng placeholder thay label. Placeholder biến mất khi gõ, không được screen reader đọc ổn định, và thường có tương phản thấp. Luôn dùng <label> thật.
Lỗi 3 — Alt text vô nghĩa. Viết alt="image123.png" hay alt="hình ảnh" còn tệ hơn không có. Alt phải mô tả nội dung/chức năng. Với ảnh trang trí thuần túy, để alt="" (rỗng) để screen reader bỏ qua.
Lỗi 4 — Lạm dụng ARIA. Có câu châm ngôn: "No ARIA is better than bad ARIA" (không dùng ARIA còn hơn dùng sai). Nhiều dev gắn role, aria-* lung tung khiến screen reader đọc sai. Ưu tiên semantic HTML gốc trước.
Lỗi 5 — Bỏ qua trạng thái động. Nội dung load bằng AJAX, thông báo toast, modal popup thường không được screen reader thông báo. Cần dùng ARIA live region (aria-live) và quản lý focus khi mở/đóng modal.
Mẹo hữu ích:
- Học thuộc "phím tắt vàng": chỉ dùng Tab đi hết trang là bài test nhanh nhất, rẻ nhất.
- Cài sẵn tiện ích axe DevTools và WAVE trên trình duyệt test.
- Dùng công cụ giả lập mù màu (Chrome DevTools > Rendering > Emulate vision deficiencies) để thấy trang qua mắt người mù màu.
- Với sản phẩm tiếng Việt, kiểm tra thuộc tính
lang="vi"trên thẻ<html>để screen reader phát âm tiếng Việt đúng, không đọc giọng tiếng Anh ngọng nghịu.
Bài tập thực hành
- Đo tương phản: Chọn một website tiếng Việt bất kỳ (ví dụ trang tin tức hoặc TMĐT bạn hay dùng). Dùng WebAIM Contrast Checker đo tỷ lệ tương phản của phần chữ chính và ít nhất 3 nút/liên kết. Ghi lại cặp nào KHÔNG đạt ngưỡng AA (4.5:1) và đề xuất mã màu thay thế.
- Test bàn phím: Mở trang đăng nhập của một dịch vụ bạn dùng. Cất chuột, chỉ dùng bàn phím hoàn thành đăng nhập. Ghi lại: có phần tử nào Tab không tới được không? Viền focus có rõ không? Có bị keyboard trap ở đâu không?
- Test screen reader: Bật VoiceOver (Mac) hoặc NVDA (Windows). Nhắm mắt, cố thêm một sản phẩm vào giỏ hàng trên một trang TMĐT. Ghi lại 3 điểm khiến trải nghiệm khó khăn và gắn mỗi điểm với tiêu chí WCAG tương ứng.
- Viết bug report: Từ một lỗi bạn tìm được ở bài 1–3, viết một bug report hoàn chỉnh gồm: tiêu chí WCAG bị vi phạm, cấp độ (A/AA), các bước tái hiện, kết quả mong đợi, kết quả thực tế và mức độ nghiêm trọng.
Tóm tắt
Accessibility Testing đảm bảo sản phẩm số dùng được cho tất cả mọi người, kể cả người khuyết tật — vừa là trách nhiệm đạo đức, vừa là yêu cầu pháp lý ở nhiều thị trường, vừa mở rộng tệp khách hàng. Kim chỉ nam là WCAG 2.1 với bốn nguyên tắc POUR: Perceivable (nhận thức được), Operable (thao tác được), Understandable (hiểu được), Robust (vững chắc). Có ba cấp độ tuân thủ A, AA, AAA, trong đó AA là mục tiêu thực tế phổ biến nhất.
Quy trình kiểm thử kết hợp ba lớp: công cụ tự động (axe, WAVE, Lighthouse — chỉ bắt ~1/3 lỗi), test bằng bàn phím (rút chuột ra), và test bằng screen reader (NVDA, VoiceOver, TalkBack). Những lỗi phổ biến nhất mà tester phải cảnh giác gồm: div giả làm nút, placeholder thay label, tương phản màu thấp, alt text vô nghĩa, và ARIA dùng sai. Với sản phẩm tiếng Việt, đừng quên thuộc tính lang="vi". Khi báo cáo, hãy luôn gắn đúng số tiêu chí WCAG để đội phát triển sửa nhanh và chính xác.