Kiểm tra khả năng tiếp cận website: nhóm lỗi cần soát và giới hạn của công cụ tự động
Công cụ tải HTML thật của trang bạn nhập và kiểm tra trực tiếp một nhóm tiêu chí WCAG diễn đạt được thành quy tắc máy móc: thuộc tính lang, thẻ title, meta viewport và việc chặn phóng to, chữ thay thế cho ảnh, nhãn liên kết với ô nhập, cấu trúc cấp tiêu đề, link/button không có tên cho trình đọc màn hình, iframe thiếu title, và id bị trùng lặp. Mỗi vấn đề ghi kèm mã tiêu chí WCAG liên quan. Điểm số là điểm tham khảo tính theo công thức cố định (trừ điểm theo từng nhóm lỗi tìm thấy), không phải số ngẫu nhiên và không phải tỷ lệ tuân thủ WCAG. Công cụ không kiểm tra được tương phản màu hay nội dung được render bằng JavaScript phía client, nên hãy dùng phần nội dung bên dưới làm danh sách kiểm tra bổ sung.
Tính năng nổi bật
- Tải HTML thật của URL bạn nhập và phân tích trực tiếp, không dùng dữ liệu dựng sẵn
- Hiển thị điểm tham khảo trên thang 100 kèm thanh tiến trình, màu phân mức và công thức tính ngay dưới điểm
- Liệt kê nhóm lỗi theo hai mức: lỗi cần sửa và cảnh báo cần xem lại
- Kiểm tra lang, title, viewport và chặn phóng to, alt ảnh, label form, cấu trúc heading, link/button không có tên, iframe thiếu title, id trùng lặp
- Ghi mã tiêu chí WCAG và mức A hoặc AA cạnh từng lỗi, tách riêng những mục chỉ là thực hành tốt
- Cho biết số ảnh, trường form, tiêu đề, liên kết, nút và iframe đã đọc được, kèm cảnh báo khi HTML gần như trống vì trang dựng bằng JavaScript
- Điểm số tính theo công thức cố định dựa trên số lỗi thực tế tìm thấy, không phải số ngẫu nhiên
- Báo lỗi rõ ràng nếu không tải được trang hoặc domain không hợp lệ
- Không lưu lại URL hay nội dung trang bạn kiểm tra
- Phần nội dung bên dưới đóng vai trò danh sách kiểm tra để bạn tự rà soát thêm phần máy không kiểm tra được
Vì sao khả năng tiếp cận là việc phải làm, không phải việc nên làm
Một website khó tiếp cận không chỉ gây khó cho người khiếm thị. Nhóm bị ảnh hưởng rộng hơn nhiều: người lớn tuổi mắt kém đọc chữ xám nhạt trên nền trắng, người dùng chỉ điều khiển được bàn phím vì đau cổ tay, người dùng điện thoại ngoài trời nắng chói, người xem video ở nơi ồn không nghe được tiếng, người dùng máy cũ tải ảnh chậm nên chỉ thấy phần chữ thay thế. Mọi cải thiện về khả năng tiếp cận đều là cải thiện trải nghiệm cho toàn bộ người dùng. Thêm vào đó, phần lớn kỹ thuật đúng về tiếp cận trùng khớp với kỹ thuật đúng về tối ưu tìm kiếm: cấu trúc tiêu đề mạch lạc, chữ thay thế mô tả đúng ảnh, nhãn rõ ràng cho biểu mẫu, đánh dấu ngôn ngữ của trang. Điều khiến việc này hay bị bỏ qua là nó vô hình với người phát triển: bạn không nhìn thấy lỗi tiếp cận khi ngồi trước màn hình lớn với chuột và mắt tốt. Vì vậy cần một danh sách kiểm tra có hệ thống, và đó là thứ phần dưới đây cung cấp.
Lợi ích khi sử dụng
- Có danh sách nhóm lỗi cụ thể để rà soát thay vì kiểm tra theo cảm tính
- Biết rõ ranh giới giữa phần máy kiểm tra được và phần bắt buộc phải kiểm tra bằng tay
- Các mốc số cụ thể về tương phản màu và kích thước vùng bấm để đối chiếu ngay khi thiết kế
- Phần lớn việc sửa lỗi tiếp cận cũng cải thiện cấu trúc trang cho công cụ tìm kiếm
- Thứ tự ưu tiên rõ ràng giúp nhóm nhỏ biết sửa gì trước khi thời gian có hạn
Cách rà soát khả năng tiếp cận cho một trang
- 1Nhập địa chỉ trang vào ô phía trên và bấm Kiểm tra để quét nhanh HTML của trang, rồi chạy thêm một lượt bằng phần kiểm tra tiếp cận có sẵn trong công cụ dành cho nhà phát triển của trình duyệt để phủ phần tương phản màu và nội dung do JavaScript dựng.
- 2Sửa hết các lỗi máy bắt được, vì đó là nhóm rẻ nhất và rõ ràng nhất: thiếu chữ thay thế, thiếu nhãn biểu mẫu, thiếu thuộc tính ngôn ngữ, tương phản màu không đạt.
- 3Rút chuột ra và dùng phím Tab đi hết trang, kiểm tra xem có tới được mọi thành phần bấm được không và viền tiêu điểm có luôn nhìn thấy không.
- 4Phóng to trình duyệt lên hai trăm phần trăm và thu cửa sổ về khoảng 320 pixel CSS bề ngang, xem nội dung có bị cắt, chồng lên nhau hoặc buộc phải cuộn ngang không.
- 5Cuối cùng đọc lại trang bằng trình đọc màn hình hoặc nhờ người dùng thật kiểm tra, vì phần lớn tiêu chí quan trọng không có cách nào kiểm tra tự động.
Công cụ này kiểm tra thật những gì, và điểm số tính như thế nào
Khi bạn nhập một địa chỉ và bấm kiểm tra, máy chủ tải trực tiếp mã HTML của trang đó về và phân tích bằng một trình phân tích DOM thật, giống cách trình duyệt đọc trang. Các mục được kiểm tra: thẻ html có thuộc tính lang hay không, trang có thẻ title hay không, có khai báo meta viewport hay không, bao nhiêu ảnh thiếu thuộc tính alt, bao nhiêu ô nhập không có nhãn liên kết, cấu trúc cấp tiêu đề có nhảy cóc hay thiếu H1 không, có link hoặc button nào không có nội dung cho trình đọc màn hình không, và có id nào bị trùng lặp không. Ngoài ra công cụ còn xem thẻ viewport có chặn phóng to không, nút dạng input type image có alt không và thẻ iframe có title không. Điểm số bắt đầu từ 100, trừ 8 điểm cho mỗi nhóm lỗi và 4 điểm cho mỗi nhóm cảnh báo tìm thấy, nên cùng một trang sẽ luôn ra cùng một điểm, không có yếu tố ngẫu nhiên. Thiếu H1, nhiều H1 hay tiêu đề nhảy cấp được xếp vào cảnh báo vì WCAG không bắt buộc cấu trúc cụ thể đó, đây là thực hành tốt. Giới hạn cần biết: công cụ chỉ đọc HTML tĩnh trả về từ server, nên không đánh giá được tỷ lệ tương phản màu (cần dựng CSS thật) và không thấy được nội dung được JavaScript chèn thêm sau khi trang tải xong (ví dụ các trang React/Vue render phía client). Với hai nhóm đó, hãy dùng thêm axe DevTools hoặc Lighthouse như phần dưới đây hướng dẫn.
Công cụ tự động thật bắt được gì và không bắt được gì
Ngay cả những công cụ rà soát tốt nhất cũng chỉ kiểm tra được phần tiêu chí có thể diễn đạt thành quy tắc máy móc, và phần đó là thiểu số trong toàn bộ danh sách tiêu chí. Máy kiểm tra tốt các lỗi có mặt hoặc vắng mặt: ảnh có thuộc tính chữ thay thế hay không, ô nhập có nhãn liên kết hay không, trang có khai báo ngôn ngữ hay không, tỷ lệ tương phản giữa hai màu là bao nhiêu, thứ tự cấp tiêu đề có nhảy cóc hay không. Máy không kiểm tra được chất lượng: một tấm ảnh biểu đồ có chữ thay thế ghi đúng một chữ hình ảnh thì vẫn qua được máy nhưng hoàn toàn vô dụng với người dùng trình đọc màn hình. Máy cũng không biết thứ tự đọc có hợp lý không, tên của một nút có mô tả đúng hành động không, thông báo lỗi có được truyền tới người dùng không nhìn thấy màn hình không, hay một video có phụ đề đúng nội dung hay chỉ là phụ đề tự động sai bét. Kết luận thực tế: chạy máy để dọn sạch tầng lỗi cơ học, rồi bắt đầu công việc thật bằng tay.
Tương phản màu: các mốc số cần nhớ
Đây là nhóm lỗi phổ biến nhất và cũng là nhóm dễ kiểm tra nhất vì có con số rõ ràng. Chữ cỡ thường cần tỷ lệ tương phản tối thiểu 4,5 trên 1 so với nền để đạt mức AA. Chữ cỡ lớn, tức từ 18 điểm trở lên hoặc từ 14 điểm trở lên nếu in đậm, được hạ xuống mức 3 trên 1. Các thành phần giao diện bấm được và các nét đồ họa mang thông tin, chẳng hạn viền ô nhập, biểu tượng chức năng, đường biểu đồ, cũng cần tối thiểu 3 trên 1 so với vùng xung quanh. Mức AAA nâng hai ngưỡng đầu lên 7 trên 1 và 4,5 trên 1, thường chỉ áp dụng cho nội dung đặc thù. Hai chỗ hay bị bỏ sót: chữ đặt trên ảnh nền, nơi tương phản thay đổi theo từng vùng ảnh nên phải kiểm tra ở vùng xấu nhất; và trạng thái phụ của thành phần như chữ giữ chỗ trong ô nhập, nhãn bị làm mờ, hay nút ở trạng thái rê chuột, những chỗ mà thiết kế hay hạ độ đậm màu xuống dưới ngưỡng.
Bàn phím và tiêu điểm: phép thử năm phút phát hiện nhiều lỗi nhất
Bỏ tay khỏi chuột và nhấn phím Tab từ đầu trang. Ba câu hỏi cần trả lời. Thứ nhất, bạn có nhìn thấy mình đang ở đâu không: mỗi thành phần nhận tiêu điểm phải có viền hoặc dấu hiệu rõ ràng, và lỗi thường gặp là ai đó xóa viền mặc định của trình duyệt vì thấy xấu mà không thay bằng kiểu khác. Thứ hai, bạn có tới được mọi thứ bấm được không: các thành phần dựng bằng thẻ chia khối kèm sự kiện nhấp chuột thường không nhận được tiêu điểm bàn phím, đó là lý do nên dùng đúng thẻ nút và thẻ liên kết. Thứ ba, bạn có bị mắc kẹt ở đâu không: cửa sổ bật lên là chỗ hay giữ tiêu điểm sai cách, phải giữ tiêu điểm bên trong khi đang mở và trả lại đúng chỗ cũ khi đóng, đồng thời đóng được bằng phím Escape. Thêm một chi tiết nhỏ mà tác động lớn: một liên kết bỏ qua điều hướng đặt ở đầu trang giúp người dùng bàn phím không phải nhấn Tab qua toàn bộ trình đơn ở mỗi trang.
Chữ thay thế, cấu trúc tiêu đề và nhãn biểu mẫu
Với chữ thay thế của ảnh, quy tắc là mô tả chức năng của ảnh trong ngữ cảnh chứ không mô tả ảnh. Ảnh trang trí thuần túy nên để chữ thay thế rỗng để trình đọc màn hình bỏ qua, chứ không phải bỏ hẳn thuộc tính. Ảnh là liên kết thì chữ thay thế phải mô tả đích đến. Ảnh chứa chữ hoặc biểu đồ thì phải truyền đạt được thông tin đó, và nếu quá dài thì đặt phần diễn giải ngay trong nội dung trang. Với cấu trúc tiêu đề, mỗi trang nên có đúng một tiêu đề cấp một mô tả nội dung chính, các cấp sau đi tuần tự không nhảy cóc, và tuyệt đối không chọn cấp tiêu đề vì lý do cỡ chữ. Người dùng trình đọc màn hình duyệt trang bằng cách nhảy giữa các tiêu đề, nên cấu trúc lộn xộn khiến họ mất khả năng định vị. Với biểu mẫu, mỗi ô nhập cần một nhãn thật sự liên kết bằng thuộc tính tương ứng, không dùng chữ giữ chỗ thay nhãn vì chữ đó biến mất ngay khi bắt đầu gõ, và thông báo lỗi phải gắn với đúng ô nhập chứ không chỉ đổi màu viền.
Ví dụ đọc kết quả và cách điểm số được tính
Giả sử bạn kiểm tra một trang giới thiệu dịch vụ và công cụ trả về bốn dòng. Dòng một, thẻ html thiếu thuộc tính lang, mức A theo tiêu chí 3.1.1, là lỗi. Dòng hai, 3 trên 12 thẻ img thiếu alt, tiêu chí 1.1.1, là lỗi. Dòng ba, có 2 thẻ H1, là cảnh báo thực hành tốt. Dòng bốn, cấu trúc heading nhảy cấp ở 1 vị trí, là cảnh báo. Điểm được tính là 100 trừ 8 cho mỗi dòng lỗi và trừ 4 cho mỗi dòng cảnh báo, tức 100 trừ 16 trừ 8 bằng 76. Cần hiểu đúng hai điểm của công thức này. Thứ nhất, điểm trừ theo nhóm chứ không theo số phần tử, nên 3 ảnh thiếu alt hay 300 ảnh thiếu alt đều trừ 8 điểm, bạn phải đọc con số trong từng dòng để biết mức độ thật. Thứ hai, điểm 100 chỉ có nghĩa là không phát hiện vấn đề ở các mục máy kiểm tra được, không có nghĩa trang đạt chuẩn WCAG, vì phần lớn tiêu chí nằm ngoài tầm với của một lần đọc HTML. Thứ tự sửa hợp lý với ví dụ trên là thêm lang vào thẻ html trước vì chỉ mất một dòng, rồi viết alt cho 3 ảnh, với ảnh trang trí thì để alt rỗng, sau đó mới xem lại cấu trúc tiêu đề. Dòng thông tin phía trên danh sách lỗi cho biết công cụ đã đọc được bao nhiêu ảnh, trường form, tiêu đề, liên kết, nút và iframe. Nếu các con số này gần như bằng không trong khi trang hiển thị đầy đủ trên trình duyệt, đó là dấu hiệu trang dựng nội dung bằng JavaScript phía trình duyệt, và kết quả không phản ánh những gì người dùng thật sự thấy.
Bảng đối chiếu: mỗi mục kiểm tra ứng với tiêu chí WCAG nào và máy bỏ sót gì
Thuộc tính lang ứng với tiêu chí 3.1.1 mức A. Máy chỉ biết có hay không, không biết đúng hay sai: trang tiếng Việt cần khai báo lang bằng vi để trình đọc màn hình chọn giọng đọc tiếng Việt, khai báo nhầm en sẽ khiến nội dung bị đọc bằng giọng tiếng Anh gần như không nghe được, và công cụ không phát hiện được lỗi đó. Thẻ title ứng với 2.4.2 mức A, máy không đánh giá title có mô tả đúng trang hay không. Alt của ảnh ứng với 1.1.1 mức A, máy chấp nhận mọi alt không rỗng kể cả alt ghi đúng một chữ ảnh. Ảnh được ẩn bằng aria-hidden hoặc role presentation không bị tính là thiếu alt. Nhãn ô nhập ứng với 1.3.1 và 4.1.2 mức A, chữ giữ chỗ không được tính là nhãn. Link và nút không có tên ứng với 2.4.4 và 4.1.2 mức A, công cụ chấp nhận tên từ chữ bên trong, aria-label, title, alt của ảnh con hoặc aria-label của biểu tượng SVG bên trong, nhưng không biết tên đó có mô tả đúng hành động không, một nút tên Bấm vào đây vẫn qua. Iframe thiếu title ứng với 4.1.2. Viewport chặn phóng to liên quan tới 1.4.4 mức AA. Thiếu viewport, thiếu H1, nhiều H1 và tiêu đề nhảy cấp là thực hành tốt nên chỉ là cảnh báo. Id trùng lặp từng thuộc tiêu chí 4.1.1, nhưng tiêu chí này đã bị bỏ trong WCAG 2.2, nên công cụ chỉ cảnh báo và cho biết bao nhiêu id trùng đang được label hoặc thuộc tính aria tham chiếu tới, vì chỉ những id đó mới gây lỗi thật cho trình đọc màn hình. Những nhóm công cụ không kiểm tra: tương phản màu 1.4.3 và 1.4.11, bàn phím 2.1.1, thứ tự và dấu hiệu tiêu điểm 2.4.3 và 2.4.7, phụ đề 1.2.2, thông báo lỗi biểu mẫu 3.3.1, cùng toàn bộ các tiêu chí mới của WCAG 2.2.
WCAG 2.2 có gì mới và vì sao máy gần như không kiểm tra được phần mới
WCAG 2.2 được W3C công bố thành khuyến nghị chính thức vào tháng 10 năm 2023, thêm chín tiêu chí mới so với 2.1 và bỏ tiêu chí 4.1.1 về phân tích cú pháp. Ở mức A có 3.2.6 trợ giúp nhất quán, yêu cầu cơ chế trợ giúp như số điện thoại hay khung chat nằm ở cùng vị trí tương đối giữa các trang, và 3.3.7 tránh nhập lại, không bắt người dùng nhập lại thông tin đã cung cấp trong cùng quy trình. Ở mức AA có 2.4.11 tiêu điểm không bị che, phần tử đang nhận tiêu điểm không được bị che hoàn toàn bởi header dính, banner cookie hay nút chat; 2.5.7 thao tác kéo, mọi chức năng kéo thả phải làm được bằng một cú bấm đơn; 2.5.8 kích thước vùng bấm tối thiểu 24 pixel CSS; và 3.3.8 xác thực dễ tiếp cận, không bắt người dùng giải câu đố nhận thức như nhớ mật khẩu mà không cho dán hay dùng trình quản lý mật khẩu. Ở mức AAA có 2.4.12, 2.4.13 và 3.3.9. Điểm chung của các tiêu chí mới là chúng nói về hành vi khi tương tác, vị trí hiển thị thật trên màn hình và quy trình nhiều bước, không phải về thẻ HTML. Một lần đọc HTML tĩnh như công cụ này không thể biết banner cookie có che mất ô đang được Tab tới hay không, hay trang đăng nhập có chặn dán mật khẩu bằng JavaScript hay không. Vì vậy với WCAG 2.2, phần kiểm tra thủ công quan trọng hơn bao giờ hết: Tab qua trang khi có header dính và banner đang mở, thử mọi chức năng kéo thả bằng cú bấm, và đo vùng bấm của các biểu tượng nhỏ trên di động.
Câu hỏi thường gặp (FAQ)
Kết quả trên trang này có phải phân tích trang tôi vừa nhập không?
Có. Công cụ tải HTML thật của địa chỉ bạn nhập và phân tích trực tiếp bằng trình phân tích DOM. Điểm số tính theo công thức cố định dựa trên số lỗi tìm thấy, không phải số ngẫu nhiên. Lưu ý công cụ chỉ đọc HTML tĩnh nên không kiểm tra được tương phản màu và không thấy nội dung do JavaScript chèn thêm sau khi tải trang — hai phần đó cần chạy thêm bằng axe DevTools hoặc Lighthouse.
Vậy nên dùng công cụ nào để kiểm tra thật?
Bắt đầu bằng phần kiểm tra khả năng tiếp cận có sẵn trong công cụ dành cho nhà phát triển của trình duyệt, đây là lựa chọn miễn phí và không cần cài gì. Sau đó bổ sung một tiện ích rà soát chuyên dụng để có báo cáo chi tiết theo từng tiêu chí, rồi tự kiểm tra thủ công bằng bàn phím và trình đọc màn hình.
Công cụ tự động bắt được bao nhiêu phần lỗi tiếp cận?
Chỉ một phần, và phần còn lại luôn lớn hơn. Máy kiểm tra tốt những thứ có hoặc không có, ví dụ ảnh thiếu chữ thay thế hay tương phản màu dưới ngưỡng. Máy không đánh giá được chất lượng, chẳng hạn chữ thay thế có mô tả đúng ảnh hay không, thứ tự đọc có hợp lý hay không, tên nút có nói đúng hành động hay không.
Tỷ lệ tương phản tối thiểu là bao nhiêu?
Ở mức AA, chữ cỡ thường cần 4,5 trên 1, chữ cỡ lớn từ 18 điểm hoặc từ 14 điểm in đậm cần 3 trên 1. Các thành phần giao diện bấm được và nét đồ họa mang thông tin cũng cần tối thiểu 3 trên 1. Mức AAA nâng hai ngưỡng đầu lên 7 trên 1 và 4,5 trên 1.
WCAG mức A, AA và AAA khác nhau ra sao?
A là mức tối thiểu, thiếu nó thì một số nhóm người dùng không sử dụng được trang. AA là mức mà hầu hết tổ chức và quy định trên thế giới lấy làm mục tiêu, cân bằng giữa tác động và chi phí. AAA đặt yêu cầu rất cao và thường chỉ áp dụng cho từng phần nội dung cụ thể chứ không cho cả website.
Ảnh trang trí nên đặt chữ thay thế thế nào?
Để thuộc tính chữ thay thế rỗng chứ không bỏ hẳn thuộc tính. Chữ thay thế rỗng là tín hiệu để trình đọc màn hình bỏ qua ảnh đó, còn khi thiếu hẳn thuộc tính thì một số trình đọc sẽ đọc tên tệp, thứ thường là một chuỗi vô nghĩa và gây nhiễu cho người nghe.
Dùng chữ giữ chỗ thay cho nhãn ô nhập được không?
Không nên. Chữ giữ chỗ biến mất ngay khi người dùng bắt đầu gõ, nên người ta mất thông tin về việc ô đó dùng để nhập gì, đặc biệt khi quay lại kiểm tra biểu mẫu dài. Ngoài ra chữ giữ chỗ thường có màu nhạt nên hay không đạt ngưỡng tương phản. Hãy dùng nhãn thật sự liên kết với ô nhập.
Vì sao không nên xóa viền tiêu điểm mặc định?
Vì đó là dấu hiệu duy nhất cho người dùng bàn phím biết mình đang ở đâu trên trang. Xóa đi mà không thay bằng kiểu hiển thị khác khiến việc điều hướng bằng phím Tab trở nên bất khả thi. Nếu viền mặc định không hợp thiết kế, hãy thay bằng viền riêng có tương phản đủ chứ đừng bỏ trắng.
Cấu trúc tiêu đề sai thì ảnh hưởng gì?
Người dùng trình đọc màn hình thường duyệt trang bằng cách nhảy giữa các tiêu đề để tìm phần mình cần, giống như người sáng lướt mắt qua trang. Cấu trúc nhảy cóc hoặc chọn cấp tiêu đề theo cỡ chữ khiến họ mất khả năng định vị. Mỗi trang nên có đúng một tiêu đề cấp một và các cấp sau đi tuần tự.
Vùng bấm trên di động nên rộng bao nhiêu?
WCAG 2.2 thêm tiêu chí 2.5.8 ở mức AA: vùng bấm tối thiểu 24 nhân 24 pixel CSS, hoặc nếu nhỏ hơn thì phải có đủ khoảng trống xung quanh để một vòng tròn đường kính 24 pixel đặt tại tâm không chạm vùng bấm khác, có ngoại lệ cho liên kết nằm trong đoạn văn. Mức AAA ở tiêu chí 2.5.5 là 44 nhân 44 pixel CSS, con số nhiều nhóm thiết kế vẫn dùng làm mục tiêu cho di động. Các nút nhỏ nằm sát nhau là nguồn của rất nhiều thao tác nhầm. Nếu vì lý do thiết kế mà biểu tượng phải nhỏ, hãy mở rộng vùng bấm bằng phần đệm trong suốt xung quanh, hoặc chừa khoảng cách đủ lớn giữa các mục liền kề.
Làm khả năng tiếp cận có giúp ích cho tối ưu tìm kiếm không?
Có, một cách gián tiếp nhưng rõ ràng. Cấu trúc tiêu đề mạch lạc, thẻ ngữ nghĩa đúng vai trò, chữ thay thế mô tả đúng ảnh, khai báo ngôn ngữ và tiêu đề trang rõ ràng đều là những thứ giúp máy tìm kiếm hiểu nội dung. Ngoài ra trải nghiệm tốt hơn cho mọi người cũng làm giảm tỷ lệ rời trang.
Điểm 100 có nghĩa là website đạt chuẩn WCAG không?
Không. Điểm 100 chỉ có nghĩa là không phát hiện vấn đề ở nhóm mục công cụ đọc được từ HTML. Những tiêu chí quan trọng như tương phản màu, điều hướng bằng bàn phím, tiêu điểm bị che hay chất lượng chữ thay thế đều nằm ngoài phạm vi đó. Muốn khẳng định đạt WCAG mức AA cần kiểm tra thủ công từng tiêu chí, thường theo phương pháp đánh giá có cấu trúc như WCAG-EM của W3C.
Vì sao trang React hoặc Next.js của tôi bị báo thiếu H1 hay không có liên kết?
Công cụ chỉ đọc HTML mà máy chủ trả về lần đầu, không chạy JavaScript. Nếu trang dựng nội dung hoàn toàn ở phía trình duyệt, HTML ban đầu gần như trống và kết quả sẽ sai lệch. Dòng số phần tử đã đọc trong kết quả giúp bạn nhận ra trường hợp này. Trang Next.js dựng sẵn ở máy chủ thường không gặp vấn đề, còn trang chỉ dựng phía trình duyệt nên kiểm tra thêm bằng Lighthouse hoặc axe DevTools ngay trên trình duyệt.
WCAG 2.2 khác WCAG 2.1 ở điểm nào?
WCAG 2.2 thêm chín tiêu chí, trong đó các tiêu chí mức A và AA gồm trợ giúp nhất quán, tránh nhập lại, tiêu điểm không bị che, thao tác kéo có phương án bấm đơn, vùng bấm tối thiểu 24 pixel CSS và xác thực dễ tiếp cận. Đồng thời tiêu chí 4.1.1 về phân tích cú pháp bị bỏ vì trình duyệt và công nghệ hỗ trợ hiện đại đã tự xử lý lỗi cú pháp HTML. Trang đạt WCAG 2.2 thì cũng đạt 2.1 ở cùng mức.
Trang tiếng Việt nên khai báo thuộc tính lang thế nào?
Đặt lang bằng vi trên thẻ html. Trình đọc màn hình dựa vào giá trị này để chọn giọng đọc, khai báo nhầm en trên trang tiếng Việt khiến nội dung bị đọc bằng giọng tiếng Anh gần như không hiểu được. Đoạn nội dung bằng ngôn ngữ khác nằm trong trang, như một câu trích dẫn tiếng Anh, nên được bọc trong thẻ có lang riêng. Công cụ chỉ kiểm tra lang có hay không, không kiểm tra giá trị có đúng ngôn ngữ nội dung hay không.
Nên sửa nhóm lỗi nào trước khi thời gian có hạn?
Ưu tiên những lỗi chặn hẳn việc sử dụng: thành phần bấm được nhưng không tới được bằng bàn phím, biểu mẫu thiếu nhãn, viền tiêu điểm bị xóa, và tương phản quá thấp ở phần nội dung chính. Sau đó tới chữ thay thế của ảnh mang thông tin và cấu trúc tiêu đề. Các mục còn lại xử lý dần theo từng đợt phát hành.
Từ khóa liên quan
- wcag 2.2 có gì mới
- kích thước vùng bấm 24px wcag
- kiểm tra khả năng tiếp cận website
- wcag là gì
- accessibility website
- tương phản màu chữ và nền
- chữ thay thế cho ảnh
- điều hướng bằng bàn phím
- trình đọc màn hình
- nhãn biểu mẫu html
- cấu trúc thẻ tiêu đề
- wcag mức aa
- liên kết bỏ qua điều hướng
- viền tiêu điểm css
- html ngữ nghĩa
- thuộc tính aria
- kiểm tra accessibility bằng lighthouse
- lỗi tiếp cận thường gặp
- thiết kế web cho người khiếm thị
- phóng to trang 200 phần trăm
- vùng bấm trên di động
- audit accessibility thủ công