Mở đầu — vì sao bài này quan trọng
Ở các bài trước, bạn đã học cách kiểm thử bằng công cụ tự động (browser extension như axe, Lighthouse) và kiểm thử thủ công bằng bàn phím. Nhưng có một sự thật khó chịu: các công cụ tự động chỉ phát hiện được khoảng 30–40% lỗi accessibility. Phần còn lại — những lỗi ảnh hưởng trực tiếp nhất đến người dùng khiếm thị — chỉ lộ ra khi bạn thật sự nghe trang web của mình đọc lên.
Screen reader (trình đọc màn hình) là phần mềm chuyển giao diện thành giọng nói. Với hàng triệu người khiếm thị, đó là cách duy nhất họ "nhìn" thấy sản phẩm của bạn. Một nút bấm không có nhãn, với mắt thường vẫn đẹp long lanh, nhưng qua screen reader lại đọc thành "button, button, button" — vô nghĩa hoàn toàn.
Điều làm nhiều designer và developer Việt Nam ngại screen reader là cảm giác "khó, lạ, không biết bắt đầu từ đâu". Sự thật là bạn không cần trở thành người dùng thành thạo screen reader — bạn chỉ cần biết đủ để tự nghe sản phẩm của mình và phát hiện chỗ vô lý. Bài này sẽ dạy bạn chính xác điều đó: cài đặt, các phím tắt cốt lõi, và quy trình test thực chiến. Đây không phải kiến thức lý thuyết — sau bài này bạn có thể mở laptop lên và test ngay trong 20 phút.
Khái niệm cốt lõi
Screen reader hoạt động ra sao?
Screen reader không "đọc màn hình" theo nghĩa chụp hình pixel. Nó đọc accessibility tree — một cấu trúc mà trình duyệt dựng lên từ HTML semantic, ARIA, và nội dung. Đây là lý do các bài trước nhấn mạnh semantic HTML: nếu bạn dùng <button> thật, screen reader biết đó là nút; nếu bạn dùng <div onclick>, nó chỉ thấy một khối text câm.
Người dùng screen reader điều hướng theo hai chế độ chính:
- Đọc tuần tự (linear): đọc từ trên xuống dưới, phần tử này qua phần tử khác.
- Điều hướng nhanh (navigation): nhảy giữa các heading, link, landmark, form field bằng phím tắt — giống như người sáng mắt "quét" trang để tìm phần cần đọc.
Ba screen reader bạn cần biết
Không có một screen reader duy nhất — mỗi hệ điều hành có công cụ riêng, và người dùng thật dùng nhiều loại khác nhau. Bạn nên test trên ít nhất một cái, lý tưởng là hai.
- VoiceOver (macOS + iOS): có sẵn, miễn phí, tích hợp sâu. Trên Mac bật/tắt bằng
Cmd + F5. Đây là lựa chọn dễ nhất nếu bạn dùng máy Mac. Cặp trình duyệt tốt nhất: VoiceOver + Safari. - NVDA (Windows): miễn phí, tải từ nvaccess.org, là screen reader phổ biến nhất thế giới cùng với JAWS. Khởi động bằng
Ctrl + Alt + N. Cặp tốt nhất: NVDA + Firefox hoặc Chrome. - TalkBack (Android) và VoiceOver (iOS): dùng để test mobile — sẽ nói kỹ hơn ở bài Mobile A11y, nhưng ở đây bạn cần biết chúng tồn tại.
"Test" nghĩa là gì với screen reader?
Test screen reader không phải là "chạy cho xong". Bạn đang kiểm tra bốn câu hỏi:
- Tên (Name): Mỗi phần tử tương tác có được đọc tên rõ ràng không? Nút "Đặt hàng" có đọc là "Đặt hàng" hay "button"?
- Vai trò (Role): Screen reader có thông báo đúng loại phần tử không? Nó nói "link", "button", "checkbox" đúng chưa?
- Trạng thái (State): Checkbox có đọc "checked/unchecked" không? Accordion có đọc "expanded/collapsed" không?
- Thứ tự & ngữ cảnh (Order & Context): Nội dung đọc lên có theo trình tự hợp lý không? Người dùng có hiểu mình đang ở đâu không?
Tình huống thực tế
Ví dụ 1 — Tiki và nút "yêu thích" câm
Một nhóm QA giả định tại một sàn thương mại điện tử lớn kiểu Tiki test lại trang chi tiết sản phẩm. Về mặt tự động, axe DevTools báo "0 lỗi". Nhưng khi một tester bật NVDA và tab đến biểu tượng trái tim "thêm vào yêu thích", screen reader đọc: "button". Không tên, không ngữ cảnh. Icon trái tim được làm bằng SVG không có nhãn.
Người dùng khiếm thị nghe thấy 8 nút "button" liên tiếp trên trang mà không phân biệt được cái nào làm gì. Bài học: công cụ tự động không bắt được lỗi "thiếu accessible name" khi phần tử có role hợp lệ nhưng nội dung rỗng. Chỉ có tai người mới phát hiện. Fix: thêm aria-label="Thêm vào danh sách yêu thích". Sau khi sửa, tester nghe lại — "Thêm vào danh sách yêu thích, button" — rõ ràng. Đây là loại lỗi chỉ mất 20 phút test thủ công để tìm ra nhưng ảnh hưởng đến toàn bộ hành trình mua hàng.
Ví dụ 2 — Form đăng ký ngân hàng số đọc sai thứ tự
Một ngân hàng số tại Việt Nam (bối cảnh giả định kiểu Timo hoặc TPBank) làm form mở tài khoản. Về giao diện, label nằm ngay trên ô input, trông rất gọn. Nhưng developer đã dùng CSS order trong flexbox để đảo vị trí hiển thị, trong khi thứ tự HTML thật thì label ô "Số CMND" lại nằm sau ô nhập.
Khi test VoiceOver, tester nghe: ô nhập được đọc lên trước, rồi mới đến label "Số CMND" — người dùng khiếm thị nhập vào một ô mà không biết ô đó dùng để làm gì cho tới khi đã gõ xong. Tệ hơn, thông báo lỗi "CMND không hợp lệ" xuất hiện dạng text đỏ nhưng không được screen reader thông báo vì không có aria-live.
Bài học rút ra: thứ tự đọc (reading order) đi theo DOM, không theo mắt nhìn. CSS chỉ thay đổi hình thức, không thay đổi thứ tự screen reader đọc. Kiểm thử thủ công lộ ra cả hai vấn đề: thứ tự sai và thông báo lỗi câm. Với sản phẩm ngân hàng — nơi một lỗi nhập liệu có thể khiến khách hàng bỏ cuộc — đây là lỗi nghiêm trọng, và không một extension nào báo cho bạn biết.
Ví dụ 3 — Modal đặt lịch của một startup edtech
Một startup giáo dục ở TP.HCM có tính năng đặt lịch học với mentor qua một modal (hộp thoại). Người sáng mắt dùng mượt mà. Nhưng khi test NVDA, tester phát hiện: khi modal mở ra, screen reader không thông báo gì cả — nó vẫn đang "kẹt" đọc nội dung trang nền phía sau. Người dùng không hề biết một hộp thoại vừa hiện ra, và có thể tab ra ngoài modal xuống tận footer.
Nguyên nhân: modal thiếu role="dialog", thiếu focus management (không đưa focus vào modal khi mở), và không có aria-modal="true". Bài học: các component động (modal, dropdown, tab) là nơi screen reader lộ ra nhiều lỗi nhất, vì trạng thái thay đổi mà không được thông báo. Chi tiết về cách sửa modal thuộc bài riêng, nhưng điều bạn cần nhớ ở đây là: luôn test các thao tác động bằng screen reader, không chỉ trang tĩnh.
Hướng dẫn từng bước
Dưới đây là quy trình test thực chiến. Chọn một screen reader và làm theo.
Bước 1 — Cài đặt và làm quen (một lần duy nhất)
Trên Mac (VoiceOver):
- Bấm
Cmd + F5để bật. Một khung đen (VoiceOver caption) hiện ra ở góc dưới, hiển thị chữ nó đang đọc. - Phím điều khiển chính gọi là "VO" =
Control + Option(giữ đồng thời). - Nên chạy VoiceOver Training có sẵn: mở VoiceOver Utility, phần đầu có bài học tương tác 30 phút.
- Tải NVDA miễn phí từ nvaccess.org, cài đặt.
- Khởi động bằng
Ctrl + Alt + N. Có sẵn giọng đọc tiếng Việt (chọn trong Settings > Speech). - Phím "NVDA" mặc định là
Insert(hoặcCaps Locknếu bật chế độ laptop).
Bước 2 — Học 6 phím tắt cốt lõi
Bạn không cần thuộc hàng trăm phím. Chỉ cần 6 thao tác sau là test được 90% trường hợp:
| Mục tiêu | VoiceOver (Mac) | NVDA (Windows) |
|---|---|---|
| Đọc phần tử kế tiếp | VO + → | ↓ (mũi tên xuống) |
| Nhảy giữa các heading | VO + Cmd + H | H |
| Nhảy giữa các link | VO + Cmd + L | K |
| Nhảy giữa form field | VO + Cmd + J | F |
| Duyệt landmark/vùng | VO + U (rotor) | D |
| Kích hoạt phần tử | VO + Space | Enter |
VO + U mở Rotor — một menu cho phép duyệt nhanh mọi heading, link, landmark. Đây là công cụ mạnh nhất để "quét" trang như người dùng thật.Bước 3 — Chạy quy trình test 20 phút
- Tắt màn hình hoặc nhắm mắt. Nghe nghiêm túc là điểm mấu chốt — nếu vẫn nhìn màn hình, bạn sẽ "tự bù" ngữ cảnh mà người khiếm thị không có.
- Đọc tuần tự đầu trang. Trang có tự giới thiệu tên (title) không? Có landmark rõ ràng không?
- Nhảy qua các heading. Cấu trúc heading có kể được "câu chuyện" của trang không, hay lộn xộn?
- Nhảy qua link. Có link nào đọc là "bấm vào đây", "xem thêm" mà không rõ dẫn đi đâu không?
- Test form. Mỗi ô có được đọc tên (label) khi focus vào không? Lỗi validation có được thông báo không?
- Test thao tác động. Mở modal, dropdown, tab — screen reader có thông báo thay đổi không?
- Ghi lại lỗi. Mỗi lỗi ghi: phần tử nào, screen reader đọc gì, kỳ vọng đọc gì.
Bước 4 — So sánh chéo
Nếu có thể, test cùng một trang trên 2 cặp (ví dụ VoiceOver + Safari và NVDA + Chrome). Screen reader có hành vi khác nhau; một lỗi xuất hiện ở NVDA có thể không xuất hiện ở VoiceOver. Test chéo giúp bạn không bỏ sót.
Lỗi thường gặp & mẹo
Lỗi 1 — Vẫn nhìn màn hình khi test. Đây là sai lầm phổ biến nhất. Não bạn tự động điền ngữ cảnh từ hình ảnh, khiến bạn bỏ qua chỗ screen reader đọc vô nghĩa. Hãy thật sự tắt màn hình hoặc nhắm mắt cho các vòng test quan trọng.
Lỗi 2 — Chỉ test trên Chrome + VoiceOver. Cặp này có nhiều bug tương thích. Nếu dùng VoiceOver, hãy ghép với Safari. Nếu dùng NVDA, ghép với Firefox hoặc Chrome. Ghép sai cặp sẽ cho kết quả gây hiểu lầm.
Lỗi 3 — Nhầm "im lặng" với "không có lỗi". Khi screen reader không đọc gì lúc bạn bấm nút, đó KHÔNG phải là ổn — đó là lỗi. Trạng thái thay đổi mà không thông báo là một trong những vấn đề nghiêm trọng nhất.
Lỗi 4 — Quên tắt screen reader và hoảng loạn. Người mới thường bật VoiceOver rồi không biết tắt, cả máy "nói loạn". Nhớ: Cmd + F5 tắt VoiceOver, Insert + Q (rồi Enter) thoát NVDA. Ghi hai phím này ra giấy dán màn hình lúc mới học.
Mẹo 1 — Học phím "đọc lại". VoiceOver: VO + A đọc từ vị trí hiện tại. NVDA: Insert + ↓ đọc toàn bộ. Dùng để nghe lại một đoạn.
Mẹo 2 — Test với người thật khi có thể. Bạn test giỏi đến đâu cũng không thay được người dùng screen reader thực thụ. Bài sau về Real User Testing sẽ nói kỹ, nhưng hãy coi test cá nhân là bước sàng lọc, không phải bước cuối.
Mẹo 3 — Bắt đầu nhỏ. Đừng test cả sản phẩm ngay. Chọn một luồng quan trọng (ví dụ: thanh toán) và test kỹ luồng đó bằng screen reader. Thà làm sâu một luồng còn hơn quét hời hợt cả trang.
Bài tập thực hành
- Cài đặt & làm quen (30 phút). Bật screen reader trên máy của bạn (VoiceOver nếu Mac, NVDA nếu Windows). Chạy bài training tích hợp hoặc điều hướng thử trang chủ Google trong 15 phút cho đến khi thoải mái với 6 phím cốt lõi.
- Test một trang thật (20 phút). Chọn một trang web bạn hay dùng (ví dụ trang chi tiết sản phẩm trên một sàn TMĐT Việt Nam). Tắt màn hình. Nhảy qua heading, link, và thử điền một form. Ghi lại 5 vấn đề bạn nghe thấy: phần tử nào đọc vô nghĩa, thiếu label, hay im lặng khi cần thông báo.
- Bảng đối chiếu (15 phút). Với mỗi lỗi tìm được ở bài 2, viết một dòng theo mẫu: "[Phần tử] — screen reader đọc: '...' — nên đọc: '...'". Đây chính là định dạng bug report accessibility bạn sẽ dùng trong công việc thật.
- Nâng cao (nếu có 2 máy/trình duyệt). Test lại cùng trang trên một cặp screen reader + trình duyệt khác. So sánh: lỗi nào xuất hiện ở cả hai, lỗi nào chỉ ở một?
Tóm tắt
Screen reader là công cụ duy nhất cho bạn nghe được sản phẩm của mình đúng như hàng triệu người khiếm thị trải nghiệm — và nó bắt được đúng những lỗi mà công cụ tự động bỏ sót. Ba screen reader cốt lõi: VoiceOver (Mac/iOS, Cmd + F5), NVDA (Windows, miễn phí, Ctrl + Alt + N), và TalkBack (Android). Bạn không cần thành thạo — chỉ cần 6 phím tắt cốt lõi và một quy trình test 20 phút: đọc tuần tự, nhảy heading, nhảy link, test form, test thao tác động, và ghi lại lỗi theo bốn tiêu chí Name–Role–State–Order.
Ba tình huống thực tế cho thấy pattern chung: nút icon câm, thứ tự đọc sai lệch với hình nhìn, và component động không thông báo trạng thái — tất cả đều "sạch" dưới mắt công cụ tự động nhưng lộ ra ngay khi bạn nghe. Quy tắc vàng: tắt màn hình, ghép đúng cặp screen reader + trình duyệt, và đừng bao giờ nhầm "im lặng" với "không có lỗi". Test thủ công bằng screen reader không khó — nó chỉ cần bạn chịu mở tai ra và nghe.