Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 13 — Screen Reader Basics

Đã đọc 0/14 mục · còn khoảng 13 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn đang thiết kế một website thương mại điện tử tuyệt đẹp: hình ảnh sắc nét, hiệu ứng mượt mà, bố cục cân đối. Nhưng với một người khiếm thị đang dùng máy tính, tất cả những "đẹp mắt" đó biến mất hoàn toàn. Thứ duy nhất họ nhận được là một giọng đọc máy phát ra từ chiếc screen reader (trình đọc màn hình), đọc lần lượt từng phần của trang. Nếu bạn không hiểu screen reader hoạt động thế nào, thì mọi công sức thiết kế của bạn có thể trở thành một mê cung khó chịu đối với họ.

Đây chính là lý do Bài 13 là một cột mốc quan trọng trong khóa học. Ở các bài trước, chúng ta đã nói về semantic HTML, ARIA, màu sắc, bàn phím. Nhưng screen reader mới là công cụ "biến" toàn bộ những nỗ lực đó thành trải nghiệm thực tế cho người khiếm thị. Nếu semantic HTML là bộ xương, thì screen reader là người kể chuyện đọc bộ xương đó thành lời.

Ở bài này, mục tiêu của chúng ta rất cụ thể và có giới hạn: hiểu screen reader là gì, biết những trình đọc phổ biến nhất (NVDA, JAWS, VoiceOver, TalkBack), nắm được cách chúng đọc và điều hướng nội dung, và tự mình bật thử một screen reader để nghe website của chính bạn. Chúng ta chưa đi sâu vào quy trình kiểm thử bài bản (đó là Bài 39), cũng chưa bàn về alt text hay form (Bài 14, 15). Bài 13 là bài "làm quen" — nhưng là lần làm quen sẽ thay đổi cách bạn nhìn nhận nghề thiết kế.

Khái niệm cốt lõi

Screen reader là gì?

Screen reader là một phần mềm trung gian đứng giữa người dùng và giao diện. Nó "đọc" cấu trúc của trang web hoặc ứng dụng — thông qua một lớp thông tin gọi là accessibility tree (cây trợ năng) — rồi chuyển thành âm thanh (text-to-speech) hoặc chữ nổi Braille (qua thiết bị Braille display).

Điểm mấu chốt bạn cần nhớ: screen reader không đọc thứ mắt bạn nhìn thấy, mà đọc thứ trình duyệt cung cấp cho nó qua code. Một cái nút bấm trông đẹp nhưng viết bằng <div onclick="..."> sẽ vô hình với screen reader, vì trong accessibility tree nó chỉ là một khối văn bản vô danh, không phải "button". Đây là lý do các bài về semantic HTML và ARIA lại quan trọng đến vậy — chúng viết ra chính cái "kịch bản" mà screen reader sẽ đọc.

Bốn trình đọc màn hình phổ biến nhất

Bạn không cần thuộc lòng mọi screen reader trên đời, nhưng bốn cái tên sau chiếm gần như toàn bộ thị phần thực tế:

  • NVDA (NonVisual Desktop Access) — chạy trên Windows, miễn phí và mã nguồn mở. Đây là screen reader phổ biến nhất trong cộng đồng người khiếm thị hiện nay, đặc biệt ở các nước đang phát triển như Việt Nam, vì không tốn tiền bản quyền. Nếu bạn chỉ chọn một công cụ để học, hãy chọn NVDA.
  • JAWS (Job Access With Speech) — cũng trên Windows, nhưng trả phí và khá đắt (bản thương mại tốn hàng trăm đô mỗi năm). Bù lại, JAWS là "tiêu chuẩn doanh nghiệp", được nhiều tổ chức lớn, ngân hàng, cơ quan chính phủ tại Mỹ và châu Âu sử dụng. Khi bạn kiểm thử cho khách hàng lớn, họ thường yêu cầu test trên JAWS.
  • VoiceOver — được tích hợp sẵn trong macOS và iOS của Apple. Không cần cài đặt gì thêm. Đây là screen reader mặc định của toàn bộ hệ sinh thái Apple, và là lựa chọn số một để test trên iPhone/iPad.
  • TalkBack — screen reader tích hợp sẵn trên Android của Google. Vì Android chiếm thị phần điện thoại rất lớn ở Việt Nam và Đông Nam Á, TalkBack là công cụ bắt buộc phải biết nếu sản phẩm của bạn có người dùng di động.
