Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một tính năng mới, chạy một công cụ quét accessibility, thấy "0 lỗi" và tự tin đưa lên production. Ba tuần sau, một người dùng khiếm thị gửi email phàn nàn rằng họ không thể hoàn tất bước thanh toán. Chuyện gì đã xảy ra? Công cụ tự động chỉ bắt được khoảng 30–40% các vấn đề accessibility. Phần còn lại — thứ tự đọc rối loạn, focus bị mất khi mở modal, nút "Tiếp tục" không có nhãn rõ ràng cho screen reader — chỉ con người mới phát hiện được.
Đây chính là lý do bài học này tồn tại. Ở các bài trước, bạn đã học cách phát hiện từng loại lỗi: dùng browser extension, test bằng bàn phím, test bằng screen reader. Nhưng biết cách kiểm tra một thứ khác hoàn toàn với việc có một chiến lược kiểm tra bền vững cho cả đội, chạy đều đặn theo nhịp (cadence), tích hợp vào quy trình phát triển. Không có chiến lược, accessibility sẽ trở thành việc "ai đó nhớ thì làm" — và trong thực tế, chẳng ai nhớ cả khi deadline cận kề.
Bài này dạy bạn cách thiết kế một hệ thống kiểm tra nhiều lớp (multi-layer testing), phân bổ trách nhiệm rõ ràng, và quan trọng nhất: biết kiểm tra cái gì, khi nào, và ai chịu trách nhiệm. Đây là tư duy của một người làm accessibility chuyên nghiệp, không phải người "sửa lỗi khi có người phàn nàn".
Khái niệm cốt lõi
Vì sao phải kiểm tra nhiều lớp (multi-layer)?
Không có một công cụ hay một phương pháp nào bắt được tất cả lỗi accessibility. Mỗi phương pháp có điểm mù riêng:
- Automated scan (quét tự động) rất giỏi bắt lỗi có quy tắc rõ ràng: thiếu
alt, tương phản màu thấp, thiếulabelcho input. Nhưng nó không biết alt text có ý nghĩa hay không, thứ tự tab có hợp lý không, hay nội dung có dễ hiểu không. - Manual keyboard testing bắt được lỗi focus, thứ tự điều hướng, bẫy focus (focus trap) — những thứ máy không "cảm nhận" được.
- Screen reader testing bắt được lỗi ngữ nghĩa: nút không có tên, thông báo động không được đọc lên, cấu trúc heading vô nghĩa.
- User testing với người khuyết tật thật bắt được vấn đề trải nghiệm mà không ai trong đội nghĩ tới.
Bốn lớp kiểm tra và nhịp (cadence) tương ứng
Hãy hình dung một kim tự tháp. Càng lên cao càng tốn công, càng ít tần suất, nhưng giá trị càng sâu.
Lớp 1 — Automated scan (tự động, mọi commit/PR). Đây là nền móng. Tích hợp công cụ như axe-core, Pa11y hoặc Lighthouse vào CI pipeline, chạy trên mỗi pull request. Rẻ, nhanh, không cần con người can thiệp. Mục tiêu: chặn regression cơ bản trước khi merge.
Lớp 2 — Manual spot-check (bán thủ công, trong quá trình phát triển). Designer và developer tự kiểm tra nhanh khi làm tính năng: nhấn Tab đi hết trang, bật screen reader đọc thử component mới, kiểm tra tương phản màu trong Figma. Nhịp: theo từng tính năng, ngay khi code còn "nóng".
Lớp 3 — Structured manual audit (kiểm tra có cấu trúc, định kỳ). Một người có kỹ năng accessibility (hoặc cả đội theo checklist WCAG) rà soát toàn diện một luồng quan trọng theo lịch: mỗi sprint, mỗi tháng, hoặc trước mỗi release lớn. Đây là lúc dùng checklist WCAG 2.1 AA đầy đủ.
Lớp 4 — User testing với người khuyết tật (sâu, thưa). Mời người dùng thật dùng assistive technology thử sản phẩm. Tốn kém và cần chuẩn bị, nên thường làm mỗi quý hoặc trước các cột mốc lớn.
"Shift-left": kiểm tra càng sớm càng rẻ
Một nguyên tắc kinh tế quan trọng: chi phí sửa một lỗi accessibility tăng theo cấp số nhân theo thời gian nó tồn tại. Sửa trong Figma tốn 1 phút. Sửa trong code review tốn 10 phút. Sửa sau khi lên production, đã có người dùng phàn nàn và có thể dính rủi ro pháp lý — có thể tốn hàng ngày công cộng với thiệt hại uy tín. "Shift-left" nghĩa là đẩy việc kiểm tra về phía sớm trong quy trình — bắt đầu ngay từ khâu thiết kế, không đợi đến cuối.
Định nghĩa "cadence" cho rõ
Cadence là nhịp lặp lại đều đặn của một hoạt động kiểm tra. Điều làm nên chiến lược tốt không phải là "làm nhiều test", mà là mỗi loại test có một nhịp cố định, được ghi vào quy trình, và có người chịu trách nhiệm. Không có cadence, mọi thứ chỉ là ý định tốt.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Việt Nam "thắng" nhờ automated gate
Một công ty e-commerce ở TP.HCM (giả định tên "ShopViet") có đội 12 developer, mỗi ngày merge khoảng 20 pull request. Trước đây họ kiểm tra accessibility "khi rảnh" — tức là gần như không bao giờ. Kết quả: một đợt audit cuối năm phát hiện hơn 340 lỗi WCAG, trong đó 60% là những lỗi lặp đi lặp lại như thiếu alt text và tương phản kém.
Đội quyết định thêm lớp 1 trước: tích hợp axe-core vào GitHub Actions, cấu hình fail CI nếu phát hiện lỗi mức "critical" hoặc "serious". Ban đầu nhiều dev khó chịu vì PR bị chặn, nhưng sau 6 tuần, số lỗi critical mới lọt vào codebase giảm về gần 0. Điểm mấu chốt: họ không cố sửa hết 340 lỗi cũ ngay lập tức (sẽ làm tê liệt sản phẩm), mà chỉ dựng "rào chắn" ngăn lỗi mới, rồi dọn nợ cũ dần theo từng sprint.
Bài học: Automated gate không bắt được mọi thứ, nhưng nó ngăn đội "lùi" — biến accessibility từ việc dọn dẹp một lần thành việc duy trì liên tục. Và chiến lược "ngăn lỗi mới trước, dọn nợ cũ sau" giúp không làm đội quá tải.
Ví dụ 2 — Ứng dụng ngân hàng số ở Singapore và lớp audit định kỳ
Một fintech ở Singapore phát triển app ngân hàng cần tuân thủ tiêu chuẩn accessibility nghiêm ngặt. Họ nhận ra automated scan báo "sạch" nhưng người dùng screen reader vẫn không mở nổi màn hình xác thực OTP — vì thông báo lỗi hiện lên bằng một div không được screen reader đọc.
Họ thiết lập lớp 3 — structured manual audit với nhịp mỗi sprint hai tuần: một QA engineer được đào tạo accessibility sẽ rà soát các luồng ưu tiên cao (đăng nhập, chuyển tiền, xác thực) theo checklist WCAG 2.1 AA. Mỗi lỗi tìm được được ghi thành ticket với mức độ nghiêm trọng và gắn tiêu chí WCAG cụ thể (ví dụ: "vi phạm 4.1.3 Status Messages"). Sau hai quý, thời gian phát hiện một lỗi nghiêm trọng giảm từ trung bình 40 ngày (đợi người dùng phàn nàn) xuống còn dưới 14 ngày (bắt trong sprint).
Bài học: Có những lỗi chỉ audit thủ công có cấu trúc mới bắt được. Nhịp đều đặn theo sprint biến việc kiểm tra thành thói quen, không phải chiến dịch. Và việc gắn mỗi lỗi với tiêu chí WCAG cụ thể giúp cả đội học chuẩn dần.
Ví dụ 3 — Startup nhỏ và chiến lược "vừa đủ"
Không phải đội nào cũng có QA chuyên trách. Một startup edtech 5 người ở Hà Nội không đủ nguồn lực làm cả bốn lớp mỗi tuần. Họ chọn chiến lược tối giản nhưng có cadence rõ:
- Lớp 1: axe DevTools chạy tự động mỗi PR (miễn phí, tự động).
- Lớp 2: mỗi dev tự test bàn phím + tương phản khi làm component mới (5 phút/tính năng).
- Lớp 3: gộp thành một buổi "A11y Friday" cuối mỗi sprint, cả đội cùng rà một luồng theo checklist rút gọn 15 mục.
- Lớp 4: chưa làm — nhưng ghi rõ trong roadmap sẽ thuê user testing khi có ngân sách sau vòng gọi vốn.
Hướng dẫn từng bước
Đây là cách xây dựng chiến lược kiểm tra cho đội của bạn từ con số 0.
Bước 1 — Xác định phạm vi và ưu tiên. Liệt kê các luồng quan trọng nhất (critical user journeys): đăng ký, đăng nhập, thanh toán, tìm kiếm. Bạn không thể test đều mọi trang, nên dồn công sức vào nơi người dùng thực sự đi qua và nơi rủi ro cao nhất.
Bước 2 — Chọn mục tiêu tuân thủ. Thường là WCAG 2.1 mức AA — đây là tiêu chuẩn thực tế được luật pháp nhiều nơi tham chiếu. Ghi rõ mục tiêu để cả đội có cùng "thước đo".
Bước 3 — Dựng lớp 1 (automated) vào CI. Tích hợp axe-core/Pa11y/Lighthouse vào pipeline. Bắt đầu bằng chế độ "cảnh báo" (warning) để đội làm quen, sau vài tuần chuyển sang "chặn" (fail) với các lỗi critical/serious. Đừng chặn bằng mọi lỗi ngay từ đầu — sẽ gây phản ứng ngược.
Bước 4 — Chuẩn hóa lớp 2 (spot-check). Viết một checklist ngắn 8–15 mục cho developer/designer tự kiểm trước khi mở PR: Tab đi hết được không? Focus có nhìn thấy không? Screen reader đọc component mới có hợp lý không? Tương phản đạt chưa? Đưa checklist này vào template pull request.
Bước 5 — Lên lịch lớp 3 (structured audit). Chọn nhịp phù hợp: mỗi sprint hoặc mỗi tháng. Chỉ định người phụ trách (a11y champion). Dùng checklist WCAG đầy đủ. Mỗi phát hiện ghi thành ticket có mức độ nghiêm trọng và tiêu chí WCAG.
Bước 6 — Lập kế hoạch lớp 4 (user testing). Đặt nhịp mỗi quý hoặc theo cột mốc. Kết nối với cộng đồng người khuyết tật hoặc dịch vụ chuyên nghiệp. Nếu chưa đủ nguồn lực, ghi rõ vào roadmap.
Bước 7 — Ghi lại thành tài liệu và phân vai (RACI). Ai chịu trách nhiệm (Responsible), ai duyệt (Accountable), ai tư vấn, ai được thông báo cho mỗi lớp. Chiến lược không được viết ra sẽ biến mất khi người phụ trách nghỉ.
Bước 8 — Đo lường và điều chỉnh. Theo dõi vài chỉ số đơn giản: số lỗi mới lọt qua CI, thời gian trung bình phát hiện lỗi, tỷ lệ luồng đạt WCAG AA. Nếu một lớp không bắt được gì trong nhiều tháng, xem lại cách làm — có thể checklist đã lỗi thời.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ dựa vào automated scan. Đây là sai lầm phổ biến nhất. "Lighthouse 100 điểm accessibility" không có nghĩa trang của bạn accessible. Điểm số đó chỉ phản ánh phần máy kiểm được. Luôn phải có lớp thủ công.
Lỗi 2 — Không có cadence, chỉ có ý định. "Chúng ta sẽ test accessibility" mà không gắn với nhịp cụ thể và người chịu trách nhiệm thì gần như chắc chắn sẽ không xảy ra. Mẹo: gắn mỗi lớp vào một sự kiện có sẵn trong quy trình (mỗi PR, mỗi sprint review, mỗi release).
Lỗi 3 — Chặn CI quá gắt ngay từ đầu. Nếu bạn bật fail với mọi lỗi ngay ngày đầu trên một codebase đầy nợ cũ, đội sẽ nổi loạn hoặc tắt kiểm tra đi. Mẹo: chặn lỗi mới trước, dọn nợ cũ dần theo baseline.
Lỗi 4 — Test một lần rồi thôi (audit-and-forget). Accessibility là trạng thái động: mỗi lần deploy có thể làm hỏng thứ đã đúng. Một cú regression âm thầm còn nguy hiểm hơn lỗi ban đầu. Vì thế cadence lặp lại mới là điểm cốt lõi, không phải một cuộc audit hoành tráng duy nhất.
Lỗi 5 — Không phân biệt mức độ nghiêm trọng. Đổ tất cả lỗi vào một rổ khiến đội tê liệt. Mẹo: phân loại critical/serious/moderate/minor và ưu tiên theo mức độ ảnh hưởng tới người dùng, không theo mức độ dễ sửa.
Mẹo vàng: Bắt đầu nhỏ nhưng thật. Một chiến lược hai lớp được duy trì đều đặn 12 tháng có giá trị hơn một chiến lược bốn lớp bị bỏ dở sau 3 tuần. Sự bền bỉ (consistency) quan trọng hơn sự hoàn hảo.
Bài tập thực hành
- Vẽ kim tự tháp kiểm tra cho một dự án bạn biết. Chọn một website hoặc app (của bạn, công ty bạn, hoặc một sản phẩm bạn dùng hàng ngày). Viết ra bốn lớp kiểm tra và với mỗi lớp, đề xuất: công cụ/phương pháp cụ thể, nhịp (cadence), và người chịu trách nhiệm.
- Soạn checklist spot-check. Viết một checklist 10 mục mà developer có thể tự chạy trong 5 phút trước khi mở pull request. Tập trung vào những thứ automated scan không bắt được (thứ tự tab, focus visible, tên nút cho screen reader...).
- Thiết kế "baseline" cho codebase có nợ cũ. Giả sử một dự án có 200 lỗi accessibility hiện hữu. Hãy viết ra kế hoạch tích hợp automated gate mà không làm tê liệt đội: bạn sẽ chặn cái gì trước, dọn nợ cũ theo nhịp nào?
- Thử tự audit một luồng. Chọn luồng đăng ký của một website bất kỳ. Chạy axe DevTools (lớp 1), rồi tự test bàn phím (lớp 2). Ghi lại: automated bắt được bao nhiêu lỗi, còn bạn tự tìm thêm được bao nhiêu lỗi mà máy bỏ sót? Con số này sẽ cho bạn cảm nhận trực tiếp về "điểm mù" của công cụ tự động.
Tóm tắt
Kiểm tra accessibility hiệu quả không phải là chạy một công cụ và tin vào con số nó trả về. Nó là một hệ thống nhiều lớp, mỗi lớp bắt phần mà lớp khác bỏ sót: automated scan trên mỗi PR làm nền móng, spot-check thủ công trong lúc phát triển, structured audit định kỳ theo sprint/tháng, và user testing với người khuyết tật thật theo quý.
Điều biến những hoạt động rời rạc này thành chiến lược chính là cadence — mỗi lớp có nhịp cố định, gắn vào quy trình sẵn có, và có người chịu trách nhiệm rõ ràng. Hãy shift-left: kiểm tra càng sớm càng rẻ. Hãy bắt đầu nhỏ nhưng bền bỉ: ngăn lỗi mới trước, dọn nợ cũ dần. Và hãy nhớ rằng consistency quan trọng hơn perfection — một cadence khiêm tốn được duy trì lâu dài luôn thắng một kế hoạch hoành tráng bị bỏ dở.
Ở các bài tiếp theo, bạn sẽ đi sâu vào những mảnh ghép cụ thể của chiến lược này: cách gỡ các lỗi web phổ biến, cách xây dựng persona hòa nhập, và cách đưa accessibility vào design system — tất cả đều vận hành tốt hơn khi bạn đã có một chiến lược kiểm tra vững chắc làm bệ đỡ.