Mở đầu — vì sao bài này quan trọng
Ở bài trước, chúng ta đã hiểu tại sao accessibility (khả năng tiếp cận) là điều bắt buộc chứ không phải "làm cho có". Nhưng để thiết kế sản phẩm dễ tiếp cận, bạn phải trả lời được một câu hỏi rất cụ thể: chúng ta đang thiết kế cho ai?
Rất nhiều designer và developer khi nghe từ "khuyết tật" (disability) sẽ lập tức nghĩ đến hình ảnh một người ngồi xe lăn. Đây là một hiểu lầm phổ biến và tai hại. Trong thực tế công việc web/app, người dùng khuyết tật mà bạn phục vụ đa dạng hơn rất nhiều: người khiếm thị dùng phần mềm đọc màn hình, người khiếm thính cần phụ đề, người run tay không dùng được chuột, người mắc chứng khó đọc (dyslexia), người bị động kinh nhạy cảm với ánh sáng nhấp nháy... Mỗi nhóm này tương tác với sản phẩm của bạn theo một cách hoàn toàn khác nhau, và dùng những công cụ hỗ trợ (assistive technology) khác nhau.
Bài học này giống như buổi "làm quen với người dùng thật" của bạn. Nếu bạn không hiểu người khiếm thị "nghe" giao diện thế nào, bạn sẽ không hiểu tại sao một nút bấm không có nhãn lại là thảm họa. Nếu bạn không biết công tắc (switch device) hoạt động ra sao, bạn sẽ không hiểu vì sao thứ tự tab lộn xộn khiến người dùng bực bội. Hiểu người dùng và công cụ của họ chính là nền móng để mọi kỹ thuật ở các bài sau (semantic HTML, ARIA, keyboard navigation...) trở nên có ý nghĩa, thay vì chỉ là những quy tắc học thuộc lòng.
Hãy nhớ con số này để giữ động lực: theo WHO, khoảng 16% dân số thế giới — hơn 1,3 tỷ người — đang sống với một dạng khuyết tật đáng kể. Ở Việt Nam, theo Tổng cục Thống kê, có khoảng 6,2 triệu người khuyết tật từ 2 tuổi trở lên. Đây không phải nhóm thiểu số bên lề — họ là một phần rất lớn thị trường của bạn.
Khái niệm cốt lõi
Cách phân loại hữu ích nhất cho người làm sản phẩm số là chia khuyết tật theo giác quan/chức năng bị ảnh hưởng, vì mỗi loại tương ứng với một cách tương tác và một nhóm công cụ hỗ trợ riêng. Chúng ta sẽ đi qua bốn nhóm lớn: thị giác, thính giác, vận động, và nhận thức/thần kinh.
Một khái niệm quan trọng cần nắm ngay: khuyết tật có thể là vĩnh viễn (permanent), tạm thời (temporary) hoặc theo tình huống (situational). Microsoft gọi đây là "khung khuyết tật liên tục" (Persona Spectrum). Ví dụ với nhóm "chỉ dùng được một tay": người cụt tay là vĩnh viễn, người gãy tay bó bột là tạm thời, và một bà mẹ đang bế con là theo tình huống. Cả ba đều cần cùng một giải pháp thiết kế. Điều này chứng minh rằng accessibility phục vụ đông đảo người dùng hơn bạn tưởng rất nhiều.
Nhóm thị giác (Visual)
Đây là nhóm được nhắc đến nhiều nhất trong accessibility web vì web vốn là môi trường thị giác.
- Mù hoàn toàn (Blindness): mất hoàn toàn thị lực. Người dùng không nhìn thấy màn hình mà "nghe" nó qua screen reader (trình đọc màn hình) — phần mềm chuyển văn bản và cấu trúc trang thành giọng nói tổng hợp hoặc chữ nổi Braille. Các screen reader phổ biến: NVDA (miễn phí, mã nguồn mở, chạy trên Windows), JAWS (trả phí, mạnh nhất trong môi trường doanh nghiệp Windows), VoiceOver (tích hợp sẵn trên macOS và iOS), TalkBack (tích hợp trên Android). Người dùng điều hướng chủ yếu bằng bàn phím hoặc cử chỉ vuốt trên màn hình cảm ứng, chứ không dùng chuột.
- Thị lực kém (Low vision): còn nhìn được một phần — có thể mờ, hẹp tầm nhìn, hoặc chỉ thấy được vùng trung tâm/ngoại vi. Công cụ hỗ trợ gồm screen magnifier (phần mềm phóng đại màn hình như ZoomText, hoặc tính năng zoom tích hợp của hệ điều hành), chế độ tương phản cao (high contrast mode), và tăng cỡ chữ. Nhóm này rất nhạy với độ tương phản màu và khả năng phóng to giao diện mà không vỡ layout.
- Mù màu (Color blindness): không phân biệt được một số cặp màu, phổ biến nhất là đỏ–xanh lá. Ảnh hưởng khoảng 8% nam giới và 0,5% nữ giới gốc Bắc Âu. Nhóm này không cần công cụ hỗ trợ đặc biệt, nhưng đòi hỏi bạn không được dùng màu sắc làm phương tiện truyền tin duy nhất (bài 10 sẽ đào sâu).
Nhóm thính giác (Auditory)
- Điếc (Deafness) và nghe kém (Hard of hearing): không nghe được hoặc nghe hạn chế nội dung âm thanh. Với web/app, điều này ảnh hưởng đến video, podcast, cảnh báo bằng âm thanh. Công cụ và giải pháp: phụ đề (captions) cho video, bản chép lời (transcripts) cho audio, và thay thế tín hiệu âm thanh bằng tín hiệu hình ảnh (visual alerts). Nhiều người điếc bẩm sinh xem ngôn ngữ ký hiệu là tiếng mẹ đẻ, nên ngôn ngữ viết trong phụ đề cần rõ ràng, đơn giản.
Nhóm vận động (Motor / Physical)
- Bao gồm liệt, run tay (như bệnh Parkinson), cụt chi, đau khớp, hoặc yếu cơ. Điểm chung: khó hoặc không dùng được chuột, thao tác chính xác kém, dễ mỏi. Công cụ hỗ trợ rất đa dạng: bàn phím (là "vua" trong nhóm này — nhiều người chỉ dùng bàn phím), switch device (công tắc — người dùng chỉ cần nhấn một hoặc hai nút để quét và chọn từng phần tử trên màn hình), eye-tracking (điều khiển bằng mắt), voice control (điều khiển bằng giọng nói như Dragon NaturallySpeaking, Voice Control của Apple). Đây là lý do keyboard navigation và focus indicator (bài 11, 12) quan trọng sống còn.
Nhóm nhận thức & thần kinh (Cognitive / Neurological)
Đây là nhóm lớn nhất nhưng thường bị bỏ quên nhất.
- Khó đọc (Dyslexia), khuyết tật học tập, suy giảm trí nhớ, ADHD, tự kỷ (autism), và khuyết tật trí tuệ. Ngoài ra còn có động kinh nhạy sáng (photosensitive epilepsy) — có thể bị co giật khi thấy nội dung nhấp nháy quá 3 lần/giây. Nhóm nhận thức thường không dùng một "công cụ" cụ thể mà phụ thuộc vào thiết kế: ngôn ngữ đơn giản, bố cục nhất quán, ít gây xao nhãng, không đặt giới hạn thời gian ngặt nghèo, tránh animation gây choáng. Một số người dùng công cụ đọc-to (text-to-speech) hoặc phần mềm hỗ trợ đọc như tô sáng từng dòng.
Tình huống thực tế
Ví dụ 1 — Anh Tuấn, nhân viên tổng đài khiếm thị tại một ngân hàng ở TP.HCM
Anh Tuấn mất thị lực hoàn toàn từ năm 20 tuổi, hiện làm chăm sóc khách hàng. Anh dùng máy tính Windows với NVDA. Mỗi ngày anh phải đăng nhập vào hệ thống nội bộ (CRM) của ngân hàng để tra cứu thông tin khách hàng.
Vấn đề: form đăng nhập của hệ thống dùng ô input không có <label>, chỉ có placeholder mờ. Khi anh Tuấn nhấn Tab tới ô đầu tiên, NVDA đọc "edit, blank" — anh không biết đây là ô tên đăng nhập hay mật khẩu. Nút đăng nhập lại là một thẻ <div> có gắn sự kiện click bằng JavaScript, không phải <button> thật, nên khi Tab tới, focus nhảy qua luôn, không dừng lại được. Anh phải nhờ đồng nghiệp đăng nhập hộ mỗi sáng.
Diễn giải: Screen reader phụ thuộc hoàn toàn vào ngữ nghĩa của HTML. Placeholder không thay thế được label. Một <div> giả làm nút bấm thì không nhận được focus bàn phím và không thông báo vai trò "button" cho NVDA.
Bài học: Khi thiết kế/lập trình, luôn tự hỏi "nếu tắt màn hình đi, người dùng có hoàn thành được tác vụ này không?". Dùng đúng thẻ ngữ nghĩa (<label>, <button>) là cách rẻ nhất và mạnh nhất để hỗ trợ nhóm khiếm thị.
Ví dụ 2 — Chị Lan, giáo viên bị run tay do Parkinson, học online qua nền tảng của một startup EdTech Việt
Chị Lan 58 tuổi, mắc Parkinson giai đoạn sớm nên tay run, khó rê và click chuột chính xác. Chị điều hướng hoàn toàn bằng bàn phím. Startup EdTech nơi chị học có một menu thả xuống (dropdown) chỉ mở ra khi rê chuột (:hover), và các nút "bài tiếp theo" quá nhỏ, sát nhau.
Kết quả: chị không mở được menu chọn khóa học vì không có chuột để hover, và thường bấm nhầm sang bài khác vì các nút quá gần. Đội sản phẩm phát hiện vấn đề qua khảo sát, sau đó thêm khả năng mở menu bằng phím Enter/Space, tăng vùng chạm (touch target) tối thiểu lên 44×44px và giãn khoảng cách. Tỷ lệ hoàn thành bài học của nhóm học viên lớn tuổi tăng thấy rõ trong quý sau.
Diễn giải: Tương tác chỉ-hover loại bỏ hoàn toàn người dùng bàn phím và người dùng cảm ứng. Vùng chạm nhỏ gây khó cho cả người run tay lẫn... bất kỳ ai đang đi xe buýt xóc nảy (khuyết tật theo tình huống!).
Bài học: Mọi tương tác quan trọng phải làm được bằng bàn phím. Kích thước và khoảng cách nút là vấn đề accessibility, không chỉ là thẩm mỹ.
Ví dụ 3 — Grab và phụ đề cho tài xế khiếm thính
Nhiều nền tảng gọi xe ở Đông Nam Á, trong đó có Grab, có chương trình tuyển tài xế là người khiếm thính. Với nhóm này, các thông báo bằng âm thanh (chuông báo có chuyến mới, hướng dẫn giọng nói) hoàn toàn vô dụng. Giải pháp mà các nền tảng áp dụng: thay chuông báo bằng rung mạnh + đèn nhấp nháy màn hình, hiển thị mọi thông tin chuyến đi bằng chữ và bản đồ trực quan, và cho phép khách hàng được báo trước rằng tài xế khiếm thính để giao tiếp qua tin nhắn thay vì gọi điện.
Diễn giải: Đây là ví dụ điển hình của nguyên tắc "đừng dùng một giác quan duy nhất". Thông tin quan trọng (có chuyến mới) được truyền qua nhiều kênh: âm thanh cho người nghe được, rung + hình ảnh cho người khiếm thính.
Bài học: Với mỗi tín hiệu âm thanh trong sản phẩm, hãy luôn có một tương đương bằng hình ảnh hoặc xúc giác. Đây cũng là thiết kế tốt cho người dùng đang ở nơi ồn ào hoặc để im lặng điện thoại.
Hướng dẫn từng bước
Đây là quy trình để bạn "lập bản đồ người dùng khuyết tật" cho một sản phẩm cụ thể, áp dụng được ngay trong dự án của bạn.
- Liệt kê các luồng tác vụ chính (key user flows). Ví dụ với một app học online: đăng nhập → chọn khóa → xem bài giảng video → làm quiz → xem chứng chỉ.
- Với mỗi luồng, chạy qua 4 nhóm khuyết tật và tự hỏi "điểm nghẽn ở đâu?"
- Xác định assistive technology mục tiêu để kiểm thử. Tối thiểu nên chọn: một screen reader (NVDA trên Windows hoặc VoiceOver trên Mac — cả hai đều miễn phí), điều hướng chỉ bằng bàn phím, và trình phóng đại/zoom trình duyệt.
- Trải nghiệm thử như người dùng thật. Rút chuột ra khỏi máy và cố hoàn thành một luồng chỉ bằng bàn phím. Bật VoiceOver (Cmd+F5 trên Mac) và nhắm mắt điều hướng trang chủ. Chỉ 15 phút làm việc này sẽ mở mắt bạn hơn cả chục bài lý thuyết.
- Ghi lại điểm nghẽn thành danh sách vấn đề (issues) gắn với nhóm khuyết tật cụ thể, để ưu tiên xử lý ở các bài kỹ thuật sau.
Lỗi thường gặp & mẹo
- Lỗi: Chỉ nghĩ đến người mù/khiếm thị. Nhóm nhận thức và vận động thường đông hơn nhưng bị bỏ quên. Mẹo: mỗi khi review thiết kế, chạy đủ checklist 4 nhóm ở trên.
- Lỗi: Nghĩ rằng "cứ có screen reader là mọi thứ tự đọc được". Screen reader chỉ đọc được HTML có ngữ nghĩa đúng. Ảnh không alt, nút là
<div>, form không label — công cụ đều bó tay. Mẹo: coi assistive tech là "người đọc phụ thuộc vào bạn khai báo".
- Lỗi: Dùng màu/âm thanh làm kênh truyền tin duy nhất. Ô đỏ báo lỗi mà không có chữ, chuông báo mà không có hình. Mẹo: luôn có ít nhất hai kênh cho thông tin quan trọng (màu + chữ + icon; âm thanh + rung + hình).
- Lỗi: Test bằng chính bạn — một người khỏe mạnh dùng chuột. Bạn không phải người dùng. Mẹo: rút chuột, bật screen reader, phóng to 200% — trải nghiệm sự bất tiện thật.
- Mẹo về ngôn ngữ: Trong tiếng Việt, dùng cách nói "người khuyết tật", "người khiếm thị/khiếm thính" thay vì các từ mang tính miệt thị. Trong tài liệu tiếng Anh, ưu tiên "person with a disability" (people-first) trừ khi cộng đồng cụ thể có preference khác.
- Mẹo về tư duy: Đừng xem accessibility là "làm thêm cho một nhóm nhỏ". Phụ đề giúp cả người xem video ở nơi ồn; contrast tốt giúp cả người dùng ngoài nắng; nút to giúp cả người đang đi tàu xe. Thiết kế cho khuyết tật là thiết kế tốt cho tất cả.
Bài tập thực hành
- Trải nghiệm screen reader (bắt buộc): Bật VoiceOver (Mac: Cmd+F5) hoặc cài NVDA (Windows, miễn phí tại nvaccess.org). Mở một trang bạn hay dùng (ví dụ trang chủ một tờ báo Việt Nam) và cố tìm + đọc một bài viết mà không nhìn màn hình (tắt màn hình hoặc nhắm mắt). Ghi lại 3 điều gây khó khăn nhất.
- Kiểm thử bàn phím: Chọn một website bất kỳ, rút/không dùng chuột. Chỉ dùng Tab, Shift+Tab, Enter, Space và các phím mũi tên để: tìm kiếm một nội dung, mở một menu, và gửi một form. Ghi lại chỗ nào bị "kẹt" không tiếp tục được.
- Lập bản đồ khuyết tật: Chọn một sản phẩm bạn đang làm (hoặc một app bạn hay dùng). Vẽ bảng gồm cột "luồng tác vụ" và bốn cột nhóm khuyết tật (thị giác, thính giác, vận động, nhận thức). Điền vào mỗi ô điểm nghẽn tiềm năng. Đây sẽ là tài liệu tham chiếu cho phần còn lại của khóa học.
- Nghiên cứu nhỏ: Tìm hiểu Persona Spectrum của Microsoft. Với nhóm "một tay", "một mắt", "một tai", hãy viết ra một ví dụ vĩnh viễn, một tạm thời và một theo tình huống cho mỗi nhóm.
Tóm tắt
- Người dùng khuyết tật đa dạng hơn hình ảnh phổ biến rất nhiều, chia thành bốn nhóm chính: thị giác (mù, thị lực kém, mù màu), thính giác (điếc, nghe kém), vận động (khó/không dùng chuột), và nhận thức/thần kinh (dyslexia, ADHD, tự kỷ, động kinh nhạy sáng...).
- Mỗi nhóm dùng assistive technology riêng: screen reader (NVDA, JAWS, VoiceOver, TalkBack), screen magnifier, bàn phím, switch device, eye-tracking, voice control, phụ đề và transcript.
- Khuyết tật có ba dạng — vĩnh viễn, tạm thời, theo tình huống — nên giải pháp accessibility phục vụ lượng người dùng lớn hơn bạn nghĩ.
- Assistive technology chỉ hoạt động tốt khi bạn khai báo đúng (HTML ngữ nghĩa, label, alt text, đúng thẻ button). Công cụ và cách bạn code là một cặp không tách rời.
- Nguyên tắc vàng: đừng bao giờ truyền thông tin quan trọng qua một giác quan/kênh duy nhất, và hãy tự trải nghiệm sản phẩm bằng bàn phím và screen reader để thật sự thấu hiểu.