Họ đang đo gì
Bạn có coi khả năng tiếp cận là một phần của công việc hay là việc của người khác.
Trả lời ngắn~30 giây
Trước hết dùng đúng thẻ: <button> đã có focus, có phím Enter/Space, có vai trò đúng — một <div onClick> thì không có gì cả. Nếu buộc phải tự dựng, bạn phải tự cấp bốn thứ: tabindex để nhận focus, xử lý phím tương ứng, role và aria-* để nói ra trạng thái, và một vòng focus rõ ràng nhìn thấy được. Kiểm tra nhanh nhất là cất chuột đi và thử dùng trang bằng Tab.
Giải thích sâu
Sai lầm hay gặp nhất không phải thiếu ARIA mà là thừa và sai. role="button" trên một <div> khiến trình đọc màn hình nói “nút”, nhưng phím Space vẫn cuộn trang thay vì kích hoạt, nên người dùng nghe thấy một cái nút không bấm được — tệ hơn là không có gì. ARIA chỉ mô tả, nó không thêm hành vi nào.
Với các thành phần có lớp phủ — modal, dropdown — phần khó là quản lý focus: focus phải đi vào khi mở, bị giữ lại bên trong khi còn mở, và quay về đúng phần tử đã kích hoạt khi đóng. Thiếu bước cuối cùng khiến người dùng bàn phím bị ném về đầu trang mỗi lần đóng hộp thoại, và đó là lỗi tiếp cận bị bỏ sót nhiều nhất trong các dự án mình từng xem.
Một điểm nữa đáng biết: display: none và visibility: hidden cũng ẩn khỏi trình đọc màn hình, nhưng opacity: 0 hay đẩy ra ngoài màn hình thì KHÔNG — nội dung vẫn được đọc và vẫn nhận được Tab. Đó là lý do một menu “đã đóng” bằng opacity vẫn khiến người dùng bàn phím tab qua mười liên kết vô hình.
Câu hỏi tiếp theo họ sẽ hỏi
?Kiểm tra bằng công cụ nào?
axe DevTools hoặc Lighthouse bắt được khoảng một phần ba vấn đề — chủ yếu là tương phản màu và thuộc tính thiếu. Phần còn lại phải kiểm tra tay: đi bằng Tab, và bật trình đọc màn hình có sẵn (VoiceOver, NVDA) nghe thử một luồng.
Trả lời thế này là mất điểm
- Xoá vòng focus bằng
outline: nonemà không thay bằng gì. Đây là một dòng CSS làm trang không dùng được bằng bàn phím.