Mở đầu — vì sao bài này quan trọng
Hãy thử một thí nghiệm nhỏ: tắt màn hình điện thoại của bạn, rồi cố gắng mở ứng dụng ngân hàng và chuyển khoản chỉ bằng cách lắng nghe trình đọc màn hình đọc lên. Phần lớn các bạn sẽ bỏ cuộc sau ba mươi giây vì không thể biết nút "Xác nhận" nằm ở đâu, hoặc trình đọc chỉ đọc trơ trọi "button, button, button" mà không nói nút đó làm gì. Đó chính xác là trải nghiệm hằng ngày của hàng triệu người dùng khiếm thị khi họ sử dụng sản phẩm mà bạn đang xây.
Accessibility — viết tắt là a11y (số 11 là 11 chữ cái giữa chữ "a" và "y") — là việc thiết kế sản phẩm sao cho mọi người, kể cả người khuyết tật, đều có thể sử dụng được. Đây không phải chủ đề "tốt thì làm" mà là một phần trách nhiệm cốt lõi của PM hiện đại, vì ba lý do rất thực tế.
Thứ nhất, quy mô thị trường lớn hơn bạn nghĩ. Theo WHO, khoảng 15% dân số toàn cầu — hơn 1,3 tỷ người — sống chung với một dạng khuyết tật nào đó. Tại Việt Nam, con số người khuyết tật vào khoảng 7 triệu người (theo Tổng cục Thống kê), chưa kể nhóm "khuyết tật tình huống" như người lớn tuổi mắt kém, người đang bế con nên chỉ thao tác được một tay, hay người dùng ngoài nắng chói không nhìn rõ màn hình. Bỏ qua a11y nghĩa là bạn tự nguyện loại bỏ một phần đáng kể thị trường.
Thứ hai, đây ngày càng là yêu cầu pháp lý. Ở Mỹ có đạo luật ADA (Americans with Disabilities Act) — đã có vô số vụ kiện doanh nghiệp vì website không tiếp cận được. Ở châu Âu, European Accessibility Act có hiệu lực từ tháng 6/2025 buộc nhiều sản phẩm số (ngân hàng, thương mại điện tử, e-book) phải đạt chuẩn tiếp cận. Nếu sản phẩm của bạn phục vụ khách hàng quốc tế, đây không còn là lựa chọn.
Thứ ba, a11y làm UX tốt hơn cho tất cả mọi người — nguyên lý gọi là "curb-cut effect": vỉa hè được hạ thấp cho xe lăn hóa ra lại tiện cho cả người kéo vali, đẩy xe nôi. Phụ đề video làm cho người điếc lại được mọi người xem video không tiếng dùng. Đó là lý do bài học này quan trọng với PM, dù sản phẩm của bạn có "nhắm tới người khuyết tật" hay không.
Khái niệm cốt lõi
Bốn nguyên tắc POUR
Chuẩn quốc tế về tiếp cận web gọi là WCAG (Web Content Accessibility Guidelines), hiện ở phiên bản 2.2. Bạn không cần thuộc lòng hàng trăm tiêu chí, nhưng cần nắm bốn nguyên tắc nền tảng, viết tắt là POUR:
- Perceivable (Cảm nhận được): người dùng phải nhận biết được thông tin. Ví dụ: ảnh phải có văn bản thay thế (alt text) để trình đọc màn hình đọc; video phải có phụ đề; màu chữ và nền phải đủ tương phản.
- Operable (Thao tác được): mọi chức năng phải dùng được, không chỉ bằng chuột mà cả bằng bàn phím. Người không dùng được chuột (do liệt tay, run tay) di chuyển bằng phím Tab. Không được đặt "bẫy" khiến focus mắc kẹt.
- Understandable (Hiểu được): giao diện và nội dung phải dễ hiểu, dễ đoán. Thông báo lỗi phải nói rõ sai ở đâu và sửa thế nào, thay vì chỉ tô đỏ ô nhập.
- Robust (Bền vững): sản phẩm phải hoạt động ổn định với nhiều công nghệ hỗ trợ (assistive technology) khác nhau, nay và mai.
Ba mức tuân thủ: A, AA, AAA
WCAG chia thành ba mức. Mức A là tối thiểu, AA là mức mà đa số luật và doanh nghiệp lấy làm chuẩn mục tiêu, và AAA là mức cao nhất (thường chỉ áp dụng cho nội dung đặc thù). Khi ai đó hỏi "sản phẩm mình cần đạt chuẩn a11y nào?", câu trả lời mặc định an toàn là WCAG 2.1 AA.
Các nhóm khuyết tật và công nghệ hỗ trợ
Để thiết kế đúng, PM cần hình dung bốn nhóm người dùng chính:
- Thị giác: người mù dùng screen reader (VoiceOver trên iOS, TalkBack trên Android, NVDA trên Windows); người kém thị lực phóng to màn hình; người mù màu cần không bị phụ thuộc hoàn toàn vào màu sắc để hiểu thông tin.
- Thính giác: người điếc/khiếm thính cần phụ đề, văn bản thay thế cho âm thanh.
- Vận động: người không dùng được chuột, điều hướng bằng bàn phím hoặc thiết bị chuyển mạch (switch).
- Nhận thức: người mắc chứng khó đọc (dyslexia), rối loạn tăng động giảm chú ý — cần ngôn ngữ đơn giản, bố cục rõ ràng, ít gây xao nhãng.
Vài chỉ số cụ thể PM nên nhớ
- Tỷ lệ tương phản màu: chữ thường cần đạt ít nhất 4.5:1 so với nền (mức AA); chữ lớn cần ít nhất 3:1.
- Kích thước vùng chạm (touch target): tối thiểu khoảng 44x44 pixel để người run tay vẫn bấm trúng.
- Không dùng màu làm phương tiện duy nhất: ví dụ trường nhập sai không chỉ tô đỏ mà phải kèm biểu tượng và dòng chữ giải thích.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Việt Nam và nút "Mua ngay" vô hình
Một sàn TMĐT lớn tại Việt Nam (gọi là sàn X) nhận được phản ánh từ cộng đồng người khiếm thị rằng họ không thể tự đặt hàng. Khi đội ngũ PM ngồi xuống dùng thử với VoiceOver bật lên, họ phát hiện nút "Mua ngay" được lập trình bằng một thẻ <div> có gắn sự kiện bấm, thay vì dùng thẻ <button> chuẩn. Hệ quả: trình đọc màn hình hoàn toàn bỏ qua nó — với người khiếm thị, nút quan trọng nhất của cả luồng mua hàng không tồn tại.
Diễn giải: đây là lỗi cực kỳ phổ biến. Lập trình viên dùng <div> để dễ tạo kiểu (styling), nhưng <div> không mang ngữ nghĩa "đây là nút bấm" cho công nghệ hỗ trợ. Sửa lại bằng cách dùng thẻ <button> đúng chuẩn (hoặc thêm thuộc tính role="button" và hỗ trợ bàn phím) chỉ tốn vài giờ kỹ thuật, nhưng mở khóa toàn bộ luồng chuyển đổi cho nhóm người dùng này.
Bài học rút ra: a11y phần lớn không phải là "thêm tính năng đắt đỏ" mà là dùng đúng thành phần HTML có sẵn ngữ nghĩa. PM cần đưa tiêu chí này vào "định nghĩa hoàn thành" (Definition of Done), nếu không lỗi sẽ tích lũy thầm lặng.
Ví dụ 2 — Ứng dụng ngân hàng số và bài kiểm thử bằng bàn phím
Một ngân hàng số tại Đông Nam Á chuẩn bị ra mắt phiên bản web cho khách hàng doanh nghiệp lớn tuổi. Trong buổi review, PM yêu cầu cả đội cất chuột đi và chỉ dùng phím Tab để hoàn thành một giao dịch chuyển khoản. Kết quả: khi mở hộp thoại (modal) xác nhận OTP, focus bàn phím vẫn "thoát" ra phía sau modal, người dùng vô tình điều hướng tới các nút ẩn dưới nền — một lỗi gọi là thiếu focus trap. Tệ hơn, sau khi đóng modal, focus không quay về vị trí cũ, khiến người dùng "lạc".
Diễn giải: với người dùng bàn phím và người khiếm thị, focus management (quản lý vị trí con trỏ điều hướng) là xương sống của trải nghiệm. Một modal đúng chuẩn phải: giữ focus bên trong khi mở, cho đóng bằng phím Esc, và trả focus về nút đã kích hoạt nó khi đóng.
Bài học rút ra: nhiều lỗi a11y chỉ lộ ra khi bạn trải nghiệm như người dùng thật — bỏ chuột, bật trình đọc màn hình. PM nên biến việc này thành nghi thức kiểm thử định kỳ, không đợi đến khi có khiếu nại.
Ví dụ 3 — Phụ đề video và "curb-cut effect" tại một nền tảng học trực tuyến
Một nền tảng học trực tuyến (giả định tương tự bối cảnh khóa học này) ban đầu thêm phụ đề cho video bài giảng chỉ để phục vụ học viên khiếm thính, vốn được ước tính chỉ chiếm khoảng 2% người dùng. Nhưng sau ba tháng, dữ liệu cho thấy hơn 40% lượt xem có bật phụ đề — phần lớn là học viên xem bài trên xe buýt, trong văn phòng yên tĩnh không tiện mở loa, hoặc người học nghe tiếng Anh muốn đọc kèm để hiểu rõ hơn. Thời lượng xem trung bình tăng đáng kể.
Diễn giải: đây là minh chứng sống động cho hiệu ứng "curb-cut" — tính năng làm cho nhóm thiểu số lại mang lợi ích cho đa số. Đầu tư a11y thường có ROI vượt xa nhóm đối tượng ban đầu.
Bài học rút ra: khi thuyết phục lãnh đạo đầu tư a11y, đừng chỉ nói về "đạo đức" hay "tuân thủ" — hãy chỉ ra lợi ích mở rộng cho toàn bộ tệp người dùng và gắn với chỉ số kinh doanh.
Hướng dẫn từng bước
Đây là quy trình để PM đưa a11y vào sản phẩm một cách có hệ thống:
Bước 1 — Đặt mục tiêu tuân thủ rõ ràng. Quyết định mức chuẩn (thường là WCAG 2.1 AA) và ghi vào tài liệu chuẩn của đội. Không có mục tiêu chung thì mỗi người làm một kiểu.
Bước 2 — Đưa a11y vào Definition of Done. Mỗi user story khi hoàn thành phải qua được checklist tối thiểu: dùng được bằng bàn phím, có alt text cho ảnh có ý nghĩa, tương phản màu đạt chuẩn, nhãn (label) rõ ràng cho mọi trường nhập. Nếu không "qua" thì story chưa xong.
Bước 3 — Trang bị công cụ kiểm tra tự động. Cài các công cụ như axe DevTools, Lighthouse (có sẵn trong Chrome), hoặc WAVE. Chúng bắt được khoảng 30–50% lỗi a11y một cách tự động — không đủ nhưng là lớp lưới đầu tiên rất rẻ.
Bước 4 — Kiểm thử thủ công. Phần còn lại cần con người: thử điều hướng toàn bộ luồng quan trọng chỉ bằng bàn phím; bật VoiceOver/TalkBack/NVDA và lắng nghe; kiểm tra với chế độ phóng to 200%.
Bước 5 — Kiểm thử với người dùng thật. Nếu có điều kiện, mời chính người khuyết tật dùng thử. Một buổi với người dùng screen reader thật sẽ phát hiện những vấn đề mà không công cụ nào bắt được.
Bước 6 — Theo dõi và bảo trì. A11y dễ bị "thoái hóa" khi tính năng mới được thêm vào. Đặt nó thành mục kiểm tra định kỳ và đưa vào quy trình review thiết kế/code.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi a11y là "việc làm sau cùng". Khi để đến cuối dự án mới sửa, chi phí gấp nhiều lần và thường bị cắt khi sát hạn. Mẹo: tích hợp ngay từ khâu thiết kế — yêu cầu designer kiểm tra tương phản màu và ghi chú thứ tự focus ngay trong file Figma.
Lỗi 2 — Phụ thuộc hoàn toàn vào công cụ tự động. Lighthouse báo "100 điểm" không có nghĩa sản phẩm dễ tiếp cận; nó chỉ kiểm được phần máy đo được. Mẹo: luôn kết hợp kiểm thử thủ công bằng bàn phím và screen reader.
Lỗi 3 — Alt text vô nghĩa. Viết alt text kiểu "image123.jpg" hoặc mô tả thừa "hình ảnh của...". Mẹo: alt text nên truyền tải ý nghĩa của ảnh trong ngữ cảnh; ảnh trang trí thuần túy thì để alt rỗng để trình đọc bỏ qua.
Lỗi 4 — Dùng màu làm tín hiệu duy nhất. Ví dụ biểu đồ chỉ phân biệt bằng màu, người mù màu không đọc được. Mẹo: luôn kèm nhãn, hoa văn hoặc biểu tượng bổ sung.
Lỗi 5 — Quên nhãn cho trường nhập. Placeholder không thay thế được label; khi người dùng gõ vào, placeholder biến mất và họ mất ngữ cảnh. Mẹo: mọi input phải có <label> gắn đúng.
Mẹo vàng cho PM: đừng cố trở thành chuyên gia kỹ thuật a11y. Vai trò của bạn là đặt ưu tiên, đưa vào quy trình, và bảo vệ ngân sách cho việc này — phần thực thi chi tiết để designer và engineer làm.
Bài tập thực hành
- Tự kiểm tra một luồng quan trọng: chọn một luồng cốt lõi trong sản phẩm bạn đang làm (hoặc một app bạn hay dùng). Cất chuột đi, chỉ dùng phím Tab và Enter để hoàn thành luồng đó. Ghi lại mọi điểm bạn bị "kẹt" hoặc không biết mình đang focus ở đâu.
- Bật screen reader 10 phút: bật VoiceOver (iPhone) hoặc TalkBack (Android) và thử mở một app quen thuộc. Liệt kê ba chỗ khiến trải nghiệm khó hiểu hoặc không đọc được nội dung.
- Chạy audit tự động: mở một trang web bất kỳ, dùng tab Lighthouse trong Chrome DevTools chạy mục "Accessibility". Đọc báo cáo và phân loại các lỗi theo bốn nguyên tắc POUR.
- Viết một mẩu thuyết phục: soạn một đoạn ngắn (150 từ) trình bày với "sếp giả định" lý do nên đầu tư a11y cho quý tới, kết hợp cả lý do thị trường, pháp lý và lợi ích UX mở rộng.
Tóm tắt
Accessibility (a11y) là việc thiết kế sản phẩm để mọi người, kể cả người khuyết tật, đều dùng được — và đó là trách nhiệm cốt lõi của PM, không phải tùy chọn. Lý do gồm quy mô thị trường lớn (15% dân số toàn cầu, ~7 triệu người tại Việt Nam), yêu cầu pháp lý đang siết chặt (ADA, European Accessibility Act), và lợi ích UX lan tỏa cho mọi người qua hiệu ứng "curb-cut".
Khung tư duy nền tảng là POUR (Perceivable, Operable, Understandable, Robust) theo chuẩn WCAG 2.1 AA. PM cần nhớ vài chỉ số cụ thể: tương phản màu 4.5:1, vùng chạm 44x44px, không dùng màu làm tín hiệu duy nhất, và mọi chức năng phải dùng được bằng bàn phím.
Về thực thi: đặt mục tiêu tuân thủ rõ ràng, đưa a11y vào Definition of Done, kết hợp công cụ tự động (axe, Lighthouse) với kiểm thử thủ công bằng bàn phím và screen reader, và lý tưởng nhất là kiểm thử với chính người dùng khuyết tật. Vai trò của PM không phải là chuyên gia kỹ thuật, mà là người đặt ưu tiên, đưa vào quy trình và bảo vệ ngân sách để a11y không bị bỏ rơi vào phút chót.