Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa thiết kế xong một trang thanh toán đẹp lộng lẫy: gradient tím mềm mại, chữ xám nhạt thanh thoát trên nền trắng, nút "Đặt hàng" chỉ hiện icon giỏ hàng không kèm chữ. Trên màn hình MacBook của bạn, mọi thứ hoàn hảo. Nhưng với một người dùng lớn tuổi bị giảm thị lực, dòng chữ xám nhạt gần như vô hình. Với một người khiếm thị dùng trình đọc màn hình (screen reader), cái nút chỉ có icon kia được đọc thành "button" — không biết bấm vào sẽ xảy ra chuyện gì. Với một người bị chấn thương tay chỉ dùng được bàn phím, họ không thể "tab" tới ô nhập thẻ tín dụng. Bạn vừa vô tình khóa cửa hàng của mình trước hàng triệu khách.
Accessibility (viết tắt a11y — chữ "a", 11 ký tự ở giữa, rồi chữ "y") là mức độ mà sản phẩm số có thể sử dụng được bởi tất cả mọi người, bao gồm người khuyết tật về thị giác, thính giác, vận động và nhận thức. Ở các bài trước, chúng ta đã đo sự hài lòng (CSAT), nỗ lực (CES), tỷ lệ hoàn thành tác vụ. Nhưng tất cả các chỉ số đó đều giả định người dùng có thể tương tác với sản phẩm ngay từ đầu. Accessibility metrics đo cái nền tảng phía dưới: sản phẩm có mở cửa cho mọi người hay không.
Đây không chỉ là chuyện đạo đức. Theo WHO, khoảng 16% dân số thế giới — hơn 1,3 tỷ người — sống với một dạng khuyết tật đáng kể. Ở Việt Nam, con số người khuyết tật ước tính trên 7 triệu. Về pháp lý, nhiều thị trường xuất khẩu (EU với chỉ thị European Accessibility Act có hiệu lực từ 2025, Mỹ với ADA) bắt buộc a11y, và các doanh nghiệp Việt làm outsourcing hoặc bán sản phẩm ra nước ngoài phải tuân thủ nếu không muốn bị kiện hoặc mất hợp đồng. Bài này cho bạn cách đo accessibility một cách định lượng, dựa trên tiêu chuẩn quốc tế WCAG, để nó không còn là "cảm giác tốt" mơ hồ mà thành con số theo dõi được.
Khái niệm cốt lõi
WCAG là gì
WCAG (Web Content Accessibility Guidelines) là bộ tiêu chuẩn do W3C (tổ chức quản lý chuẩn web toàn cầu) ban hành, hiện là thước đo chuẩn mà cả thế giới dùng để đánh giá accessibility. Bạn sẽ gặp các phiên bản 2.0 (2008), 2.1 (2018, thêm tiêu chí cho mobile và người khiếm thị nhẹ), và 2.2 (2023, thêm về xác thực và mục tiêu chạm). Với hầu hết dự án hiện nay, WCAG 2.1 hoặc 2.2 là mục tiêu thực tế.
Bốn nguyên tắc: POUR
Toàn bộ WCAG xoay quanh bốn nguyên tắc, viết tắt là POUR — hãy nhớ kỹ vì đây là bộ khung tư duy:
- 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ó alt text để screen reader đọc; video phải có phụ đề; màu chữ phải đủ tương phản với nền.
- Operable (Thao tác được): Người dùng phải điều khiển được giao diện. Ví dụ: mọi chức năng phải dùng được bằng bàn phím; không có nội dung nhấp nháy gây động kinh; đủ thời gian để hoàn thành tác vụ.
- Understandable (Hiểu được): Nội dung và cách vận hành phải dễ hiểu. Ví dụ: thông báo lỗi rõ ràng chỉ cách sửa; giao diện nhất quán; ngôn ngữ trang được khai báo đúng.
- Robust (Bền vững): Nội dung phải hoạt động ổn định với nhiều công nghệ hỗ trợ (assistive technology) khác nhau, hiện tại và tương lai. Ví dụ: HTML đúng chuẩn, dùng đúng thẻ semantic và ARIA.
Ba mức tuân thủ: A, AA, AAA
Mỗi tiêu chí (success criterion) trong WCAG được gán một mức độ nghiêm ngặt:
- Level A — mức tối thiểu: Những rào cản nghiêm trọng nhất. Nếu không đạt, một nhóm người dùng hoàn toàn không dùng được sản phẩm. Ví dụ: video không có phụ đề, ảnh nút bấm không có nhãn.
- Level AA — mục tiêu thực tế của đa số: Đây là mức mà 90% dự án chuyên nghiệp và hầu hết luật pháp nhắm tới. Ví dụ tiêu biểu: tương phản màu chữ thường phải đạt tỷ lệ tối thiểu 4.5:1, chữ lớn (từ 18pt hoặc 14pt in đậm) đạt 3:1; trang phải dùng được khi phóng to 200%.
- Level AAA — mức nghiêm ngặt nhất: Rất khó và đôi khi bất khả thi cho toàn bộ nội dung (ví dụ yêu cầu tương phản 7:1, hoặc phụ đề cho mọi nội dung âm thanh live). W3C khuyến cáo không nên lấy AAA làm chính sách chung cho cả website; thường chỉ áp dụng AAA cho các phần thật quan trọng.
Đo lường: từ tiêu chí sang con số
Accessibility có thể biến thành metrics theo vài cách:
- Automated compliance score / violation count: Công cụ tự động (axe, Lighthouse, WAVE) quét trang và trả về số lỗi. Ví dụ: "12 vấn đề nghiêm trọng, 30 vấn đề vừa". Lighthouse còn cho điểm Accessibility 0–100.
- % pass các success criteria: Ví dụ "đạt 42/50 tiêu chí Level AA áp dụng được = 84%".
- Số issue theo mức nghiêm trọng (critical/serious/moderate/minor): Dùng để ưu tiên xử lý.
- Task success rate với người dùng khuyết tật thật: Chỉ số vàng nhưng tốn công — ví dụ "7/10 người dùng screen reader hoàn thành đăng ký".
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt và bài toán tương phản màu
Một sàn thương mại điện tử tại TP.HCM (gọi là ShopViet) chạy campaign giảm giá, thiết kế lại trang sản phẩm với tông "sang trọng": giá gốc gạch bỏ màu xám nhạt (#B0B0B0) trên nền trắng, giá khuyến mãi màu hồng pastel (#FF9EB5). Nhìn trên màn hình thiết kế thì đẹp. Nhưng sau khi ra mắt, đội growth phát hiện tỷ lệ chuyển đổi trên nhóm người dùng trên 45 tuổi giảm 18%.
Khi chạy kiểm tra tương phản, họ phát hiện: chữ giá khuyến mãi hồng pastel trên nền trắng chỉ đạt tỷ lệ tương phản 1.9:1 — thấp hơn xa ngưỡng AA là 4.5:1. Người thị lực bình thường vẫn đọc được, nhưng người có mắt kém hoặc dùng điện thoại ngoài nắng thì con số giá gần như biến mất. Đội thiết kế đổi màu giá khuyến mãi sang đỏ đậm (#D32F2F, đạt 4.6:1) và giữ giá gốc gạch ngang đủ đậm hơn. Chuyển đổi nhóm tuổi cao phục hồi và còn tăng nhẹ ở toàn bộ người dùng mobile.
Bài học: Tương phản màu là tiêu chí AA dễ vi phạm nhất và dễ đo nhất. Nó ảnh hưởng đến tất cả người dùng, không chỉ người khuyết tật, đặc biệt trên mobile ngoài trời — bối cảnh rất phổ biến ở Việt Nam. Hãy kiểm tra tương phản ngay từ khâu design, trước khi code.
Ví dụ 2 — Startup fintech và cú sốc audit trước vòng gọi vốn
Một startup fintech Đông Nam Á chuẩn bị mở rộng sang thị trường Úc và cần đối tác ngân hàng thẩm định. Ngân hàng yêu cầu app phải đạt WCAG 2.1 AA. Startup tự tin vì điểm Lighthouse Accessibility của họ là 96/100. Nhưng khi thuê audit thủ công độc lập, kết quả gây sốc: app không đạt AA vì hàng loạt lỗi mà công cụ tự động không thấy được.
Cụ thể: luồng đăng ký tài khoản không dùng được bằng bàn phím — nút "Tiếp tục" là một thẻ <div> có onclick, không phải <button>, nên người dùng screen reader không tab tới được. Các thông báo lỗi validation ("Số CMND không hợp lệ") hiện bằng màu đỏ nhưng không được screen reader thông báo (thiếu ARIA live region). Toàn bộ icon trạng thái chỉ phân biệt bằng màu (xanh = thành công, đỏ = lỗi), vi phạm tiêu chí "không dùng riêng màu để truyền tải thông tin" (Level A, tiêu chí 1.4.1).
Kết quả: hoãn ra mắt 6 tuần để sửa. Team học được rằng điểm tự động cao đã ru ngủ họ.
Bài học: Đừng bao giờ tuyên bố "đạt AA" chỉ dựa trên công cụ tự động. Ba lỗi cổ điển mà máy hay bỏ sót — thao tác bàn phím, thông báo động cho screen reader, và phụ thuộc màu — đều cần kiểm thử thủ công. Với sản phẩm có yếu tố pháp lý/đối tác quốc tế, hãy audit thủ công trước deadline chứ đừng sau.
Ví dụ 3 — Trang tin tức và alt text vô nghĩa
Một tòa soạn báo điện tử tại Hà Nội tự động chèn alt text cho mọi ảnh bằng cách lấy tên file. Điểm tự động của họ về "images have alt" đạt 100% vì có thuộc tính alt. Nhưng khi một biên tập viên khiếm thị dùng screen reader duyệt bài, cô nghe thấy: "IMG-2024-08-15-final-v3-copy dot jpg". Hoàn toàn vô nghĩa.
Đội kỹ thuật nhận ra rằng "có alt" khác xa "alt hữu ích". Họ chuyển sang quy trình: ảnh trang trí thì để alt="" (screen reader bỏ qua), ảnh mang thông tin thì biên tập viên viết mô tả ngắn gọn ("Cầu Long Biên trong sương sớm, nhìn từ bờ Bắc"). Họ thêm chỉ số mới vào bảng theo dõi: tỷ lệ ảnh có alt được biên tập thủ công, thay vì chỉ đếm ảnh "có thuộc tính alt".
Bài học: Cẩn thận với các chỉ số hình thức. Một metric có thể đạt 100% mà vẫn thất bại về bản chất. Accessibility metrics tốt phải đo chất lượng trải nghiệm, không chỉ sự tồn tại của thuộc tính kỹ thuật.
Hướng dẫn từng bước
Đây là quy trình thực tế để đo và cải thiện a11y cho một sản phẩm:
Bước 1 — Xác định mục tiêu tuân thủ. Chọn phiên bản và mức: thường là WCAG 2.1 AA hoặc 2.2 AA. Ghi rõ trong tài liệu để cả team có chung đích. Đừng chọn AAA cho toàn site.
Bước 2 — Chạy quét tự động để lấy baseline. Dùng axe DevTools (extension Chrome/Firefox), Lighthouse (có sẵn trong Chrome DevTools), hoặc WAVE. Ghi lại: điểm số, tổng số vi phạm, và phân loại theo mức nghiêm trọng. Đây là con số khởi điểm để theo dõi tiến độ. Với dự án lớn, tích hợp axe-core vào CI để tự quét mỗi lần build.
Bước 3 — Kiểm thử bàn phím thủ công. Cất chuột đi. Chỉ dùng Tab, Shift+Tab, Enter, Space, phím mũi tên để đi hết một luồng quan trọng (ví dụ: đăng ký, thanh toán). Kiểm tra: có tab tới được mọi thứ tương tác không? Có thấy được focus đang ở đâu không (focus indicator)? Thứ tự tab có hợp lý không? Có bị "bẫy" không thoát ra được không?
Bước 4 — Kiểm thử với screen reader. Dùng VoiceOver (miễn phí trên Mac/iOS), NVDA (miễn phí trên Windows), hoặc TalkBack (Android). Nhắm mắt lại và nghe. Nút bấm có được đọc rõ chức năng không? Ảnh có mô tả nghĩa không? Lỗi form có được thông báo không?
Bước 5 — Kiểm tra tương phản và zoom. Dùng công cụ contrast checker (WebAIM Contrast Checker online, hoặc tích hợp trong Figma) cho mọi cặp màu chữ/nền. Phóng trình duyệt lên 200% và kiểm tra bố cục không vỡ, chữ không bị cắt.
Bước 6 — Lập bảng theo dõi (dashboard). Đưa các chỉ số vào một bảng để theo dõi theo thời gian: điểm Lighthouse, số vi phạm critical/serious, % tiêu chí AA đạt được, số lỗi tồn đọng. Đặt mục tiêu, ví dụ "0 lỗi critical trước khi release".
Bước 7 — Ưu tiên và sửa. Sắp xếp theo mức nghiêm trọng và số người bị ảnh hưởng. Lỗi critical chặn hoàn toàn một nhóm người dùng được sửa trước. Sau khi sửa, quét lại và cập nhật số.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin tưởng tuyệt đối vào điểm tự động. Như đã nói, máy chỉ bắt 30–40% vấn đề. Điểm Lighthouse 100 mà bỏ qua kiểm thử bàn phím và screen reader là ảo tưởng an toàn. Mẹo: luôn cặp đôi automated + manual.
Lỗi 2 — Chỉ dùng màu để truyền thông tin. Ô bắt buộc chỉ tô viền đỏ khi lỗi; trạng thái chỉ phân biệt bằng chấm xanh/đỏ. Người mù màu (khoảng 8% nam giới) không phân biệt được. Mẹo: luôn kèm icon, chữ hoặc pattern bên cạnh màu.
Lỗi 3 — Nhồi ARIA lung tung. Nhiều dev nghĩ thêm nhiều thuộc tính aria- là làm cho accessible hơn. Thực tế "No ARIA is better than bad ARIA" — ARIA sai còn tệ hơn không có. Mẹo:* ưu tiên HTML semantic đúng (<button>, <nav>, <label>) trước; chỉ dùng ARIA khi HTML thuần không diễn đạt được.
Lỗi 4 — Bỏ qua focus indicator. Nhiều team dùng CSS outline: none để nút "sạch" hơn, vô tình xóa luôn viền báo focus khiến người dùng bàn phím lạc lối. Mẹo: nếu bỏ outline mặc định, phải thay bằng focus style rõ ràng khác.
Lỗi 5 — Làm a11y ở cuối dự án. Sửa accessibility sau khi code xong tốn gấp nhiều lần làm đúng từ đầu. Mẹo: đưa contrast check vào khâu design, đưa axe vào CI, biến a11y thành một phần của Definition of Done.
Lỗi 6 — Quên nội dung động. Modal, toast, kết quả tìm kiếm tải bằng AJAX thường không được screen reader thông báo. Mẹo: dùng ARIA live regions và quản lý focus khi mở/đóng modal.
Bài tập thực hành
- Audit nhanh một trang thật. Chọn một website Việt bạn hay dùng (một sàn TMĐT, một trang ngân hàng, hoặc chính sản phẩm bạn đang làm). Chạy Lighthouse (tab Accessibility) và axe DevTools. Ghi lại điểm số và liệt kê 5 vi phạm nghiêm trọng nhất.
- Thử làm người dùng bàn phím. Cũng trên trang đó, cất chuột và thử hoàn thành một tác vụ (tìm sản phẩm và thêm vào giỏ) chỉ bằng bàn phím. Ghi lại những chỗ bạn bị kẹt: nút không tab tới được, không thấy focus, thứ tự lộn xộn.
- Kiểm tra tương phản. Lấy 3 cặp màu chữ/nền quan trọng nhất của một giao diện, đưa vào WebAIM Contrast Checker. Ghi tỷ lệ và đánh dấu cặp nào không đạt AA (4.5:1). Đề xuất màu thay thế đạt chuẩn.
- Thiết kế dashboard. Vẽ (trên giấy hoặc slide) một bảng theo dõi a11y gồm ít nhất 4 chỉ số: điểm Lighthouse, số lỗi critical, % tiêu chí AA đạt, số issue tồn đọng. Đặt một mục tiêu cụ thể cho mỗi chỉ số.
- Nghe bằng tai. Bật VoiceOver (Cmd+F5 trên Mac) hoặc NVDA và nghe một form đăng ký được đọc lên. Viết một đoạn ngắn: trải nghiệm đó rõ ràng hay khó hiểu, và tại sao.
Tóm tắt
Accessibility (a11y) là mức độ sản phẩm dùng được cho tất cả mọi người, và WCAG là bộ tiêu chuẩn toàn cầu để đo nó. Hãy khắc ghi bốn nguyên tắc POUR — Perceivable, Operable, Understandable, Robust — làm khung tư duy. Ba mức tuân thủ A / AA / AAA mang tính cộng dồn, trong đó AA là mục tiêu thực tế của hầu hết dự án và luật pháp; AAA quá nghiêm ngặt để áp cho cả site.
Về đo lường: bạn có thể dùng điểm số tự động (Lighthouse), số vi phạm phân theo mức nghiêm trọng, % tiêu chí AA đạt được, và task success rate với người dùng khuyết tật thật. Nhưng bài học lớn nhất — được minh họa qua cả ba tình huống — là: công cụ tự động chỉ bắt được 30–40% vấn đề. Điểm cao không đồng nghĩa với accessible. Ba thứ máy hay bỏ sót là thao tác bàn phím, thông báo động cho screen reader, và chất lượng thực của alt text/nhãn.
Quy trình chuẩn: chọn mục tiêu (thường WCAG 2.1/2.2 AA) → quét tự động lấy baseline → kiểm thử bàn phím → kiểm thử screen reader → kiểm tra tương phản và zoom → lập dashboard → ưu tiên sửa theo mức nghiêm trọng. Làm a11y sớm, từ khâu design và CI, luôn rẻ hơn sửa lúc cuối. Accessibility không phải gánh nặng tuân thủ — nó mở rộng thị trường, cải thiện trải nghiệm cho mọi người dùng, và là dấu hiệu của một sản phẩm được làm tử tế.