Một quy tắc thực tế: screen reader và trình duyệt đi thành cặp. NVDA hợp nhất với Firefox và Chrome, JAWS cũng thường dùng với Chrome, còn VoiceOver gắn chặt với Safari. Test sai cặp có thể ra kết quả lệch, nên hãy ghi nhớ cặp "chuẩn" của từng công cụ.

Screen reader đọc và điều hướng như thế nào?

Người dùng screen reader không di chuột. Họ dùng bàn phím (trên desktop) hoặc thao tác vuốt/chạm (trên di động) để đi qua trang. Có hai chế độ điều hướng chính bạn cần hiểu:

  • Đọc tuần tự (linear reading) — screen reader đọc từ trên xuống dưới, từng phần tử một, theo đúng thứ tự trong code (DOM order). Đây là lý do thứ tự các phần tử trong HTML quan trọng hơn thứ tự chúng hiển thị bằng CSS.
  • Điều hướng nhảy nhanh (navigation shortcuts) — thay vì nghe hết cả trang, người dùng thành thạo sẽ dùng phím tắt để "nhảy" giữa các thành phần: nhấn H để chuyển giữa các tiêu đề (heading), K để nhảy giữa các liên kết, B để nhảy giữa các nút, F để nhảy giữa các ô nhập form, D hoặc phím landmark để nhảy giữa các vùng chính của trang. Ngoài ra còn có tính năng liệt kê — ví dụ mở một danh sách tất cả tiêu đề để xem "mục lục" của trang trong vài giây.
Chính cơ chế điều hướng nhảy nhanh này giải thích vì sao heading structure (Bài 17) và landmark (Bài 18) lại sống còn: chúng là "bản đồ" giúp người khiếm thị định vị nhanh, giống như người sáng mắt liếc qua trang là biết đâu là menu, đâu là nội dung chính.

Chế độ Browse mode và Focus mode

Với các screen reader trên Windows (NVDA, JAWS), có một khái niệm quan trọng: browse mode (chế độ duyệt) và focus mode / forms mode (chế độ nhập liệu). Ở browse mode, các phím như H, K, B được dùng để điều hướng. Nhưng khi con trỏ đi vào một ô input, screen reader tự chuyển sang focus mode để bạn gõ chữ bình thường — nếu không, gõ chữ "h" sẽ bị hiểu là "nhảy tới heading tiếp theo" thay vì gõ chữ h vào ô. Hiểu điều này giúp bạn đọc đúng các báo cáo lỗi trợ năng sau này.

Tình huống thực tế

Ví dụ 1 — Tiki và cái nút "vô hình"

Giả sử một nhóm dev tại một sàn thương mại điện tử lớn kiểu Tiki xây trang chi tiết sản phẩm. Nút "Thêm vào giỏ hàng" được làm bằng <div class="btn-cart">Thêm vào giỏ</div> cho dễ style. Trên màn hình, nó trông hoàn hảo. Nhưng khi một cộng tác viên khiếm thị dùng NVDA test, screen reader đọc dòng đó là "Thêm vào giỏ" — như một đoạn văn bản thường, không hề báo đây là một nút bấm, và nhấn phím B (nhảy giữa các button) hoàn toàn bỏ qua nó.

Kết quả: người dùng nghe thấy chữ nhưng không biết có thể bấm vào, cũng không dùng phím Enter để kích hoạt được. Bài học: screen reader chỉ nhận ra "nút" khi code thật sự là <button> hoặc có role="button". Cái đẹp bằng mắt không có ý nghĩa gì nếu accessibility tree trống rỗng. Chỉ cần đổi thành <button> là NVDA lập tức đọc "Thêm vào giỏ, nút" và người dùng biết ngay phải làm gì.

Ví dụ 2 — App ngân hàng và trải nghiệm TalkBack tại Việt Nam

Một ngân hàng số tại Việt Nam ra mắt app chuyển tiền. Trong đợt kiểm thử với người dùng khiếm thị thật, một anh dùng điện thoại Android bật TalkBack để thao tác. Khi vuốt qua màn hình nhập số tiền, TalkBack đọc: "Ô nhập, chỉnh sửa" — nhưng không đọc nhãn cho biết đây là ô nhập gì, vì nhãn "Số tiền" được đặt bằng một <span> tách rời, không liên kết với ô input.

Hậu quả là anh không biết mình đang gõ số tiền hay số tài khoản, phải mò mẫm bằng cách vuốt lên xuống để đoán ngữ cảnh. Với một app tài chính, sự mơ hồ này là không thể chấp nhận được — gõ nhầm ô có thể chuyển sai tiền. Bài học ở đây: screen reader đọc nhãn được liên kết đúng cách (qua thuộc tính label, aria-label...), chứ không tự đoán từ vị trí trên màn hình. Đây cũng là lý do vì sao ta phải test bằng screen reader thật chứ không chỉ nhìn giao diện.

