Accessibility trong thiết kế web (giao diện ai cũng dùng được)

Một giao diện đẹp nhưng chỉ vài nhóm người dùng được thì vẫn là thiết kế dở. Khoảng một phần sáu dân số thế giới sống chung với một dạng khuyết tật nào đó, và còn nhiều tình huống tạm thời (gãy tay, mắt mỏi, ngoài nắng chói) khiến ai cũng có lúc cần một trang dễ tiếp cận. Đây là phần nền tảng của thiết kế giao diện, không phải tính năng làm sau cho có.

Accessibility hướng tới những ai

Khi nói tới người khuyết tật, nhiều người chỉ hình dung người khiếm thị. Thực tế phổ rộng hơn nhiều, và mỗi nhóm có rào cản riêng:

• Thị giác: người khiếm thị hoàn toàn (dùng trình đọc màn hình — screen reader, phần mềm đọc to nội dung), người nhìn kém, người loạn sắc (color blindness — không phân biệt được một số cặp màu, phổ biến nhất là đỏ–xanh lá).
• Vận động: người không dùng được chuột, chỉ điều hướng bằng bàn phím hoặc thiết bị chuyển động đầu; người bị run tay khó bấm trúng nút nhỏ.
• Nhận thức: người khó tập trung, khó đọc, dễ choáng khi gặp giao diện rối hoặc hiệu ứng chuyển động mạnh.
• Thính giác: người điếc hoặc nghe kém — cần phụ đề cho video, không phụ thuộc âm thanh để hiểu.

Thiết kế tốt cho các nhóm này thường tốt cho tất cả: nút to dễ bấm trên điện thoại, tương phản cao dễ đọc ngoài nắng, cấu trúc rõ ràng giúp mọi người quét nhanh.

WCAG 2.2 gồm những gì

WCAG (Web Content Accessibility Guidelines — bộ hướng dẫn khả năng tiếp cận nội dung web) là chuẩn của W3C, hiện hành là bản 2.2 (W3C công nhận chính thức từ tháng 10/2023). Toàn bộ xoay quanh bốn nguyên tắc gọi tắt POUR:

• Perceivable (cảm nhận được): nội dung phải truyền đạt được qua nhiều giác quan — ảnh có alt, video có phụ đề, màu chữ đủ tương phản.
• Operable (thao tác được): mọi thứ bấm được bằng chuột thì cũng phải làm được bằng bàn phím; không bẫy người dùng trong một vùng.
• Understandable (hiểu được): ngôn ngữ rõ, thông báo lỗi dễ hiểu, hành vi giao diện nhất quán.
• Robust (bền vững): mã nguồn chuẩn để các công nghệ hỗ trợ (assistive technology) đọc đúng.

WCAG 2.2 có 87 tiêu chí thành công (success criteria), chia ba mức A, AA, AAA. Đa số tổ chức nhắm tới mức AA — đủ chặt mà thực tế làm được. Bản 2.2 bổ sung 9 tiêu chí mới so với 2.1, đáng chú ý cho người làm giao diện:

• Target Size — Minimum (2.5.8): vùng bấm tối thiểu 24×24 CSS pixel, hoặc nhỏ hơn nhưng phải có khoảng cách đủ giữa các nút.
• Focus Appearance: viền focus (vành sáng quanh phần tử đang được chọn bằng bàn phím) phải rõ — dày tương đương đường viền 2px và tương phản ít nhất 3:1.
• Focus Not Obscured: phần tử đang focus không bị thanh cố định hay popup che khuất.
• Dragging Movements: thao tác kéo–thả phải có cách thay thế bằng một cú bấm đơn.

Những con số cần nhớ đúng

Đây là vùng dễ nói sai nhất, nên ghi rõ nguồn từng con số:

Lưu ý phân biệt: 24px là ngưỡng tối thiểu để đạt chuẩn, còn 44–48px là khuyến nghị thực dụng để ngón tay bấm thoải mái. Web22 thường lấy mốc 44px làm chuẩn dựng giao diện cảm ứng — xem thêm bài kích thước vùng chạm tối thiểu để biết cách áp dụng cụ thể.

Checklist cơ bản khi thiết kế

