Cách làm cho website dễ tiếp cận: hướng dẫn nhập môn WCAG 2.2

Để làm cho website dễ tiếp cận, hãy xây dựng sao cho mọi người có thể dùng nó bằng bàn phím, trình đọc màn hình, phóng to hoặc thiết bị chuyển đổi, cũng như chuột: dùng các phần tử HTML thật cho nút, liên kết, tiêu đề và nhãn form; cung cấp văn bản thay thế có ý nghĩa cho hình ảnh; giữ độ tương phản văn bản cao và làm cho tiêu điểm nhìn thấy được. Tiêu chuẩn cần nhắm tới là WCAG 2.2 Mức AA. Công cụ kiểm tra tự động bắt được một phần vấn đề; một bài kiểm tra bằng bàn phím và trình đọc màn hình trong mười phút sẽ bắt được phần lớn phần còn lại.

“Dễ tiếp cận” nghĩa là gì trong thực tế

Khả năng tiếp cận là về con người: một người khiếm thị dùng trình đọc màn hình, một người bị run tay điều hướng bằng bàn phím, một người thị lực kém phóng to lên 200%, một người đọc dưới ánh nắng gay gắt, một người tạm thời bị gãy tay. Khả năng tiếp cận tốt thường khiến website tốt hơn cho tất cả mọi người — cấu trúc rõ ràng hơn, văn bản dễ đọc hơn, form giải thích lỗi của chúng.

Tiêu chuẩn tham chiếu là Web Content Accessibility Guidelines (WCAG) của W3C. Tính đến tháng 9 năm 2026, phiên bản hiện tại là WCAG 2.2 (công bố tháng 10 năm 2023, cập nhật tháng 12 năm 2024); WCAG 3 là bản nháp sơ khai. WCAG được tổ chức quanh bốn nguyên tắc — nội dung phải có thể cảm nhận, có thể vận hành, có thể hiểu và bền vững — và có ba mức tuân thủ:

Các luật ở nhiều nơi tham chiếu đến WCAG — ví dụ Đạo luật Khả năng tiếp cận Châu Âu, áp dụng cho nhiều dịch vụ số hướng tới người tiêu dùng tại EU từ tháng 6 năm 2025. Quy tắc nào áp dụng cho bạn phụ thuộc vào nơi bạn hoạt động và bạn bán gì; hãy hỏi chuyên gia tư vấn nếu bạn không chắc. Hướng dẫn này tập trung vào công việc thực tế.

Các lựa chọn: làm thế nào để đạt được

Với hầu hết website nhỏ, hai cách đầu là đủ: yêu cầu AI xây dựng theo hướng dễ tiếp cận ngay từ đầu, rồi kiểm tra trước khi ra mắt.

Những cách sửa quan trọng nhất

Dùng đúng phần tử HTML

Phần lớn khả năng tiếp cận có sẵn khi HTML đúng. Một <button> có thể lấy tiêu điểm, hoạt động với phím Enter và Space, và được đọc là nút. Một <div> có trình xử lý nhấp chuột thì không có cái nào trong số đó. Mã do AI tạo ra đôi khi dùng div có định kiểu cho mọi thứ; hãy yêu cầu các phần tử ngữ nghĩa:

• <button> cho hành động, <a href> cho điều hướng
• Một <h1> cho mỗi trang, sau đó <h2>, <h3> theo đúng thứ tự — người dùng trình đọc màn hình nhảy giữa các tiêu đề
• Các vùng (landmark): <header>, <nav>, <main>, <footer>
• <label> được liên kết với mọi trường form
• Ngôn ngữ của trang trong <html lang="en">

Chỉ dùng thuộc tính ARIA khi không có phần tử gốc nào phù hợp — ví dụ cho một bộ tab hoặc combobox tùy chỉnh. ARIA sai còn tệ hơn không có ARIA.

Truy cập bằng bàn phím và tiêu điểm nhìn thấy được