Ví dụ 3 — Grab và thứ tự đọc bị đảo lộn

Một team làm màn hình đặt xe kiểu Grab dùng CSS để đưa nút "Đặt xe ngay" lên đầu màn hình cho nổi bật, dù trong code HTML nó nằm ở cuối cùng. Người dùng sáng mắt thấy nút ngay lập tức. Nhưng khi một tester dùng VoiceOver trên iPhone đọc tuần tự từ trên xuống, screen reader đọc lần lượt: điểm đón, điểm đến, loại xe, giá tiền... và mãi tới cuối mới đọc "Đặt xe ngay, nút".

Người khiếm thị phải nghe qua toàn bộ nội dung mới tới được hành động chính, trong khi lẽ ra nó phải ở vị trí hợp lý. Bài học: screen reader đọc theo thứ tự DOM, không theo thứ tự CSS hiển thị. Khi bạn dùng order, position: absolute hay flex-direction: reverse để sắp xếp lại giao diện, hãy luôn tự hỏi: "Nếu nghe theo thứ tự code, câu chuyện có còn logic không?"

Hướng dẫn từng bước

Cách học screen reader tốt nhất không phải đọc lý thuyết mà là tự nghe website của mình bằng tai. Dưới đây là lộ trình để bạn bắt đầu ngay hôm nay.

Bước 1 — Chọn công cụ theo máy bạn đang có. Nếu dùng Windows: tải NVDA miễn phí từ trang chính thức của NV Access. Nếu dùng Mac: VoiceOver có sẵn, bật bằng Cmd + F5. Nếu có iPhone: vào Cài đặt > Trợ năng > VoiceOver. Nếu có điện thoại Android: vào Cài đặt > Trợ năng > TalkBack. Không cần cài cả bốn — hãy bắt đầu với một cái tiện nhất.

Bước 2 — Học một vài phím tắt sinh tồn trước khi bật. Điều nhiều người sợ nhất khi bật screen reader lần đầu là "không biết cách tắt". Hãy ghi nhớ trước:

  • NVDA: bật bằng Ctrl + Alt + N, tắt bằng Insert + Q. Phím Insert là phím điều khiển chính (gọi là NVDA modifier).
  • VoiceOver (Mac): bật/tắt cùng bằng Cmd + F5. Điều hướng bằng Ctrl + Option + phím mũi tên.
  • Trên di động: VoiceOver/TalkBack đổi cách chạm — một chạm để chọn và nghe, chạm đúp để kích hoạt, vuốt trái/phải để đi giữa các phần tử.
Bước 3 — Nhắm mắt lại và nghe một trang bạn quen. Mở một website bạn biết rõ, bật screen reader, rồi thực sự nhắm mắt. Để nó đọc tuần tự từ đầu. Bạn sẽ ngạc nhiên vì nhiều thứ nghe rất khác so với nhìn.

Bước 4 — Thử điều hướng bằng phím tắt. Trên NVDA, nhấn H liên tục để nhảy giữa các heading. Nhấn Insert + F7 để mở danh sách tất cả liên kết và heading — đây chính là "mục lục" mà người khiếm thị dùng. Cảm nhận xem trang của bạn có dễ định vị không.

Bước 5 — Thử hoàn thành một tác vụ mà không nhìn. Chọn một việc cụ thể: tìm một sản phẩm, điền một form đơn giản, bấm một nút. Làm hoàn toàn bằng tai và bàn phím. Nếu bạn bí, người khiếm thị cũng sẽ bí ở đúng chỗ đó.

Bước 6 — Ghi lại những chỗ khó chịu. Đừng cố sửa ngay. Chỉ cần ghi chú: "Nút này không đọc thành button", "Ô này không có nhãn", "Đọc mãi mới tới nội dung chính". Đây là dữ liệu vàng cho các bài kiểm thử sau này.

Lỗi thường gặp & mẹo

Lỗi 1 — Nghĩ rằng "nhìn ổn là được". Đây là sai lầm lớn nhất. Rất nhiều thành phần trông hoàn hảo bằng mắt nhưng câm lặng hoặc gây nhiễu với screen reader. Cách duy nhất để biết là bật lên và nghe.

Lỗi 2 — Chỉ test bằng một screen reader rồi kết luận. Mỗi trình đọc diễn giải code hơi khác nhau. Một đoạn ARIA chạy đúng trên NVDA có thể im lặng trên VoiceOver. Với dự án quan trọng, hãy test ít nhất một cặp desktop (NVDA hoặc JAWS) và một cặp di động (VoiceOver hoặc TalkBack).

