Mở đầu — vì sao bài này quan trọng
Suốt hơn 50 bài học vừa qua, chúng ta đã trang bị cho bạn một kho công cụ khổng lồ: từ semantic HTML, ARIA, color contrast, keyboard navigation, cho tới các trình kiểm thử tự động và cách tự mình test bằng screen reader. Bạn có thể tự tin nói rằng sản phẩm của mình "đạt WCAG AA". Nhưng tôi muốn hỏi bạn một câu thẳng thắn: Bạn đã bao giờ thực sự ngồi cạnh một người mù, một người liệt hai tay, hay một người khiếm thính và xem họ dùng sản phẩm của bạn chưa?
Nếu câu trả lời là "chưa", thì bài học hôm nay chính là mảnh ghép còn thiếu quan trọng nhất trong toàn bộ khóa học.
Đây là sự thật mà nhiều kỹ sư và designer không muốn thừa nhận: tuân thủ WCAG không đồng nghĩa với việc sản phẩm dễ dùng cho người khuyết tật. Một nút bấm có thể có aria-label hoàn hảo, contrast 7:1, focus indicator rõ ràng — nhưng khi một người khiếm thị thật sự dùng thử, họ vẫn có thể lạc lối trong 30 giây và bỏ cuộc. WCAG là điều kiện cần, không phải điều kiện đủ.
Real User Testing với disabled users — kiểm thử với chính người dùng khuyết tật thật — là cách duy nhất để bạn biết sản phẩm của mình có thực sự dùng được hay không, thay vì chỉ "đúng về mặt kỹ thuật". Đây là bước chuyển từ compliance mindset (tuân thủ để không bị kiện) sang empathy mindset (thấu hiểu để phục vụ). Và đó cũng là kỹ năng phân biệt một chuyên gia accessibility thực thụ với một người chỉ biết chạy tool.
Khái niệm cốt lõi
Real User Testing là gì và khác gì so với những gì đã học?
Real User Testing với disabled users là quá trình bạn tuyển, mời và trả công cho những người khuyết tật thật để họ thực hiện các tác vụ trên sản phẩm của bạn, trong khi bạn quan sát và ghi nhận. Nó khác biệt căn bản so với ba loại kiểm thử bạn đã học:
- Automated testing (Bài 37): tìm được khoảng 30–40% lỗi kỹ thuật, nhưng không hiểu trải nghiệm.
- Manual testing bởi chính bạn (Bài 38, 39): bạn giả lập việc dùng keyboard hoặc screen reader, nhưng bạn không phải người khuyết tật — bạn vẫn nhìn thấy màn hình, vẫn biết trước sản phẩm hoạt động thế nào.
- Real user testing: người dùng thật, với thói quen thật, trợ lý công nghệ (assistive technology) mà họ đã dùng hàng chục năm, và cách xử lý vấn đề mà bạn không bao giờ đoán được.
Vì sao phải trả tiền để thuê người khuyết tật test?
Đây là ba lý do cốt lõi — cũng chính là ý định gốc của bài:
1. Đây là cách xác thực (validation) chính xác nhất về accessibility. Không có phép đo nào đáng tin bằng việc người dùng thật hoàn thành được tác vụ. Nếu 4/5 người mù không thể tự đặt hàng trên website của bạn, thì mọi điểm số Lighthouse 100/100 đều vô nghĩa.
2. Bắt được những lỗi mà công cụ tự động bỏ sót. Tool có thể xác nhận một <label> tồn tại, nhưng không biết được label đó khó hiểu. Tool thấy alt="image" là "có alt text" nhưng không biết nó vô dụng. Tool không phát hiện được rằng thứ tự đọc của screen reader khiến người dùng tưởng nút "Xóa" là nút "Lưu".
3. Phát hiện những vấn đề bất ngờ (surface unexpected issues). Đây là phần giá trị nhất. Người khuyết tật thường có "cách làm việc vòng" (workaround) và cả những kỳ vọng riêng mà bạn không thể lường trước. Ví dụ: một người dùng chuyển động hạn chế có thể dùng công tắc (switch device) và cần mỗi thao tác không quá 2 lần nhấn; một người có chứng khó đọc (dyslexia) có thể cần đọc to bằng text-to-speech ngay cả khi họ nhìn được.
Ai là "disabled users" bạn nên tuyển?
Đừng gộp tất cả vào một nhóm. Ít nhất hãy phủ các nhóm chính (nhắc lại từ Bài 5):
- Người khiếm thị hoàn toàn (dùng screen reader)
- Người nhìn kém / low vision (dùng phóng đại màn hình, high contrast)
- Người mù màu
- Người khuyết tật vận động (keyboard-only, switch, voice control)
- Người khiếm thính (cần captions, transcripts)
- Người khuyết tật nhận thức / cognitive (khó đọc, khó tập trung, khó ghi nhớ)
Nguyên tắc đạo đức: "Nothing about us without us"
Đây là khẩu hiệu của cộng đồng người khuyết tật toàn cầu: "Không có gì về chúng tôi mà không có chúng tôi." Nghĩa là đừng thiết kế cho người khuyết tật rồi tự phán đoán họ cần gì — hãy đưa họ vào quy trình. Và luôn nhớ: trả công xứng đáng. Thời gian và chuyên môn của họ có giá trị. Test miễn phí "vì lòng tốt" là một dạng bóc lột. Ở Việt Nam, mức thù lao hợp lý thường là 300.000–800.000đ cho một phiên 60 phút, tùy độ chuyên sâu.
Tình huống thực tế
Tình huống 1: Sàn thương mại điện tử Việt và bài toán "giỏ hàng vô hình"
Một sàn TMĐT lớn tại Việt Nam (giả định gọi là "ShopViet") đã đầu tư nghiêm túc: đội frontend chạy axe-core trong CI, đạt 96% pass rate, Lighthouse accessibility 98/100. Ban lãnh đạo tin rằng sản phẩm đã "accessible".
Họ quyết định thử một buổi real user testing với 5 người khiếm thị, thù lao 500.000đ/người, mỗi phiên 45 phút. Tác vụ đơn giản: "Tìm một chai dầu gội, thêm vào giỏ, và thanh toán."
Kết quả gây sốc: 4/5 người không thể hoàn thành. Vấn đề nằm ở chỗ mà không tool nào bắt được. Khi họ bấm "Thêm vào giỏ", một toast notification hiện ra ở góc màn hình trong 3 giây rồi biến mất — nhưng nó không được screen reader thông báo (thiếu aria-live). Người dùng bấm nút, không nghe thấy gì, tưởng là hỏng, bấm lại 5–6 lần, và cuối cùng giỏ hàng có tới 6 chai dầu gội mà họ không hề biết. Một người dùng đã thốt lên: "Tôi không biết mình đã bỏ vào giỏ chưa, cái web này im lặng như tờ."
Bài học rút ra: Automated tool xác nhận nút có aria-label đúng, nhưng không thể biết phản hồi sau khi bấm có đến được tai người dùng hay không. Chỉ real user testing mới lộ ra "giỏ hàng vô hình". Sau khi thêm aria-live="polite" cho khu vực thông báo, tỷ lệ hoàn thành tăng lên 5/5 ở lần test tiếp theo.
Tình huống 2: Ứng dụng ngân hàng số và người dùng switch control
Một ngân hàng số ở Đông Nam Á (giả định "NeoBank SG") tự tin về app của mình. Họ mời một người đàn ông 34 tuổi bị bại liệt tứ chi do tai nạn, sử dụng switch control — thiết bị chỉ có 2 công tắc để điều khiển toàn bộ điện thoại bằng cách quét (scanning) qua từng phần tử.
Nhóm sản phẩm đã sốc khi thấy anh mất hơn 4 phút chỉ để đăng nhập. Vì sao? Màn hình đăng nhập có 14 phần tử có thể focus (bao gồm cả các icon trang trí vô nghĩa mà lập trình viên vô tình để tabindex="0"). Switch control quét lần lượt qua từng phần tử một, mỗi phần tử dừng 2 giây. Anh phải chờ hệ thống quét qua 9 phần tử vô dụng trước khi đến được ô nhập mật khẩu.
Anh nói một câu mà cả nhóm ghi nhớ mãi: "Với mấy bạn, một nút thừa chỉ là một cú click phí. Với tôi, nó là 2 giây cuộc đời, nhân với mỗi lần mở app, mỗi ngày."
Bài học rút ra: Vấn đề "quá nhiều điểm focus" không hề vi phạm WCAG một cách rõ ràng — mọi phần tử đều có contrast tốt, đều "accessible" về mặt kỹ thuật. Nhưng trải nghiệm thực tế thì thảm họa. Nhóm đã loại bỏ tabindex khỏi các phần tử trang trí, gom nhóm focus, và giảm thời gian đăng nhập của anh xuống còn 50 giây. Đây chính là loại "unexpected issue" mà bài học nhấn mạnh.
Tình huống 3: Microsoft và mô hình tuyển dụng người khuyết tật vào chính đội test
Ở quy mô lớn hơn, Microsoft là ví dụ kinh điển. Họ không chỉ thuê người khuyết tật test theo phiên, mà xây dựng cả một chương trình tuyển dụng nhân sự khuyết tật vào đội ngũ (Disability Answer Desk, Inclusive Tech Lab). Khi phát triển bộ điều khiển Xbox Adaptive Controller, họ làm việc trực tiếp với các game thủ khuyết tật vận động trong suốt quá trình thiết kế, không chỉ ở khâu test cuối.
Kết quả: sản phẩm không chỉ "vượt qua kiểm tra" mà thực sự thay đổi cuộc sống người dùng — và trở thành case study accessibility được ca ngợi toàn cầu.
Bài học rút ra: Real user testing đạt hiệu quả cao nhất khi diễn ra sớm và liên tục, không phải là một buổi "kiểm tra cho có" trước khi launch. Đưa người khuyết tật vào từ giai đoạn thiết kế sẽ rẻ hơn nhiều so với sửa lỗi sau khi đã code xong.
Hướng dẫn từng bước
Đây là quy trình 7 bước để bạn tự tổ chức một buổi real user testing, kể cả với ngân sách nhỏ:
Bước 1 — Xác định mục tiêu và tác vụ (task). Đừng test "cả website". Chọn 3–5 luồng quan trọng nhất (đăng ký, thanh toán, tìm kiếm...). Viết task dưới dạng mục tiêu, không phải hướng dẫn: nói "Hãy đặt một chiếc bánh sinh nhật giao vào ngày mai", KHÔNG nói "Bấm nút màu xanh ở góc phải".
Bước 2 — Tuyển người tham gia. Ở Việt Nam, bạn có thể liên hệ qua Hội Người mù Việt Nam, các trung tâm như Nghị lực sống, các cộng đồng Facebook của người khuyết tật, hoặc nền tảng quốc tế như Fable, AccessWorks (nếu ngân sách cho phép). Tuyển đúng nhóm khuyết tật khớp với sản phẩm. Mục tiêu 2–3 người mỗi profile.
Bước 3 — Chuẩn bị hậu cần và thù lao. Chốt thù lao rõ ràng từ đầu. Hỏi trước họ dùng assistive tech nào (NVDA? JAWS? VoiceOver? switch?) để bạn không bị bỡ ngỡ. Nếu test online, đảm bảo công cụ họp (Zoom, Google Meet) cho phép họ share màn hình kèm âm thanh screen reader.
Bước 4 — Thiết lập môi trường quan sát. Lý tưởng là có một người điều phối (moderator) và một người ghi chú (note-taker). Xin phép ghi màn hình và ghi âm. Với screen reader user, bạn cần nghe được giọng đọc của họ để hiểu điều gì đang diễn ra.
Bước 5 — Chạy phiên test theo phương pháp think-aloud. Yêu cầu người dùng "nói ra suy nghĩ" trong lúc thao tác. Quy tắc vàng của người điều phối: im lặng và quan sát. Đừng gợi ý, đừng "cứu" họ ngay khi họ bối rối — chính khoảnh khắc bối rối đó là dữ liệu quý nhất. Chỉ can thiệp khi họ hoàn toàn kẹt sau 2–3 phút.
Bước 6 — Ghi nhận và phân loại lỗi. Sau mỗi phiên, ghi lại: (a) task nào hoàn thành/thất bại, (b) mất bao lâu, (c) điểm bối rối cụ thể, (d) trích dẫn nguyên văn của người dùng. Phân loại theo mức độ nghiêm trọng: blocker (không thể tiếp tục), major (khó khăn lớn), minor (bực mình nhẹ).
Bước 7 — Tổng hợp và hành động. Đối chiếu các lỗi lặp lại ở nhiều người — đó là ưu tiên số một. Chuyển thành ticket cụ thể, gán cho dev, và lý tưởng nhất là mời chính người dùng đó test lại sau khi fix để đóng vòng lặp.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi real user testing thay thế cho automated/manual testing. Sai. Chúng bổ sung cho nhau. Hãy dùng tool để dọn sạch 40% lỗi kỹ thuật trước, rồi mới mời người dùng — đừng lãng phí thời gian quý giá của họ vào những lỗi mà axe-core đã có thể bắt.
Lỗi 2 — Người điều phối nói quá nhiều. Bản năng của chúng ta là muốn "giúp đỡ" khi thấy người khuyết tật loay hoay. Nhưng mỗi lần bạn nhảy vào, bạn giết chết một phát hiện. Hãy cắn răng im lặng.
Lỗi 3 — Chỉ test 1 người rồi kết luận. Một người không đại diện cho cả cộng đồng. Nếu chỉ 1 người mù test và họ dùng JAWS thành thạo, bạn sẽ bỏ lỡ trải nghiệm của người mới dùng NVDA. Tối thiểu 2–3 người/profile.
Lỗi 4 — Đối xử với người tham gia như "vật thí nghiệm". Đây là con người, là chuyên gia về chính khuyết tật của họ. Hỏi tên, tôn trọng thời gian, đừng dùng ngôn ngữ thương hại ("tội nghiệp", "khổ thân"). Ngôn ngữ chuyên nghiệp: "người dùng khiếm thị", không phải "người mù tội nghiệp".
Lỗi 5 — Test xong để đó. Nếu không chuyển phát hiện thành fix và re-test, cả buổi chỉ là diễn kịch. Tệ hơn, nó lãng phí thời gian của người tham gia.
Mẹo hay:
- Luôn có một task khởi động dễ để người dùng làm quen công cụ họp trước khi vào task chính.
- Chuẩn bị sẵn plan B nếu công nghệ trục trặc (screen reader không share được âm thanh là chuyện thường gặp).
- Ghi lại tốc độ đọc screen reader của người dùng — nó cho bạn cảm nhận về độ thành thạo của họ.
- Nếu ngân sách cực hạn hẹp, một buổi test với chỉ 3 người vẫn phát hiện được ~80% vấn đề nghiêm trọng nhất (theo nghiên cứu của Nielsen Norman Group về usability testing).
Bài tập thực hành
Bài 1 — Viết kịch bản test (task script). Chọn một website bạn quen thuộc (ví dụ trang bán vé xem phim). Viết 3 task theo dạng mục tiêu, không tiết lộ bước bấm. Với mỗi task, xác định "tiêu chí thành công" rõ ràng (ví dụ: "người dùng nhận được xác nhận đặt vé mà không cần trợ giúp").
Bài 2 — Tự đóng vai (mini test). Nhờ một người bạn không phải dân IT thử dùng sản phẩm của bạn chỉ bằng bàn phím (không chuột) trong khi bạn im lặng quan sát và ghi chú. Đây là bản tập dượt cho việc điều phối — luyện kỹ năng "im lặng và ghi nhận".
Bài 3 — Lập kế hoạch tuyển dụng. Với sản phẩm của bạn, xác định 3 nhóm khuyết tật ưu tiên nhất cần test. Viết ra: bạn sẽ tìm họ ở đâu (kênh cụ thể tại Việt Nam), thù lao dự kiến, và assistive tech bạn cần chuẩn bị hỏi trước.
Bài 4 — Phân tích tình huống. Đọc lại Tình huống 2 (switch control). Hãy liệt kê 3 vấn đề accessibility "ẩn" khác mà automated tool có thể bỏ sót nhưng real user testing sẽ phát hiện được. Gợi ý: nghĩ về thời gian, số thao tác, và độ mệt mỏi.
Tóm tắt
Real user testing với disabled users là đỉnh cao của quy trình accessibility — nơi mọi kiến thức kỹ thuật bạn tích lũy được kiểm chứng bởi thực tế phũ phàng nhưng chân thật nhất. Ba lý do cốt lõi để làm điều này: nó là cách xác thực chính xác nhất, nó bắt được lỗi mà tool bỏ sót, và nó phơi bày những vấn đề bất ngờ mà không ai lường trước.
Hãy khắc ghi: WCAG compliance là điều kiện cần, nhưng chỉ có con người thật mới xác nhận được điều kiện đủ. Automated tool bắt ~40% lỗi kỹ thuật; manual testing của bạn thêm một lớp nữa; nhưng chỉ khi một người khiếm thị, một người dùng switch, một người khiếm thính thật sự hoàn thành được tác vụ, bạn mới có quyền nói sản phẩm của mình "accessible".
Nguyên tắc sống còn: "Nothing about us without us" — đưa người khuyết tật vào quy trình sớm, liên tục, và trả công xứng đáng. Tổ chức test có phương pháp: chọn task đúng, tuyển đủ 2–3 người mỗi profile, im lặng quan sát, phân loại lỗi, và đóng vòng lặp bằng cách fix rồi re-test.
Ở bài tiếp theo, chúng ta sẽ bàn về con đường sự nghiệp và chuyên môn hóa trong lĩnh vực accessibility — nơi kỹ năng làm việc với người dùng thật mà bạn vừa học sẽ trở thành lợi thế cạnh tranh lớn nhất của bạn.