Mở đầu — vì sao bài này quan trọng
Suốt 47 bài trước, bạn đã học từng mảnh ghép của accessibility: từ semantic HTML, ARIA, color contrast, keyboard navigation cho tới cách kiểm thử bằng screen reader. Nhưng trong công việc thật, bạn hiếm khi được giao "hãy sửa một cái nút". Bạn sẽ được giao một sản phẩm sống — hàng nghìn trang, hàng chục người từng chạm tay vào code, deadline sát nút, và một câu hỏi lớn: "Sản phẩm của chúng ta có accessible không, và nếu không thì phải bắt đầu từ đâu?"
Bài này là bài đầu tiên trong chuỗi hai case study (Bài 48 và Bài 49) đưa bạn vào đúng tình huống đó. Chúng ta sẽ đi qua trọn vẹn một cuộc audit accessibility (kiểm toán khả năng tiếp cận) cho một sàn thương mại điện tử (TMĐT) Việt Nam quy mô lớn — từ lúc nhận yêu cầu, xác định phạm vi, chọn mẫu trang, chấm điểm lỗi, cho tới việc viết báo cáo và lập lộ trình khắc phục (remediation roadmap).
Điều quan trọng cần hiểu: audit không phải là chạy một cái tool rồi dán kết quả vào email. Một audit tốt là sự kết hợp giữa tự động và thủ công, giữa kỹ thuật và ưu tiên kinh doanh. Nó trả lời được ba câu hỏi mà sếp bạn thực sự quan tâm: "Chúng ta đang ở đâu?", "Rủi ro pháp lý lớn cỡ nào?", và "Sửa cái gì trước để có tác động lớn nhất với chi phí nhỏ nhất?". Nắm được quy trình audit tức là bạn nắm được cách biến toàn bộ kiến thức rời rạc thành một sản phẩm tư vấn có giá trị thật.
Khái niệm cốt lõi
Bối cảnh case study
Xuyên suốt bài, chúng ta dùng một công ty giả định nhưng rất sát thực tế: ChợViệt — một sàn TMĐT nằm trong top 5 Việt Nam, ra mắt năm 2018, khoảng 12 triệu người dùng hoạt động hằng tháng, chưa từng làm audit accessibility. Đầu Q1/2026, ban lãnh đạo quyết định audit và khắc phục a11y trước khi mở rộng sang thị trường EU — nơi Đạo luật European Accessibility Act (EAA) có hiệu lực từ 28/6/2025, buộc các dịch vụ TMĐT phải đạt WCAG 2.1 mức AA. Đây chính là chất xúc tác điển hình: accessibility thường không được ưu tiên cho tới khi có một áp lực pháp lý hoặc thị trường rõ ràng.
Audit khác gì với "test cho vui"
Một audit chuyên nghiệp có bốn đặc điểm phân biệt nó với việc test lẻ tẻ:
- Có phạm vi (scope) rõ ràng: bạn không audit "cả website" — điều đó vô nghĩa với 50.000 trang. Bạn chọn các user flow (luồng người dùng) quan trọng nhất.
- Có tiêu chuẩn tham chiếu: mọi lỗi được ánh xạ vào một success criterion (tiêu chí thành công) cụ thể của WCAG, ví dụ 1.4.3 Contrast hay 4.1.2 Name, Role, Value.
- Có mức độ nghiêm trọng (severity): không phải lỗi nào cũng bằng nhau. Một nút "Thanh toán" không bấm được bằng bàn phím nghiêm trọng hơn nhiều so với thiếu alt text ở icon trang trí.
- Có sản phẩm bàn giao (deliverable): một báo cáo có thể hành động được, kèm lộ trình.
Ba trụ cột phương pháp
Một audit đúng chuẩn kết hợp ba nguồn dữ liệu, và bạn phải hiểu điểm mạnh — điểm mù của từng cái:
1. Kiểm thử tự động (automated testing). Dùng axe DevTools, Lighthouse, WAVE. Nhanh, phủ rộng, tìm được lỗi máy đọc được như thiếu alt, contrast thấp, thiếu label. Nhưng — và đây là điều học viên hay quên — công cụ tự động chỉ bắt được khoảng 30–40% số vấn đề WCAG. Nó không biết alt text bạn viết có ý nghĩa hay không, không biết thứ tự focus có hợp lý hay không.
2. Kiểm thử thủ công (manual testing). Người thật dùng bàn phím, dùng screen reader (NVDA, VoiceOver), zoom 200%, tắt CSS. Đây là nơi phát hiện những lỗi "chết người" mà tool bỏ sót: modal bẫy focus sai, thứ tự đọc lộn xộn, thao tác chỉ dùng được bằng chuột.
3. Kiểm thử với người dùng thật khuyết tật (nếu ngân sách cho phép). Đây là "tiêu chuẩn vàng", nhưng thường nằm ở giai đoạn sau audit ban đầu (chúng ta bàn kỹ ở Bài 54).
Chọn mẫu trang — nghệ thuật của scoping
Với ChợViệt, đội audit không thể xem hết. Họ chọn theo nguyên tắc "luồng tạo doanh thu + trang lưu lượng cao". Kết quả là một danh sách mẫu (page sample) gồm khoảng 12 màn hình đại diện cho toàn bộ trải nghiệm mua hàng:
- Trang chủ (homepage)
- Trang kết quả tìm kiếm + bộ lọc (filter/facet)
- Trang danh mục sản phẩm
- Trang chi tiết sản phẩm (product detail — có gallery ảnh, chọn biến thể, review)
- Giỏ hàng
- Luồng thanh toán (checkout — nhiều bước, có form địa chỉ, chọn phương thức thanh toán)
- Đăng nhập / đăng ký
- Trang tài khoản người dùng
- Trang theo dõi đơn hàng
Tình huống thực tế
Ví dụ 1 — ChợViệt: lỗi checkout suýt chặn cả thương vụ EU
Đội audit của ChợViệt (2 chuyên viên a11y, 3 tuần) bắt đầu bằng automated scan trên 12 trang mẫu bằng axe DevTools. Kết quả thô: term khoảng 380 lỗi tự động, nhưng khi gộp các lỗi trùng lặp (cùng một component lỗi lặp lại), con số thật rút xuống còn 41 loại vấn đề riêng biệt.
Điểm mấu chốt nằm ở giai đoạn manual. Khi một chuyên viên dùng NVDA đi qua luồng checkout, họ phát hiện: bước chọn phương thức thanh toán dùng các thẻ <div> được style thành nút bấm, gắn onclick bằng JavaScript nhưng không có role, không nhận focus bàn phím. Nghĩa là một người dùng chỉ dùng bàn phím hoặc screen reader không thể hoàn tất thanh toán — họ bị kẹt ở bước cuối cùng, sau khi đã bỏ công chọn hàng.
Đây được chấm Severity: Critical (Blocker) vì nó chặn hoàn toàn một luồng tạo doanh thu. Về mặt WCAG, nó vi phạm cùng lúc 2.1.1 (Keyboard) và 4.1.2 (Name, Role, Value).
Bài học rút ra: lỗi nghiêm trọng nhất thường không phải lỗi nhiều nhất. Automated scan báo hàng trăm lỗi contrast, nhưng thứ suýt khiến ChợViệt trượt điều kiện vào EU lại là một component <div> giả nút mà tool tự động chỉ cảnh báo mờ nhạt. Manual testing mới là nơi lộ ra rủi ro thật.
Ví dụ 2 — Sàn thời trang "LazMall-style": bài học về gộp lỗi và ưu tiên
Một sàn TMĐT thời trang khu vực Đông Nam Á (mô hình tương tự Zalora) làm audit năm 2024. Automated scan báo hơn 5.000 lỗi trên toàn site — một con số khiến ban giám đốc hoảng loạn và định "hoãn vô thời hạn vì quá tốn kém".
Đội tư vấn đã làm một việc cứu vãn tình thế: họ gộp (deduplicate) và phân nhóm theo nguyên nhân gốc. Hóa ra 5.000 lỗi chỉ đến từ khoảng 60 nguyên nhân gốc, và 3 trong số đó — thẻ ảnh sản phẩm thiếu alt trong component grid, thiếu label cho ô tìm kiếm, và contrast của nhãn giá khuyến mãi (chữ đỏ trên nền trắng, tỷ lệ 3.9:1, dưới ngưỡng 4.5:1) — chiếm tới hơn 70% tổng số lỗi. Sửa 3 component đó, hàng nghìn lỗi biến mất cùng lúc.
Bài học rút ra: con số lỗi thô là công cụ gây hoang mang, không phải công cụ ra quyết định. Giá trị của người làm audit nằm ở việc dịch "5.000 lỗi" thành "60 việc cần làm, trong đó 3 việc quan trọng nhất". Đây là kỹ năng phân biệt một auditor giỏi với một người chỉ biết export báo cáo từ tool.
Ví dụ 3 — Trang chi tiết sản phẩm: cái bẫy của "gallery ảnh đẹp"
Trên trang product detail của ChợViệt, có một image gallery cho phép vuốt/bấm để xem nhiều ảnh sản phẩm, cùng phần đánh giá sao và tab "Mô tả / Thông số / Đánh giá". Về mặt hình ảnh, nó rất mượt. Nhưng audit phát hiện ba tầng vấn đề:
- Các thumbnail (ảnh nhỏ) đều dùng chung một alt text
"product image"— screen reader đọc ra "product image, product image, product image..." vô nghĩa. - Số sao đánh giá được vẽ bằng icon
<i>không có text thay thế — người dùng screen reader không biết sản phẩm được mấy sao. - Bộ tab dùng
<div>với JavaScript ẩn/hiện, không córole="tab", không quản lý focus (Bài 24 đã bàn pattern đúng).
Bài học rút ra: severity phải được đọc cả theo ngữ cảnh kinh doanh, không chỉ theo mức WCAG. Một lỗi "Moderate" trên trang product detail của sàn TMĐT có thể đáng ưu tiên hơn một lỗi "Serious" ở trang chính sách bảo mật mà ít ai vào.
Hướng dẫn từng bước
Đây là quy trình audit bạn có thể áp dụng nguyên vẹn cho một dự án thật.
Bước 1 — Xác định phạm vi và tiêu chuẩn. Chốt rõ: audit theo WCAG phiên bản nào, mức nào (thường là 2.1 hoặc 2.2 mức AA), trên nền tảng nào (desktop web, mobile web, app), trình duyệt và screen reader nào. Với ChợViệt: WCAG 2.1 AA, Chrome + Safari, NVDA + VoiceOver.
Bước 2 — Chọn page sample. Liệt kê các user flow tạo giá trị (mua hàng, đăng ký, tra cứu) và các trang lưu lượng cao. Chọn 8–15 màn hình đại diện. Đảm bảo mỗi loại component xuất hiện ít nhất một lần.
Bước 3 — Chạy automated scan. Dùng axe DevTools / Lighthouse / WAVE trên từng trang mẫu. Xuất kết quả. Đây là lớp phủ rộng, làm nhanh trước để có bức tranh tổng thể.
Bước 4 — Kiểm thử thủ công bằng bàn phím. Chỉ dùng Tab, Shift+Tab, Enter, Space, mũi tên. Ghi lại: có bẫy focus không, focus indicator có thấy không, thứ tự tab có logic không, có thao tác nào chỉ dùng chuột được không.
Bước 5 — Kiểm thử bằng screen reader. Đi qua từng flow với NVDA hoặc VoiceOver. Chú ý: heading structure, tên các nút/liên kết, thông báo động (toast, lỗi form), thứ tự đọc.
Bước 6 — Kiểm thử zoom & reflow. Zoom trình duyệt lên 200% và 400%, kiểm tra nội dung có bị cắt, chồng chéo, hay xuất hiện thanh cuộn ngang không (liên quan Bài 31).
Bước 7 — Ghi nhận và gộp lỗi (issue logging & dedup). Mỗi lỗi ghi đủ 6 trường: mô tả, trang/URL, ảnh chụp hoặc bước tái hiện, tiêu chí WCAG vi phạm, severity, và gợi ý sửa. Gộp các lỗi cùng nguyên nhân gốc lại.
Bước 8 — Chấm severity. Dùng thang 4 mức phổ biến:
- Critical/Blocker: chặn hoàn toàn một tác vụ (không thanh toán được).
- Serious: gây khó khăn lớn nhưng có đường vòng.
- Moderate: gây bất tiện, giảm trải nghiệm.
- Minor: lỗi nhỏ, thẩm mỹ.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ chạy tool rồi coi là xong. Như đã nói, automated chỉ bắt 30–40%. Nộp một báo cáo chỉ có output từ Lighthouse là thiếu chuyên nghiệp và bỏ sót đúng những lỗi nghiêm trọng nhất.
Lỗi 2 — Đếm lỗi thô thay vì gộp theo nguyên nhân gốc. "5.000 lỗi" làm khách hàng hoảng và làm mờ đi 3 việc quan trọng thật. Luôn dedup trước khi trình bày.
Lỗi 3 — Không ánh xạ vào WCAG. Nếu bạn nói "nút này khó dùng" mà không chỉ ra nó vi phạm 2.1.1, báo cáo của bạn không có sức nặng pháp lý và developer khó tra cứu cách sửa.
Lỗi 4 — Severity theo cảm tính. Hai auditor chấm cùng một lỗi ra hai kết quả khác nhau thì báo cáo mất uy tín. Hãy định nghĩa thang severity rõ ràng ngay từ đầu và áp dụng nhất quán.
Lỗi 5 — Chỉ báo lỗi, không gợi ý sửa. Một audit chỉ liệt kê vấn đề mà không nói cách khắc phục sẽ bị "ném lại" cho đội dev và nằm im. Mỗi lỗi nên kèm một gợi ý sửa ngắn gọn, có tính khả thi.
Mẹo:
- Bắt đầu bằng automated để có bản đồ tổng thể, nhưng dành phần lớn thời gian cho manual — đó là nơi tạo ra giá trị.
- Quay video màn hình khi tái hiện lỗi blocker bằng screen reader; không gì thuyết phục lãnh đạo bằng việc nghe screen reader "tắc" ngay tại nút thanh toán.
- Ưu tiên component dùng chung: sửa một chỗ, lợi ích lan tỏa toàn site.
- Gắn mỗi cụm lỗi với một chỉ số kinh doanh (trang chuyển đổi, luồng doanh thu) để giúp ban lãnh đạo ra quyết định ngân sách.
Bài tập thực hành
Hãy tự thực hiện một mini-audit để biến lý thuyết thành phản xạ:
- Chọn đối tượng. Vào một sàn TMĐT Việt Nam bất kỳ (Tiki, Shopee, Sendo...) hoặc một cửa hàng online nhỏ. Chọn đúng 3 trang: trang chi tiết sản phẩm, giỏ hàng, và bước đầu của checkout.
- Automated scan. Cài axe DevTools (miễn phí) cho Chrome, chạy trên cả 3 trang, xuất danh sách lỗi.
- Manual keyboard test. Rút chuột ra, chỉ dùng bàn phím đi qua luồng "xem sản phẩm → thêm vào giỏ → vào giỏ hàng → bắt đầu thanh toán". Ghi lại mọi chỗ bạn bị kẹt hoặc mất dấu focus.
- Lập bảng lỗi. Tạo một bảng gồm các cột: Mô tả lỗi | Trang | Tiêu chí WCAG | Severity | Gợi ý sửa. Ghi tối thiểu 8 lỗi và gộp những lỗi trùng nguyên nhân.
- Viết executive summary. Trong đúng 5 câu, tóm tắt cho một "giám đốc" tưởng tượng: tình trạng hiện tại, rủi ro lớn nhất, và 3 việc nên làm trước.
Tóm tắt
Một audit accessibility cho sàn TMĐT không phải là chạy tool, mà là một quy trình có kỷ luật: xác định phạm vi và tiêu chuẩn, chọn page sample đại diện theo luồng doanh thu, kết hợp automated với manual (vì tool chỉ bắt 30–40% vấn đề), ghi nhận và gộp lỗi theo nguyên nhân gốc, chấm severity nhất quán, rồi bàn giao một báo cáo có executive summary và remediation roadmap phân đợt. Qua case study ChợViệt, ta thấy lỗi nguy hiểm nhất (checkout không dùng được bằng bàn phím) là lỗi mà automated scan gần như bỏ qua; qua case study sàn thời trang, ta thấy "5.000 lỗi" thực chất chỉ là 60 nguyên nhân gốc với 3 việc chiếm 70% tác động. Kỹ năng cốt lõi của người làm audit không phải là tìm ra nhiều lỗi, mà là biến mớ lỗi hỗn độn thành một danh sách việc được ưu tiên theo rủi ro và giá trị kinh doanh. Ở Bài 49, chúng ta sẽ mang chính bộ kỹ năng này sang một ngữ cảnh khắt khe hơn — ứng dụng ngân hàng, nơi mức độ tuân thủ và bảo mật đặt ra những thách thức a11y rất riêng.