Bài 16 — Link Best Practices

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

Hãy tưởng tượng bạn bước vào một hiệu sách khổng lồ nhưng bị bịt mắt. Cách duy nhất để bạn tìm đường là một nhân viên đọc to cho bạn nghe một danh sách: "Xem thêm. Nhấn vào đây. Tại đây. Đọc tiếp. Nhấn vào đây. Xem thêm." Bạn sẽ đi đâu? Bạn hoàn toàn mất phương hướng, vì mỗi mục trong danh sách chẳng nói lên điều gì.

Đó chính xác là trải nghiệm của một người dùng screen reader (trình đọc màn hình) khi họ mở "danh sách link" trên trang web của bạn. Đây là điều mà rất ít nhà thiết kế và lập trình viên nhận ra: người khiếm thị hiếm khi đọc trang web từ trên xuống dưới như chúng ta. Họ thường bật một tính năng gọi là link list — trình đọc màn hình sẽ tách toàn bộ các đường link trên trang ra thành một danh sách riêng, tách khỏi ngữ cảnh xung quanh, rồi đọc lần lượt từng cái để họ nhảy nhanh đến nơi cần đến.

Khi các link được tách ra khỏi ngữ cảnh, phần chữ trong link (link text) phải tự nó nói lên đích đến. Nếu bạn có mười cái link đều ghi "Click here" hay "Nhấn vào đây", danh sách đó vô dụng. Đây không phải chuyện nhỏ nhặt: theo tiêu chí WCAG 2.4.4 (Link Purpose - In Context) và ở mức khắt khe hơn là 2.4.9 (Link Purpose - Link Only), mục đích của mỗi link phải rõ ràng. Bài học hôm nay sẽ chỉ cho bạn cách viết, thiết kế và cấu trúc link sao cho mọi người dùng — kể cả người khiếm thị, người dùng bàn phím, người có suy giảm nhận thức — đều hiểu ngay link đó dẫn đi đâu.

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

Link text phải mô tả được đích đến

Nguyên tắc vàng: đọc riêng phần chữ trong link, không cần nhìn xung quanh, người ta vẫn phải hiểu link dẫn đi đâu. Đây gọi là "self-describing link" (link tự mô tả).

Hãy so sánh:

<!-- Tệ: chữ link vô nghĩa khi tách ra khỏi ngữ cảnh -->
<p>Chúng tôi vừa ra mắt báo cáo thị trường 2026.
   <a href="/bao-cao-2026">Nhấn vào đây</a> để xem.</p>

<!-- Tốt: chữ link tự nói lên đích đến -->
<p>Chúng tôi vừa ra mắt <a href="/bao-cao-2026">báo cáo thị trường 2026</a>.</p>

Trong ví dụ tốt, nếu người dùng screen reader nghe danh sách link, họ nghe "báo cáo thị trường 2026" — rõ ràng và hữu ích. Trong ví dụ tệ, họ chỉ nghe "Nhấn vào đây", chẳng biết dẫn đâu.

Những cụm từ cần loại bỏ vì chúng vô nghĩa khi đứng một mình: "Nhấn vào đây", "Click here", "Xem thêm" (khi lặp lại nhiều lần), "Đọc tiếp", "Tại đây", "Link", "Chi tiết".

Không được có hai link khác đích nhưng cùng chữ

WCAG yêu cầu: nếu hai link dẫn đến hai nơi khác nhau, chữ của chúng phải khác nhau (hoặc ít nhất phần accessible name phải khác). Trang tin tức thường mắc lỗi này: mỗi bài viết có một link "Xem thêm". Với người khiếm thị, danh sách link hiện ra 20 mục "Xem thêm" giống hệt nhau — không thể phân biệt.

Ngược lại, nếu hai link dẫn đến cùng một đích, nên dùng cùng chữ để tránh gây rối.

Accessible name — cái mà screen reader thực sự đọc

Trình đọc màn hình không đọc "phần chữ bạn nhìn thấy" mà đọc accessible name của link. Thứ tự tính toán (đơn giản hóa): aria-labelledby → aria-label → chữ bên trong thẻ (bao gồm alt của ảnh) → title.

Điều này cho bạn công cụ để "vá" những trường hợp không thể đổi chữ hiển thị:

<!-- Card sản phẩm: nút "Xem" ngắn gọn về mặt thị giác,
     nhưng accessible name đầy đủ cho screen reader -->
<a href="/san-pham/serum-b5" aria-label="Xem chi tiết Serum B5 phục hồi da">Xem</a>

Lưu ý quan trọng: aria-label ghi đè hoàn toàn chữ hiển thị. Nếu người dùng phần mềm ra lệnh bằng giọng nói nói "click Xem" nhưng accessible name lại là một câu dài khác, lệnh có thể không khớp. Vì thế, khi dùng aria-label, hãy đảm bảo nó chứa chữ hiển thị (đây là yêu cầu của WCAG 2.5.3 Label in Name).