Lỗi 3 — Bối rối vì browse mode và focus mode. Người mới thường thấy "phím H không hoạt động" khi con trỏ đang ở trong ô input — đó là vì screen reader đã tự chuyển sang focus mode. Đây là hành vi bình thường, không phải lỗi trang web.

Mẹo 1 — Tăng tốc độ đọc từ từ. Người khiếm thị thành thạo nghe screen reader ở tốc độ rất nhanh, có khi 300–400 từ/phút. Ban đầu bạn nên để chậm cho dễ theo, nhưng hiểu rằng người dùng thật nghe nhanh hơn bạn tưởng nhiều.

Mẹo 2 — Học phím "danh sách phần tử". Thay vì nghe cả trang, hãy tập dùng tính năng liệt kê heading/link (như Insert + F7 của NVDA). Nó cho bạn thấy ngay cấu trúc trang có mạch lạc không, chỉ trong vài giây.

Mẹo 3 — Đừng học screen reader như học một app mới, hãy học như học một ngôn ngữ. Ban đầu sẽ rối và bực. Nhưng chỉ cần 30 phút thực hành mỗi ngày trong một tuần, bạn sẽ "nghe" được website như người khiếm thị nghe — và đó là siêu năng lực nghề nghiệp thật sự.

Bài tập thực hành

  • Cài và bật một screen reader. Nếu dùng Windows, tải NVDA; nếu dùng Mac/iPhone, bật VoiceOver; nếu dùng Android, bật TalkBack. Ghi lại phím/thao tác bật và tắt.
  • Nghe mù một trang chủ. Chọn một website tiếng Việt bạn hay dùng (ví dụ một sàn thương mại điện tử hoặc báo điện tử). Nhắm mắt, để screen reader đọc tuần tự 2 phút đầu tiên. Viết ra 3 điều khiến bạn ngạc nhiên khi nghe so với khi nhìn.
  • Thử "mục lục" của trang. Dùng tính năng liệt kê heading (NVDA: Insert + F7; VoiceOver: dùng Rotor). Nhận xét: nghe qua danh sách heading, bạn có hiểu được trang này nói về cái gì và có mấy phần chính không?
  • Hoàn thành một tác vụ chỉ bằng tai. Cố tìm và mở một sản phẩm/bài viết cụ thể mà không nhìn màn hình. Ghi lại chỗ nào bạn bị "kẹt" và mất bao lâu.
  • So sánh (nâng cao). Nếu có điều kiện, đọc cùng một trang bằng hai screen reader khác nhau (ví dụ NVDA và VoiceOver). Ghi ra một điểm chúng đọc khác nhau. Đây là bước tập luyện tư duy quan trọng cho công việc kiểm thử về sau.

Tóm tắt

Screen reader là phần mềm biến cấu trúc code của trang thành âm thanh hoặc chữ nổi, giúp người khiếm thị sử dụng web và ứng dụng. Điều cốt lõi cần khắc ghi: screen reader đọc thứ code cung cấp qua accessibility tree, không phải thứ mắt nhìn thấy — nên một giao diện đẹp mà code sai vẫn có thể hoàn toàn vô dụng với người khiếm thị.

Bốn trình đọc quan trọng nhất là NVDA (Windows, miễn phí, phổ biến nhất — nên học đầu tiên), JAWS (Windows, trả phí, tiêu chuẩn doanh nghiệp), VoiceOver (tích hợp sẵn trong macOS/iOS) và TalkBack (tích hợp sẵn trong Android — cực kỳ quan trọng ở Việt Nam vì thị phần Android lớn). Người dùng điều hướng bằng bàn phím hoặc cử chỉ chạm, đọc tuần tự theo thứ tự DOM và nhảy nhanh qua heading, link, button, form.

Ba câu chuyện thực tế — nút "vô hình" trên sàn thương mại điện tử, ô nhập không nhãn trong app ngân hàng, và nút bị đảo thứ tự đọc trên app đặt xe — đều chỉ về một sự thật: bạn không thể đánh giá trợ năng bằng mắt. Cách học tốt nhất là tự bật một screen reader, nhắm mắt, và nghe chính sản phẩm của mình. Khi bạn đã "nghe" được như người khiếm thị nghe, mọi bài học tiếp theo về alt text, form, heading, landmark sẽ trở nên rõ ràng và có ý nghĩa hơn rất nhiều.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi