WCAG 3 vừa có bản Working Draft ngày 10/09/2026 với một cách báo cáo khá khác WCAG 2.2: thay vì ba level A, AA, AAA, bản nháp đặt một mốc conformance và các reporting tier ở cả phía trước lẫn phía sau mốc đó. Nhìn bảng Tier 1–6 rất dễ nảy ra câu hỏi: có nên đổi checklist audit ngay không?
Câu trả lời ngắn là chưa. trang giới thiệu WCAG 3 của W3C gọi đây là bản nháp chưa hoàn chỉnh, nhiều phần còn thay đổi đáng kể, đồng thời nói cách chuẩn bị tốt nhất hiện nay là đáp ứng WCAG 2.2. Reporting tiers đáng để học và thử trên một scope nhỏ, nhưng chưa phải lý do để bỏ baseline đang dùng cho production.
Mục lục [Hiển thị]
WCAG 3 chưa thay checklist WCAG 2.2
WCAG 3 Working Draft ngày 10/09/2026 nằm trên Recommendation Track, nhưng trạng thái Working Draft không đồng nghĩa W3C đã xác nhận nội dung. Chính tài liệu ghi nó có thể được cập nhật, thay thế hoặc làm lỗi thời và chỉ nên được trích dẫn như công việc đang tiến hành.
Trong khi đó, WCAG 2.2 là W3C Recommendation ổn định, có success criteria ở ba level A, AA và AAA. Vì vậy audit production, procurement hoặc hồ sơ cần một chuẩn tham chiếu hôm nay vẫn nên bám WCAG 2.2 và các yêu cầu pháp lý, hợp đồng áp dụng cho chính tổ chức. Bài này không suy diễn Working Draft thành yêu cầu pháp lý mới.
Điểm hợp lý để thử WCAG 3 là lớp báo cáo nội bộ: cùng một issue đã có bằng chứng WCAG 2.2, nhóm sản phẩm thêm cột mapping sang provision và tag trong draft. Cách đó giúp làm quen với mô hình mới mà không đổi nhãn pass/fail đã cam kết với khách hàng.
Reporting tier khác A, AA, AAA ở đâu?
WCAG 2 gắn conformance với các success criterion theo level. Bản nháp WCAG 3 hiện chuyển ý tưởng “level” sang lớp báo cáo. Một scope chỉ được gọi là conform khi thỏa mọi core requirement. Bốn tag của core requirement — Physical Harm, Risk, Barrier và Friction — giúp mô tả tiến độ đi tới mốc đó; chúng không tạo bốn kiểu conformance độc lập.
| Tier trong draft | Cần đạt | Cách đọc an toàn |
|---|---|---|
| 1 — Avoid physical harm | Physical Harm + Risk | Tiến độ trước conformance |
| 2 — Foundational access | Thêm Barrier | Tiến độ trước conformance |
| 3 — Conformance | Thêm Friction, đủ mọi core requirement | Mốc conformance duy nhất trong mô hình hiện tại |
| 4 — Bronze | Thêm supplemental requirements và content assertions | Vượt conformance; số lượng còn TBD |
| 5 — Silver | Thêm số lượng lớn hơn | Vượt conformance; số lượng còn TBD |
| 6 — Gold | Thêm organization assertions | Vượt conformance; số lượng còn TBD |
Sáu tier là dạng cộng dồn. Tier 2 bao gồm Tier 1; Tier 3 bao gồm hai bậc trước và toàn bộ core requirement. Bronze, Silver, Gold nằm sau conformance, nhưng các ngưỡng vẫn ghi TBD. Vậy nên một dashboard tự đặt “Bronze 80%” lúc này chỉ là quy ước nội bộ, không phải claim do W3C định nghĩa.
Chỗ dễ nhầm thứ hai là scoring. WCAG 3 Explainer có một phương án thay thế dùng trọng số 3 cho Physical Harm/Risk, 2 cho Barrier và 1 cho Friction để tính phần trăm tiến độ. Nhưng W3C ghi rõ phần này là phương án đang cân nhắc, không nằm trong Working Draft; điểm số báo cáo tiến độ chứ không quyết định một sản phẩm có conform hay không.
Thử trên một flow form, đừng thử cả website
Một pilot đủ nhỏ có thể bắt đầu từ flow đăng ký: mở form trống, nhập dữ liệu, gửi một trường sai, đọc error summary, quay focus về trường lỗi, sửa rồi tới trang xác nhận. Scope phải ghi rõ điểm đầu, điểm cuối, viewport, browser, cách dùng bàn phím và công nghệ hỗ trợ nếu có.
Giữ hai lớp bằng chứng cạnh nhau. Cột WCAG 2.2 ghi success criterion hiện hành, bước tái hiện và kết quả quan sát. Cột WCAG 3 chỉ ghi provision/tag của đúng bản draft đã đọc, ngày mapping và mức chắc chắn. Nếu provision còn trạng thái Developing hoặc cách map chưa rõ, đánh dấu để rà lại thay vì ép thành pass/fail.
Positive control có thể là trường email với label lập trình được, thông báo lỗi được liên kết bằng aria-describedby, error summary có link và focus quay đúng vị trí. Negative control là một trường chỉ đổi viền đỏ nhưng không có thông báo lập trình được. Hai nhánh này cho biết template có phân biệt được bằng chứng tốt và lỗi cơ bản hay chỉ đang tô màu bảng.
Case form này dựa trên cách kiểm có thể tái hiện trong bài form báo lỗi, error summary và focus. Bài hiện tại không chạy user study và cũng không chạy một pass screen reader mới, nên không có tỷ lệ hoàn thành task hoặc kết luận trải nghiệm người dùng. Khi cần evidence cho assistive technology, nên ghi chính xác phiên bản và task, giống nguyên tắc ở bài timeline với screen reader.
Một audit sheet tối thiểu cần ghi gì?
Mỗi hàng nên chứa step, viewport, browser, keyboard hoặc AT, kết quả quan sát, WCAG 2.2 SC, WCAG 3 provision/tag, mức chắc chắn, URL nguồn và ngày kiểm tra. Ảnh chụp chỉ là một phần bằng chứng; với focus, accessible name hay error association, cần thêm DOM/accessibility tree hoặc thao tác tái hiện.
Scope cũng không được viết kiểu “toàn bộ sản phẩm” nếu nhóm chỉ thử một form. Working Draft yêu cầu một conformance scope được xác định, còn accessibility support set nêu tập browser, assistive technology và thiết lập giả định. Danh sách thực tế phải đi cùng claim; một kết quả trên Chrome không tự đại diện cho mọi browser và AT.
Nếu nhóm đang kiểm focus indicator, bài đo diện tích và tương phản theo WCAG 2.2 là ví dụ tốt cho việc giữ số đo gốc. Khi thêm mapping WCAG 3, đừng vứt số đo đó để đổi lấy một badge mới; evidence càng cụ thể thì càng dễ remap khi draft thay đổi.
Ba chỗ chưa nên chốt thành policy
Thứ nhất, các tier trên conformance còn ngưỡng TBD. Bronze, Silver và Gold đã có vị trí trong mô hình, nhưng số supplemental requirement và assertion cần đạt chưa chốt. Đưa chúng vào hợp đồng như mốc cố định lúc này sẽ tạo một mục tiêu có thể đổi dưới chân đội dự án.
Thứ hai, scoring chỉ là phương án thay thế được mời phản hồi. Một bảng phần trăm có thể hữu ích để theo dõi backlog nội bộ, nhưng không được đổi tên thành “điểm tuân thủ WCAG 3”. Conformance trong draft hiện vẫn đòi hỏi tất cả core requirement của scope.
Thứ ba, chi tiết reporting và accessibility support còn tiếp tục hoàn thiện. Working Draft đã mô tả default và alternative accessibility support set, nhưng nhóm sản phẩm vẫn phải chờ tài liệu/method đủ trưởng thành để biết tổ hợp nào phù hợp với ngôn ngữ, khu vực và công nghệ cụ thể. Pilot nên lưu URL phiên bản có ngày, không chỉ link latest, để vài tháng sau còn biết mapping dựa trên bản nào.
Nhóm sản phẩm nên làm gì trong quý này?
Giữ WCAG 2.2 làm baseline cho audit production. Chọn đúng một flow có ranh giới rõ để thêm lớp mapping WCAG 3, rồi version-control audit sheet cùng ngày nguồn. Sau một hoặc hai vòng, kiểm tra xem tags có giúp ưu tiên issue tốt hơn không, phần nào gây tranh luận và evidence nào đang thiếu.
Ngôn ngữ báo cáo nên là “pilot”, “mapping theo Working Draft 10/09/2026” hoặc “theo dõi tiến độ nội bộ”. Tránh “đạt WCAG 3”, “được chứng nhận Bronze” hay “thay thế AA” khi chưa có căn cứ. Nếu cần chia sẻ ra ngoài, ghi cả giới hạn scope, support set, test method và những phần chưa kiểm.
Cuối cùng, đặt lịch rà lại mapping khi W3C ra draft mới. Đây là điểm quan trọng hơn việc dựng dashboard đẹp: draft thay đổi mà bảng vẫn giữ nhãn cũ thì dữ liệu trông chính xác nhưng đã mất ngữ cảnh.
Chốt lại
Reporting tiers của WCAG 3 mở ra cách nói rõ tiến độ trước conformance và thành tựu sau conformance. Trong Working Draft hiện tại có sáu tier, với Tier 3 là mốc đủ mọi core requirement; scoring là phương án thay thế, không phải thước đo conformance đã chốt.
Điều nên làm ngay là giữ audit WCAG 2.2, thử mapping WCAG 3 trên một flow nhỏ và lưu evidence có phiên bản. Đổi toàn bộ checklist production hoặc tự gắn badge Bronze lúc này thì hơi sớm — học mô hình mới được, nhưng đừng biến bản nháp thành con dấu.
