Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều team sản phẩm ở Việt Nam vẫn hay ngộ nhận: chỉ cần "pass" được bộ kiểm tra WCAG, gắn được cái badge "AA compliant" lên báo cáo là coi như đã làm xong accessibility. Nhưng nếu bạn từng ngồi cạnh một người khiếm thị dùng screen reader để đặt vé máy bay, hay quan sát một người lớn tuổi run tay cố gắng bấm nút "Xác nhận" bé xíu trên app ngân hàng, bạn sẽ hiểu ngay rằng "tuân thủ" (compliance) và "thực sự dùng được" (usable) là hai chuyện hoàn toàn khác nhau.
Trong toàn khóa học này, chúng ta đã có Bài 30 nói về Accessibility Metrics: WCAG Compliance — tức là cách đo lường, cách chấm điểm, cách chạy audit tự động để biết trang có bao nhiêu lỗi kỹ thuật. Bài 55 hôm nay cố tình đứng ở một chỗ khác. Chúng ta sẽ không quay lại bàn về contrast ratio 4.5:1 hay alt text nữa. Thay vào đó, chúng ta bàn về tư duy (mindset) accessibility — cách bạn nhìn nhận sự đa dạng của con người, cách thiết kế cho sự bao hàm (inclusion) chứ không chỉ để né kiện tụng hay qua được checklist.
Đây là bài học về sự trưởng thành nghề nghiệp. Một designer giỏi kỹ thuật có thể fix hết lỗi màu sắc, nhưng một designer trưởng thành mới hiểu rằng accessibility không phải là "thêm việc cho người khuyết tật", mà là làm sản phẩm tốt hơn cho tất cả mọi người. Khi bạn nắm được tư duy này, bạn sẽ ra quyết định thiết kế khác hẳn — ngay cả khi không có ai bắt bạn phải làm.
Khái niệm cốt lõi
Compliance chỉ là sàn, không phải trần
Hãy hình dung WCAG như luật giao thông. Việc bạn không vượt đèn đỏ không có nghĩa là bạn lái xe giỏi hay an toàn — nó chỉ có nghĩa là bạn không phạm luật. Tương tự, một website pass hết tiêu chí WCAG AA vẫn có thể là một trải nghiệm tồi tệ với người khuyết tật.
Ví dụ kinh điển: một cái nút có alt text đúng ("Nút Thanh toán"), contrast đủ, focus state rõ ràng — nghĩa là pass mọi tiêu chí kỹ thuật. Nhưng nếu để đến được nút đó, người dùng screen reader phải nghe đọc qua 47 link menu, 12 banner quảng cáo và 3 popup, thì về mặt "trải nghiệm" họ đã bỏ cuộc từ lâu. Checklist xanh không đồng nghĩa với người dùng thành công.
Vì vậy, tư duy đúng là: coi WCAG là mức sàn tối thiểu (baseline), và mục tiêu thật sự là inclusive design — thiết kế bao hàm, nơi trải nghiệm mượt mà cho càng nhiều người càng tốt.
Phổ đa dạng của con người (spectrum of disability)
Điều làm thay đổi tư duy mạnh nhất là hiểu rằng "khuyết tật" không phải một nhóm nhỏ tách biệt. Microsoft trong bộ Inclusive Design Toolkit đã đưa ra một khung rất hay: mỗi dạng suy giảm khả năng đều có ba trạng thái:
- Vĩnh viễn (permanent): người mất một tay.
- Tạm thời (temporary): người bị gãy tay, bó bột vài tuần.
- Tình huống (situational): một bà mẹ đang bế con nên chỉ còn một tay để thao tác điện thoại.
Chúng ta hãy điểm qua các nhóm chính, kèm theo hệ quả thiết kế:
Thị giác (visual):
- Người mù (blind) — dùng screen reader như NVDA, VoiceOver, TalkBack.
- Người nhìn kém (low vision) — phóng to màn hình, cần contrast cao.
- Người mù màu (color blindness) — khoảng 8% nam giới; không được dùng chỉ màu sắc để truyền tải thông tin (ví dụ ô sai chỉ tô đỏ mà không có icon hay chữ).
- Tình huống: dùng điện thoại ngoài trời nắng gắt, màn hình lóa.
- Người liệt, run tay (Parkinson), hoặc chỉ dùng bàn phím/công tắc (switch).
- Hệ quả: vùng chạm (touch target) đủ lớn (tối thiểu 44x44px theo Apple, 48x48dp theo Google), không đặt các nút quan trọng sát nhau, không yêu cầu thao tác chính xác kiểu drag-and-drop mà không có phương án thay thế.
- Người điếc hoặc nghe kém — cần phụ đề (caption) cho video, transcript cho audio.
- Tình huống: xem video ở nơi công cộng không tiện bật loa (đây là lý do vì sao caption tự động phổ biến đến vậy).
- Nhóm bị bỏ quên nhiều nhất nhưng lại đông đảo nhất: người mắc ADHD, tự kỷ, khó đọc (dyslexia), suy giảm trí nhớ, hoặc đơn giản là người lớn tuổi và người ít học vấn.
- Hệ quả: ngôn ngữ đơn giản, bố cục nhất quán, giảm gánh nặng ghi nhớ, tránh timeout đột ngột, tránh hiệu ứng chuyển động gây chóng mặt (respecting
prefers-reduced-motion).
Curb-cut effect: làm cho một nhóm, lợi cho tất cả
Có một khái niệm bạn nên khắc cốt ghi tâm: curb-cut effect (hiệu ứng lối lên vỉa hè). Những đoạn vỉa hè được cắt vát để xe lăn lên xuống ban đầu làm cho người khuyết tật. Nhưng cuối cùng ai hưởng lợi? Người kéo vali, người đẩy xe hàng, phụ huynh đẩy xe nôi, người giao hàng shipper. Thiết kế cho ca khó nhất thường nâng chất lượng cho tất cả.
Trong digital, ví dụ rõ nhất là phụ đề video: làm cho người điếc, nhưng bây giờ đại đa số người xem video trên mạng xã hội bật caption vì họ lướt điện thoại ở chỗ đông người. Accessibility tốt = UX tốt cho số đông.
Tình huống thực tế
Tình huống 1: App ngân hàng Việt và người dùng lớn tuổi
Một ngân hàng số tại Việt Nam (giả định là "VBank") tự hào rằng app của họ đã pass audit WCAG 2.1 AA do một đối tác kiểm định. Contrast đạt chuẩn, mọi nút đều có label cho screen reader. Trên giấy tờ, điểm accessibility gần như tuyệt đối.
Nhưng bộ phận chăm sóc khách hàng lại nhận trung bình 1.200 cuộc gọi mỗi tuần từ khách trên 55 tuổi, phần lớn than phiền "không tìm thấy nút chuyển tiền", "app tự thoát khi tôi đang nhập". Khi team UX ngồi quan sát trực tiếp (in-person) 8 người dùng lớn tuổi, họ phát hiện điều mà audit không bao giờ bắt được: phiên đăng nhập (session) hết hạn sau 90 giây không thao tác. Với người trẻ, 90 giây là dư dả. Với một bác 60 tuổi phải đeo kính, dò từng số tài khoản trên tờ giấy rồi gõ lại, 90 giây là không đủ — và mỗi lần văng ra là một lần hoảng loạn.
Diễn giải: Timeout 90 giây không vi phạm WCAG một cách hiển nhiên (thực ra WCAG 2.2.1 có yêu cầu về timing nhưng dễ bị bỏ qua khi audit tự động). Vấn đề nằm ở tư duy: team đã thiết kế cho một người dùng "mặc định" nhanh nhẹn, không hình dung ra người dùng thật đa dạng thế nào.
Bài học: Team nới timeout lên 5 phút kèm cảnh báo "Bạn có muốn tiếp tục?" trước khi hết hạn. Kết quả: cuộc gọi phàn nàn của nhóm khách lớn tuổi giảm khoảng 40% trong hai tháng. Không một dòng nào trong WCAG bắt họ làm điều đó — chính tư duy inclusive mới bắt họ làm.
Tình huống 2: Grab và caption cho tài xế thính lực kém
Một ví dụ có thật ở tầm khu vực Đông Nam Á: các nền tảng gọi xe như Grab có một lượng đáng kể tài xế và khách hàng khiếm thính. Ban đầu, mọi liên lạc tài xế–khách chủ yếu qua gọi điện. Với tài xế điếc, đây là rào cản lớn.
Giải pháp inclusive không phải là "thêm một tính năng đặc biệt cho người điếc", mà là thiết kế lại luồng giao tiếp: đẩy mạnh chat trong app, có mẫu tin nhắn nhanh (canned message) như "Tôi đã đến điểm đón", chia sẻ vị trí trực tiếp trên bản đồ để không cần gọi hỏi đường.
Diễn giải: Khi giao tiếp không phụ thuộc hoàn toàn vào giọng nói, tài xế điếc dùng được. Nhưng đồng thời, tất cả tài xế đều hưởng lợi — vì nhắn tin an toàn hơn gọi điện khi đang lái, và không bị rào cản khi khách nói giọng vùng miền khó nghe. Đây chính là curb-cut effect ngoài đời.
Bài học: Đừng thiết kế "phiên bản dành cho người khuyết tật" tách riêng. Hãy thiết kế luồng chính (main flow) sao cho bản thân nó đã bao hàm. Giải pháp riêng biệt thường bị bỏ bê, còn giải pháp tích hợp thì luôn được nuôi dưỡng vì cả số đông cùng dùng.
Tình huống 3: Trang thương mại điện tử và người mù màu
Một sàn TMĐT giả định "ShopViet" thiết kế trang chọn size/màu áo. Các màu đã hết hàng được làm mờ đi 30% opacity. Về mặt kỹ thuật, contrast của chữ vẫn đủ, audit không báo lỗi.
Nhưng khi phỏng vấn người dùng mù màu (và cả người dùng bình thường trên màn hình điện thoại rẻ tiền ngoài nắng), họ không phân biệt nổi màu nào còn hàng, màu nào hết. Họ chọn màu, bấm mua, rồi báo lỗi — làm tăng tỉ lệ bỏ giỏ hàng (cart abandonment) ở bước này lên rõ rệt.
Diễn giải: Đây là lỗi kinh điển của việc "chỉ dùng thị giác/màu sắc để truyền tải trạng thái". Người mù màu chiếm khoảng 1/12 nam giới — con số không hề nhỏ với một sàn TMĐT hàng triệu người dùng.
Bài học: Thêm dấu hiệu không phụ thuộc màu: gạch chéo lên ô hết hàng, thêm nhãn chữ "Hết hàng", đổi con trỏ chuột. Sau thay đổi, số đơn phải hủy vì "chọn nhầm hàng hết" giảm mạnh. Nguyên tắc vàng: không bao giờ để màu sắc là kênh thông tin duy nhất.
Hướng dẫn từng bước
Đây là quy trình để chuyển đội của bạn từ tư duy "compliance" sang tư duy "inclusion".
Bước 1 — Lập bản đồ người dùng thật (không phải người dùng lý tưởng). Với mỗi luồng quan trọng, hãy tự hỏi: nếu người này mù thì sao? Nếu chỉ dùng được một tay? Nếu đang ở nơi ồn ào không nghe được? Nếu là người lớn tuổi thao tác chậm? Viết ra các "persona rìa" (edge personas) này — đây gọi là inclusive personas.
Bước 2 — Đừng để màu, âm thanh, hay chuyển động là kênh duy nhất. Mọi thông tin quan trọng phải được truyền qua ít nhất hai kênh (ví dụ: màu + icon + chữ). Đây là quy tắc thiết kế dễ áp dụng nhất mà hiệu quả nhất.
Bước 3 — Tự trải nghiệm bằng công nghệ hỗ trợ. Mỗi designer/dev nên tự bật VoiceOver (iOS) hoặc TalkBack (Android), tắt màn hình, và thử hoàn thành một tác vụ. Cảm giác lạc lối trong 30 giây đầu dạy bạn nhiều hơn 10 buổi đọc tài liệu WCAG.
Bước 4 — Kiểm tra với bàn phím. Rút chuột ra, chỉ dùng phím Tab và Enter đi hết luồng. Nếu bạn không đến được nút mua hàng, người dùng khuyết tật vận động cũng không.
Bước 5 — Test với người khuyết tật thật. Đây là bước quyết định, không thể thay thế bằng công cụ tự động. Ở Việt Nam, bạn có thể kết nối qua các hội người mù, các nhóm cộng đồng khiếm thính, hoặc đơn giản là mời chính những người dùng lớn tuổi trong gia đình. Chỉ cần 3–5 người là lộ ra hầu hết vấn đề nghiêm trọng.
Bước 6 — Đưa accessibility vào Definition of Done. Đừng để nó là "giai đoạn cuối" hay "nếu còn thời gian". Biến nó thành tiêu chí bắt buộc trong quy trình review, ngay từ giai đoạn thiết kế.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi accessibility là công đoạn cuối. Nhiều team làm xong hết rồi mới "nhét" accessibility vào lúc gần release. Lúc đó sửa vừa tốn kém vừa hời hợt. Mẹo: đưa vào từ khâu wireframe — chọn thứ tự đọc, phân cấp heading, contrast ngay từ đầu.
Lỗi 2 — Tin tưởng tuyệt đối vào công cụ tự động. Các tool như axe, Lighthouse chỉ bắt được khoảng 30–40% vấn đề accessibility (phần còn lại cần con người đánh giá). Một trang "0 lỗi" trên Lighthouse vẫn có thể hoàn toàn không dùng được bằng screen reader. Mẹo: dùng tool để quét lỗi cơ bản, nhưng luôn kiểm tra thủ công phần trải nghiệm.
Lỗi 3 — Bỏ quên khuyết tật nhận thức. Đây là nhóm đông nhất nhưng ít được nghĩ tới nhất. Mẹo: viết nội dung ở trình độ đọc lớp 8, câu ngắn, tránh thuật ngữ, bố cục nhất quán, một hành động chính rõ ràng trên mỗi màn hình.
Lỗi 4 — Tạo "phiên bản dành cho người khuyết tật" riêng. Trang "accessible version" tách biệt gần như luôn bị bỏ bê, thiếu tính năng, và cập nhật chậm. Mẹo: chỉ có một sản phẩm, và nó bao hàm ngay trong luồng chính.
Lỗi 5 — Lạm dụng ARIA. Nhiều dev nghĩ cứ rắc thật nhiều thuộc tính aria-* là accessible. Thực tế ARIA sai còn tệ hơn không có. Mẹo: ưu tiên HTML ngữ nghĩa (semantic HTML) như <button>, <nav>, <label> trước; ARIA chỉ dùng khi HTML không diễn đạt được.
Mẹo tư duy chốt lại: Mỗi khi bạn định dùng lý do "nhóm này quá nhỏ, không đáng làm", hãy nhớ tới curb-cut effect. Cái bạn làm cho ca khó nhất thường nâng trải nghiệm cho tất cả mọi người.
Bài tập thực hành
- Kiểm tra một tay và một mắt. Chọn một app bạn hay dùng (ví dụ MoMo, Shopee, hoặc VNeID). Thử hoàn thành một tác vụ (chuyển tiền, mua hàng) chỉ bằng một ngón cái, trong lúc đi bộ. Ghi lại 5 điểm khó chịu. Với mỗi điểm, đề xuất một thay đổi thiết kế.
- Thử screen reader. Bật VoiceOver hoặc TalkBack, tắt màn hình, thử đăng nhập vào một website bất kỳ. Ghi lại thời điểm bạn "lạc" và lý do. Đây sẽ là bài học không thể quên.
- Audit "không phụ thuộc màu". Lấy một màn hình sản phẩm của bạn (hoặc một app tùy chọn), chụp màn hình rồi chuyển sang thang xám (grayscale). Liệt kê mọi thông tin bị mất khi không còn màu. Thiết kế lại để mỗi thông tin có ít nhất hai kênh truyền tải.
- Viết inclusive personas. Với một luồng quan trọng trong dự án của bạn, viết 3 persona rìa (một người khiếm thị, một người dùng một tay, một người lớn tuổi thao tác chậm). Với mỗi persona, chỉ ra một chỗ trong luồng hiện tại sẽ khiến họ thất bại.
Tóm tắt
- Compliance là sàn, inclusion là mục tiêu. Pass WCAG chỉ nghĩa là bạn không phạm luật, chưa chắc người dùng đã thành công. Bài 30 lo phần đo lường tuân thủ; bài này lo phần tư duy.
- Khuyết tật là một phổ, không phải một nhóm nhỏ. Mỗi dạng có ba trạng thái: vĩnh viễn, tạm thời, tình huống. Thiết kế cho ca khó nhất là phục vụ hàng triệu người ở trạng thái tạm thời và tình huống.
- Bốn nhóm cần nhớ: thị giác, vận động, thính giác, và nhận thức — trong đó nhận thức là nhóm đông nhất nhưng hay bị quên nhất.
- Curb-cut effect: làm cho một nhóm, cả xã hội cùng hưởng lợi. Phụ đề, thao tác một tay, ngôn ngữ đơn giản — tất cả đều nâng UX cho số đông.
- Ba nguyên tắc thực chiến: không để màu/âm thanh là kênh duy nhất; tự trải nghiệm bằng công nghệ hỗ trợ; test với người khuyết tật thật.
- Ba tình huống VBank, Grab và ShopViet cho thấy cùng một điều: giá trị thật của accessibility nằm ở tư duy bao hàm, không nằm ở checklist xanh.