Mở đầu — vì sao bài này quan trọng
Hãy thử tưởng tượng bạn vừa tung ra một ứng dụng đặt vé xem phim rất đẹp, hiệu ứng chuyển động mượt mà, màu sắc bắt mắt. Nhưng có một nhóm người dùng hoàn toàn không thể mua nổi một tấm vé: người khiếm thị dùng trình đọc màn hình (screen reader) không nghe được nút "Đặt vé" vì nó chỉ là một <div> không có nhãn; người không dùng được chuột (do liệt tay, run tay, hoặc chỉ thích bàn phím) bị kẹt vì không thể Tab tới ô chọn ghế; người lớn tuổi mắt kém không đọc nổi dòng chữ xám nhạt trên nền trắng. Họ không phàn nàn — họ chỉ lặng lẽ rời đi.
Tại Việt Nam có khoảng hơn 6 triệu người khuyết tật (theo Tổng điều tra dân số), chưa kể nhóm "khuyết tật tình huống" rất lớn: người đang bế con nên chỉ dùng được một tay, người đi xe buýt xóc nảy khó bấm chính xác, người ra ngoài nắng chói không nhìn rõ màn hình. Accessibility (viết tắt là a11y — vì giữa chữ "a" và "y" có 11 ký tự) không phải là làm từ thiện cho một nhóm nhỏ, mà là mở rộng tệp người dùng và giảm rủi ro pháp lý, thương hiệu.
Bài này tập trung vào Accessibility Testing — cách bạn, với tư cách một UX Researcher, kiểm tra xem sản phẩm có thực sự dùng được với người khuyết tật hay không. Đây là một dạng nghiên cứu đánh giá (evaluative) rất đặc thù, kết hợp công cụ tự động, kiểm thử thủ công, và quan trọng nhất là nghiên cứu với người dùng thật có khiếm khuyết. Bạn sẽ học cách phối hợp cả ba lớp này để không bỏ sót lỗi.
Khái niệm cốt lõi
Trước khi nói về cách test, cần nắm chuẩn tham chiếu. Trên thế giới, gần như mọi tổ chức đều dựa vào WCAG (Web Content Accessibility Guidelines) do W3C ban hành, hiện ở phiên bản 2.2. WCAG xoay quanh bốn nguyên tắc, viết tắt là POUR:
- Perceivable (Cảm nhận được) — người dùng phải nhận biết được nội dung qua ít nhất một giác quan. Ví dụ: ảnh phải có văn bản thay thế (alt text), video phải có phụ đề.
- Operable (Thao tác được) — mọi chức năng phải dùng được, kể cả khi chỉ có bàn phím. Không được "bẫy" người dùng vào một vùng không thoát ra được.
- Understandable (Hiểu được) — nội dung và cách vận hành phải dễ hiểu, dễ đoán; thông báo lỗi phải rõ ràng.
- Robust (Vững chắc) — mã nguồn phải tương thích với công nghệ hỗ trợ (assistive technology) như trình đọc màn hình.
Phần kiểm thử a11y chia làm ba lớp bổ trợ cho nhau. Không lớp nào thay thế được lớp nào.
Lớp 1 — Automated tools (Kiểm thử tự động)
Đây là tuyến đầu, nhanh và rẻ. Các công cụ phổ biến:
- axe DevTools (của Deque) — extension trình duyệt, quét một trang và liệt kê lỗi kèm hướng dẫn sửa. Được xem là chuẩn mực về độ chính xác, ít báo lỗi giả.
- Lighthouse — tích hợp sẵn trong Chrome DevTools, cho điểm Accessibility từ 0–100. Tiện để theo dõi xu hướng nhưng nông.
- WAVE (của WebAIM) — hiển thị lỗi trực quan ngay trên trang bằng biểu tượng, rất dễ cho người mới.
Lớp 2 — Manual testing (Kiểm thử thủ công)
Đây là nơi bạn bắt phần lớn 60–70% lỗi còn lại. Ba kỹ thuật chủ lực:
- Keyboard navigation (điều hướng bằng bàn phím) — rút chuột ra, chỉ dùng
Tab,Shift+Tab,Enter,Space, phím mũi tên. Bạn kiểm tra: có Tab tới được mọi thành phần tương tác không? Thứ tự Tab có logic không? Có thấy được "focus indicator" (viền sáng quanh phần tử đang chọn) không? Có bị "keyboard trap" — kẹt trong một popup không thoát ra được không? - Screen reader testing (trình đọc màn hình) — bật trình đọc và nhắm mắt nghe. Trên macOS dùng VoiceOver (Cmd+F5), trên Windows dùng NVDA (miễn phí) hoặc JAWS, trên Android có TalkBack, trên iOS có VoiceOver. Bạn nghe xem nút có được đọc đúng tên không, ảnh có mô tả không, lỗi form có được thông báo không.
- Zoom / Reflow — phóng to trình duyệt lên 200% và 400%. Theo WCAG, nội dung phải còn đọc được, không bị tràn ngang, không che mất chữ. Cũng nên thử tăng cỡ chữ hệ thống.
Lớp 3 — User testing với người khuyết tật
Lớp cao nhất và giá trị nhất: mời chính người dùng có khiếm khuyết thật — người khiếm thị dùng screen reader hằng ngày, người vận động khó khăn dùng bàn phím hoặc thiết bị chuyển mạch (switch), người khiếm thính — tham gia một buổi usability test. Họ sẽ phát hiện những vấn đề mà người sáng mắt, dùng chuột thành thạo như bạn không bao giờ hình dung ra. Lưu ý: lớp này tận dụng kỹ năng moderated usability testing đã học ở các bài trước, nhưng đối tượng và cách chuẩn bị rất khác — bạn cần để họ dùng chính công nghệ hỗ trợ quen thuộc của họ, không ép họ dùng thiết bị lạ.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT và cái bẫy "điểm Lighthouse 95"
Một sàn thương mại điện tử tại TP.HCM (gọi là "ShopViet") tự tin vì trang sản phẩm đạt điểm Lighthouse Accessibility 95/100. Đội phát triển coi như xong việc. Nhưng khi đội Research mời ba người khiếm thị dùng NVDA và VoiceOver test thử quy trình mua hàng, kết quả gây sốc: cả ba đều không hoàn tất được đơn.
Vì sao? Lighthouse 95 nhưng vẫn ẩn chứa hàng loạt lỗi máy không bắt được. Nút "Thêm vào giỏ" là một thẻ <div> có icon giỏ hàng — screen reader chỉ đọc "nút" trống rỗng, không biết nó làm gì. Bộ chọn số lượng dùng dấu "+" và "−" bằng hình ảnh, không có nhãn. Quan trọng nhất: sau khi thêm vào giỏ, một toast thông báo "Đã thêm" hiện ra rồi tự biến mất — screen reader không hề đọc lên (vì thiếu thuộc tính aria-live), nên người khiếm thị không biết hành động đã thành công, cứ bấm đi bấm lại và thêm nhầm 5 sản phẩm vào giỏ.
Bài học rút ra: điểm số tự động cao không đồng nghĩa với "dùng được". Lighthouse không thể đánh giá trải nghiệm theo thời gian của người dùng screen reader. Chỉ một buổi test với người thật, kéo dài chưa tới một giờ, đã lộ ra vấn đề mà 95 điểm tự động che giấu hoàn toàn.
Ví dụ 2 — Ứng dụng ngân hàng số và bài test bàn phím 30 phút
Một ngân hàng số (giả định "VBank Digital") chuẩn bị ra mắt tính năng chuyển khoản mới. Trước khi mời người dùng khuyết tật, một researcher quyết định làm bài test rẻ tiền nhất: rút chuột, chỉ dùng bàn phím đi hết luồng chuyển khoản trong đúng 30 phút.
Phát hiện liên tiếp: ô nhập số tài khoản có thể Tab tới, nhưng cái lịch chọn ngày giao dịch thì không — phải bấm chuột mới mở được. Modal xác nhận OTP là một "keyboard trap": khi nó hiện lên, Tab cứ chạy vòng vòng các nút phía sau modal chứ không vào được ô nhập OTP, và không có cách nào đóng modal bằng phím Esc. Tệ hơn, focus indicator bị CSS xóa mất (outline: none) nên ngay cả khi Tab đúng chỗ, người dùng cũng không nhìn thấy mình đang ở đâu.
Đội kỹ thuật sửa ba lỗi này trong hai ngày, trước khi tốn tiền mời người dùng thật. Bài học rút ra: keyboard navigation là phép thử "đáng đồng tiền" nhất trong a11y — không tốn công cụ, không tốn tuyển người, nhưng bắt được nhóm lỗi nghiêm trọng ảnh hưởng cả người khuyết tật lẫn power user. Hãy làm nó trước, để dành ngân sách test người thật cho những lỗi tinh vi hơn.
Ví dụ 3 — Ứng dụng học trực tuyến và người dùng thật
Một startup edtech ở Hà Nội ("HocCung") làm app dạy tiếng Anh, muốn đảm bảo học viên khiếm thị dùng được. Họ tuyển bốn người tham gia qua Hội Người mù Hà Nội, trả thù lao 500.000đ/buổi, mỗi buổi 60 phút, để người dùng làm bài học đầu tiên bằng chính điện thoại và TalkBack quen thuộc của họ.
Công cụ tự động trước đó cho điểm khá tốt. Nhưng buổi test hé lộ vấn đề rất "con người": bài tập trắc nghiệm có bốn đáp án A, B, C, D dạng nút bấm. Screen reader đọc đúng nội dung từng đáp án, nhưng khi người dùng chọn sai, app chỉ đổi màu nút sang đỏ — một tín hiệu hoàn toàn vô hình với người khiếm thị. Họ không biết mình trả lời đúng hay sai, mất hết động lực học. Ngoài ra, các icon "phát âm thanh" nằm cạnh mỗi từ vựng đều được đọc thành "button button button" liên tiếp, gây nhiễu kinh khủng.
Đội sửa bằng cách bổ sung thông báo bằng âm thanh/văn bản ("Đáp án đúng" / "Chưa đúng, thử lại") và đặt nhãn rõ cho từng nút phát âm. Bài học rút ra: chỉ truyền tải thông tin bằng màu sắc đơn thuần là một trong những lỗi a11y phổ biến nhất, và chỉ người dùng thật mới giúp bạn cảm nhận hết mức độ nghiêm trọng của nó.
Hướng dẫn từng bước
Dưới đây là quy trình bạn có thể áp dụng cho một tính năng hoặc một luồng quan trọng.
Bước 1 — Xác định phạm vi và luồng cốt lõi. Đừng cố test cả sản phẩm cùng lúc. Chọn 1–2 luồng quan trọng nhất (ví dụ: đăng ký, thanh toán, gửi đơn). Accessibility cũng tuân theo nguyên tắc 80/20.
Bước 2 — Quét tự động trước. Chạy axe DevTools hoặc WAVE trên từng màn hình trong luồng. Ghi lại và sửa ngay các lỗi rõ ràng: thiếu alt text, độ tương phản thấp, thiếu nhãn form. Đây là cách dọn "rác lớn" để buổi test thủ công không bị phân tâm bởi lỗi vặt.
Bước 3 — Test bàn phím. Rút chuột. Đi hết luồng bằng Tab, Enter, Space, mũi tên, Esc. Kiểm tra: tới được mọi thứ không, thứ tự logic không, thấy focus không, có keyboard trap không. Ghi chú từng điểm vướng.
Bước 4 — Test screen reader. Bật NVDA (Windows) hoặc VoiceOver (Mac/iOS) hoặc TalkBack (Android). Nhắm mắt và đi lại luồng đó. Lắng nghe: nút có tên đúng nghĩa không, ảnh có mô tả không, thông báo động (toast, lỗi) có được đọc không, tiêu đề trang có cấu trúc không.
Bước 5 — Test zoom và reflow. Phóng to 200% rồi 400%. Kiểm tra nội dung không bị tràn, không bị che, vẫn thao tác được.
Bước 6 — Test với người dùng thật. Sau khi đã dọn sạch lỗi ở bước 2–5, mới mời người khuyết tật tham gia. Tuyển qua các hội/nhóm chuyên biệt (Hội Người mù, cộng đồng người khiếm thính...). Để họ dùng chính thiết bị và công nghệ hỗ trợ của họ. Quan sát, đừng can thiệp, đừng "mớm" thao tác.
Bước 7 — Tổng hợp và phân mức nghiêm trọng. Gom mọi phát hiện vào một bảng: mô tả lỗi, ai bị ảnh hưởng, mức độ (chặn hoàn toàn / cản trở / khó chịu), tiêu chí WCAG liên quan, gợi ý sửa. Ưu tiên các lỗi "chặn hoàn toàn" trước.
Lỗi thường gặp & mẹo
Lỗi: coi điểm tự động là đích đến. Như đã thấy ở ví dụ ShopViet, điểm 95–100 không đảm bảo gì cả. Mẹo: luôn đặt automated tools là điểm khởi đầu, không phải dòng kết.
Lỗi: chỉ test trên desktop. Phần lớn người Việt dùng app trên điện thoại, và nhiều người khuyết tật cũng vậy. Hãy test TalkBack/VoiceOver trên di động thật, không chỉ NVDA trên máy tính.
Lỗi: truyền thông tin chỉ bằng màu. Đỏ là sai, xanh là đúng — vô nghĩa với người mù màu (khoảng 8% nam giới) và người khiếm thị. Mẹo: luôn kèm thêm icon, văn bản, hoặc nhãn.
Lỗi: xóa focus indicator vì lý do thẩm mỹ. Designer hay ghét cái viền xanh khi Tab. Đừng bao giờ đặt outline: none mà không thay bằng một focus style rõ ràng khác.
Lỗi: dùng người không khuyết tật "đóng vai". Bạn bịt mắt rồi tự dùng screen reader rất hữu ích để học, nhưng không thay thế được người dùng screen reader thành thạo. Họ điều hướng nhanh gấp nhiều lần và biết những thủ thuật bạn không biết.
Mẹo vàng: học vài phím tắt screen reader cơ bản (đọc tiêu đề, đọc liên kết, đọc danh sách form) để hiểu cách người mù quét trang thay vì đọc tuần tự. Điều này thay đổi hoàn toàn cách bạn đánh giá cấu trúc nội dung.
Bài tập thực hành
Chọn một trang web hoặc app bạn hay dùng (ví dụ trang đặt vé, app ngân hàng, hoặc chính sản phẩm công ty bạn). Thực hiện:
- Quét tự động: cài axe DevTools hoặc WAVE, quét một màn hình chính, ghi lại 5 lỗi nghiêm trọng nhất.
- Test bàn phím: rút chuột, đi hết một luồng (ví dụ tìm kiếm rồi xem chi tiết). Ghi lại mọi điểm bạn bị kẹt hoặc không thấy focus.
- Test screen reader 15 phút: bật VoiceOver (Mac/iOS) hoặc TalkBack (Android), nhắm mắt và thử hoàn thành một tác vụ đơn giản. Viết lại cảm giác và 3 điểm gây bối rối nhất.
- Tổng hợp: lập một bảng nhỏ gồm cột [Lỗi] – [Ai bị ảnh hưởng] – [Mức nghiêm trọng] – [Gợi ý sửa] với ít nhất 6 dòng.
Tóm tắt
Accessibility Testing là việc kiểm tra sản phẩm có thực sự dùng được với người khuyết tật và người dùng trong tình huống hạn chế hay không, lấy WCAG (mục tiêu thực tế là mức AA) làm chuẩn tham chiếu với bốn nguyên tắc POUR. Phương pháp gồm ba lớp bổ trợ: automated tools (axe, Lighthouse, WAVE) bắt 30–40% lỗi và là điểm khởi đầu; manual testing (điều hướng bàn phím, screen reader, zoom) bắt phần lớn lỗi còn lại với chi phí thấp; và user testing với người khuyết tật thật phát hiện những vấn đề con người mà không công cụ nào thấy được. Quy trình khôn ngoan là dọn lỗi tự động và thủ công trước, rồi mới dành ngân sách cho người dùng thật. Ba bài học cốt lõi từ thực tế Việt Nam: đừng tin điểm số tự động, hãy ưu tiên test bàn phím vì nó rẻ và hiệu quả, và đừng bao giờ chỉ truyền thông tin bằng màu sắc. Làm tốt a11y không chỉ là tuân thủ — đó là mở rộng tệp người dùng và xây dựng một sản phẩm tử tế hơn với tất cả mọi người.