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 trang landing page cho chiến dịch Tết của một thương hiệu mỹ phẩm. Giao diện đẹp, màu sắc hài hòa, khách hàng gật gù. Nhưng liệu một người dùng khiếm thị dùng screen reader có điền được form đăng ký nhận ưu đãi không? Một người mù màu có phân biệt được nút "Đặt hàng" với nút "Hủy" không? Nếu chỉ nhìn bằng mắt, bạn sẽ không bao giờ biết. Đó là lúc bạn cần công cụ đo lường.
Trong toàn bộ khóa học này, chúng ta đã đi qua rất nhiều nguyên tắc: POUR, WCAG, semantic HTML, ARIA, color contrast, keyboard navigation. Nhưng biết nguyên tắc là một chuyện, kiểm tra xem sản phẩm thực tế có tuân thủ hay không lại là chuyện khác. Bài 37 mở ra chương về testing — và chúng ta bắt đầu từ nơi dễ tiếp cận nhất, ít rào cản nhất: browser extensions (tiện ích mở rộng của trình duyệt).
Vì sao lại bắt đầu từ browser extension? Vì chúng miễn phí (hoặc có bản free đủ dùng), cài trong một phút, chạy ngay trên trang bạn đang xem, và cho kết quả tức thì. Bạn không cần dựng CI/CD pipeline, không cần viết một dòng code test nào. Với một designer hay một frontend developer mới bắt đầu quan tâm đến accessibility, đây chính là cánh cửa đầu tiên — và là công cụ bạn sẽ dùng hằng ngày trong suốt sự nghiệp. Hãy coi bài này như buổi học "làm quen đồ nghề" trước khi bước vào các phương pháp kiểm thử thủ công sâu hơn ở những bài sau.
Khái niệm cốt lõi
Browser extension để kiểm thử accessibility là những công cụ tự động (automated) chạy trên DOM của trang web, phát hiện các vi phạm WCAG có thể "đo được bằng máy". Điều quan trọng nhất bạn cần khắc cốt ghi tâm ngay từ đầu: công cụ tự động chỉ bắt được khoảng 30–40% lỗi accessibility. Phần còn lại (như alt text có ý nghĩa hay không, thứ tự đọc có hợp lý không, keyboard trap ngoài ý muốn) đòi hỏi con người kiểm tra. Đừng bao giờ nghĩ "công cụ báo 0 lỗi nghĩa là trang đã accessible". Đó là sai lầm nguy hiểm nhất.
axe DevTools (Deque) — tiêu chuẩn vàng
axe DevTools là extension nổi tiếng nhất, do Deque Systems phát triển. Nó dựa trên engine mã nguồn mở axe-core — engine này cũng là "lõi" của rất nhiều công cụ khác (Lighthouse, Cypress-axe, Playwright...). Nói cách khác, học axe DevTools bạn sẽ hiểu được "ngôn ngữ chung" của cả hệ sinh thái.
Cách hoạt động: sau khi cài, bạn mở DevTools của Chrome/Firefox (phím F12), sẽ thấy một tab mới tên axe DevTools. Nhấn "Scan all of my page", vài giây sau nó trả về danh sách các violations (vi phạm), được sắp xếp theo mức độ nghiêm trọng (impact): Critical → Serious → Moderate → Minor. Điểm mạnh nhất của axe là mỗi lỗi đều đi kèm: phần tử HTML gây lỗi (highlight ngay trên trang), giải thích vì sao đó là vấn đề, tham chiếu tới tiêu chí WCAG cụ thể, và hướng dẫn cách sửa. Nó gần như "cầm tay chỉ việc".
Một triết lý quan trọng của axe: nó ưu tiên zero false positives (không báo lỗi sai). Nghĩa là nếu axe báo lỗi, gần như chắc chắn đó là lỗi thật. Nhờ vậy bạn có thể tin tưởng và xử lý ngay, không mất thời gian nghi ngờ.
WAVE (WebAIM) — trực quan bằng hình ảnh
WAVE do tổ chức WebAIM phát triển, có cách tiếp cận rất khác. Thay vì đưa danh sách trong DevTools, WAVE phủ các icon trực tiếp lên trang web: icon đỏ là lỗi (errors), icon vàng là cảnh báo (alerts), icon xanh là điểm tốt (features như alt text đã có). Người mới học rất thích WAVE vì nó "nhìn thấy được" — bạn thấy ngay chỗ nào trên giao diện đang có vấn đề, thay vì đọc danh sách trừu tượng. WAVE đặc biệt mạnh ở việc hiển thị cấu trúc heading và landmark, giúp bạn hình dung "bộ xương" của trang.
Lighthouse — có sẵn trong Chrome
Lighthouse được tích hợp sẵn trong Chrome DevTools (tab Lighthouse), không cần cài thêm. Nó chấm điểm accessibility từ 0–100 dựa trên một tập con của axe-core. Ưu điểm: tiện, có sẵn, cho một con số dễ báo cáo với sếp/khách hàng. Nhược điểm: điểm số dễ gây hiểu lầm — đạt 100 điểm Lighthouse KHÔNG có nghĩa trang accessible hoàn toàn, vì nó chỉ kiểm được phần tự động. Hãy dùng Lighthouse như một "nhiệt kế nhanh", không phải "bản án cuối cùng".
IBM Equal Access, ARC Toolkit và các lựa chọn khác
Ngoài ba cái tên trên, còn có IBM Equal Access Accessibility Checker (miễn phí, phân loại theo mức độ và có tính năng gợi ý sửa), ARC Toolkit của TPGi, và Accessibility Insights của Microsoft (nổi bật với tính năng "FastPass" và chế độ hướng dẫn kiểm thử thủ công có cấu trúc). Mỗi công cụ có engine và cách diễn giải hơi khác nhau, nên đôi khi kết quả không hoàn toàn trùng khớp — điều này bình thường.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử mỹ phẩm và cái bẫy "0 lỗi giả"
Một team frontend tại Vietnamcos (giả định) chuẩn bị ra mắt trang chi tiết sản phẩm mới. Bạn frontend lead chạy Lighthouse, được 97/100 accessibility, và tự tin báo cáo "trang đã ổn về accessibility". Nhưng khi QA cài thêm axe DevTools và scan kỹ, họ phát hiện 12 lỗi Serious: các nút chọn tông màu son (color swatch) chỉ được phân biệt bằng màu, không có nhãn text, nên screen reader đọc ra "button, button, button" — người khiếm thị hoàn toàn không biết đang chọn màu nào.
Vì sao Lighthouse bỏ sót? Vì các nút đó về mặt kỹ thuật vẫn "có" nội dung (ảnh nền màu), engine không đủ tinh để biết ý nghĩa bị mất. axe với ruleset đầy đủ hơn đã bắt được aria-label thiếu. Bài học: đừng dựa vào một công cụ duy nhất, và đừng để điểm số cao ru ngủ. Một điểm Lighthouse cao chỉ nói "không có lỗi thô", không nói "trải nghiệm tốt".
Ví dụ 2: Startup fintech Đông Nam Á và quy trình "scan trước mỗi PR"
Một startup ví điện tử ở TP.HCM (khoảng 15 người trong team product) từng bị một khách hàng doanh nghiệp phàn nàn rằng nhân viên khiếm thị của họ không dùng được màn hình xác nhận giao dịch. Sau sự cố, team đặt ra quy tắc đơn giản: mỗi designer và developer đều phải cài axe DevTools, và trước khi tạo pull request, phải scan màn hình mình vừa làm, chụp màn hình kết quả đính kèm vào PR.
Trong ba tháng đầu áp dụng, số lỗi accessibility phát hiện ở khâu review giảm khoảng 60%, vì lỗi được bắt ngay lúc code còn "nóng" thay vì để đến khi audit tổng thể. Chi phí gần như bằng 0 — chỉ là một extension miễn phí và thói quen. Bài học: giá trị lớn nhất của browser extension không nằm ở lần audit hoành tráng cuối dự án, mà ở việc biến kiểm tra thành thói quen thường ngày, "shift-left" — đẩy việc phát hiện lỗi về sớm nhất có thể.
Ví dụ 3: Trang tin tức và sự khác biệt giữa các công cụ
Một biên tập viên kỹ thuật ở một tòa soạn online chạy cùng một bài báo qua ba công cụ. WAVE báo 8 alerts liên quan đến heading bị nhảy cấp (h2 nhảy thẳng xuống h4). axe báo 3 violations về contrast của phần chú thích ảnh màu xám nhạt. Lighthouse cho 88 điểm và chỉ nêu contrast. Ba kết quả khác nhau khiến biên tập viên bối rối: "Cái nào đúng?"
Câu trả lời: cả ba đều đúng, chỉ là nhìn ở góc khác nhau. WAVE mạnh về cấu trúc, axe mạnh về độ chính xác và chi tiết sửa, Lighthouse cho cái nhìn tổng quan nhanh. Bài học: đừng coi các công cụ là đối thủ của nhau. Hãy dùng WAVE để "nhìn tổng thể cấu trúc", axe để "đào sâu và sửa từng lỗi", Lighthouse để "báo cáo con số". Chúng bổ trợ nhau.
Hướng dẫn từng bước
Dưới đây là quy trình chuẩn để kiểm thử một trang bằng browser extension, dùng axe DevTools làm trục chính:
- Cài đặt. Vào Chrome Web Store (hoặc Firefox Add-ons), tìm "axe DevTools", nhấn Add. Tương tự cài WAVE để có góc nhìn thứ hai. Cả hai đều miễn phí ở bản cơ bản.
- Chuẩn bị trạng thái trang. Đây là bước hay bị quên. Extension chỉ quét DOM ở trạng thái hiện tại. Vì vậy, trước khi scan hãy đưa trang về đúng trạng thái cần kiểm: mở modal ra nếu muốn kiểm modal, đăng nhập nếu muốn kiểm trang nội bộ, hiển thị thông báo lỗi form nếu muốn kiểm error message. Trang tĩnh mặc định không phản ánh hết các thành phần động.
- Mở DevTools và chạy scan. Nhấn F12, chọn tab axe DevTools, nhấn "Scan all of my page". Với WAVE, chỉ cần nhấn icon extension trên thanh công cụ, các icon sẽ phủ lên trang.
- Đọc kết quả theo mức độ. Ưu tiên xử lý theo thứ tự Critical → Serious → Moderate → Minor. Với mỗi lỗi, nhấn vào để axe highlight phần tử tương ứng và đọc phần "How to fix".
- Xác minh từng lỗi. Không phải lỗi nào cũng cần sửa y hệt gợi ý — hãy hiểu bản chất trước. Nhấn "Highlight" để nhìn phần tử thật, "Inspect node" để xem trong DOM.
- Ghi nhận và sửa. Xuất kết quả (axe cho phép export), hoặc chụp màn hình đính kèm vào ticket/PR. Sửa xong thì scan lại để xác nhận.
- Kiểm chéo bằng công cụ thứ hai. Sau khi axe báo sạch, chạy WAVE hoặc Lighthouse để bắt những gì công cụ đầu có thể bỏ sót, đặc biệt là cấu trúc heading/landmark.
- Nhớ giới hạn. Kết thúc automated scan không đồng nghĩa với "đã accessible". Đánh dấu rằng trang này còn cần kiểm thủ công bằng bàn phím và screen reader (nội dung của các bài sau).
Lỗi thường gặp & mẹo
Lỗi 1 — Tin tuyệt đối vào con số. Như đã nhấn mạnh, automated tools chỉ bắt 30–40% vấn đề. "0 lỗi" hoặc "100 điểm" chỉ là điều kiện cần, không phải điều kiện đủ. Luôn ghi chú rằng phần còn lại cần con người.
Lỗi 2 — Chỉ scan trạng thái tĩnh. Quên mở modal, dropdown, tab, hay trạng thái sau khi submit form. Rất nhiều lỗi accessibility nằm trong các thành phần động này. Mẹo: lập một checklist các trạng thái cần scan cho mỗi màn hình.
Lỗi 3 — Scan cả trang lớn rồi ngợp. Với trang phức tạp, số lỗi có thể lên hàng trăm và bạn nản. Mẹo: axe cho phép scan một vùng cụ thể ("Scan part of the page") — hãy chia nhỏ theo component để xử lý gọn gàng.
Lỗi 4 — Bỏ qua "Needs review" / alerts. WAVE có mục cảnh báo (màu vàng) và axe có mục "Needs review" cho những thứ máy không chắc chắn. Nhiều người lờ đi. Đây thường là nơi ẩn các vấn đề thật sự cần mắt người — đừng bỏ qua.
Lỗi 5 — Không kiểm chéo. Chỉ dùng một công cụ duy nhất. Mỗi engine có điểm mù riêng. Mẹo vàng: dùng ít nhất hai công cụ khác engine (ví dụ axe + WAVE, vì WAVE không hoàn toàn dùng axe-core).
Mẹo bonus: Tạo thói quen "một phím một scan". Ghim axe DevTools và WAVE lên thanh công cụ. Biến scan thành phản xạ mỗi khi bạn hoàn thành một giao diện, giống như developer chạy linter vậy.
Bài tập thực hành
- Cài đặt bộ đôi. Cài axe DevTools và WAVE lên trình duyệt của bạn.
- Scan trang thật. Chọn một trang web tiếng Việt bạn hay dùng (ví dụ một trang thương mại điện tử hoặc trang tin). Chạy axe DevTools, ghi lại số lượng lỗi theo từng mức Critical/Serious/Moderate/Minor.
- So sánh hai công cụ. Chạy WAVE trên cùng trang đó. Lập một bảng nhỏ so sánh: axe tìm được bao nhiêu lỗi, WAVE bao nhiêu, có lỗi nào chỉ một trong hai bắt được không? Rút ra nhận xét về điểm mạnh mỗi công cụ.
- Kiểm trạng thái động. Tìm một trang có modal hoặc dropdown. Scan lần một khi chưa mở, scan lần hai sau khi mở. So sánh xem có lỗi mới xuất hiện không.
- Chọn 3 lỗi và diễn giải. Với 3 lỗi Serious bất kỳ, viết lại bằng lời của bạn: lỗi này là gì, ảnh hưởng đến ai (người mù? mù màu? dùng bàn phím?), và bạn sẽ sửa thế nào. Đây là bước biến "kết quả máy" thành "hiểu biết của người".
- Chạy Lighthouse trên cùng trang và ghi điểm accessibility. Đối chiếu điểm số đó với số lỗi thực tế axe tìm được — bạn có thấy khoảng cách không?
Tóm tắt
Browser extension là điểm khởi đầu lý tưởng cho hành trình kiểm thử accessibility: miễn phí, nhanh, cho phản hồi tức thì ngay trên trang. Ba công cụ chủ lực bạn nên nắm là axe DevTools (chi tiết, chính xác, gợi ý sửa cụ thể), WAVE (trực quan bằng icon phủ lên trang, mạnh về cấu trúc), và Lighthouse (có sẵn trong Chrome, cho điểm số nhanh để báo cáo).
Điều quan trọng nhất cần nhớ: automated tools chỉ bắt được 30–40% vấn đề accessibility — chúng là điều kiện cần chứ không phải điều kiện đủ. "0 lỗi" không đồng nghĩa với "accessible". Hãy dùng nhiều công cụ khác engine để kiểm chéo, luôn scan cả các trạng thái động (modal, dropdown, form lỗi), và biến việc scan thành thói quen thường ngày thay vì một sự kiện cuối dự án. Quan trọng hơn cả, hãy luôn nhớ rằng phần lớn nhất của bức tranh — thứ tự đọc, ý nghĩa alt text, trải nghiệm bàn phím và screen reader thật — vẫn cần bàn tay và bộ óc con người. Đó chính là những gì các bài kiểm thử thủ công tiếp theo sẽ dẫn bạn đi tới.