Icon-only link phải có nhãn

Link chỉ có biểu tượng (icon) — như logo, icon giỏ hàng, icon mạng xã hội — hoàn toàn "trống" với screen reader nếu không được gán nhãn.

<!-- Tệ: screen reader chỉ đọc "link", không biết là gì -->
<a href="/gio-hang"><i class="fa fa-shopping-cart"></i></a>

<!-- Tốt: có nhãn ẩn -->
<a href="/gio-hang" aria-label="Giỏ hàng">
  <i class="fa fa-shopping-cart" aria-hidden="true"></i>
</a>

Chú ý aria-hidden="true" trên icon để screen reader không cố đọc font-icon (đôi khi đọc thành ký tự lạ), và aria-label cung cấp nhãn thật.

Link mở tab mới / tải file — báo trước cho người dùng

Nếu một link mở cửa sổ mới (target="_blank") hoặc tải một tệp PDF, người dùng nên được biết trước. Người khiếm thị đặc biệt dễ bối rối khi tự dưng "màn hình nhảy đi đâu mất" mà không quay lại được bằng nút Back.

<a href="/huong-dan.pdf" target="_blank" rel="noopener">
  Hướng dẫn sử dụng (PDF, mở tab mới)
</a>

Bạn có thể ẩn phần "(PDF, mở tab mới)" về mặt thị giác bằng icon, nhưng vẫn nên để screen reader đọc được, ví dụ qua một <span> có class visually-hidden.

Link phải "trông giống link" và không chỉ dựa vào màu

Đây là phần giao thoa nhẹ với chủ đề màu sắc, nhưng riêng cho link thì rất quan trọng: theo WCAG 1.4.1 (Use of Color), bạn không được phân biệt link với văn bản xung quanh chỉ bằng màu. Người mù màu có thể không thấy sự khác biệt. Giải pháp phổ biến nhất là gạch chân (underline) cho link nằm trong đoạn văn, hoặc đảm bảo có tín hiệu phi-màu khác (đậm hơn rõ rệt, icon...).

Tình huống thực tế

Tình huống 1 — Sàn thương mại điện tử và "20 nút Xem thêm"

Một sàn TMĐT nội thất tại TP.HCM, tạm gọi là NhaViet.vn, tổ chức đợt audit accessibility trước khi ký hợp đồng với một khách hàng doanh nghiệp lớn (đối tác này bắt buộc nhà cung cấp đạt WCAG 2.1 AA). Chuyên gia audit bật NVDA (một screen reader miễn phí phổ biến) và mở danh sách link ở trang danh mục sản phẩm.

Kết quả: 24 sản phẩm trên trang, mỗi sản phẩm có một link "Xem chi tiết" y hệt nhau. Danh sách link đọc lên là "Xem chi tiết, Xem chi tiết, Xem chi tiết…" 24 lần. Không thể phân biệt sản phẩm nào với sản phẩm nào. Đây vi phạm cả 2.4.4 (mục đích link không rõ) lẫn nguyên tắc link trùng chữ khác đích.

Cách sửa mà đội kỹ thuật áp dụng chỉ tốn nửa ngày: giữ nguyên nút "Xem chi tiết" về mặt thị giác (không muốn nút quá dài phá layout), nhưng bổ sung aria-label động ghép tên sản phẩm vào:

<a href="/sp/ghe-sofa-oslo"
   aria-label="Xem chi tiết Ghế sofa Oslo 3 chỗ màu xám">
  Xem chi tiết
</a>

Sau khi sửa, danh sách link đọc lên rõ từng sản phẩm. Bài học: khi thiết kế UI cần chữ ngắn gọn (nút, card), đừng hy sinh khả năng tiếp cận — dùng accessible name để bù đắp. Và lưu ý họ đã đưa tên sản phẩm ("Ghế sofa Oslo") vào label để không vi phạm Label in Name, vì cụm này cũng là cách người dùng giọng nói gọi tên.

Tình huống 2 — Ngân hàng số và cái link "tại đây" trong email OTP

Một ngân hàng số ở Đông Nam Á (giả định là TimoPay) nhận phàn nàn từ một khách hàng khiếm thị: anh không thể hoàn tất việc kích hoạt thẻ. Trang hướng dẫn có câu: "Để kích hoạt thẻ, vui lòng nhấn tại đây. Để đổi mã PIN, nhấn tại đây. Nếu cần hỗ trợ, nhấn tại đây."

