Mở đầu — vì sao bài này quan trọng
Ở những bài trước, bạn đã hiểu accessibility (khả năng tiếp cận) quan trọng thế nào, và biết được có những loại khuyết tật cùng công nghệ hỗ trợ (assistive technology) ra sao. Nhưng khi bắt tay vào làm việc thật, bạn sẽ nhanh chóng gặp một câu hỏi rất thực tế: "Vậy làm thế nào để biết một sản phẩm đã đủ 'accessible' hay chưa? Dựa vào cảm tính à?"
Câu trả lời là: không dựa vào cảm tính. Toàn bộ thế giới accessibility hiện đại vận hành xoay quanh một bộ tiêu chuẩn tên là WCAG (Web Content Accessibility Guidelines — Hướng dẫn về Khả năng Tiếp cận Nội dung Web), và cái xương sống triết lý của WCAG chính là POUR — bốn nguyên lý nền tảng.
Hãy hình dung thế này: nếu accessibility là một ngôi nhà, thì POUR là bốn cây cột chống. Còn WCAG là bản thiết kế chi tiết ghi rõ từng cây cột phải cao bao nhiêu, dày bao nhiêu, làm bằng vật liệu gì. Bài này sẽ giúp bạn nắm cả hai: hiểu triết lý POUR đủ sâu để "cảm" được vấn đề, và hiểu cấu trúc WCAG đủ rõ để biết chính xác mình phải đạt tiêu chuẩn nào khi ai đó nói "làm cho tôi trang web đạt chuẩn AA".
Đây là bài mang tính "bản đồ tư duy". Nắm chắc nó, mọi bài kỹ thuật phía sau — từ color contrast, semantic HTML, đến ARIA — bạn sẽ luôn biết chúng thuộc về đâu trong bức tranh lớn.
Khái niệm cốt lõi
POUR — bốn nguyên lý nền tảng
POUR là viết tắt của bốn từ tiếng Anh: Perceivable, Operable, Understandable, Robust. Đây không phải bốn checklist riêng lẻ, mà là bốn góc nhìn để soi chiếu bất kỳ giao diện nào. Một sản phẩm chỉ thực sự accessible khi thỏa mãn cả bốn.
1. Perceivable — Có thể cảm nhận được
Người dùng phải "nhận" được nội dung qua ít nhất một giác quan. Vấn đề là: bạn không biết người dùng của mình đang dùng giác quan nào. Người khiếm thị "đọc" trang web bằng tai (qua screen reader) hoặc bằng tay (qua màn hình chữ nổi Braille). Người khiếm thính không nghe được audio. Người bị nhược thị cần phóng to chữ.
Nguyên lý Perceivable đòi hỏi: mọi thông tin không được chỉ tồn tại ở một dạng cảm nhận duy nhất. Nếu bạn truyền thông tin bằng hình ảnh, phải có văn bản thay thế (alt text) để screen reader đọc. Nếu bạn truyền bằng âm thanh trong video, phải có phụ đề. Nếu bạn dùng màu đỏ để báo lỗi, không được chỉ dựa vào màu — vì người mù màu không phân biệt được.
Một cách nhớ đơn giản: "Người dùng có thể lấy được thông tin này không, dù họ không dùng giác quan mà tôi mặc định?"
2. Operable — Có thể thao tác được
Người dùng phải có khả năng điều khiển, tương tác với giao diện — bấm nút, điền form, mở menu, đóng modal. Vấn đề: không phải ai cũng dùng chuột. Người khiếm thị điều hướng hoàn toàn bằng bàn phím. Người bị run tay (Parkinson) không rê chuột chính xác được. Người liệt vận động có thể dùng công tắc (switch) hoặc điều khiển bằng mắt.
Operable đòi hỏi: mọi chức năng phải thao tác được không chỉ bằng chuột, mà quan trọng nhất là bằng bàn phím. Ngoài ra, không được đặt bẫy khiến người dùng mắc kẹt (keyboard trap), không được đặt giới hạn thời gian quá gấp gáp, không dùng hiệu ứng nhấp nháy có thể gây co giật động kinh.
Câu hỏi tự vấn: "Người dùng có làm được mọi thứ trên trang này mà không cần chạm vào chuột không?"
3. Understandable — Có thể hiểu được
Cảm nhận được và thao tác được vẫn chưa đủ — người dùng còn phải hiểu nội dung và cách vận hành của giao diện. Chữ nghĩa phải rõ ràng, dễ đọc. Giao diện phải hoạt động theo cách có thể đoán trước (predictable) — nút "Đăng nhập" ở mọi trang nên nằm cùng một chỗ. Khi người dùng nhập sai, hệ thống phải báo lỗi rõ ràng và gợi ý cách sửa.
Nguyên lý này đặc biệt quan trọng với người có khuyết tật nhận thức (cognitive), người lớn tuổi, hoặc người dùng ngôn ngữ thứ hai. Ví dụ rất gần gũi ở Việt Nam: một người bà 65 tuổi lần đầu dùng app ngân hàng — nếu form chuyển tiền báo "Lỗi 402: giao dịch bị từ chối" thay vì "Số dư không đủ để chuyển 5.000.000đ", thì bà ấy hoàn toàn bế tắc.
Câu hỏi tự vấn: "Người dùng có hiểu nội dung này nói gì, và có đoán được điều gì sẽ xảy ra khi họ bấm không?"
4. Robust — Vững chắc, tương thích
Nội dung phải đủ "chắc chắn" để hoạt động ổn định trên nhiều loại công nghệ khác nhau — nhiều trình duyệt, nhiều screen reader, nhiều thiết bị, cả những công nghệ hỗ trợ sẽ ra đời trong tương lai. Điều này đạt được chủ yếu bằng cách viết code chuẩn: HTML hợp lệ (valid), dùng đúng semantic, khai báo đúng name/role/value cho mọi thành phần giao diện.
Robust là nguyên lý "vô hình" nhất — người dùng cuối không trực tiếp thấy nó, nhưng nếu thiếu nó, screen reader sẽ đọc sai, hoặc component tự chế của bạn sẽ "câm" hoàn toàn trước công nghệ hỗ trợ.
Câu hỏi tự vấn: "Code này có được screen reader và các trình duyệt hiểu đúng như tôi mong đợi không?"
Cấu trúc WCAG — từ nguyên lý xuống tiêu chí
POUR là triết lý. WCAG biến triết lý đó thành thứ có thể kiểm tra được, bằng một cấu trúc phân cấp bốn tầng:
- Principles (Nguyên lý) — chính là 4 chữ POUR. Đây là tầng cao nhất, mang tính triết lý.
- Guidelines (Hướng dẫn) — dưới mỗi nguyên lý có các hướng dẫn tổng quát. WCAG có tổng cộng 13 guidelines. Ví dụ dưới Perceivable có guideline 1.1 "Text Alternatives", 1.4 "Distinguishable"...
- Success Criteria (Tiêu chí thành công) — đây là tầng quan trọng nhất về mặt kiểm tra. Mỗi tiêu chí là một điều kiện cụ thể có thể pass/fail, được đánh số như 1.4.3, 2.1.1... Đây là thứ mà auditor thực sự dùng để chấm điểm.
- Techniques (Kỹ thuật) — các cách làm cụ thể để đạt được tiêu chí. Đây chỉ mang tính tham khảo, không bắt buộc.
Ba mức độ tuân thủ: A, AA, AAA
Mỗi Success Criteria được gán một trong ba mức:
- Level A — mức tối thiểu tuyệt đối. Không đạt A nghĩa là có rào cản nghiêm trọng, một số người dùng gần như không dùng được sản phẩm.
- Level AA — mức tiêu chuẩn của ngành. Đây là mục tiêu mà 99% dự án thực tế nhắm tới, và cũng là mức mà hầu hết luật pháp trên thế giới yêu cầu.
- Level AAA — mức cao nhất, lý tưởng. Rất khó đạt toàn bộ cho cả một website, thường chỉ áp dụng cho nội dung chuyên biệt.
Các phiên bản WCAG
WCAG 2.0 ra đời năm 2008, WCAG 2.1 năm 2018 (bổ sung mạnh về mobile và cognitive), WCAG 2.2 năm 2023 (thêm 9 tiêu chí mới, chú trọng touch target và cognitive). WCAG 3.0 đang trong quá trình soạn thảo và còn nhiều năm nữa mới hoàn thiện. Trong thực tế công việc hiện nay, hãy nhắm WCAG 2.1 hoặc 2.2, mức AA — đó là chuẩn mà bạn sẽ nghe nhắc đến nhiều nhất.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử và cái nút "câm" (Robust + Operable)
Một công ty thương mại điện tử tại TP.HCM — tạm gọi là ShopViet — thuê đội frontend làm lại nút "Thêm vào giỏ". Đội dev, vì muốn tùy biến giao diện đẹp, đã dùng thẻ <div> gắn sự kiện click thay vì thẻ <button> chuẩn. Trên màn hình bằng chuột, nút hoạt động hoàn hảo.
Nhưng một khách hàng khiếm thị dùng screen reader NVDA phản ánh: anh không thể mua hàng. Khi kiểm tra, đội phát hiện cái <div> đó không có role, không nhận focus từ bàn phím, và screen reader đọc lướt qua như thể nó là một khối văn bản vô nghĩa. Người dùng chuột thì không sao, nhưng người dùng bàn phím thì "va" thẳng vào tường.
Diễn giải: Đây là vi phạm cùng lúc hai nguyên lý. Vi phạm Operable (không thao tác được bằng bàn phím — trượt tiêu chí 2.1.1 Keyboard, Level A) và vi phạm Robust (thiếu name/role/value đúng chuẩn — trượt tiêu chí 4.1.2 Name, Role, Value, Level A). Cả hai đều ở Level A, tức là rào cản nghiêm trọng nhất.
Bài học: Đừng bao giờ "chế lại" những thành phần mà HTML đã cung cấp sẵn. Một thẻ <button> chuẩn tự động có đủ role, tự nhận focus bàn phím, tự phản hồi phím Enter/Space. Khi POUR chỉ ra vấn đề ở tầng triết lý, WCAG cho bạn tên chính xác của lỗi (4.1.2) để đưa vào phiếu bug và theo dõi.
Ví dụ 2: App ngân hàng và màu đỏ vô hình (Perceivable)
Một ngân hàng số ở Đông Nam Á thiết kế màn hình lịch sử giao dịch: số tiền vào hiển thị màu xanh lá, số tiền ra hiển thị màu đỏ — không có dấu +/- hay nhãn chữ nào khác. Với người mắt bình thường, nhìn phát là hiểu ngay.
Nhưng khoảng 8% nam giới bị mù màu đỏ-xanh lá (deuteranopia/protanopia). Với họ, hai màu này trông gần như giống hệt nhau. Một người dùng đã suýt hiểu nhầm một khoản chi 12 triệu đồng thành khoản thu, vì anh không phân biệt được sắc thái.
Diễn giải: Đây là vi phạm Perceivable, cụ thể là tiêu chí 1.4.1 "Use of Color" (Level A) — không được dùng màu sắc làm phương tiện duy nhất để truyền tải thông tin. Thông tin quan trọng (vào/ra) chỉ được mã hóa bằng một kênh cảm nhận (màu), nên nhóm người không cảm nhận được kênh đó bị bỏ lại.
Bài học: Màu sắc là công cụ tăng cường, không phải công cụ duy nhất. Cách sửa rất rẻ: thêm dấu "+"/"−", thêm chữ "Nhận"/"Chi", hoặc dùng icon mũi tên. Đây là ví dụ điển hình cho thấy accessibility thường không đòi hỏi redesign tốn kém — chỉ cần một điều chỉnh nhỏ đúng chỗ.
Ví dụ 3: Cổng dịch vụ công và câu hỏi "chúng ta cần đạt mức nào?" (WCAG Structure)
Một sở thông tin địa phương chuẩn bị ra mắt cổng dịch vụ công trực tuyến. Trong buổi họp, giám đốc dự án hỏi: "Đơn vị kiểm định yêu cầu chúng ta 'đạt chuẩn accessibility'. Cụ thể là mức nào?" Không ai trong phòng trả lời rõ ràng được, và dự án suýt cam kết đạt AAA — một mục tiêu gần như bất khả thi cho một cổng thông tin lớn, khiến chi phí và thời gian đội lên gấp nhiều lần.
May mắn là một thành viên hiểu cấu trúc WCAG đã giải thích: chuẩn thực tế mà các cơ quan nhà nước trên thế giới (như luật Section 508 của Mỹ, hay EN 301 549 của châu Âu) đều lấy làm mốc là WCAG 2.1 Level AA. AAA chỉ nên áp dụng có chọn lọc cho từng nội dung, không phải cho toàn site.
Diễn giải: Hiểu cấu trúc A/AA/AAA không chỉ là kiến thức hàn lâm — nó ảnh hưởng trực tiếp đến ngân sách và tiến độ. Cam kết sai mức có thể khiến dự án hoặc quá lỏng (không đủ tuân thủ pháp lý), hoặc quá chặt (lãng phí nguồn lực khổng lồ).
Bài học: Khi ai đó nói "làm cho accessible", câu hỏi đầu tiên của một chuyên gia luôn là: "Phiên bản WCAG nào, mức nào?". Câu trả lời mặc định an toàn cho hầu hết dự án là WCAG 2.1 AA (hoặc 2.2 AA nếu muốn đón đầu).
Hướng dẫn từng bước
Đây là cách áp dụng POUR + WCAG vào một tính năng cụ thể mà bạn đang làm:
Bước 1 — Xác định mục tiêu tuân thủ. Trước khi làm gì, chốt rõ với dự án: nhắm WCAG phiên bản nào, mức nào. Mặc định: WCAG 2.1 hoặc 2.2, Level AA. Ghi rõ điều này vào tài liệu dự án để tránh tranh cãi về sau.
Bước 2 — Soi tính năng qua từng chữ POUR. Lấy màn hình/component bạn đang làm, đặt lần lượt bốn câu hỏi:
- Perceivable: Mọi thông tin có tồn tại ở nhiều hơn một dạng cảm nhận không? (ảnh có alt, video có phụ đề, màu không phải kênh duy nhất)
- Operable: Làm được mọi thứ chỉ bằng bàn phím không? Có bẫy nào không?
- Understandable: Nội dung có rõ ràng, hành vi có đoán trước được, lỗi có được giải thích không?
- Robust: Code có valid, có dùng semantic đúng, có name/role/value đầy đủ không?
Bước 4 — Ưu tiên theo mức. Sửa toàn bộ lỗi Level A trước (rào cản chặn hoàn toàn người dùng), rồi đến Level AA. Level AAA chỉ làm khi còn nguồn lực và với nội dung phù hợp.
Bước 5 — Ghi lại thành tài liệu tuân thủ. Với mỗi tiêu chí, ghi trạng thái: đạt / không đạt / không áp dụng. Đây chính là nền tảng cho báo cáo tuân thủ chính thức mà bạn sẽ học kỹ hơn ở các bài về VPAT sau này.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm POUR là checklist đủ để hoàn thành. POUR chỉ là bốn góc nhìn tư duy, không phải danh sách bốn việc cần tick. Việc kiểm tra thực sự nằm ở tầng Success Criteria. Hãy dùng POUR để phát hiện vấn đề, dùng Success Criteria để đo lường và báo cáo.
Lỗi 2: Cam kết Level AAA cho cả website. AAA rất khó đạt trọn vẹn (ví dụ tiêu chí 1.4.6 yêu cầu độ tương phản tới 7:1, hay 2.4.9 yêu cầu mọi link phải rõ nghĩa chỉ từ text). Nhắm AAA toàn site thường là dấu hiệu người ra quyết định chưa hiểu cấu trúc WCAG. Mặc định luôn là AA.
Lỗi 3: Nghĩ rằng đạt AA thì không cần quan tâm A. Nhớ rằng các mức tích lũy: AA đã bao gồm toàn bộ A. Nếu bạn còn trượt bất kỳ tiêu chí A nào, bạn chưa đạt AA, dù đã pass hết các tiêu chí AA.
Lỗi 4: Chỉ tập trung vào Perceivable và quên ba chữ còn lại. Rất nhiều người mới học accessibility chỉ nhớ mỗi "thêm alt text, sửa màu tương phản" — đó chỉ là Perceivable. Một trang có alt text hoàn hảo nhưng không dùng được bằng bàn phím (Operable) vẫn là một trang thất bại về accessibility.
Mẹo ghi nhớ POUR: Hình dung một người dùng lần lượt: đầu tiên phải nhận được nội dung (Perceivable), rồi phải tương tác được với nó (Operable), rồi phải hiểu được (Understandable), và tất cả điều đó phải hoạt động ổn định trên công nghệ của họ (Robust). Đó là hành trình tự nhiên của một lần dùng sản phẩm.
Mẹo tra cứu nhanh: Số hiệu tiêu chí luôn có dạng X.Y.Z, trong đó chữ số đầu (X) cho biết nó thuộc nguyên lý nào: 1 = Perceivable, 2 = Operable, 3 = Understandable, 4 = Robust. Nhìn "2.1.1" là biết ngay đây là vấn đề thao tác (Operable).
Bài tập thực hành
Bài 1 — Phân loại theo POUR. Với mỗi tình huống dưới đây, xác định nó vi phạm nguyên lý nào trong POUR:
- (a) Video hướng dẫn không có phụ đề.
- (b) Menu chỉ mở ra được khi rê chuột vào, không mở được bằng bàn phím.
- (c) Thông báo lỗi ghi "Đã xảy ra lỗi" mà không nói lỗi gì.
- (d) Component tabs tự viết bằng
<div>, screen reader không đọc được đây là tabs.
Bài 3 — Tình huống ra quyết định. Sếp bạn nói: "Đối tác yêu cầu website đạt accessibility, hãy làm cho tôi đạt AAA cho tự tin." Hãy viết một đoạn 3–4 câu phản hồi, giải thích tại sao AA thường là lựa chọn hợp lý hơn và AAA nên áp dụng thế nào.
Bài 4 — Tự soi sản phẩm. Mở một trang web bạn hay dùng (ví dụ trang chủ một ngân hàng Việt Nam). Chọn một tính năng bất kỳ (ví dụ form đăng nhập) và viết ra bốn câu hỏi POUR cùng câu trả lời sơ bộ của bạn cho tính năng đó.
Gợi ý đáp án Bài 1: (a) Perceivable, (b) Operable, (c) Understandable, (d) Robust. Bài 2: 1.4.3 → Perceivable, 2.4.7 → Operable, 3.3.1 → Understandable, 4.1.2 → Robust.
Tóm tắt
- POUR là bốn nguyên lý nền tảng của accessibility: Perceivable (cảm nhận được), Operable (thao tác được), Understandable (hiểu được), Robust (vững chắc, tương thích). Chúng là bốn góc nhìn tư duy, không phải checklist.
- WCAG biến POUR thành tiêu chuẩn kiểm tra được, với cấu trúc bốn tầng: Principles (POUR) → Guidelines → Success Criteria (tầng đo lường thực sự) → Techniques.
- Mỗi Success Criteria thuộc một trong ba mức: A (tối thiểu), AA (tiêu chuẩn ngành, mục tiêu thực tế), AAA (lý tưởng). Các mức tích lũy — đạt AA nghĩa là đạt cả A và AA.
- Chuẩn mặc định an toàn cho hầu hết dự án là WCAG 2.1 hoặc 2.2, Level AA — cũng là mức mà đa số luật pháp thế giới yêu cầu.
- Số hiệu tiêu chí X.Y.Z: chữ số đầu chỉ nguyên lý (1=P, 2=O, 3=U, 4=R) — mẹo tra cứu cực nhanh.
- Dùng POUR để phát hiện vấn đề bằng cảm quan, dùng Success Criteria để đặt tên, đo lường và báo cáo. Đây là bản đồ tư duy cho mọi bài kỹ thuật phía sau.