Tự kiểm thử khả năng truy cập website trong 30 phút: bàn phím, phóng to và trình đọc màn hình

Cập nhật tháng 10/2026. Phím tắt và vị trí cài đặt của trình đọc màn hình có thể khác đôi chút theo phiên bản hệ điều hành; bài dẫn tài liệu gốc để bạn đối chiếu.

Nhiều người coi khả năng truy cập (accessibility) là “tính năng” cho người khiếm thị, làm sau cũng được. Bài này nhìn ngược lại: trang mà bàn phím không bấm được nút, phóng to thì vỡ bố cục, trình đọc màn hình đọc thành “nút, nút, ảnh” là trang làm chưa xong. Phần lớn lỗi lộ rõ bạn tự tìm được trong 30 phút.

1. Khả năng truy cập là chất lượng, không phải tính năng thêm

Theo W3C, khả năng truy cập web là thiết kế để người khuyết tật cũng dùng được, nhưng người hưởng lợi rộng hơn: người xem điện thoại dưới nắng, người tạm gãy tay, người lớn tuổi mắt kém. Chuẩn chung là WCAG 2.2, mục tiêu thường là mức AA.

Coi đây là chất lượng nghĩa là kiểm nó như kiểm chính tả: lần nào sửa giao diện cũng kiểm lại. Hai bài trước đã đi sâu từng mảng: thiết kế form liên hệ dễ dùng và màu sắc, độ tương phản. Bài này là bài kiểm tổng thể, dựa trên bộ Easy Checks của W3C WAI.

2. Chuẩn bị trong 3 phút

3. Phút 3–10: cất chuột, chỉ dùng bàn phím

Bấm vào thanh địa chỉ rồi nhấn Tab liên tục. Shift+Tab để lùi, Enter để mở liên kết, Space để bấm nút hay đánh dấu ô chọn, phím mũi tên trong danh sách chọn, Esc để đóng popup. Safari trên Mac mặc định Tab bỏ qua liên kết, nên dùng Chrome cho nhanh.

Để ý bốn điều:

• Có thấy mình đang ở đâu không? Phần tử nhận focus phải có viền nổi rõ (tiêu chí 2.4.7). Lỗi hay gặp: theme đặt outline: none; sửa gọn bằng :focus-visible.
• Focus có bị che không? Tiêu chí mới 2.4.11 của WCAG 2.2: phần tử đang focus không bị menu dính, banner cookie hay nút chat che kín.
• Thứ tự có hợp lý không? Focus đi theo thứ tự đọc; nhảy lung tung thường do CSS đảo vị trí hoặc tabindex dương.
• Có bị kẹt không? Menu, popup, bản đồ nhúng: vào được thì phải ra được (tiêu chí 2.1.2).

Ví dụ minh hoạ: một phòng khám nha khoa có nút “Đặt lịch” là thẻ div gắn sự kiện click. Chuột bấm được, Tab thì bỏ qua, nên người không dùng chuột không đặt lịch được. Đổi sang button là xong.

4. Phút 10–14: phóng to 200% rồi 400%

Nhấn Ctrl và + (trên Mac là Cmd và +) đến 200%. Theo tiêu chí 1.4.4, nội dung và chức năng phải còn đủ: chữ không cắt, không đè, nút không bị đẩy khỏi màn hình.

Lên tiếp 400% trên cửa sổ rộng 1280px. Tiêu chí 1.4.10 (Reflow) yêu cầu không phải cuộn ngang, trừ bảng, bản đồ. Lỗi hay gặp: menu dính chiếm nửa màn hình.

5. Phút 14–22: nghe trang bằng trình đọc màn hình có sẵn

Không cần mua phần mềm:

Tập vài phút trước vì cử chỉ thay đổi khi bật. Rồi nghe ba thứ: tên nút, liên kết có rõ đích đến không (“Xem chi tiết” lặp mười lần là vô nghĩa), ô nhập có được đọc nhãn không, thông báo lỗi có được đọc lên không.