Ba link, ba đích khác nhau, nhưng cả ba đều là "tại đây". Người dùng screen reader duyệt qua link list nghe "tại đây, tại đây, tại đây" và không biết cái nào kích hoạt thẻ. Anh nhấn nhầm sang trang đổi PIN và bị khóa tạm thời sau vài lần thử sai.

Đội thiết kế sửa lại thành:

<a href="/kich-hoat-the">Kích hoạt thẻ Visa Debit</a>
<a href="/doi-pin">Đổi mã PIN</a>
<a href="/ho-tro">Liên hệ hỗ trợ khách hàng</a>

Bài học: với lĩnh vực nhạy cảm như ngân hàng, một link mơ hồ không chỉ gây khó chịu mà còn dẫn đến hậu quả thực (khóa tài khoản, mất tiền). Chữ link rõ ràng vừa tốt cho accessibility, vừa giảm lỗi thao tác cho mọi người dùng, kể cả người sáng mắt đang vội.

Tình huống 3 — Trang tin tức và link icon mạng xã hội

Một tòa soạn báo điện tử chạy audit và phát hiện phần chân trang có 5 icon mạng xã hội (Facebook, YouTube, Zalo, TikTok, Threads) đều là link chỉ-icon, không nhãn. Screen reader đọc cả 5 thành "link, link, link, link, link". Ngoài ra, mỗi bài trong danh sách "Tin liên quan" có một thumbnail (ảnh nhỏ) là link nhưng ảnh không có alt, và một link chữ "Đọc tiếp" ngay bên dưới — dẫn đến hai link cạnh nhau cùng đích nhưng một cái trống rỗng, một cái mơ hồ.

Họ sửa hai việc: (1) gán aria-label cho từng icon mạng xã hội ("Fanpage Facebook của báo", "Kênh YouTube của báo"...); (2) gộp thumbnail và tiêu đề vào một link duy nhất bọc quanh cả khối, với accessible name là chính tiêu đề bài viết, và đặt alt="" cho ảnh (ảnh trang trí, tiêu đề đã cung cấp ngữ cảnh) để tránh screen reader đọc trùng.

<a href="/bai-viet/123" class="card">
  <img src="thumb.jpg" alt="">
  <h3>Giá vàng SJC vượt 80 triệu đồng một lượng</h3>
</a>

Bài học: nhiều link nhỏ trùng đích cạnh nhau vừa gây rối cho screen reader vừa tạo nhiều "điểm dừng" thừa khi dùng phím Tab. Gộp thành một vùng link lớn (larger touch/click target) tốt hơn cho cả người khiếm thị lẫn người dùng di động.

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

Đây là quy trình bạn có thể áp dụng cho bất kỳ trang nào:

• Liệt kê tất cả link như screen reader thấy. Mở NVDA (Windows, miễn phí) hoặc VoiceOver (Mac), nhấn phím tắt để bật danh sách link (NVDA: Insert + F7; VoiceOver: Ctrl + Option + U rồi chọn Links). Nếu chưa cài screen reader, dùng extension như "HeadingsMap" hoặc chạy đoạn JS trong console: document.querySelectorAll('a').forEach(a => console.log(a.textContent.trim() || a.getAttribute('aria-label'))).

• Đọc riêng danh sách đó và tự hỏi từng dòng: "Nếu chỉ nghe câu này, tôi có biết nó dẫn đi đâu không?" Đánh dấu mọi dòng mơ hồ ("xem thêm", "tại đây", trống rỗng).

• Sửa chữ hiển thị trước, aria-label sau. Ưu tiên đổi chính chữ link vì nó tốt cho tất cả mọi người (SEO, người sáng mắt, người suy giảm nhận thức). Chỉ dùng aria-label khi vì lý do thiết kế không thể đổi chữ hiển thị.

• Gán nhãn cho mọi link chỉ-icon. Thêm aria-label mô tả đích, và aria-hidden="true" cho phần icon.

• Kiểm tra link trùng chữ khác đích. Với các danh sách lặp (sản phẩm, bài viết), thêm ngữ cảnh riêng vào từng link.

• Đánh dấu link mở tab mới / tải file. Thêm chú thích văn bản (có thể visually-hidden) cho biết định dạng và hành vi.

• Bảo đảm link phân biệt được không chỉ bằng màu. Link trong đoạn văn nên gạch chân; kiểm tra cả trạng thái :focus để người dùng bàn phím thấy được link đang được chọn (phần focus indicator sẽ học sâu ở bài riêng).

• Kiểm tra lại bằng screen reader thật, không chỉ dựa vào công cụ tự động — nhiều lỗi ngữ nghĩa máy không bắt được.

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