Mọi thứ bạn làm được bằng chuột phải dùng được bằng bàn phím (WCAG 2.1.1). Nhấn Tab qua trang: mọi liên kết, nút và trường nhập phải tới được theo thứ tự hợp lý, và bạn phải luôn thấy tiêu điểm đang ở đâu (2.4.7 Focus Visible). WCAG 2.2 bổ sung rằng phần tử đang có tiêu điểm không được bị che hoàn toàn bởi tiêu đề dính hoặc banner cookie (2.4.11, Mức AA).

Các lỗi thường gặp: menu chỉ mở khi di chuột, hộp thoại không giữ tiêu điểm hoặc không thể đóng bằng Escape, và outline: none trong CSS mà không có gì thay thế.

Văn bản thay thế

Mọi hình ảnh có ý nghĩa cần văn bản thay thế mô tả nó thể hiện điều gì trong ngữ cảnh (“Đầu bếp đang bày món ăn của thực đơn nếm thử”, không phải “image1.jpg”). Hình ảnh trang trí nhận alt="" rỗng để trình đọc màn hình bỏ qua. Nút chỉ có biểu tượng cần một tên có thể truy cập (“Đóng”, “Tìm kiếm”). Video cần phụ đề; âm thanh cần bản ghi lời.

Màu sắc và độ tương phản

WCAG 2.2 AA yêu cầu tỷ lệ tương phản ít nhất 4,5:1 cho văn bản thường và 3:1 cho văn bản lớn (1.4.3), và 3:1 cho các phần giao diện như viền ô nhập và biểu tượng có ý nghĩa (1.4.11). Văn bản placeholder màu xám nhạt và các nút nhạt là những lỗi phổ biến. Ngoài ra, đừng bao giờ chỉ dùng màu sắc để truyền đạt ý nghĩa — viền đỏ trên một trường không hợp lệ cũng cần một thông báo lỗi.

Thay đổi kích thước và bố cục lại

Văn bản phải vẫn dùng được khi phóng to 200% (1.4.4), và nội dung phải hoạt động ở chiều rộng 320 pixel CSS mà không phải cuộn ngang (1.4.10). Một bố cục responsive xử lý được phần lớn điều này.

Vùng chạm, form và lỗi

• Kích thước vùng chạm: WCAG 2.2 AA yêu cầu vùng chạm bằng con trỏ ít nhất 24 x 24 pixel CSS, hoặc có đủ khoảng cách quanh các vùng nhỏ hơn (2.5.8). Lớn hơn thì thân thiện hơn trên điện thoại.
• Form: nhãn hiển thị (không chỉ có placeholder), hướng dẫn rõ ràng, và thông báo lỗi nói rõ điều gì sai và cách sửa, đặt cạnh trường đó.
• Đăng nhập: đừng bắt người dùng giải câu đố hoặc chép lại mã mà không có phương án thay thế; cho phép trình quản lý mật khẩu và dán (3.3.8 Accessible Authentication).

Các lệnh hiệu quả

Xây dựng website này đạt WCAG 2.2 Mức AA: các vùng ngữ nghĩa HTML, một h1 cho mỗi trang với các tiêu đề đúng thứ tự, các phần tử nút và liên kết thật, nhãn cho mọi trường form, kiểu tiêu điểm nhìn thấy được, độ tương phản văn bản ít nhất 4,5:1, văn bản thay thế cho hình ảnh có ý nghĩa và alt="" cho hình trang trí, và thiết lập html lang.

Kiểm tra khả năng tiếp cận của các trang /signup và /checkout. Kiểm tra việc chỉ dùng bàn phím, thứ tự tiêu điểm, tiêu điểm nhìn thấy được, nhãn, thông báo lỗi, độ tương phản và tên mà trình đọc màn hình đọc cho nút biểu tượng. Liệt kê mỗi vấn đề kèm tiêu chí WCAG, rồi sửa mà không thay đổi thiết kế thị giác nhiều hơn mức cần thiết.

Menu di động không dùng được bằng bàn phím. Hãy biến nó thành một nút có aria-expanded, đưa tiêu điểm vào menu khi mở, đóng bằng Escape và trả tiêu điểm về nút.

Từng bước