Không cần thuộc lòng 87 tiêu chí. Khi dựng một giao diện mới, rà qua danh sách ngắn này đã chặn được phần lớn lỗi nặng:

1. Tương phản màu: kiểm chữ trên nền bằng công cụ đo tỉ lệ, đạt 4.5:1. Đừng dùng riêng màu để truyền thông tin (vd lỗi chỉ tô đỏ) — thêm icon hoặc chữ cho người loạn sắc.
2. Điều hướng bàn phím: bấm Tab đi hết trang theo thứ tự hợp lý, mọi nút/link đều tới được, có viền focus nhìn thấy rõ. Đây là lỗi đáng sửa đầu tiên.
3. Văn bản thay thế (alt): ảnh mang thông tin phải có alt mô tả; ảnh trang trí để alt rỗng để trình đọc bỏ qua.
4. Cấu trúc heading: dùng đúng cấp h1→h2→h3, không nhảy cóc — trình đọc màn hình dựa vào đây để quét trang.
5. Nhãn cho form: mỗi ô nhập có nhãn gắn đúng; thông báo lỗi nói rõ lỗi gì, sửa thế nào.
6. ARIA đúng chỗ: dùng ARIA để bổ sung ngữ nghĩa khi HTML thuần không đủ (vd nút chỉ có icon cần aria-label). Nguyên tắc: ưu tiên HTML ngữ nghĩa trước, ARIA chỉ để vá chỗ thiếu.
7. Tôn trọng cài đặt người dùng: hỗ trợ prefers-reduced-motion để tắt hiệu ứng cho người dễ choáng; bật được dark mode.

<!-- Nút chỉ có icon: bắt buộc có nhãn cho trình đọc -->
<button aria-label="Đóng cửa sổ">
  <svg aria-hidden="true">...</svg>
</button>

Vì sao đáng làm và còn là chuyện luật

Ngoài lý do đạo đức và mở rộng tệp người dùng, accessibility ngày càng mang tính pháp lý. Tại châu Âu, Đạo luật Tiếp cận châu Âu (European Accessibility Act) đã có hiệu lực từ giữa năm 2025, buộc nhiều dịch vụ số đạt chuẩn; ở Mỹ, các vụ kiện theo ADA nhắm vào website không tiếp cận được tăng đều nhiều năm. Một trang dễ tiếp cận cũng thường có HTML sạch, cấu trúc rõ — điều này giúp cả công cụ tìm kiếm đọc hiểu tốt hơn, nên accessibility và SEO đi cùng hướng.

Điểm cốt lõi: làm accessibility ngay từ khâu thiết kế rẻ hơn nhiều so với vá sau khi giao diện đã code xong. Khi bạn nhờ Web22 dựng website, vì đội vừa thiết kế vừa lập trình, các quy ước tiếp cận (tương phản, viền focus, vùng chạm) được đưa thẳng vào hệ thống component dùng lại, nên không bị thất lạc ở khâu bàn giao.

Câu hỏi thường gặp

Accessibility và usability khác nhau ra sao?

Usability là trang có dễ dùng với số đông không; accessibility là trang có dùng được với người khuyết tật và công nghệ hỗ trợ không. Hai cái chồng lấn nhưng không thay thế nhau — một trang có thể dễ dùng với người sáng mắt mà vẫn chặn người dùng bàn phím.

Có công cụ nào tự kiểm tra accessibility không?

Có các công cụ tự động như trình kiểm tra của trình duyệt hoặc plugin Lighthouse, bắt được lỗi tương phản, thiếu alt, sai cấu trúc. Nhưng tự động chỉ tìm được phần ngọn; nhiều tiêu chí (vd thứ tự tab có hợp lý không) vẫn phải kiểm thủ công bằng bàn phím và trình đọc màn hình.

Phải đạt mức AAA mới được không?

Không. Hầu hết khuyến nghị nhắm mức AA — đủ bao phủ rào cản phổ biến mà vẫn khả thi. AAA rất chặt, thường chỉ áp cho nội dung chuyên biệt, không bắt buộc cho cả trang.

Nếu bạn muốn một giao diện đạt chuẩn tiếp cận ngay từ bản thiết kế, tham khảo dịch vụ thiết kế trải nghiệm người dùng của Web22.