Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là QA Lead của một ngân hàng số ở Việt Nam. Ứng dụng mobile banking của bạn hoạt động hoàn hảo trên mọi thiết bị bạn từng test. Nhưng một ngày, bạn nhận được email khiếu nại từ một khách hàng khiếm thị: anh ấy dùng trình đọc màn hình (screen reader) để chuyển khoản, nhưng nút "Xác nhận giao dịch" chỉ được screen reader đọc thành "button" — không có nhãn. Anh ấy không dám bấm vì không biết đó là nút gì. Hậu quả: một khách hàng bị loại khỏi dịch vụ, và nếu chuyện này bị đưa lên báo chí, đó là một khủng hoảng thương hiệu.
Đây chính xác là lý do Accessibility Testing (kiểm thử khả năng tiếp cận) tồn tại. Theo Tổ chức Y tế Thế giới (WHO), khoảng 15% dân số toàn cầu — hơn 1,3 tỷ người — sống với một dạng khuyết tật nào đó. Tại Việt Nam, theo Tổng cục Thống kê, có khoảng 7% dân số (hơn 6,2 triệu người) là người khuyết tật. Đây không phải một nhóm nhỏ để "bỏ qua cho tiện" — đây là một thị trường, một tập khách hàng, và trên hết là những con người có quyền được tiếp cận sản phẩm của bạn.
Với vai trò QA Leadership, bạn không chỉ cần biết cách test accessibility, mà phải biết xây dựng chiến lược để accessibility trở thành một phần của quy trình chất lượng, chứ không phải việc chữa cháy phút chót. Bài này sẽ dạy bạn điều đó.
Khái niệm cốt lõi
Accessibility là gì và ai được hưởng lợi
Accessibility (viết tắt a11y — vì giữa chữ "a" và "y" có 11 ký tự) là khả năng để mọi người, bao gồm cả người khuyết tật, có thể tiếp cận và sử dụng sản phẩm số. Các nhóm khuyết tật cần quan tâm gồm:
- Khiếm thị / mù: dùng screen reader (NVDA, JAWS, VoiceOver), cần độ tương phản màu cao, cần phóng to.
- Khiếm thính / điếc: cần phụ đề (captions), transcript cho nội dung audio/video.
- Khuyết tật vận động: không dùng được chuột, chỉ dùng bàn phím hoặc thiết bị hỗ trợ, cần vùng bấm đủ lớn.
- Khuyết tật nhận thức: cần ngôn ngữ đơn giản, bố cục nhất quán, ít yếu tố gây nhiễu.
WCAG — tiêu chuẩn xương sống
Tiêu chuẩn quốc tế cho accessibility trên web là WCAG (Web Content Accessibility Guidelines) do W3C ban hành. Phiên bản phổ biến nhất hiện nay là WCAG 2.1 và 2.2. WCAG xoay quanh 4 nguyên tắc, viết tắt là POUR:
- Perceivable (Cảm nhận được): Người dùng phải cảm nhận được nội dung — ví dụ ảnh phải có alt text, video phải có phụ đề.
- Operable (Vận hành được): Người dùng phải thao tác được — mọi chức năng phải dùng được bằng bàn phím, không có bẫy focus.
- Understandable (Hiểu được): Nội dung và cách vận hành phải dễ hiểu — thông báo lỗi rõ ràng, hành vi nhất quán.
- Robust (Bền vững): Nội dung phải hoạt động tốt với nhiều công nghệ hỗ trợ khác nhau, kể cả trong tương lai.
Bối cảnh pháp lý — vì sao đây không phải chuyện "làm cho vui"
Accessibility ngày càng là một yêu cầu pháp lý, không phải lựa chọn:
- Mỹ — ADA (Americans with Disabilities Act): Nhiều vụ kiện đã buộc các website (kể cả Domino's Pizza) phải tuân thủ. Nếu sản phẩm của bạn phục vụ khách Mỹ, đây là rủi ro pháp lý thật.
- EU — European Accessibility Act (EAA): Có hiệu lực từ tháng 6/2025, bắt buộc nhiều sản phẩm và dịch vụ số (bao gồm ngân hàng, thương mại điện tử) phải đạt chuẩn accessibility.
- Việt Nam — Luật Người khuyết tật 2010 và các văn bản liên quan yêu cầu tạo điều kiện tiếp cận công nghệ thông tin cho người khuyết tật. Với các cơ quan nhà nước và dự án công, đây là yêu cầu ràng buộc.
Các loại kiểm thử accessibility
Chiến lược tốt kết hợp ba lớp kiểm thử:
- Automated testing (tự động): Dùng công cụ như axe DevTools, WAVE, Lighthouse, Pa11y quét lỗi phổ biến (thiếu alt, tương phản kém, thiếu label). Nhanh, rẻ, nhưng chỉ phát hiện được khoảng 30–40% vấn đề.
- Manual testing (thủ công): Kiểm tra bằng bàn phím (chỉ dùng Tab, Enter, Space, mũi tên), zoom 200%, kiểm tra thứ tự focus, kiểm tra thông báo lỗi. Đây là phần 60–70% còn lại mà automation không bắt được.
- Assistive technology testing: Test thực sự bằng screen reader (NVDA miễn phí trên Windows, VoiceOver có sẵn trên Mac/iPhone), và lý tưởng nhất là test với người dùng khuyết tật thật.
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử và nút "Thêm vào giỏ" vô hình
Một sàn thương mại điện tử tại TP.HCM (giả định tên là ShopViet) chạy automated scan bằng Lighthouse và đạt điểm accessibility 92/100 — trông rất đẹp. Team QA báo cáo "ổn". Nhưng khi một tester thử điều hướng bằng bàn phím, họ phát hiện: nút "Thêm vào giỏ" được làm bằng thẻ <div> có gắn sự kiện onclick, không phải thẻ <button>. Kết quả: người dùng bàn phím và screen reader không thể focus vào nút này — họ không thể mua hàng.
Diễn giải: Lighthouse cho điểm cao vì nó chỉ kiểm tra được những gì máy đọc được. Nó không "bấm thử". Vì div không phải phần tử tương tác gốc, nó bị bỏ khỏi luồng focus mặc định, và automation không đánh giá được rằng đây đáng lẽ phải là nút bấm.
Bài học: Điểm số automation cao không đồng nghĩa với accessible. Chiến lược của bạn phải luôn có lớp manual keyboard testing. Và về mặt kỹ thuật: hãy dùng đúng phần tử HTML ngữ nghĩa (<button>, <a>, <input>) thay vì "chế" nút từ div/span.
Tình huống 2 — Ngân hàng số và bài kiểm tra WCAG trước khi lên sóng
Một ngân hàng số (giả định tên Timo-style) chuẩn bị ra mắt tính năng mở tài khoản online. Vì thuộc lĩnh vực tài chính và có tham vọng phục vụ khách quốc tế, ban lãnh đạo yêu cầu đạt WCAG 2.1 AA trước khi go-live. QA Lead xây một "accessibility gate" trong quy trình release: mọi màn hình phải qua checklist gồm automated scan (axe), keyboard navigation, kiểm tra tương phản màu, và test bằng NVDA.
Trong quá trình test, họ phát hiện các trường nhập OTP dùng màu xám nhạt trên nền trắng — tỷ lệ tương phản chỉ 2.8:1, thấp hơn mức yêu cầu 4.5:1 của WCAG AA cho chữ thường. Người lớn tuổi và người thị lực kém sẽ khó đọc. Team đổi màu, đạt 4.6:1, và pass.
Diễn giải: Bằng cách biến accessibility thành một release criteria (tiêu chí phát hành) thay vì việc làm sau, họ bắt lỗi trước khi khách hàng gặp phải.
Bài học: Với sản phẩm fintech/banking, accessibility gate không phải "nice to have". Nó vừa giảm rủi ro pháp lý, vừa mở rộng tập khách hàng (người cao tuổi là nhóm khách gửi tiết kiệm lớn — và họ rất cần độ tương phản cao và chữ to).
Tình huống 3 — Video khóa học không phụ đề
Một nền tảng học trực tuyến (bối cảnh tương tự chính nền tảng này) đăng hàng nghìn video bài giảng nhưng không có phụ đề. Một học viên khiếm thính phản hồi rằng cô không thể học được các video, dù đã trả tiền. Team ban đầu nghĩ "làm phụ đề thủ công cho hàng nghìn video thì quá tốn kém".
Giải pháp họ chọn: dùng công cụ tạo phụ đề tự động (auto-caption) để có bản nháp, rồi thuê cộng tác viên hiệu đính những video phổ biến nhất trước (ưu tiên theo lượt xem). Chỉ với 20% video được hiệu đính, họ đã phục vụ được 80% lượt xem — và bổ sung transcript giúp SEO tăng traffic tự nhiên rõ rệt.
Bài học: Accessibility không cần "hoàn hảo ngay lập tức". Hãy ưu tiên dựa trên rủi ro và tác động (giống Risk-Based Testing) — làm những phần được dùng nhiều nhất trước.
Hướng dẫn từng bước
Đây là quy trình để xây dựng và triển khai một accessibility testing strategy:
Bước 1 — Xác định mục tiêu tuân thủ. Chọn chuẩn và mức: thông thường là WCAG 2.1 AA. Ghi rõ trong test strategy document rằng đây là baseline. Nếu có yêu cầu pháp lý riêng (EAA, ADA, dự án nhà nước VN), ghi kèm.
Bước 2 — Đánh giá hiện trạng (baseline audit). Chạy automated scan trên các trang/màn hình quan trọng nhất bằng axe DevTools hoặc WAVE. Lập danh sách lỗi và phân loại theo mức độ nghiêm trọng.
Bước 3 — Tích hợp automation vào CI/CD. Đưa công cụ như axe-core hoặc Pa11y vào pipeline để mỗi lần build tự động quét. Đặt ngưỡng: không cho merge nếu phát sinh lỗi accessibility mức critical mới. Đây là cách "shift-left" cho accessibility.
Bước 4 — Thiết lập quy trình manual testing. Với mỗi user flow trọng yếu (đăng nhập, thanh toán, tìm kiếm), tạo checklist manual: điều hướng chỉ bằng bàn phím, kiểm tra focus visible (viền focus có hiện rõ không), zoom 200%, kiểm tra thứ tự đọc hợp lý.
Bước 5 — Test bằng assistive technology. Chọn ít nhất một screen reader (NVDA + Chrome/Firefox là combo phổ biến) và test các flow chính. Lắng nghe xem screen reader đọc ra có đủ nghĩa không.
Bước 6 — Đưa vào Definition of Done. Một tính năng chỉ được coi là "xong" khi qua được checklist accessibility. Điều này biến accessibility từ "việc của QA" thành trách nhiệm chung của cả team (dev, design, QA).
Bước 7 — Đào tạo và tạo văn hóa. Tổ chức workshop ngắn cho dev/design về semantic HTML, alt text, tương phản màu. Phòng bệnh (viết code accessible ngay từ đầu) rẻ hơn chữa bệnh (đi sửa sau) rất nhiều.
Bước 8 — Đo lường và cải tiến. Theo dõi số lỗi accessibility theo thời gian, tỷ lệ trang đạt chuẩn, số khiếu nại từ người dùng. Báo cáo lên lãnh đạo để duy trì cam kết.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin tưởng tuyệt đối vào điểm số automation. Như đã thấy, automation chỉ bắt 30–40% vấn đề. Mẹo: luôn cặp automation với manual keyboard test cho các flow quan trọng.
Lỗi 2 — Coi accessibility là việc làm cuối cùng trước release. Sửa accessibility ở giai đoạn cuối tốn gấp nhiều lần so với làm đúng từ đầu. Mẹo: shift-left — đưa yêu cầu accessibility vào từ khâu thiết kế và acceptance criteria của user story.
Lỗi 3 — "Chế" component từ div/span. Đây là nguyên nhân số một khiến screen reader và bàn phím không dùng được. Mẹo: ưu tiên semantic HTML; nếu buộc phải dùng custom component, phải bổ sung đúng thuộc tính ARIA (role, aria-label, tabindex) — nhưng nhớ quy tắc vàng: "No ARIA is better than bad ARIA" (không dùng ARIA còn hơn dùng sai).
Lỗi 4 — Chỉ dựa vào màu để truyền tải thông tin. Ví dụ báo lỗi form chỉ tô đỏ mà không có text. Người mù màu (khoảng 8% nam giới) không nhận ra. Mẹo: luôn kèm text hoặc biểu tượng bên cạnh màu.
Lỗi 5 — Alt text vô nghĩa. Viết alt="image123.png" hoặc để trống cho ảnh mang thông tin. Mẹo: alt text phải mô tả nội dung và mục đích của ảnh; ảnh trang trí thuần túy thì để alt="" để screen reader bỏ qua.
Mẹo bổ sung cho QA Lead: Hãy tự mình thử "rút chuột ra" và dùng sản phẩm chỉ bằng bàn phím trong 10 phút. Bạn sẽ cảm nhận trực tiếp những rào cản mà báo cáo không bao giờ diễn tả hết được.
Bài tập thực hành
- Audit nhanh: Chọn một website bạn hay dùng (ví dụ trang thương mại điện tử Việt Nam). Cài extension axe DevTools hoặc WAVE, chạy scan trên trang sản phẩm và trang thanh toán. Ghi lại 5 lỗi nghiêm trọng nhất và phân loại chúng theo nguyên tắc POUR.
- Keyboard-only challenge: Cũng trên website đó, rút chuột (hoặc tự cấm dùng chuột), thử hoàn thành luồng "tìm sản phẩm → thêm vào giỏ → đến trang thanh toán" chỉ bằng bàn phím. Ghi lại: focus có hiện rõ không? Có bị "kẹt" ở đâu không? Có nút nào không focus được không?
- Kiểm tra tương phản: Dùng công cụ WebAIM Contrast Checker, kiểm tra 3 cặp màu chữ/nền trên trang đó. Cặp nào không đạt 4.5:1? Đề xuất màu thay thế đạt chuẩn AA.
- Viết chiến lược thu nhỏ: Giả sử bạn là QA Lead cho một ứng dụng mobile banking. Viết một trang A4 nêu: mục tiêu tuân thủ, 3 loại kiểm thử sẽ dùng, accessibility gate trong quy trình release, và cách đo lường.
Tóm tắt
Accessibility Testing không phải một hạng mục kỹ thuật nhỏ mà là một phần cốt lõi của chất lượng sản phẩm và trách nhiệm của người làm QA Leadership. Với 15% dân số toàn cầu và hơn 6 triệu người Việt Nam sống với khuyết tật, cộng thêm áp lực pháp lý (ADA, EAA, Luật Người khuyết tật VN) và lợi ích SEO, accessibility vừa là nghĩa vụ đạo đức, vừa là bài toán kinh doanh thông minh.
Nền tảng kỹ thuật là WCAG với 4 nguyên tắc POUR và mục tiêu thực tế là mức AA. Một chiến lược tốt kết hợp ba lớp: automation (nhanh nhưng chỉ bắt 30–40%), manual testing (bàn phím, zoom, tương phản), và assistive technology testing (screen reader, người dùng thật). Điều quan trọng nhất với vai trò lãnh đạo là shift-left accessibility — đưa nó vào từ thiết kế, gắn vào Definition of Done, dựng accessibility gate trong release, và xây dựng văn hóa nơi accessibility là trách nhiệm chung. Đừng bao giờ tin tuyệt đối vào một con điểm; hãy tự mình rút chuột ra và trải nghiệm sản phẩm như những người dùng mà bạn đang phục vụ.