Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn nhắm mắt lại và cố gắng dùng một ứng dụng ngân hàng chỉ bằng cách nghe. Không nhìn thấy màu sắc, không thấy vị trí nút bấm, không thấy biểu tượng nào cả. Tất cả những gì bạn có là một giọng đọc máy đọc lần lượt từng phần tử trên màn hình. Đó chính xác là trải nghiệm hằng ngày của hàng triệu người dùng khiếm thị và thị lực kém khi họ dùng screen reader (phần mềm đọc màn hình).
Ở Việt Nam, theo số liệu của Hội Người mù Việt Nam, có khoảng hơn 1 triệu người khiếm thị. Con số này chưa tính đến người cao tuổi thị lực suy giảm, người bị đục thủy tinh thể, hay đơn giản là người dùng smartphone trong điều kiện nắng gắt không nhìn rõ màn hình. Tất cả những người này đều có thể phụ thuộc vào tính năng đọc màn hình ở một thời điểm nào đó.
Là một UX writer, bạn có thể nghĩ accessibility (khả năng tiếp cận) là chuyện của designer hoặc developer. Nhưng thực tế, phần lớn những gì screen reader đọc lên chính là chữ — và chữ là địa hạt của bạn. Một label sai, một alt text vô nghĩa, một nút "Nhấn vào đây" đứng trơ trọi có thể khiến cả một luồng thao tác trở nên bất khả thi với người dùng khiếm thị. Bài học này sẽ giúp bạn hiểu screen reader hoạt động thế nào và viết copy sao cho nó phục vụ được cả những người không nhìn thấy màn hình.
Khái niệm cốt lõi
Screen reader là gì và đọc những gì
Screen reader là phần mềm chuyển nội dung màn hình thành giọng nói (text-to-speech) hoặc chữ nổi Braille. Các screen reader phổ biến gồm:
- NVDA và JAWS: chạy trên Windows, thường dùng với trình duyệt web.
- VoiceOver: tích hợp sẵn trên iPhone, iPad, Mac.
- TalkBack: tích hợp sẵn trên điện thoại Android.
- Thứ tự và ngữ cảnh của chữ cực kỳ quan trọng. Một mẩu chữ tách khỏi ngữ cảnh xung quanh sẽ vô nghĩa khi đọc riêng lẻ.
- Chữ phải tự thân giải thích được. Screen reader không truyền tải màu sắc, vị trí, hay hình ảnh. Nếu ý nghĩa nằm ở những yếu tố đó, người dùng khiếm thị sẽ mất trắng thông tin.
Alt text — mô tả hình ảnh bằng chữ
Alt text (văn bản thay thế) là đoạn mô tả gắn với hình ảnh, được screen reader đọc lên thay cho hình. Đây là một trong những phần copy quan trọng nhất mà UX writer phụ trách nhưng lại hay bị bỏ quên.
Nguyên tắc: alt text phải mô tả ý nghĩa và chức năng của hình trong ngữ cảnh, không phải mô tả chi tiết pixel. Với ảnh trang trí thuần túy (đường kẻ, họa tiết nền), alt text nên để trống (alt="") để screen reader bỏ qua, tránh làm phiền người nghe.
Ví dụ với logo là nút dẫn về trang chủ: alt text nên là "Trang chủ Tiki" chứ không phải "Hình ảnh logo màu xanh có chữ Tiki" — vì chức năng của nó là dẫn về trang chủ, đó mới là thứ người dùng cần biết.
Accessible name — cái tên mà screen reader đọc cho nút và link
Mỗi phần tử tương tác (nút, link, ô nhập liệu) đều có một "accessible name" — cái tên screen reader đọc lên khi người dùng chạm tới nó. Với nút có chữ, accessible name chính là chữ đó. Nhưng với nút chỉ có icon (ví dụ icon giỏ hàng, icon kính lúp tìm kiếm, icon dấu X đóng), bạn phải cung cấp accessible name bằng thuộc tính aria-label — và nội dung aria-label đó chính là copy bạn viết.
Đây là lý do UX writer cần ngồi cạnh accessibility: một nút hình cái thùng rác mà không có aria-label sẽ được VoiceOver đọc là "nút" (button) — người dùng khiếm thị hoàn toàn không biết bấm vào sẽ xóa cái gì.
Ngôn ngữ độc lập với giác quan (sensory-independent language)
Copy tốt cho accessibility tránh dựa vào thông tin thị giác thuần túy. Câu "Nhấn nút màu xanh bên phải để tiếp tục" hoàn toàn vô dụng với người không thấy màu và không thấy vị trí. Hãy viết theo nhãn: "Nhấn nút Tiếp tục". Tương tự, tránh "xem hình bên dưới", "như biểu tượng ở góc trên".
Cấu trúc heading — bản đồ điều hướng bằng tai
Người dùng screen reader thường điều hướng bằng cách nhảy giữa các heading (H1, H2, H3...) như mục lục. Vì thế, heading không chỉ là chuyện thẩm mỹ mà là công cụ điều hướng. Copy heading phải rõ ràng, mô tả đúng nội dung phần bên dưới, và được sắp xếp phân cấp hợp lý — điều này bạn sẽ học sâu hơn ở Bài 19, nhưng ở đây cần nhớ nó cũng phục vụ trực tiếp cho screen reader.
Tình huống thực tế
Ví dụ 1 — Nút icon không tên trên app gọi xe Xanh SM
Giả sử đội sản phẩm của một ứng dụng gọi xe như Xanh SM thiết kế màn hình chuyến đi với ba nút icon nằm cạnh nhau: một icon điện thoại (gọi tài xế), một icon tin nhắn (chat với tài xế), và một icon chia sẻ (gửi vị trí cho người thân). Trên màn hình, người sáng mắt nhìn icon là hiểu ngay.
Nhưng khi một người dùng khiếm thị mở màn hình này bằng TalkBack, cả ba nút đều được đọc là "nút, nút, nút" vì không nút nào có accessible name. Người dùng hoàn toàn không biết nút nào gọi, nút nào nhắn tin. Trong tình huống khẩn cấp — chẳng hạn cần gọi tài xế đang chờ nhầm địa điểm — đây là lỗi nghiêm trọng.
Bài học rút ra: Với mọi nút chỉ có icon, UX writer phải viết aria-label rõ nghĩa, bắt đầu bằng động từ: "Gọi tài xế", "Nhắn tin cho tài xế", "Chia sẻ vị trí chuyến đi". Ba chữ ngắn này biến màn hình từ chỗ bất khả dụng thành hoàn toàn dùng được bằng tai.
Ví dụ 2 — Thông báo lỗi phụ thuộc màu sắc trên form đăng ký
Một sàn thương mại điện tử giả định, tạm gọi là ShopViet, có form đăng ký với ô nhập số điện thoại. Khi người dùng nhập sai định dạng, hệ thống chỉ tô viền ô màu đỏ và không kèm chữ nào. Với người sáng mắt, viền đỏ là dấu hiệu quen thuộc "chỗ này sai". Nhưng screen reader không đọc được màu — người dùng khiếm thị nhập xong, bấm "Đăng ký", form không chạy, và họ không hiểu vì sao vì không nghe được bất kỳ lời cảnh báo nào.
Đội của ShopViet sau khi kiểm thử với NVDA đã bổ sung thông báo lỗi bằng chữ, gắn trực tiếp với ô nhập bằng aria-describedby để screen reader đọc lên ngay khi người dùng đứng ở ô đó: "Số điện thoại chưa đúng. Nhập 10 chữ số, bắt đầu bằng số 0." Kết quả là tỷ lệ hoàn thành form của nhóm người dùng dùng công nghệ hỗ trợ tăng rõ rệt, và điểm mấu chốt là ai cũng hưởng lợi — kể cả người sáng mắt cũng đọc được lời hướng dẫn cụ thể thay vì chỉ thấy viền đỏ mơ hồ.
Bài học rút ra: Đừng bao giờ để màu sắc là kênh truyền tin duy nhất. Mọi trạng thái lỗi, cảnh báo, thành công đều phải có chữ đi kèm và chữ đó phải được liên kết đúng để screen reader đọc.
Ví dụ 3 — Alt text vô nghĩa trên banner khuyến mãi
Một ngân hàng số ở Đông Nam Á đặt banner khuyến mãi mở thẻ tín dụng ngay trang chủ app. Banner là một tấm ảnh chứa toàn bộ thông điệp: "Mở thẻ ngay, hoàn tiền 500.000đ". Nhưng developer đặt alt text là tên file: "banner_promo_thang6_final_v2.png". Khi VoiceOver đọc, người dùng khiếm thị chỉ nghe một chuỗi tên file rối rắm, hoàn toàn không biết đó là ưu đãi gì.
Sau khi được UX writer rà soát, alt text được viết lại đúng nội dung thông điệp trong ảnh: "Mở thẻ tín dụng ngay, nhận hoàn tiền 500.000đ. Nhấn để xem chi tiết." Giờ đây người dùng khiếm thị tiếp cận được đúng ưu đãi như mọi người khác.
Bài học rút ra: Khi thông điệp quan trọng nằm trong ảnh (thường gặp với banner marketing), alt text phải chuyển tải trọn vẹn thông điệp đó bằng chữ. Tên file, mã sản phẩm, hay mô tả kỹ thuật là vô dụng với người nghe.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi viết hoặc rà soát copy cho khả năng tiếp cận screen reader:
Bước 1 — Đọc to màn hình theo thứ tự tuyến tính. Trước khi nghĩ đến giao diện đẹp, hãy đọc lần lượt từng phần tử từ trên xuống như screen reader sẽ làm. Nếu bạn nghe thấy điều gì đó vô nghĩa khi tách khỏi hình ảnh, đó là chỗ cần sửa.
Bước 2 — Rà mọi phần tử tương tác. Với từng nút, link, ô nhập, tự hỏi: "Nếu tôi chỉ nghe cái tên này mà không thấy màn hình, tôi có biết nó làm gì không?" Nút "Xem thêm", "Nhấn vào đây", "OK" đứng một mình thường thất bại bài kiểm tra này. Viết lại thành động từ + đối tượng cụ thể: "Xem thêm đánh giá sản phẩm", "Tải hóa đơn tháng 6".
Bước 3 — Viết accessible name cho nút icon. Liệt kê mọi nút chỉ có icon. Với mỗi nút, viết một aria-label ngắn gọn, bắt đầu bằng động từ, mô tả hành động: "Đóng", "Tìm kiếm", "Mở giỏ hàng", "Yêu thích sản phẩm".
Bước 4 — Viết alt text theo chức năng và ngữ cảnh. Với ảnh mang thông tin, mô tả ý nghĩa. Với ảnh là nút, mô tả hành động. Với ảnh trang trí, để trống alt để screen reader bỏ qua. Giữ alt text ngắn gọn, thường dưới một câu.
Bước 5 — Loại bỏ ngôn ngữ phụ thuộc giác quan. Tìm và thay các cụm "màu xanh", "bên phải", "hình bên dưới", "icon ở góc" bằng nhãn hoặc tên cụ thể.
Bước 6 — Đảm bảo trạng thái động được thông báo. Khi có lỗi, thành công, hay nội dung xuất hiện đột ngột (như toast, banner), phần đó cần được screen reader đọc lên. Copy của bạn phải rõ ràng, đầy đủ ngữ cảnh vì người dùng không thấy nó "nhấp nháy" trên màn hình.
Bước 7 — Kiểm thử thật bằng screen reader. Bật VoiceOver trên iPhone (Cài đặt > Trợ năng > VoiceOver) hoặc TalkBack trên Android, rồi tự dùng chính sản phẩm của bạn bằng tai. Đây là bài kiểm tra thực tế nhất và thường phơi bày ngay những lỗi mà đọc code không thấy.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi nhét từ khóa vào alt text. Nhiều người viết alt text dài dòng để làm SEO, khiến người dùng screen reader phải nghe cả đoạn quảng cáo. Alt text là để phục vụ người dùng, không phải để nhồi từ khóa. Giữ nó ngắn và đúng chức năng.
Lỗi 2 — Lặp thông tin thừa. Đừng bắt đầu alt text bằng "Hình ảnh của..." hay "Ảnh chụp..." vì screen reader đã tự thông báo đây là hình ảnh. Đi thẳng vào nội dung.
Lỗi 3 — Dùng ký tự đặc biệt và emoji vô tội vạ. Một tiêu đề như "Ưu đãi HOT 🔥🔥🔥" sẽ được screen reader đọc thành "Ưu đãi HOT, biểu tượng lửa, biểu tượng lửa, biểu tượng lửa" — vừa gây phiền vừa làm loãng thông điệp. Dùng emoji có chủ đích, và nhớ đây cũng trùng với quy tắc không dùng emoji cho UI của nền tảng chúng ta.
Lỗi 4 — Nút "Nhấn vào đây" hàng loạt. Người dùng screen reader hay dùng lệnh "liệt kê tất cả link". Nếu có mười link đều tên "Nhấn vào đây", họ nghe được một danh sách vô nghĩa. Mỗi link phải tự mô tả đích đến của nó.
Mẹo 1 — Nguyên tắc "nhắm mắt đọc to". Trước khi chốt bất kỳ label nào, nhắm mắt và đọc to nó lên tách khỏi giao diện. Nếu bạn không hiểu, người dùng khiếm thị cũng không.
Mẹo 2 — Accessibility giúp tất cả mọi người. Copy rõ ràng cho screen reader thường cũng rõ ràng hơn cho mọi người: người dùng vội, người dùng ngoài nắng, người mới. Đây không phải chi phí phụ, đây là chất lượng nền tảng.
Mẹo 3 — Viết số và đơn vị đầy đủ chữ khi cần. "SL" screen reader có thể đọc thành "sờ lờ", "TP.HCM" có thể bị đọc lắp bắp. Với nội dung quan trọng, cân nhắc viết đầy đủ hoặc kiểm tra cách screen reader phát âm viết tắt.
Bài tập thực hành
- Rà soát nút icon: Mở một app bạn hay dùng (ví dụ Grab, Momo, Shopee). Tìm ba nút chỉ có icon và tự viết aria-label cho mỗi nút theo công thức động từ + đối tượng. So sánh với những gì VoiceOver/TalkBack thực sự đọc lên.
- Sửa copy phụ thuộc giác quan: Viết lại ba câu sau cho độc lập giác quan: (a) "Nhấn nút đỏ để hủy đơn.", (b) "Chọn gói ở cột bên phải.", (c) "Xem hướng dẫn ở hình bên dưới."
- Viết alt text: Cho một banner khuyến mãi có dòng chữ "Giảm 30% toàn bộ khóa học, chỉ trong hôm nay", hãy viết alt text phù hợp khi banner đó là (a) một link dẫn tới trang khuyến mãi, và (b) chỉ là ảnh minh họa không bấm được.
- Kiểm thử thật: Bật VoiceOver (iPhone) hoặc TalkBack (Android), nhắm mắt và thử hoàn thành một thao tác đơn giản trong app của bạn — ví dụ đăng nhập. Ghi lại mọi chỗ bạn bị "kẹt" vì copy không đủ rõ.
Tóm tắt
Accessibility trong copy không phải là một tính năng phụ dành cho một nhóm nhỏ — nó là phần cốt lõi của công việc viết UX, vì phần lớn thứ screen reader truyền đạt chính là chữ do bạn viết. Screen reader đọc tuần tự và không truyền tải màu sắc, vị trí hay hình ảnh, nên copy của bạn phải tự thân đầy đủ nghĩa. Hãy viết accessible name rõ ràng cho mọi nút icon, viết alt text theo chức năng và ngữ cảnh, loại bỏ ngôn ngữ phụ thuộc giác quan, và luôn kèm chữ cho mọi trạng thái lỗi hay thành công. Cuối cùng, hãy kiểm thử thật bằng chính screen reader — nhắm mắt và nghe sản phẩm của bạn. Khi bạn viết tốt cho người không nhìn thấy màn hình, bạn đang nâng chất lượng trải nghiệm cho tất cả mọi người.