6. Phút 22–26: văn bản thay thế ảnh và tiêu đề phân cấp

Văn bản thay thế (alt): ảnh mang thông tin cần alt nói đúng thông tin đó, không phải “banner1.jpg”. Ảnh trang trí để alt=''. Ảnh trong liên kết thì alt mô tả đích đến.

Tiêu đề phân cấp: người dùng trình đọc thường lướt trang bằng danh sách tiêu đề như đọc mục lục. Nên có một h1, rồi h2, h3 đúng cấp, không nhảy cóc vì muốn chữ nhỏ. Kiểm luôn tiêu đề tab và lang='vi' để đọc đúng tiếng Việt.

7. Phút 26–30: Lighthouse và axe bắt phần máy bắt được

Trong Chrome, mở DevTools, tab Lighthouse, tích Accessibility rồi chạy. Theo Chrome, điểm là trung bình có trọng số của các bài kiểm tự động; mục kiểm tay không được tính. Tiện ích axe DevTools miễn phí chỉ thẳng phần tử lỗi.

Đừng dừng ở điểm 100: nhóm axe-core cho biết công cụ tự động tìm được trung bình khoảng 57% lỗi WCAG. Alt có đúng nghĩa không, focus có hợp lý không, chỉ con người kiểm được.

8. Checklist 30 phút

• Mọi liên kết, nút, ô nhập đều tới được bằng Tab và dùng được bằng Enter hoặc Space.
• Luôn nhìn thấy viền focus; focus không bị menu dính, banner cookie hay nút chat che kín.
• Không bị kẹt trong menu, popup, bản đồ; Esc đóng được popup.
• Phóng to 200%: chữ không cắt, không đè; 400%: không phải cuộn ngang.
• Trình đọc màn hình đọc được tên rõ nghĩa cho nút, liên kết, ô nhập và thông báo lỗi.
• Ảnh mang thông tin có alt đúng nghĩa; ảnh trang trí có alt=''.
• Một h1, tiêu đề theo đúng cấp; tiêu đề tab và lang='vi' đúng.
• Lighthouse và axe không còn lỗi mức nghiêm trọng; các mục kiểm tay đã được rà.

Bài học: đưa checklist vào bước nghiệm thu mỗi lần sửa giao diện, và sửa ở theme, component dùng chung để một lần sửa có hiệu lực cho cả site.

9. Thuật ngữ cần biết

• WCAG: bộ hướng dẫn khả năng truy cập nội dung web của W3C, phiên bản hiện hành 2.2, chia ba mức A, AA, AAA. Nguồn: WCAG 2.2.
• Focus visible (chỉ báo focus): dấu hiệu nhìn thấy cho biết phần tử nào đang nhận thao tác bàn phím. Nguồn: Understanding Focus Visible.
• Trình đọc màn hình (screen reader): phần mềm đọc to hoặc xuất ra chữ nổi nội dung trên màn hình, như VoiceOver, TalkBack, NVDA. Nguồn: VoiceOver User Guide.
• Reflow: khả năng nội dung tự xếp lại khi phóng to mà không phải cuộn theo hai chiều. Nguồn: Understanding Reflow.

10. Tìm hiểu thêm

• Easy Checks – A First Review of Web Accessibility: bộ kiểm tra nhanh của W3C WAI, nền của bài này.
• An alt Decision Tree: chọn cách viết alt cho từng loại ảnh.
• Learn Accessibility trên web.dev và :focus-visible trên MDN.
• Bắt đầu với TalkBack, bật và tập VoiceOver trên iPhone, tải NVDA.
• Cách Lighthouse tính điểm accessibility và axe-core trên GitHub.

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

PDL Digital đào tạo đội làm web và nội dung kiểm thử, sửa lỗi khả năng truy cập trong quy trình hằng ngày, kể cả dùng AI để rà nhanh hơn. Xem trang đào tạo để chọn khoá phù hợp.