🔄 Tóm tắt bài học: Trong bài học trước, bạn đã nắm vững thiết kế đáp ứng – kiểu chữ linh hoạt, hình ảnh đáp ứng và bố cục ưu tiên thiết bị di động. Giờ hãy đảm bảo các trang của bạn có thể sử dụng được cho tất cả mọi người, bao gồm cả những người điều hướng bằng bàn phím, trình đọc màn hình hoặc các công nghệ hỗ trợ khác.
Trợ năng không phải là một tính năng – mà là một thuộc tính chất lượng của tất cả code frontend tốt. Ước tính có khoảng 15-20% dân số toàn cầu mắc một dạng khuyết tật nào đó. Ngoài vấn đề đạo đức, Trợ năng còn là yêu cầu pháp lý ở nhiều khu vực pháp lý và cải thiện khả năng sử dụng cho tất cả mọi người.
Tham khảo nhanh WCAG
WCAG (Web Content Accessibility Guidelines) có 4 nguyên tắc:
Nguyên tắc
Ý nghĩa
Các yêu cầu chính
Có thể nhận biết được
Người dùng có thể cảm nhận nội dung
Văn bản thay thế, độ tương phản, chú thích
Có thể vận hành
Người dùng có thể tương tác
Điều hướng bằng bàn phím, không có nội dung gây giật
Có thể hiểu được
Nội dung rõ ràng
Văn bản dễ đọc, điều hướng dễ hiểu
Mạnh mẽ
Tương thích với công nghệ hỗ trợ
HTML hợp lệ, ARIA khi cần thiết
Mức độ tuân thủ:
A: Tối thiểu (đã loại bỏ các rào cản thiết yếu)
AA: Tiêu chuẩn (hầu hết các tổ chức đều hướng đến mức này)
AAA: Nâng cao (nghiêm ngặt nhất, không phải lúc nào cũng đạt được)
Điều hướng bằng bàn phím
Mọi yếu tố tương tác phải có thể truy cập bằng bàn phím:
Hành động
Bàn phím
Yêu cầu
Điều hướng giữa các thành phần
Tab / Shift+Tab
Thứ tự tab hợp lý
Kích hoạt nút/liên kết
Enter (liên kết), Enter/Space (nút)
Tất cả các phần tử có thể nhấp chuột
Điều hướng bên trong thành phần
Các phím mũi tên
Menu drop-down, tab, menu
Hủy bỏ/đóng
Escape
Cửa sổ pop-up, menu drop-down, chú thích công cụ
Gửi biểu mẫu
Enter
Từ bất kỳ trường biểu mẫu nào
Các nguyên tắc quản lý sự tập trung:
Quy tắc
Triển khai
Chỉ báo tiêu điểm hiển thị
outline hoặc box-shadow trên :focus-visible
Không bao giờ xóa đường viền tiêu điểm
Đừng sử dụng outline: none mà không có sự thay thế
Thứ tự tab hợp lý
Sắp xếp thứ tự hiển thị sao cho phù hợp, hạn chế sử dụng tabindex="0"
Giữ tiêu điểm trong hộp thoại modal
Tab sẽ vẫn nằm trong hộp thoại cho đến khi được đóng
Khôi phục tiêu điểm
Sau khi đóng cửa sổ modal, hãy trả lại tiêu điểm cho trình kích hoạt
Prompt AI cho việc kiểm tra bàn phím:
Kiểm tra trợ năng bàn phím của HTML này: [DÁN]. Kiểm tra: (1) Tất cả các phần tử tương tác có nhận được tiêu điểm không? (2) Thứ tự tab có hợp lý không (phù hợp với thứ tự hiển thị)? (3) Các thành phần tùy chỉnh (menu drop-down, cửa sổ pop-up) có hỗ trợ những kiểu bàn phím dự kiến không? (4) Có chỉ báo tiêu điểm hiển thị không? (5) Tiêu điểm có được quản lý chính xác cho nội dung động không (cửa sổ pop-up giữ tiêu điểm, đóng cửa sổ sẽ khôi phục tiêu điểm)?
ARIA: Khi HTML không đủ
Quy tắc ARIA: Sử dụng Semantic HTML trước. ARIA được sử dụng khi HTML gốc không thể hiện được kiểu tương tác.
Mẫu
HTML gốc
ARIA (nếu cần)
Điều hướng
<nav>
role="navigation"
Nút
<button>
role="button" + tabindex="0"
Modal
<dialog>
role="dialog" + aria-modal="true"
Giao diện tab
Không phải gốc
role="tablist", role="tab", role="tabpanel"
Cập nhật trực tiếp
Không phải gốc
aria-live="polite" hoặc role="alert"
Các thuộc tính ARIA phổ biến:
Thuộc tính
Mục đích
Ví dụ
aria-label
Tên dễ tiếp cận
<nav aria-label="Main">
aria-labelledby
Tên được đặt từ một yếu tố khác
<dialog aria-labelledby="title">
aria-describedby
Mô tả bổ sung
<input aria-describedby="help-text">
aria-expanded
Trạng thái mở/đóng
<button aria-expanded="false">
aria-hidden
Ẩn khỏi trình đọc màn hình
<span aria-hidden="true">★</span>
aria-live
Thông báo những thay đổi động
<div aria-live="polite">
aria-current
Chỉ báo mục hiện tại
<a aria-current="page">Home</a>
Màu sắc & Độ tương phản
Yêu cầu
Cấp độ WCAG
Tỷ lệ
Văn bản thông thường
AA
4.5:1
Chữ cỡ lớn (18px trở lên, in đậm hoặc 24px trở lên)
AA
3:1
Các yếu tố không phải văn bản (biểu tượng, đường viền)
AA
3:1
Văn bản thông thường
AAA
7:1
Prompt AI để kiểm tra độ tương phản:
Kiểm tra tất cả các tổ hợp màu trên trang của tôi để đảm bảo tuân thủ WCAG AA. Màu sắc của tôi: văn bản #1f2937 trên nền #ffffff, liên kết #3b82f6 trên nền #ffffff, văn bản nút #ffffff trên nền nút #3b82f6. Đối với bất kỳ tổ hợp nào không đạt yêu cầu, hãy đề xuất màu sắc gần nhất đáp ứng yêu cầu.
Giảm chuyển động
Hãy tôn trọng người dùng thích ít hiệu ứng động hơn:
📍 Nơi dán: Mở ChatGPT (chat.openai.com), Claude (claude.ai) hoặc Gemini (gemini.google.com) và bắt đầu một cuộc trò chuyện mới.
📋 Cách sao chép prompt này: Nhấp vào bất kỳ đâu bên trong khối màu xám, nhấn Cmd+A sau đó Cmd+C (Mac) hoặc Ctrl+A sau đó Ctrl+C (Windows). Hoặc sử dụng biểu tượng sao chép xuất hiện.
✏️ Cách điền thông tin chi tiết: Thay thế mỗi dấu ngoặc vuông [] và trình giữ chỗ trong ngoặc bằng thông tin cụ thể từ tình huống thực tế của bạn. Thông tin đầu vào mơ hồ sẽ tạo ra kết quả đầu ra mơ hồ — hãy cụ thể.
👀 Những gì bạn sẽ thấy: Trong vòng vài giây, AI sẽ trả về một phản hồi có cấu trúc dựa vào prompt ở trên. Hãy đọc kỹ và coi đó là bản nháp, không phải là câu trả lời cuối cùng.
📌 Nên làm gì với kết quả đầu ra: Lưu phản hồi vào file Notes. Chọn đề xuất có tác động cao nhất và thực hiện nó trong tuần này — đừng cố gắng làm mọi thứ cùng một lúc.
⚠️ Nếu thấy không ổn: Nếu các đề xuất có vẻ chung chung, hãy dán nội dung sau: "Hãy cụ thể hơn với ngữ cảnh thực tế của tôi. Bỏ qua những lời khuyên chung chung đi." Nếu bỏ qua các chi tiết quan trọng bạn đã cung cấp, hãy hỏi: "Bạn đã bỏ sót [X] trong ngữ cảnh của tôi — hãy thực hiện lại với đó là ràng buộc chính."
✅ Kiểm tra nhanh: Trang của bạn sử dụng một biểu tượng trang trí (hiển thị xếp hạng sao bằng biểu tượng cảm xúc ngôi sao). Các ngôi sao có cần văn bản thay thế (alt text) không?
Câu trả lời: Nội dung trang trí truyền tải thông tin cần có văn bản thay thế. Nếu các ngôi sao đại diện cho xếp hạng 4/5, hãy thêm aria-label="Rating: 4 out of 5" vào container và aria-hidden="true" vào từng ký tự ngôi sao riêng lẻ. Hình ảnh thuần túy trang trí không truyền tải thông tin nào nên có alt trống: alt="". Sự khác biệt nằm ở chỗ hình ảnh có truyền tải thông tin có ý nghĩa hay không.
Quy trình kiểm tra khả năng trợ năng
Bước
Công cụ
Lỗi tìm được
1. Quét tự động
axe DevTools, Lighthouse
Thiếu thông tin thay thế, độ tương phản và nhãn (~30-40%)
2. Kiểm tra bàn phím
Bàn phím của bạn (không dùng chuột)
Thứ tự tab, giữ tiêu điểm, tương tác bị thiếu
3. Trình đọc màn hình
VoiceOver (Mac), NVDA (Windows)
Thứ tự thông báo, nhãn bị thiếu, khu vực trực tiếp
4. Kiểm tra khả năng zoom
Phóng to trình duyệt lên 200%
Nội dung bị tràn, bị cắt bớt
5. Kiểm tra màu sắc
Vô hiệu hóa màu CSS
Thông tin không chỉ được truyền tải qua màu sắc
Những điểm chính cần ghi nhớ
Kiểm thử tự động chỉ phát hiện được 30-40% vấn đề trợ năng: Sau khi chạy axe/Lighthouse, hãy điều hướng thủ công qua trang bằng phím Tab (kiểm thử bàn phím), sử dụng trình đọc màn hình (kiểm thử thông báo) và phóng to lên 200% (kiểm thử trực quan) để tìm ra các vấn đề mà công cụ bỏ sót.
Nội dung động (thông báo, lỗi biểu mẫu, trạng thái load) không hiển thị với trình đọc màn hình trừ khi được thông báo: Sử dụng aria-live="polite" cho các cập nhật thông tin và role="alert" cho những thông báo khẩn cấp — đây là yêu cầu về trợ năng thường bị bỏ sót nhất trong code do AI tạo ra.
Độ tương phản màu sắc có thể đo lường được và không thể thương lượng: 4.5:1 cho văn bản bình thường, 3:1 cho văn bản lớn (WCAG AA) — khi thiết kế không đáp ứng được độ tương phản, hãy đề xuất màu sắc tuân thủ gần nhất thay vì một màu hoàn toàn khác để duy trì ý đồ thiết kế trong khi vẫn đáp ứng tiêu chuẩn.
Câu 1:
Trang của bạn có một thông báo xuất hiện sau khi gửi biểu mẫu: 'Tin nhắn của bạn đã được gửi thành công!' Người dùng có thị lực bình thường sẽ thấy thông báo này. Người dùng sử dụng trình đọc màn hình thì không nghe thấy gì. Làm thế nào để khắc phục điều này?
GIẢI THÍCH:
Các thay đổi nội dung động sẽ không hiển thị với trình đọc màn hình trừ khi được thông báo rõ ràng. Các vùng `aria-live` và `role="alert"` cho trình đọc màn hình biết cần thông báo các thay đổi nội dung. Điều này áp dụng cho tất cả giao diện người dùng động: thông báo, lỗi biểu mẫu, trạng thái load và cập nhật nội dung. Sự khác biệt giữa 'lịch sự' (chờ cho đến khi lời nói hiện tại kết thúc) và 'quyết đoán' (ngắt ngay lập tức) rất quan trọng — chỉ sử dụng quyết đoán cho các lỗi và cảnh báo quan trọng.
Câu 2:
Một nhà thiết kế đưa cho bạn một nút có văn bản màu trắng (#ffffff) trên nền màu xanh nhạt (#60a5fa). Nó trông rất tuyệt về mặt hình ảnh. Bạn kiểm tra tỷ lệ tương phản và nó là 2.8:1. WCAG AA yêu cầu 4.5:1 cho văn bản thông thường. Bạn sẽ làm gì?
GIẢI THÍCH:
Tỷ lệ tương phản màu sắc là một yêu cầu về trợ năng có thể đo lường được và không thể thương lượng. WCAG AA quy định tỷ lệ 4.5:1 cho chữ thường và 3:1 cho chữ lớn. Độ tương phản thấp ảnh hưởng đến tất cả mọi người dưới ánh sáng mặt trời mạnh, không chỉ người dùng thị lực kém. Cách tiếp cận hiệu quả là trình bày cho nhà thiết kế màu sắc gần nhất với tiêu chuẩn (không phải một màu hoàn toàn khác) — nó duy trì ý đồ thiết kế trong khi vẫn đáp ứng tiêu chuẩn.
Câu 3:
Trang của bạn vượt qua bài kiểm tra trợ năng tự động (axe DevTools không hiển thị vấn đề nào). Điều này có nghĩa là trang của bạn có thể truy cập được không?
GIẢI THÍCH:
Kiểm tra trợ năng tự động là bước đầu tiên cần thiết nhưng chỉ phát hiện được chưa đến một nửa các vấn đề thực tế. Các vấn đề ảnh hưởng nhất — thứ tự tab không hợp lý, văn bản thay thế vô nghĩa, luồng trình đọc màn hình bị lỗi và thiếu thông báo nội dung động — yêu cầu kiểm tra thủ công. Cách tiếp cận tốt nhất: kiểm tra tự động (axe, Lighthouse) cho những vấn đề dễ giải quyết, sau đó kiểm tra thủ công bằng bàn phím và trình đọc màn hình cho mọi thứ khác.
Theo Nghị định 147/2024/ND-CP, bạn cần xác thực tài khoản trước khi sử dụng tính năng này. Chúng tôi sẽ gửi mã xác thực qua SMS hoặc Zalo tới số điện thoại mà bạn nhập dưới đây: