Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một con số khiến nhiều nhà nghiên cứu UX phải giật mình: theo Tổ chức Y tế Thế giới (WHO), khoảng 16% dân số toàn cầu — tức hơn 1,3 tỷ người — đang sống chung với một dạng khuyết tật đáng kể nào đó. Tại Việt Nam, số liệu của Tổng cục Thống kê ước tính có hơn 6,2 triệu người khuyết tật từ 2 tuổi trở lên, chiếm khoảng 7% dân số. Nhưng con số này chỉ mới đếm những khuyết tật "được ghi nhận chính thức". Nếu tính cả người cao tuổi bị suy giảm thị lực, người bị chấn thương tay tạm thời, người mắc chứng khó đọc (dyslexia) hay rối loạn tăng động giảm chú ý (ADHD), thì tỷ lệ người dùng gặp rào cản tiếp cận thực tế cao hơn nhiều.
Vấn đề nằm ở chỗ: nghiên cứu UX truyền thống gần như bỏ quên nhóm này. Khi bạn tuyển 8 người dùng cho một buổi usability test và tất cả đều là người trẻ, thị lực tốt, dùng chuột thành thạo, bạn đang đo lường trải nghiệm của một "người dùng lý tưởng" không tồn tại. Bạn sẽ không bao giờ phát hiện ra rằng nút "Đặt hàng" của mình vô hình đối với người dùng trình đọc màn hình (screen reader), hay rằng bảng màu thương hiệu khiến 8% nam giới bị mù màu không phân biệt được trạng thái "thành công" và "lỗi".
Accessibility Research — nghiên cứu về khả năng tiếp cận — không phải là một nhánh phụ dễ thương của UX. Nó là một phương pháp nghiên cứu chuyên biệt, đòi hỏi kỹ thuật tuyển người, công cụ, cách quan sát và cách phân tích khác hẳn nghiên cứu thông thường. Bài học này sẽ trang bị cho bạn tư duy và bộ kỹ năng để nghiên cứu cùng người khuyết tật một cách nghiêm túc, tôn trọng và tạo ra kết quả thực sự dùng được.
Khái niệm cốt lõi
Vì sao cần nghiên cứu tiếp cận riêng biệt?
Có ba lý do khiến bạn không thể "gộp chung" accessibility vào nghiên cứu UX bình thường:
Thứ nhất — bản chất rào cản khác nhau. Một người sáng mắt gặp lỗi thiết kế thì thấy "khó chịu"; một người dùng trình đọc màn hình gặp cùng lỗi đó thì hoàn toàn bị chặn đứng, không thể hoàn thành tác vụ. Rào cản tiếp cận thường mang tính "nhị phân" — hoặc dùng được, hoặc không — chứ không phải chỉ là mức độ khó chịu.
Thứ hai — tuân thủ pháp lý và đạo đức. Nhiều thị trường có luật bắt buộc: Mỹ có ADA và Section 508, châu Âu có European Accessibility Act (có hiệu lực từ 2025). Chuẩn kỹ thuật phổ biến nhất là WCAG (Web Content Accessibility Guidelines), hiện ở phiên bản 2.2, với ba cấp độ A, AA, AAA. Nhưng đây là điểm mấu chốt bạn phải nhớ: WCAG là điều kiện cần, không phải điều kiện đủ. Một sản phẩm có thể "pass" toàn bộ checklist WCAG mà vẫn cực kỳ khó dùng với người khuyết tật thật. Đó chính là lý do bạn cần nghiên cứu với con người, không chỉ chạy công cụ kiểm tra tự động.
Thứ ba — sự đa dạng của khuyết tật. Đừng nghĩ "người khuyết tật" là một nhóm đồng nhất.
Bốn nhóm khuyết tật cần hiểu
- Thị giác (Visual): từ mù hoàn toàn (dùng screen reader như NVDA, JAWS, VoiceOver), đến thị lực kém (dùng chức năng phóng to), đến mù màu.
- Vận động (Motor): người không dùng được chuột, chỉ điều hướng bằng bàn phím, bằng thiết bị switch, hoặc bằng giọng nói. Bao gồm cả người run tay, liệt, hay cụt chi.
- Thính giác (Auditory): người điếc hoặc nghe kém — cần phụ đề, transcript cho nội dung âm thanh/video.
- Nhận thức & thần kinh (Cognitive/Neurological): dyslexia, ADHD, tự kỷ, suy giảm trí nhớ. Đây là nhóm lớn nhất và thường bị bỏ quên nhất vì rào cản của họ khó nhìn thấy.
Assistive Technology (công nghệ hỗ trợ)
Bạn không thể nghiên cứu accessibility nếu không hiểu người tham gia dùng gì để tương tác với sản phẩm. Các công nghệ hỗ trợ (AT) phổ biến gồm: trình đọc màn hình (NVDA miễn phí, JAWS trả phí, VoiceOver trên Apple, TalkBack trên Android), phần mềm phóng đại màn hình, bàn phím thay thế, thiết bị switch, phần mềm điều khiển bằng giọng nói (Dragon), và các công cụ hỗ trợ đọc. Nguyên tắc vàng: để người tham gia dùng chính AT của họ, vì họ đã cấu hình quen tay — đừng bắt họ dùng máy và phần mềm của bạn.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số Việt Nam và người dùng mù
Một ngân hàng số tại TP.HCM (tạm gọi là "V-Bank") tự tin app của họ đạt chuẩn WCAG 2.1 AA sau khi thuê một đơn vị audit chạy công cụ tự động. Điểm số kỹ thuật rất đẹp. Nhưng bộ phận CSKH liên tục nhận phản ánh từ Hội Người mù thành phố rằng nhiều hội viên không thể tự chuyển khoản.
Nhóm UX quyết định làm một buổi usability test với 5 người dùng mù thật, dùng chính điện thoại và VoiceOver/TalkBack của họ. Kết quả gây sốc: khi đến bước xác nhận chuyển khoản, app hiển thị một modal đếm ngược 60 giây để nhập OTP. Với người sáng mắt, đồng hồ đếm ngược là bình thường. Nhưng trình đọc màn hình của người mù phải đọc tuần tự từng phần tử, và mỗi giây đồng hồ thay đổi lại khiến screen reader ngắt lời và đọc lại từ đầu — người dùng không bao giờ nghe hết được hướng dẫn nhập OTP trước khi hết giờ. Ngoài ra, nút "Xác nhận" được code bằng thẻ <div> có onclick thay vì <button>, nên VoiceOver không nhận diện được đó là nút bấm.
Bài học: Cả hai lỗi này đều không bị công cụ tự động bắt được vì về mặt kỹ thuật màu sắc, kích thước chữ, alt text đều "đạt". Chỉ có nghiên cứu với con người thật mới lộ ra rào cản. V-Bank sau đó thêm nút "tạm dừng đồng hồ" và sửa lại semantic HTML, tỷ lệ hoàn thành chuyển khoản của nhóm này tăng từ 20% lên 90%.
Ví dụ 2 — Sàn thương mại điện tử và người mù màu
Một sàn TMĐT khu vực Đông Nam Á (giả định "ShopSEA") thiết kế nhãn tồn kho bằng màu: chấm xanh lá = "còn hàng", chấm đỏ = "hết hàng", không kèm chữ. Trong buổi nghiên cứu, họ mời một người tham gia bị mù màu đỏ-lục (deuteranopia — dạng phổ biến nhất, ảnh hưởng ~6% nam giới). Người này nhìn hai chấm y hệt nhau và liên tục thêm vào giỏ những sản phẩm đã hết hàng, rồi bực bội khi đến bước thanh toán mới biết.
Đội ngũ dùng thêm công cụ giả lập mù màu (như Stark hoặc bộ lọc trong Chrome DevTools) để tái hiện, và phát hiện toàn bộ hệ thống trạng thái đơn hàng đều chỉ dựa vào màu. Bài học: Không bao giờ dùng chỉ riêng màu sắc để truyền tải thông tin — đây chính là tiêu chí WCAG 1.4.1 "Use of Color". Giải pháp: thêm biểu tượng (✓ / ✗) và nhãn chữ đi kèm màu. Đây là ví dụ điển hình cho việc kết hợp công cụ giả lập với người dùng thật để vừa phát hiện vừa xác nhận vấn đề.
Ví dụ 3 — Ứng dụng học tập và người dùng dyslexia
Một startup edtech Việt Nam làm app luyện thi. Họ nhận thấy tỷ lệ bỏ ngang bài đọc cao bất thường ở một nhóm học viên. Thay vì đoán, họ tổ chức nghiên cứu định tính với vài học viên tự khai có chứng khó đọc (dyslexia). Qua quan sát và phỏng vấn, họ phát hiện: đoạn văn dài, font chữ nét mảnh, chữ căn đều hai bên (justify) tạo ra "dòng sông trắng" giữa các từ khiến người dyslexia mất dấu dòng. Họ thử cho phép người dùng đổi sang font OpenDyslexic, tăng khoảng cách dòng, và bỏ căn justify. Tỷ lệ hoàn thành bài đọc của nhóm này cải thiện rõ rệt.
Bài học: Khuyết tật nhận thức thường vô hình và bị bỏ qua nhất, nhưng những điều chỉnh phục vụ họ (tùy chỉnh typography, ngôn ngữ đơn giản) lại làm sản phẩm dễ đọc hơn cho tất cả mọi người. Curb-cut effect một lần nữa.
Hướng dẫn từng bước
Dưới đây là quy trình thực hiện một nghiên cứu accessibility bài bản:
Bước 1 — Xác định mục tiêu và phạm vi. Bạn muốn kiểm tra khả năng tiếp cận của toàn sản phẩm hay một luồng cụ thể (ví dụ: luồng thanh toán)? Ưu tiên các luồng quan trọng và các nhóm khuyết tật liên quan nhất đến sản phẩm.
Bước 2 — Chạy kiểm tra kỹ thuật trước (audit). Trước khi mời người thật, hãy dùng công cụ tự động như axe DevTools, WAVE, Lighthouse để bắt các lỗi hiển nhiên (thiếu alt text, tương phản màu kém, thiếu label form). Điều này giúp bạn không lãng phí thời gian quý báu của người tham gia vào những lỗi mà công cụ đã bắt được. Nhớ: công cụ tự động chỉ phát hiện được khoảng 30–40% vấn đề tiếp cận — phần còn lại cần con người.
Bước 3 — Tuyển người tham gia có khuyết tật thật. Đây là bước khó nhất. Đừng dùng người sáng mắt "giả vờ" nhắm mắt dùng screen reader — họ không có kỹ năng vận hành AT như người dùng thật. Nguồn tuyển tại Việt Nam: Hội Người mù Việt Nam, các hội/nhóm người khuyết tật, tổ chức như Nghị lực sống, cộng đồng trên mạng xã hội. Tuyển đa dạng loại khuyết tật và đa dạng mức độ thành thạo AT. Trả thù lao xứng đáng.
Bước 4 — Chuẩn bị môi trường test đúng cách. Để người tham gia dùng chính thiết bị và AT của họ. Nếu test từ xa, đảm bảo công cụ họp trực tuyến của bạn tương thích với screen reader. Chuẩn bị mọi tài liệu (đồng ý tham gia, hướng dẫn) ở định dạng tiếp cận được.
Bước 5 — Điều phối buổi test với sự nhạy cảm. Dùng ngôn ngữ tôn trọng (ưu tiên "person-first" — "người khuyết tật" thay vì "người tàn tật/người mù"). Cho nhiều thời gian hơn bình thường. Đừng vội can thiệp khi họ gặp khó — sự vật lộn đó chính là dữ liệu. Khuyến khích think-aloud nhưng linh hoạt, vì với người dùng screen reader, nói và nghe cùng lúc rất khó.
Bước 6 — Phân tích, phân loại mức độ nghiêm trọng và gắn với WCAG. Với mỗi vấn đề phát hiện, hãy ghi rõ: nó chặn đứng hay chỉ gây khó chịu (blocker vs. annoyance), nhóm khuyết tật nào bị ảnh hưởng, và ánh xạ tới tiêu chí WCAG nào để đội kỹ thuật dễ sửa.
Bước 7 — Báo cáo gắn với con người, không chỉ điểm số. Trình bày kèm video/audio clip người dùng thật gặp rào cản. Không gì thuyết phục ban lãnh đạo hơn cảnh một người mù không thể hoàn thành việc chuyển khoản.
Lỗi thường gặp & mẹo
- Lỗi: coi WCAG checklist là đích đến. Pass WCAG là sàn tối thiểu, không phải trải nghiệm tốt. Luôn kiểm chứng với người thật.
- Lỗi: dùng người không khuyết tật để mô phỏng. Một designer bịt mắt dùng VoiceOver lần đầu sẽ tạo ra dữ liệu sai lệch hoàn toàn — họ chậm chạp vì thiếu kỹ năng, không phải vì lỗi sản phẩm.
- Lỗi: chỉ tập trung vào người mù. Người dùng screen reader chỉ là một nhóm. Đừng quên khuyết tật vận động, thính giác và đặc biệt là nhận thức.
- Lỗi: chỉ chạy công cụ tự động rồi tự tin. Nhớ con số 30–40%. Automated testing bắt lỗi cú pháp, không bắt được lỗi trải nghiệm.
- Mẹo — "Nothing about us without us": nguyên tắc kinh điển của cộng đồng khuyết tật. Đừng thiết kế cho họ mà không có họ. Tốt nhất là mời người khuyết tật tham gia từ giai đoạn đầu, thậm chí có người khuyết tật trong đội ngũ.
- Mẹo — tự học vận hành AT cơ bản: dù không thay thế người dùng thật, việc bạn biết bật VoiceOver/NVDA và điều hướng cơ bản giúp bạn hiểu ngữ cảnh và điều phối buổi test tốt hơn.
- Mẹo — trả thù lao và tôn trọng thời gian: người khuyết tật thường mất nhiều công sức hơn để tham gia (di chuyển, sắp xếp). Đãi ngộ tương xứng là vấn đề đạo đức, không chỉ lịch sự.
Bài tập thực hành
- Tự trải nghiệm AT (30 phút): Bật VoiceOver (iPhone/Mac) hoặc TalkBack (Android) hoặc NVDA (Windows, miễn phí). Tắt màn hình hoặc nhắm mắt, thử hoàn thành một tác vụ trên chính app bạn đang làm hoặc một app phổ biến (ví dụ đặt một món trên app giao đồ ăn). Ghi lại 3 điểm khiến bạn bị chặn đứng.
- Audit tự động (20 phút): Cài extension axe DevTools hoặc dùng Lighthouse trong Chrome, chạy trên trang chủ sản phẩm của bạn. Liệt kê 5 lỗi nghiêm trọng nhất và ánh xạ mỗi lỗi tới tiêu chí WCAG tương ứng.
- Mô phỏng mù màu (15 phút): Dùng bộ lọc mù màu trong Chrome DevTools (Rendering > Emulate vision deficiencies) xem giao diện của bạn qua mắt người deuteranopia. Có thông tin nào chỉ được truyền tải bằng màu không? Đề xuất cách sửa.
- Thiết kế kế hoạch tuyển người: Viết một bản kế hoạch tuyển 5 người tham gia cho nghiên cứu accessibility, nêu rõ: nhóm khuyết tật mục tiêu, nguồn tuyển tại Việt Nam, tiêu chí sàng lọc, mức thù lao, và các điều chỉnh cần chuẩn bị để buổi test tiếp cận được.
Tóm tắt
Nghiên cứu accessibility là một phương pháp chuyên biệt, không phải phần phụ thêm cho nghiên cứu UX thông thường. Với hơn 16% dân số toàn cầu và hàng triệu người Việt Nam sống chung với khuyết tật, việc bỏ quên nhóm này vừa là thất bại đạo đức, vừa là rủi ro pháp lý, vừa là bỏ lỡ thị trường. Điểm cốt lõi cần nhớ: tuân thủ WCAG là sàn tối thiểu, không phải đích đến — công cụ tự động chỉ bắt được 30–40% vấn đề, phần còn lại chỉ lộ ra khi bạn nghiên cứu cùng người khuyết tật thật, dùng chính công nghệ hỗ trợ của họ.
Hãy hiểu bốn nhóm khuyết tật (thị giác, vận động, thính giác, nhận thức) và phân biệt khuyết tật vĩnh viễn — tạm thời — theo tình huống, vì thiết kế tiếp cận tốt tạo ra "curb-cut effect" phục vụ tất cả mọi người. Tuyển người thật, để họ dùng AT của mình, điều phối với sự nhạy cảm, phân loại rào cản theo mức nghiêm trọng và gắn với con người khi báo cáo. Và trên hết, hãy khắc cốt nguyên tắc "Nothing about us without us": không thiết kế cho người khuyết tật mà thiếu tiếng nói của chính họ.