Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa release một ứng dụng ngân hàng số. App chạy mượt, không crash, mọi tính năng đều "hoạt động đúng" theo checklist test truyền thống. Nhưng rồi một khách hàng khiếm thị gửi phản hồi: "Tôi không thể chuyển tiền được vì nút Xác nhận không đọc được bằng VoiceOver." Hoặc một người dùng ở vùng sóng yếu than phiền: "Mỗi lần mở app, màn hình đứng hình 4 giây mới hiện số dư." Cả hai trường hợp này đều là bug — nhưng chúng thường lọt qua vì đội QA không kiểm thử accessibility (khả năng tiếp cận) và performance (hiệu năng).
Đây là hai khía cạnh mà rất nhiều QA mới vào nghề bỏ quên, vì chúng "vô hình" trong test chức năng thông thường. Bạn không nhìn thấy accessibility bằng mắt thường khi tap qua các màn hình, và bạn cũng không cảm nhận rõ độ giật lag nếu chỉ test trên chiếc iPhone 15 Pro đời mới. Nhưng với người dùng thực tế — nhất là ở thị trường Việt Nam với đủ loại thiết bị từ Redmi giá rẻ đến iPhone cũ, cùng mạng 3G/4G chập chờn — hai yếu tố này quyết định trực tiếp việc họ ở lại hay xóa app.
Bài học này giúp bạn xây nền tảng tư duy về accessibility và performance ở góc độ mobile QA: hiểu screen reader hoạt động ra sao, biết dựng một checklist accessibility căn bản, và nắm những chỉ số hiệu năng đầu tiên cần quan sát. Đây là bài mang tính tổng quan, đặt móng cho các bài chuyên sâu hơn ở phần sau khóa học (a11y testing chi tiết ở Bài 13, performance FPS/frozen frames ở Bài 14). Ở đây, mục tiêu là bạn "mở mắt" ra rằng chất lượng mobile không chỉ là "app không lỗi".
Khái niệm cốt lõi
Mobile Accessibility là gì?
Accessibility (thường viết tắt a11y — vì giữa chữ "a" và "y" có 11 ký tự) là khả năng những người khuyết tật vẫn sử dụng được ứng dụng một cách bình đẳng. Khuyết tật ở đây rất đa dạng: khiếm thị (mù hoàn toàn hoặc thị lực kém), khiếm thính, khó khăn vận động (không cầm máy vững, khó tap chính xác), rối loạn nhận thức, hoặc thậm chí là mù màu.
Đừng nghĩ đây là nhóm nhỏ. Theo Tổ chức Y tế Thế giới (WHO), khoảng 15% dân số toàn cầu sống với một dạng khuyết tật nào đó. Ở Việt Nam, con số ước tính là hơn 6 triệu người khuyết tật. Chưa kể "khuyết tật tình huống" — ví dụ bạn đang bế con nên chỉ dùng được một tay, hoặc đang ngoài nắng chói không nhìn rõ màn hình. Test a11y tốt thì trải nghiệm cho tất cả mọi người đều tốt hơn.
Screen Readers — công cụ trung tâm
Với người khiếm thị, screen reader (trình đọc màn hình) là "đôi mắt" của họ. Screen reader đọc to nội dung trên màn hình và cho phép người dùng điều hướng bằng cử chỉ vuốt thay vì tap chính xác vào vị trí. Hai screen reader bạn bắt buộc phải biết:
- VoiceOver trên iOS — tích hợp sẵn trong hệ điều hành, bật tại Settings → Accessibility → VoiceOver. Khi bật, người dùng vuốt phải/trái để di chuyển giữa các phần tử, và nghe screen reader đọc nội dung từng phần tử.
- TalkBack trên Android — tương đương VoiceOver, tích hợp sẵn, bật tại Settings → Accessibility → TalkBack.
Accessibility Checklist căn bản
Đây là danh sách kiểm tra tối thiểu mà mọi mobile QA nên thuộc lòng:
- Ảnh và icon có nhãn mô tả: mọi hình ảnh mang thông tin và mọi nút dạng icon phải có accessibility label. Ảnh trang trí thuần túy thì nên đánh dấu "ẩn với screen reader" để tránh nhiễu.
- Độ tương phản màu (contrast ratio) đạt chuẩn: chữ trên nền phải đủ tương phản. Chuẩn WCAG AA yêu cầu tỉ lệ tối thiểu 4.5:1 cho chữ thường và 3:1 cho chữ lớn.
- Vùng chạm (touch target) đủ lớn: Apple khuyến nghị tối thiểu 44x44 điểm, Google khuyến nghị 48x48 dp. Nút quá nhỏ khiến người khó vận động không tap trúng.
- Thứ tự điều hướng (focus order) hợp lý: khi vuốt qua bằng screen reader, thứ tự phải logic từ trên xuống, trái sang phải — không nhảy lung tung.
- Không phụ thuộc duy nhất vào màu sắc: ví dụ ô nhập sai không được chỉ tô viền đỏ, mà cần thêm chữ hoặc icon báo lỗi (vì người mù màu không phân biệt được).
- Hỗ trợ phóng to chữ (Dynamic Type): khi người dùng tăng cỡ chữ hệ thống, layout không được vỡ hoặc cắt mất chữ.
Mobile Performance là gì?
Performance là mức độ ứng dụng phản hồi nhanh và mượt. Với người dùng, nó thể hiện qua ba cảm nhận: app mở nhanh không, cuộn có mượt không, và bấm vào có phản hồi ngay không. Ở góc độ QA, ta lượng hóa nó bằng các chỉ số:
- App launch time (thời gian khởi động): thời gian từ lúc chạm icon đến khi màn hình đầu tiên dùng được. Google khuyến nghị dưới 2 giây với "cold start".
- Frame rate (FPS): số khung hình mỗi giây khi cuộn hoặc animation chạy. Mục tiêu là 60 FPS (hoặc 120 trên máy ProMotion). Rớt xuống dưới 60 gây cảm giác giật.
- Time to interactive: thời gian đến khi người dùng thực sự thao tác được, không chỉ nhìn thấy giao diện tĩnh.
- Mức tiêu thụ tài nguyên: CPU, bộ nhớ (memory), pin, và dung lượng mạng.
Tình huống thực tế
Tình huống 1 — Nút "Chuyển tiền" vô hình với người khiếm thị (ngân hàng số)
Một ngân hàng số tại Việt Nam (gọi là "TechBank") ra mắt tính năng chuyển khoản nhanh. Đội dev dùng icon mũi tên cho nút xác nhận, trông rất đẹp và tối giản. QA test chức năng: nhập số tiền, chọn người nhận, bấm nút — giao dịch thành công. Tick xanh, pass.
Ba tuần sau, một khách hàng khiếm thị khiếu nại lên tổng đài: ông không thể hoàn tất chuyển tiền. Đội QA bật VoiceOver để tái hiện, và phát hiện: khi vuốt tới nút xác nhận, VoiceOver chỉ đọc "Button" — không hề nói đó là nút chuyển tiền. Người dùng không dám bấm vào một nút vô danh khi đang thao tác với tiền của mình.
Bài học: icon-only button là "cái bẫy" a11y phổ biến nhất. Bug này không bao giờ lộ ra nếu bạn chỉ test bằng mắt. Sau vụ này, TechBank thêm bước "test VoiceOver/TalkBack cho mọi màn hình có giao dịch tiền" vào quy trình release bắt buộc, và bổ sung accessibility label cho toàn bộ icon button. Chi phí sửa chỉ vài dòng code, nhưng nếu để lâu có thể thành khủng hoảng truyền thông về "phân biệt đối xử".
Tình huống 2 — App giật lag trên máy tầm trung (thương mại điện tử)
Một sàn thương mại điện tử Đông Nam Á (giả định tên "ShopSEA") tung màn hình danh sách sản phẩm mới với ảnh chất lượng cao và hiệu ứng cuộn đẹp mắt. Đội QA test trên iPhone 14 và Samsung Galaxy S23 — mượt hoàn hảo, 60 FPS. Release.
Vài ngày sau, tỉ lệ thoát (bounce rate) ở màn hình danh sách tăng vọt 18%, tập trung ở nhóm người dùng Android giá rẻ. Đội performance dựng lại test trên chiếc Redmi 9A (RAM 2GB) — thiết bị rất phổ biến ở phân khúc bình dân Việt Nam và Indonesia. Kết quả: khi cuộn, frame rate rớt xuống 22-30 FPS, ảnh load chậm khiến màn hình giật cục. Nguyên nhân: mỗi ảnh sản phẩm được tải ở độ phân giải full 2000px rồi mới thu nhỏ trên client, ngốn bộ nhớ và CPU khủng khiếp trên máy yếu.
Bài học: hiệu năng phải được đo trên "thiết bị thật của người dùng thật", không phải máy xịn trong túi kỹ sư. Sau đó ShopSEA đưa ra chính sách "device matrix" gồm ít nhất một máy Android tầm thấp trong mọi đợt test performance, và yêu cầu server trả ảnh đã được resize sẵn theo kích thước hiển thị. Bounce rate quay về mức cũ trong hai tuần.
Tình huống 3 — Chữ vỡ layout khi người dùng phóng to cỡ chữ (ứng dụng đọc tin)
Một ứng dụng đọc tin tức có nhiều người dùng lớn tuổi. Nhóm này thường bật cỡ chữ hệ thống lớn nhất để đọc cho đỡ mỏi mắt. QA test ở cỡ chữ mặc định — mọi thứ đẹp đẽ. Nhưng khi một tester tình cờ bật Dynamic Type lên mức "Accessibility Large", tiêu đề bài báo bị cắt mất nửa dòng, nút "Đọc tiếp" tràn ra khỏi màn hình và không bấm được.
Bài học: accessibility không chỉ dành cho screen reader. Hỗ trợ cỡ chữ động là một dạng a11y ảnh hưởng đến lượng lớn người dùng cao tuổi — nhóm ngày càng đông ở Việt Nam. QA cần thêm việc test app ở nhiều cỡ chữ hệ thống, đặc biệt các mức lớn nhất, vào checklist chuẩn.
Hướng dẫn từng bước
Đây là quy trình thực hành để bạn bắt đầu test accessibility và performance ngay hôm nay.
Phần A — Kiểm thử accessibility với screen reader:
- Bật screen reader. Trên iPhone: Settings → Accessibility → VoiceOver → On. Trên Android: Settings → Accessibility → TalkBack → On. Mẹo: thiết lập phím tắt (triple-click nút nguồn/home) để bật tắt nhanh, vì lúc đầu bạn sẽ thấy hơi bối rối khi thao tác.
- Học cử chỉ cơ bản. Vuốt phải để tới phần tử tiếp theo, vuốt trái để quay lại, double-tap để kích hoạt phần tử đang được chọn. Nhắm mắt lại và thử điều hướng — đó chính là trải nghiệm của người khiếm thị.
- Đi qua toàn bộ luồng chính. Vuốt qua từng phần tử trên màn hình và lắng nghe. Ghi lại mọi phần tử bị đọc là "Button", "Image" trống rỗng, hoặc bị bỏ qua hoàn toàn.
- Kiểm tra thứ tự focus. Đảm bảo thứ tự vuốt logic, không nhảy cóc. Kiểm tra rằng thông báo lỗi, popup, toast đều được screen reader thông báo.
- Chuẩn bị device matrix. Tối thiểu ba máy: một iPhone, một Android cao cấp, và một Android tầm trung/thấp (ví dụ Redmi hoặc Galaxy A-series). Đây là bước quan trọng nhất.
- Đo thời gian khởi động. Force-quit app, đóng hết ứng dụng nền, rồi bấm mở và đếm thời gian tới khi màn hình dùng được. Lặp lại 3-5 lần và lấy trung bình.
- Quan sát độ mượt khi cuộn. Cuộn nhanh qua các danh sách dài, để ý hiện tượng giật (jank). Trên Android, bật Developer Options → Profile GPU Rendering để nhìn thanh biểu đồ frame time trực quan.
- Test trong điều kiện thực tế. Bật giới hạn mạng (Network Link Conditioner trên iOS, hoặc bóp băng thông qua proxy) để mô phỏng mạng 3G/4G yếu. Xem app có hiển thị trạng thái loading tử tế hay chỉ đứng hình.
- Ghi nhận và báo cáo. Với mỗi vấn đề, ghi rõ thiết bị, phiên bản OS, các bước tái hiện, và con số cụ thể (ví dụ "launch 4.2s trên Redmi 9A, kỳ vọng <2s").
Lỗi thường gặp & mẹo
- Chỉ test bằng mắt, bỏ qua screen reader hoàn toàn. Đây là sai lầm số một. Hãy tập thói quen bật VoiceOver/TalkBack ít nhất một lần cho mỗi luồng quan trọng.
- Icon-only button không có label. Cực kỳ phổ biến. Cứ thấy nút chỉ có icon, hãy nghi ngờ ngay và kiểm tra screen reader đọc gì.
- Đánh giá performance chỉ trên máy flagship. Máy xịn che giấu mọi vấn đề. Luôn có một chiếc máy "yếu" của người dùng thật trong túi đồ nghề.
- Nhầm lẫn "app không crash" với "app mượt". Không crash chỉ là mức tối thiểu. Giật lag 30 FPS vẫn khiến người dùng bỏ đi dù app chẳng bao giờ văng.
- Quên test ở cỡ chữ lớn và Dark Mode. Cả hai đều thuộc a11y và dễ làm vỡ layout.
- Mẹo dùng công cụ tự động: Xcode có Accessibility Inspector để soi label và contrast; Android Studio có Accessibility Scanner app quét màn hình và gợi ý lỗi. Chúng phát hiện nhanh phần lớn lỗi cơ bản, nhưng nhớ rằng công cụ tự động chỉ bắt được khoảng 30-40% vấn đề — kiểm thử thủ công bằng screen reader vẫn không thể thay thế.
- Mẹo bối cảnh Việt Nam: đừng quên test hiển thị tiếng Việt có dấu ở cỡ chữ lớn — dấu thanh dễ bị cắt cụt hoặc chồng dòng khi layout co giãn.
Bài tập thực hành
- Trải nghiệm mù. Chọn một app bạn dùng hàng ngày (ví dụ ví MoMo hoặc app ngân hàng của bạn). Bật VoiceOver/TalkBack, nhắm mắt lại, và thử hoàn thành một tác vụ đơn giản như kiểm tra số dư. Ghi lại 3 điểm gây khó khăn nhất.
- Săn icon vô danh. Mở một app bất kỳ, bật screen reader, và tìm 5 phần tử bị đọc sai hoặc thiếu nhãn. Chụp màn hình và viết mô tả bug đúng chuẩn (thiết bị, bước tái hiện, kết quả thực tế, kết quả kỳ vọng).
- So sánh hai thiết bị. Nếu có thể, mở cùng một app trên hai máy: một máy mạnh và một máy yếu. Đo thời gian khởi động của cả hai, cuộn thử một danh sách dài, và ghi lại sự khác biệt về độ mượt.
- Dựng checklist của riêng bạn. Dựa trên phần "Accessibility Checklist căn bản" ở trên, tạo một bảng kiểm gồm 8-10 mục mà bạn sẽ áp dụng cho mọi màn hình. Đây sẽ là công cụ đi làm thực tế của bạn.
Tóm tắt
Trong bài này, bạn đã hiểu rằng chất lượng mobile không dừng ở "app chạy đúng". Hai trụ cột thường bị bỏ quên là accessibility — khả năng người khuyết tật dùng được app, với công cụ trung tâm là screen reader (VoiceOver trên iOS, TalkBack trên Android) — và performance — độ nhanh, mượt, tiết kiệm tài nguyên của ứng dụng trên nhiều loại thiết bị.
Bạn đã nắm được một accessibility checklist căn bản (nhãn cho icon, contrast màu, vùng chạm đủ lớn, thứ tự focus, không phụ thuộc màu, hỗ trợ cỡ chữ động) và những chỉ số performance đầu tiên (thời gian khởi động, FPS, time to interactive, tiêu thụ tài nguyên). Ba tình huống thực tế cho thấy các bug này vô hình với test truyền thống nhưng ảnh hưởng lớn đến người dùng thật — đặc biệt ở thị trường Việt Nam với đa dạng thiết bị và điều kiện mạng.
Điều quan trọng nhất cần mang theo: hãy tập thói quen bật screen reader và test trên máy yếu cho mỗi luồng quan trọng. Đây là nền tảng để bạn đi sâu vào các bài chuyên đề phía sau — a11y testing chi tiết và performance testing với FPS, frozen frames. Từ hôm nay, mỗi khi test một màn hình, hãy tự hỏi: "Người khiếm thị có dùng được không? Máy tầm trung có chạy mượt không?" Câu hỏi đó tách một QA giỏi ra khỏi số đông.