1. Chạy kiểm tra tự động. Mục Accessibility của Lighthouse trong Chrome DevTools, hoặc tiện ích axe cho trình duyệt, trên mỗi trang chính. Sửa mọi thứ nó báo cáo.
2. Tháo chuột ra. Nhấn Tab qua từng trang và hoàn thành mọi tác vụ chính — đăng ký, tìm kiếm, thanh toán. Ghi lại bất cứ thứ gì bạn không tới được, không thấy tiêu điểm, hoặc không thể thoát khỏi.
3. Phóng to 200% và thu hẹp cửa sổ về chiều rộng điện thoại. Không có gì bị cắt hoặc phải cuộn ngang.
4. Thử trình đọc màn hình trong mười phút: VoiceOver trên Mac và iPhone, TalkBack trên Android, hoặc NVDA trên Windows (miễn phí). Nghe các tiêu đề, liên kết và trường form. “Nút” mà không có tên, hoặc “liên kết, bấm vào đây”, nghĩa là còn việc phải làm.
5. Kiểm tra độ tương phản của văn bản, nút và ô nhập bằng công cụ kiểm tra tương phản.
6. Sửa, rồi kiểm tra lại cùng các tác vụ đó.
7. Xuất bản tuyên bố về khả năng tiếp cận nói rõ bạn nhắm tới tiêu chuẩn nào và cách báo cáo vấn đề — rồi trả lời các báo cáo đó.

Các lỗi thường gặp

• Dựa vào tiện ích phủ (overlay) thay vì sửa mã.
• Xóa viền tiêu điểm vì trông lộn xộn, không có gì thay thế.
• Văn bản placeholder là nhãn duy nhất. Nó biến mất khi người dùng bắt đầu gõ và thường có độ tương phản thấp.
• Liên kết “Bấm vào đây” và “Đọc thêm”. Khi đứng riêng, người dùng trình đọc màn hình nghe một danh sách các liên kết giống hệt nhau.
• Văn bản thay thế nhồi từ khóa. Văn bản thay thế dành cho con người; hãy mô tả hình ảnh.
• Chỉ kiểm tra một lần. Mỗi tính năng mới có thể làm hỏng khả năng truy cập bằng bàn phím. Thêm một lượt kiểm tra bàn phím vào kiểm thử trước khi ra mắt của bạn.

Danh sách kiểm tra khả năng tiếp cận

• Kiểm tra tự động (Lighthouse hoặc axe) không có lỗi trên các trang chính
• Mọi tác vụ đều hoàn thành được chỉ bằng bàn phím
• Tiêu điểm luôn nhìn thấy được và không bị che bởi phần tử dính
• Tiêu đề, vùng, nút và liên kết ngữ nghĩa; đã thiết lập lang
• Văn bản thay thế có ý nghĩa; hình trang trí có alt=""; có phụ đề cho video
• Độ tương phản văn bản ≥ 4,5:1 (văn bản lớn ≥ 3:1); thành phần giao diện ≥ 3:1
• Dùng được ở mức phóng to 200% và chiều rộng 320 px
• Mọi trường form có nhãn hiển thị và thông báo lỗi rõ ràng
• Có tuyên bố về khả năng tiếp cận kèm cách báo cáo vấn đề

Để hiểu các khái niệm đằng sau, đọc khả năng tiếp cận web là gì. Thiết kế dễ tiếp cận và thiết kế đẹp có nhiều điểm chung; cách thiết kế ứng dụng đẹp mắt với AI bàn về khía cạnh thị giác.

Khả năng tiếp cận trên Mythex

Mythex xây dựng theo bất kỳ tiêu chuẩn nào bạn yêu cầu, nên hãy đưa “WCAG 2.2 AA” vào lệnh đầu tiên và các yêu cầu tiếp theo. Bạn có thể dùng khung xem điện thoại của Preview để kiểm tra màn hình nhỏ (Preview và Code), nhưng các bài kiểm tra bàn phím, phóng to và trình đọc màn hình hoạt động tốt nhất trên URL đã xuất bản hoặc bản xem trước mở trong một tab riêng. Yêu cầu tác nhân kiểm tra một trang, sửa những gì nó tìm thấy, rồi tự kiểm tra các bản sửa — một lượt kiểm tra tự động chỉ là khởi đầu, không phải là sự chấp thuận cuối cùng.

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