Accessibility (a11y) cơ bản mọi developer nên biết

1. Accessibility là gì và vì sao quan trọng

Theo W3C WAI, web accessibility là việc thiết kế và phát triển sao cho người khuyết tật có thể nhận biết, hiểu, điều khiển và tương tác với nội dung. Làm đúng a11y không chỉ giúp một nhóm nhỏ — mà cải thiện UX cho tất cả, đồng thời hỗ trợ SEO thông qua HTML ngữ nghĩa và cấu trúc rõ ràng. Xem thêm giới thiệu từ MDN và định hướng pháp lý ở ADA.

2. Nguyên tắc WCAG (POUR)

• Perceivable: Nội dung có thể cảm nhận được (không chỉ phụ thuộc màu sắc/hình). Có văn bản thay thế cho media.
• Operable: Có thể thao tác được bằng bàn phím; không có bẫy focus; thời gian đủ để tương tác.
• Understandable: Giao diện và nội dung nhất quán, dễ hiểu; thông báo lỗi rõ ràng.
• Robust: Tương thích công nghệ hỗ trợ; HTML hợp chuẩn để screen reader diễn giải đúng.

Tham khảo tiêu chuẩn WCAG.

3. Thực hành nhanh dành cho developer

• HTML ngữ nghĩa: Dùng đúng <header>, <nav>, <main>, <footer>, và thứ bậc <h1>–<h6>. Tài liệu: MDN.
• Văn bản thay thế: Mọi <img> có alt mô tả chức năng/nội dung. Nếu chỉ là trang trí, dùng alt="" để screen reader bỏ qua.
• Tương phản màu: Đảm bảo contrast đáp ứng WCAG; không truyền tải thông tin chỉ bằng màu. Kiểm tra hướng dẫn tại WAI.
• Bàn phím trước: Mọi tương tác phải dùng được bằng Tab/Enter/Esc; trạng thái focus phải nhìn thấy.
• Form có label: Gắn <label for> với id của <input>; mô tả lỗi gần trường tương ứng; nhóm radio/checkbox bằng <fieldset>/<legend>.
• Trạng thái và thông báo: Nội dung thay đổi động nên thông báo qua vùng có thể đọc được bởi công nghệ hỗ trợ (ví dụ role="status").
• Thân thiện khi phóng to/di động: Hỗ trợ zoom 200%+ không vỡ layout; hit-area đủ lớn; thứ tự DOM hợp lý.

4. Khi nào dùng ARIA?

WAI-ARIA giúp mô tả vai trò, trạng thái, quan hệ cho UI phức tạp (menu, dialog, tabs). Quy tắc vàng: “Dùng HTML ngữ nghĩa trước, ARIA sau”. Nếu phần tử HTML đã truyền đạt ý nghĩa, không cần thêm ARIA. ARIA sai có thể làm trải nghiệm tệ hơn.

5. Kiểm thử và đưa a11y vào workflow

• Đi toàn site bằng bàn phím: thứ tự Tab, trap focus, khả năng kích hoạt điều khiển.
• Dùng công cụ tự động để phát hiện lỗi phổ biến: WAVE, axe, Lighthouse. Không phụ thuộc hoàn toàn vào chúng.
• Thử với screen reader cho các luồng chính (NVDA/JAWS trên Windows, VoiceOver trên macOS/iOS).
• Đặt tiêu chí a11y trong code review; có checklist kiểm tra trước khi release.

6. Ví dụ HTML thân thiện a11y (ngắn)

<nav aria-label="Điều hướng chính">
  <ul>
    <li><a href="/">Trang chủ</a></li>
    <li><a href="/blog">Blog</a></li>
    <li><a href="/contact">Liên hệ</a></li>
  </ul>
</nav>

<main id="content">
  <h1>Đăng ký nhận tin</h1>

  <form action="/subscribe" method="post" aria-describedby="form-help">
    <p id="form-help">Các trường có dấu * là bắt buộc.</p>

    <div>
      <label for="email">Email *</label>
      <input id="email" name="email" type="email" required autocomplete="email">
    </div>

    <fieldset>
      <legend>Tần suất nhận tin *</legend>
      <label><input type="radio" name="freq" value="weekly" required> Hàng tuần</label>
      <label><input type="radio" name="freq" value="monthly"> Hàng tháng</label>
    </fieldset>

    <div role="status" aria-live="polite" id="status"></div>

    <button type="submit">Gửi đăng ký</button>
  </form>

  <figure>
    <img src="/img/example.jpg" alt="Ảnh minh họa biểu đồ truy cập tăng dần">
    <figcaption>Biểu đồ minh họa có mô tả bằng văn bản thay thế.</figcaption>
  </figure>
</main>

7. Lợi ích và kết luận

Đưa a11y vào ngay từ đầu giúp giảm nợ kỹ thuật, mở rộng phạm vi người dùng, cải thiện SEO và hình ảnh thương hiệu. Bắt đầu bằng HTML ngữ nghĩa, kiểm thử bàn phím, alt text, contrast, form có label — sau đó mới thêm ARIA khi thật sự cần. Accessibility là nền tảng chất lượng sản phẩm, không phải “tính năng phụ”.