• Dùng <div onclick> hay <span onclick> thay cho <a>. Đây là link "giả" — không focus được bằng Tab, không kích hoạt bằng Enter, screen reader không nhận ra là link. Nếu nó điều hướng đến một URL, hãy dùng thẻ <a href> thật. (Sự khác biệt button vs link sẽ học kỹ ở Bài 20; ở đây chỉ cần nhớ: điều hướng đến trang/vị trí thì dùng link thật.)

• Nhồi cả câu dài vào aria-label. aria-label="Nhấn vào đây ngay bây giờ để đọc bài viết cực kỳ hấp dẫn về..." gây mệt cho người nghe. Ngắn gọn, đủ ý.

• Quên đồng bộ aria-label với chữ hiển thị. Vi phạm WCAG 2.5.3. Mẹo: luôn để chữ hiển thị là một phần đầu (hoặc nằm trong) accessible name.

• href="#" hoặc href="javascript:void(0)" cho hành động không điều hướng. Nếu nó thực chất là một nút bấm (mở modal, submit), hãy dùng <button>.

• Ảnh trong link không có alt hoặc alt sai. Nếu link chỉ có ảnh, alt của ảnh chính là accessible name của link — phải mô tả đích, không mô tả hình. Chi tiết alt text ở Bài 14.

• Mẹo "visually-hidden": dùng class ẩn về mặt thị giác nhưng vẫn đọc được để bổ sung ngữ cảnh, thay vì display:none (vốn ẩn khỏi cả screen reader):

.visually-hidden {
  position: absolute; width: 1px; height: 1px;
  padding: 0; margin: -1px; overflow: hidden;
  clip: rect(0,0,0,0); white-space: nowrap; border: 0;
}

<a href="/xem-them-gia-vang">Xem thêm<span class="visually-hidden"> tin về giá vàng</span></a>

Người sáng mắt thấy "Xem thêm", screen reader nghe "Xem thêm tin về giá vàng".

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

• Audit trang thật. Chọn một trang web tiếng Việt bạn hay dùng (báo, sàn TMĐT, ngân hàng). Chạy đoạn JS ở bước 1 phần Hướng dẫn để in ra tất cả accessible name của link. Đếm xem có bao nhiêu link mơ hồ ("xem thêm", "tại đây", trống). Ghi lại top 5 link tệ nhất và viết lại chữ cho chúng.

• Sửa card sản phẩm. Cho đoạn HTML sau, hãy làm cho nó tiếp cận được: giữ nút hiển thị là "Mua ngay" nhưng bảo đảm screen reader biết là mua sản phẩm nào; đồng thời gộp/ gán nhãn hợp lý.

<div class="card">
  <img src="serum.jpg">
  <h3>Serum Vitamin C 20%</h3>
  <a href="#">Mua ngay</a>
</div>

• Xử lý icon và file. Viết HTML cho: (a) một link giỏ hàng chỉ có icon; (b) một link tải bảng giá dạng PDF mở tab mới. Đảm bảo cả hai đều có accessible name rõ ràng và báo trước hành vi.

• Kiểm chứng bằng screen reader. Nếu có thể, cài NVDA hoặc bật VoiceOver, mở danh sách link (Insert+F7 / Ctrl+Option+U) trên trang bạn vừa sửa ở bài 2–3, và tự nghe xem có hiểu được đích đến của từng link không. Ghi lại cảm nhận.

Tóm tắt

Link tốt cho accessibility gói gọn trong vài nguyên tắc dễ nhớ:

• Chữ link phải tự mô tả đích đến — đọc riêng vẫn hiểu, vì người khiếm thị thường duyệt qua danh sách link tách khỏi ngữ cảnh. Loại bỏ "nhấn vào đây", "xem thêm" mơ hồ.
• Không để hai link khác đích cùng chữ. Với danh sách lặp, thêm ngữ cảnh riêng (thường qua aria-label).
• Screen reader đọc accessible name, không phải chữ bạn nhìn thấy. Dùng aria-label/aria-labelledby để vá khi cần, nhưng luôn giữ chữ hiển thị nằm trong accessible name (Label in Name).
• Link chỉ-icon phải có nhãn; icon nên aria-hidden.
• Báo trước khi link mở tab mới hoặc tải file.
• Đừng chỉ dựa vào màu để nhận biết link; gạch chân hoặc tín hiệu phi-màu khác.
• Dùng <a href> thật để điều hướng, không dùng <div onclick>.

Nắm vững những điều này, bạn không chỉ giúp người khiếm thị — bạn làm trang rõ ràng hơn cho tất cả mọi người, kể cả cỗ máy tìm kiếm. Ở các bài tiếp theo, chúng ta sẽ đi vào link đặc thù hơn như cấu trúc heading, landmark và sự khác nhau giữa button và link. Nhưng nền tảng "một link tốt là một link tự nói được nó dẫn đi đâu" sẽ theo bạn suốt.