Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ra mắt một ứng dụng ngân hàng số rất đẹp. Nút bấm bo tròn tinh tế, màu gradient tím-xanh sang trọng, animation mượt mà. Bạn tự hào lắm. Nhưng có một người dùng tên anh Tuấn — một nhân viên văn phòng ở Hà Nội bị khiếm thị hoàn toàn — mở app lên bằng trình đọc màn hình VoiceOver. Anh vuốt ngón tay qua màn hình, và điện thoại chỉ đọc lên: "Button. Button. Button. Image. Button." Không một chữ nào cho anh biết nút nào là "Chuyển tiền", nút nào là "Đăng xuất". Với anh Tuấn, ứng dụng đẹp đẽ của bạn hoàn toàn vô dụng — thậm chí nguy hiểm, vì anh có thể chuyển nhầm tiền mà không biết.
Đây chính là lý do accessibility testing (kiểm thử khả năng tiếp cận, viết tắt là a11y — vì giữa chữ "a" và "y" của từ "accessibility" có 11 ký tự) tồn tại. Trong bài này, chúng ta sẽ đi sâu vào một mảng thường bị QA Việt Nam bỏ quên nhưng ngày càng quan trọng: làm sao kiểm thử một ứng dụng mobile để đảm bảo người khuyết tật có thể dùng được nó một cách bình đẳng.
Con số đáng suy nghĩ: theo Tổng cục Thống kê, Việt Nam có khoảng 6 triệu người khuyết tật (chiếm hơn 6% dân số), trong đó hàng triệu người gặp khó khăn về thị giác, thính giác hoặc vận động. Luật Người khuyết tật 2010 (Điều 43) quy định rõ trách nhiệm bảo đảm người khuyết tật được tiếp cận thông tin và công nghệ. Ngoài yếu tố pháp lý và đạo đức, còn có yếu tố kinh doanh: một app tiếp cận tốt thường có UX tổng thể tốt hơn cho tất cả người dùng — kể cả người sáng mắt đang dùng điện thoại dưới nắng gắt.
Khái niệm cốt lõi
Accessibility là gì và không phải là gì
A11y không chỉ dành cho người mù. Nó phục vụ nhiều nhóm: người khiếm thị (mù hoàn toàn hoặc thị lực kém), người khiếm thính, người khó vận động tay (run tay, liệt), người bị rối loạn nhận thức, và cả nhóm "khuyết tật tình huống" — ví dụ người đang bế con nên chỉ dùng được một tay, hay người lớn tuổi mắt kém đang đọc chữ nhỏ.
Với mobile, có bốn trụ cột kiểm thử chính bạn cần nắm:
1. Screen reader (trình đọc màn hình). Trên iOS là VoiceOver, trên Android là TalkBack. Đây là công cụ đọc to nội dung màn hình cho người khiếm thị. Mỗi phần tử UI cần có "nhãn" (label) mô tả đúng chức năng. Người dùng điều hướng bằng cách vuốt trái/phải để nhảy giữa các phần tử, và nhấn đúp để kích hoạt.
2. Kích thước chạm (touch target). Ngón tay không chính xác như con trỏ chuột. Apple khuyến nghị tối thiểu 44x44 điểm (pt), Google khuyến nghị 48x48 dp. Nút quá nhỏ khiến người run tay hoặc ngón to bấm trượt liên tục.
3. Tương phản màu (color contrast). Chuẩn WCAG (Web Content Accessibility Guidelines) yêu cầu tỷ lệ tương phản giữa chữ và nền tối thiểu 4.5:1 cho chữ thường và 3:1 cho chữ lớn. Chữ xám nhạt trên nền trắng nhìn "sang" nhưng người thị lực kém đọc không nổi.
4. Kích thước chữ động (Dynamic Type / Font Scaling). Người dùng có thể tăng cỡ chữ hệ thống lên 200%. App tốt phải giãn theo, không được cắt chữ hay chồng lấp layout.
Các khái niệm kỹ thuật quan trọng
- accessibilityLabel: nhãn mô tả phần tử. Ví dụ nút hình cái thùng rác cần label "Xóa", không phải "trash icon".
- accessibilityHint: gợi ý hành động sẽ xảy ra, ví dụ "Nhấn đúp để chuyển tiền".
- accessibilityTraits / role: cho screen reader biết đây là button, header, hay đường link.
- Focus order (thứ tự tiêu điểm): khi vuốt, con trỏ screen reader phải đi theo trình tự logic (trên xuống, trái sang phải), không nhảy lung tung.
- Live region / announcement: khi nội dung thay đổi động (ví dụ "Đã thêm vào giỏ hàng"), screen reader cần đọc thông báo đó ra.
WCAG và mức tuân thủ
WCAG 2.1 chia ba mức: A (tối thiểu), AA (tiêu chuẩn phổ biến, đa số doanh nghiệp và quy định pháp lý nhắm tới), AAA (cao nhất, khó đạt toàn diện). Là QA, mục tiêu thực tế của bạn thường là đạt mức AA. Bạn không cần thuộc lòng 78 tiêu chí, nhưng nên nhớ nhóm nguyên tắc POUR: Perceivable (cảm nhận được), Operable (thao tác được), Understandable (hiểu được), Robust (bền vững với công nghệ hỗ trợ).
Tình huống thực tế
Ví dụ 1 — App gọi xe và cái nút "X" vô hình
Một startup gọi xe ở TP.HCM (gọi tạm là "GoRide") nhận được phản hồi 1 sao từ một hội người khiếm thị. Khi QA của họ bật VoiceOver và thử đặt xe, mọi thứ ổn cho đến bước cuối: sau khi tài xế nhận cuộc, hiện lên một màn hình có nút "X" để hủy chuyến ở góc trên. Vấn đề là lập trình viên đã dùng một UIImageView có gắn tapGestureRecognizer thay vì một UIButton thật. Kết quả: VoiceOver hoàn toàn không "thấy" nút này — nó không có trait button, không có label. Người khiếm thị bị mắc kẹt trong màn hình, không cách nào hủy chuyến, và bị tính tiền phí hủy sau đó vì để tài xế chờ quá lâu.
Bài học rút ra: những phần tử tương tác "chế cháo" từ view tĩnh là kẻ thù số một của a11y. Là QA, mỗi khi thấy một icon có thể chạm được, hãy tự hỏi: "VoiceOver có đọc được nó không? Nó có được đánh dấu là button không?" GoRide sau đó thêm quy tắc: mọi phần tử tương tác bắt buộc phải là control gốc (UIButton/Button) hoặc có accessibilityTraits = .button.
Ví dụ 2 — Sàn thương mại điện tử và bài toán tương phản màu
Một sàn TMĐT lớn ở Đông Nam Á (kiểu Shopee/Lazada) chạy chiến dịch sale với chữ giá "GIẢM 50%" màu cam nhạt (#FF9E80) trên nền hồng của banner (#FFE0E6). Nhìn trên màn hình văn phòng thì "hồng cam pastel" khá xinh. Nhưng khi QA chạy công cụ đo tương phản, tỷ lệ chỉ đạt 1.8:1 — thấp hơn xa ngưỡng 4.5:1. Đội marketing phản đối vì "màu thương hiệu". QA đã làm điều thông minh: thay vì tranh cãi cảm tính, họ chụp màn hình banner rồi mô phỏng qua bộ lọc mù màu (khoảng 8% nam giới Việt Nam bị mù màu đỏ-lục ở mức nào đó) và chụp lại dưới ánh sáng chói. Con số giảm chuyển đổi trên nhóm người dùng lớn tuổi được đưa ra làm bằng chứng. Cuối cùng team đổi chữ giá sang màu đỏ đậm #C62828 (tương phản 5.9:1), giữ nền hồng — vừa đẹp vừa đọc được.
Bài học rút ra: a11y không phải cuộc chiến giữa QA và designer. Dùng số liệu đo được (contrast ratio) và mô phỏng trực quan để thuyết phục sẽ hiệu quả hơn nhiều so với nói "nhìn khó đọc lắm".
Ví dụ 3 — Ứng dụng y tế và font scaling gãy layout
Một app đặt lịch khám bệnh (giả định "MedBook") có nhiều người dùng lớn tuổi. Bác lớn tuổi thường bật cỡ chữ hệ thống rất to. Trong một lần regression, tester để cỡ chữ ở mức Accessibility Extra Large trên iOS và mở màn hình xác nhận lịch. Kết quả: dòng "Xác nhận đặt lịch lúc 14:30 ngày 20/07" bị cắt cụt thành "Xác nhận đặt lịch lúc 14:3...", và nút "Đồng ý" bị chữ tràn đè lên nút "Hủy" khiến người dùng bấm nhầm. Đây là lỗi cực kỳ nguy hiểm với app y tế. Nguyên nhân: layout dùng chiều cao cố định (fixed height) thay vì để container tự co giãn.
Bài học rút ra: luôn đưa "test ở cỡ chữ lớn nhất" vào bộ test case cho các màn hình quan trọng, đặc biệt app phục vụ người cao tuổi. Đây là loại lỗi mà nếu chỉ test ở cỡ chữ mặc định thì bạn sẽ không bao giờ phát hiện.
Hướng dẫn từng bước
Dưới đây là quy trình kiểm thử a11y thủ công cơ bản bạn có thể áp dụng ngay cho bất kỳ màn hình nào.
Bước 1 — Bật screen reader và "đi mù". Trên iOS: Settings → Accessibility → VoiceOver (mẹo: gán vào Accessibility Shortcut bằng cách nhấn 3 lần nút nguồn để bật/tắt nhanh). Trên Android: Settings → Accessibility → TalkBack. Sau đó thử hoàn thành một luồng nghiệp vụ chính (ví dụ đăng nhập → chọn sản phẩm → thanh toán) mà không nhìn màn hình, chỉ nghe. Nếu bạn làm được, người khiếm thị nhiều khả năng cũng làm được.
Bước 2 — Kiểm tra nhãn của mọi phần tử. Vuốt qua từng phần tử. Ghi lại những phần tử bị đọc sai: icon đọc là "image", nút đọc trống, hay label bằng tiếng Anh trong app tiếng Việt ("Submit" thay vì "Gửi"). Đặc biệt chú ý icon-only button (nút chỉ có biểu tượng).
Bước 3 — Kiểm tra thứ tự tiêu điểm (focus order). Vuốt liên tục sang phải và xem con trỏ có đi theo trình tự hợp lý không. Lỗi thường gặp: sau header nhảy thẳng xuống footer rồi mới quay lên nội dung giữa.
Bước 4 — Đo tương phản màu. Chụp màn hình, dùng công cụ như Colour Contrast Analyser (TPGi, miễn phí) hoặc Stark (plugin Figma/Chrome) để đo tỷ lệ chữ/nền. Ghi lại các cặp màu dưới 4.5:1.
Bước 5 — Test kích thước chạm. Bật tính năng hiển thị kích thước phần tử (Accessibility Inspector trên Xcode / Layout Inspector trên Android Studio) và kiểm tra các nút có đạt 44pt/48dp không, đặc biệt các icon nhỏ như "đóng", "yêu thích".
Bước 6 — Test dynamic type / font scaling. Đẩy cỡ chữ hệ thống lên mức lớn nhất và duyệt lại các màn hình quan trọng, tìm chữ bị cắt, bị chồng, hoặc layout gãy.
Bước 7 — Chạy công cụ tự động để quét diện rộng.
Dùng Accessibility Scanner (Google, app miễn phí trên Play Store) cho Android — nó quét màn hình và gợi ý lỗi label, contrast, touch target. Với Espresso, dùng AccessibilityChecks.enable(). Với iOS/Appium có thể tích hợp thư viện kiểm tra. Lưu ý: công cụ tự động chỉ bắt được khoảng 30–40% lỗi a11y; phần còn lại — như label có đúng ngữ cảnh không — vẫn cần con người.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi công cụ tự động là đủ. Accessibility Scanner báo "không có lỗi" không có nghĩa app dùng được với screen reader. Nó không hiểu được label "Nút 1" là vô nghĩa hay không. Luôn kết hợp test thủ công bằng chính screen reader.
Lỗi 2 — Label trùng lặp hoặc thừa. Một ảnh trang trí thuần túy (ví dụ họa tiết nền) không nên được screen reader đọc — hãy đánh dấu nó là ẩn khỏi accessibility (accessibilityElementsHidden / importantForAccessibility="no"). Ngược lại, đừng để screen reader đọc cả label lẫn hint trùng ý gây rườm rà.
Lỗi 3 — Chỉ dựa vào màu để truyền tải thông tin. Ô input báo lỗi chỉ bằng viền đỏ thì người mù màu không thấy. Luôn kèm text hoặc icon: "Số điện thoại không hợp lệ".
Lỗi 4 — Quên trạng thái động. Khi bấm "Thêm vào giỏ", nếu màn hình không phát announcement, người khiếm thị không biết hành động đã thành công. Test cả các thông báo toast, badge cập nhật số lượng.
Mẹo vàng: Viết a11y test case như một phần của Definition of Done, không phải "sẽ làm sau". Với mỗi màn hình mới, thêm checklist 5 dòng: (1) VoiceOver/TalkBack đọc đúng mọi nút? (2) Contrast ≥ 4.5:1? (3) Touch target ≥ 44pt? (4) Font lớn không gãy? (5) Có phần tử tương tác nào bị screen reader bỏ sót? Checklist ngắn được làm mỗi lần tốt hơn checklist dài không ai làm.
Mẹo về ngôn ngữ tiếng Việt: đảm bảo screen reader đọc đúng dấu tiếng Việt và số. Có trường hợp label để "SĐT" thì VoiceOver đọc thành "ét-đê-tê" khó hiểu; nên viết đầy đủ "Số điện thoại" trong accessibilityLabel dù trên UI vẫn hiển thị "SĐT".
Bài tập thực hành
- Đi mù thực chiến: Chọn một app bạn hay dùng (ví dụ app ngân hàng hoặc ví điện tử). Bật VoiceOver (iOS) hoặc TalkBack (Android), tắt/che màn hình, và thử thực hiện một giao dịch từ đầu đến cuối chỉ bằng nghe. Ghi lại mọi điểm bạn bị "kẹt" — mỗi điểm kẹt là một bug a11y tiềm năng.
- Săn lỗi tương phản: Chụp 3 màn hình bất kỳ trong một app, dùng công cụ Colour Contrast Analyser hoặc Stark đo tỷ lệ tương phản của tất cả text. Lập bảng: phần tử | màu chữ | màu nền | tỷ lệ | đạt/không đạt AA.
- Test font scaling: Đẩy cỡ chữ hệ thống lên mức lớn nhất, duyệt qua màn hình đăng nhập và màn hình thanh toán của một app. Chụp lại mọi chỗ chữ bị cắt hoặc layout gãy, viết thành bug report chuẩn (bước tái hiện + kết quả mong đợi + kết quả thực tế + ảnh).
- Viết checklist: Soạn một a11y checklist gồm 8–10 mục để đội của bạn áp dụng cho mỗi màn hình mới trước khi release. Ưu tiên các mục kiểm được nhanh trong dưới 5 phút.
Tóm tắt
Accessibility testing không phải là công việc "làm cho có" hay chỉ để tránh kiện tụng — nó là thước đo mức độ chuyên nghiệp và bao trùm của một sản phẩm. Với khoảng 6 triệu người khuyết tật tại Việt Nam và yêu cầu tiếp cận thông tin trong Luật Người khuyết tật 2010, một QA giỏi ngày nay bắt buộc phải nắm được kỹ năng này.
Những điều cốt lõi cần nhớ: (1) Bốn trụ cột kiểm thử là screen reader, touch target, color contrast và dynamic type. (2) Nhắm tới chuẩn WCAG mức AA — chữ tương phản ≥ 4.5:1, nút chạm ≥ 44pt/48dp. (3) Công cụ tự động (Accessibility Scanner, AccessibilityChecks) giúp quét nhanh nhưng chỉ bắt được 30–40% lỗi; test thủ công bằng chính VoiceOver/TalkBack là không thể thay thế. (4) Đừng chỉ dùng màu để truyền thông tin, và luôn test ở cỡ chữ lớn nhất. (5) Đưa a11y vào Definition of Done bằng một checklist ngắn gọn làm được mỗi lần.
Cách kiểm tra tốt nhất vẫn là câu hỏi giản dị mà anh Tuấn ở đầu bài đặt ra: "Nếu tôi không nhìn thấy màn hình, tôi có dùng được app này không?" Trả lời được câu đó, bạn đã là một Mobile QA thực thụ quan tâm đến từng người dùng.