SEO WordPress #19: Accessibility và khả năng tiếp cận

1. Accessibility trong SEO WordPress là gì?

Accessibility trong SEO WordPress là việc làm cho nội dung và mọi chức năng của website dùng được bằng nhiều cách nhập khác nhau và nhiều cách đọc khác nhau, gồm bàn phím, trình đọc màn hình, phóng to chữ và thiết bị cảm ứng. Chuẩn tham chiếu là WCAG của W3C, và mức phổ biến trong hợp đồng là AA.

Cần nói rõ ngay để không đo sai: WCAG không phải yếu tố xếp hạng của Google. Không có tài liệu nào của Google nói một website đạt AA thì xếp hạng cao hơn. Phần giao nhau thật sự nằm ở chỗ khác: liên kết crawlable, alt text, HTML có ngữ nghĩa và khả năng đọc nội dung mà không cần thao tác, những thứ vừa là điều kiện tiếp cận vừa là điều kiện để máy hiểu trang.

Lý do làm accessibility vì vậy không phải để đổi lấy hạng. Nó là điều kiện để một phần người dùng thật sự dùng được website, là yêu cầu hợp đồng ở nhiều thị trường, và là cách rẻ nhất để phát hiện những lỗi giao diện mà phép đo hiệu năng không nhìn thấy. Một nút không có tên truy cập vẫn bấm được bằng chuột, nên nó không xuất hiện trong bất kỳ báo cáo nào ngoài báo cáo accessibility.

Đầu ra cần có: danh sách lỗi gắn với URL, thành phần, mã tiêu chí WCAG, cách tái hiện bằng bàn phím hoặc trình đọc màn hình, và điều kiện nghiệm thu. Nền của chuẩn nằm ở mục tra cứu WCAG 2.1 AA; bài này bổ sung phần WCAG 2.2 ở tiêu chí focus.

2. Checklist Accessibility: 10 tiêu chí từ 154 đến 163

Mười tiêu chí dưới đây là khung nghiệm thu accessibility của series, gồm tương phản, skip link, bàn phím, focus, landmark, tên truy cập, ARIA, ngôn ngữ, media và reflow. Cả mười đều mang trọng số Bắt buộc, vì mỗi tiêu chí trong nhóm này khi không đạt là chặn hẳn một cách dùng website chứ không chỉ làm chậm một bước.

Chia trạng thái thành Đạt, Chưa đạt và Chưa kiểm. Con số quan trọng cần nhớ khi đọc báo cáo tự động: phần lớn tiêu chí WCAG không kiểm được bằng máy. Một trang xanh trong axe hoặc WAVE chỉ nghĩa là nó không mắc những lỗi máy nhận ra được, chứ không nghĩa là nó dùng được bằng bàn phím.

Vì vậy trình tự kiểm nên là: chạy công cụ tự động để loại các lỗi rõ ràng, rồi đi Tab qua toàn trang, rồi nghe bằng trình đọc màn hình ở ba trang đại diện. Ba bước đó bắt được hai nhóm lỗi khác nhau và không thay thế nhau.

3. Tiêu chí 154: Tương phản văn bản và thành phần giao diện

Tương phản đạt mức AA nghĩa là văn bản thường đạt tỉ lệ tối thiểu 4.5:1, văn bản lớn đạt tối thiểu 3:1, còn thành phần giao diện và đồ họa thiết yếu đạt tối thiểu 3:1. Văn bản lớn theo định nghĩa của WCAG là từ 18pt trở lên, hoặc từ 14pt trở lên khi in đậm, tức khoảng 24px và 18.66px đậm.

Cách kiểm: chạy WAVE hoặc axe DevTools để bắt các cặp màu rõ ràng, rồi dùng Colour Contrast Analyser cho những chỗ máy không đọc được, gồm chữ nằm trên ảnh, chữ trên gradient và chữ trong SVG. Đừng bỏ qua nhóm thành phần: viền của trường nhập, đường ranh của nút phẳng, icon mang nghĩa và các đường của biểu đồ đều thuộc mức 3:1 theo tiêu chí 1.4.11.

WCAG có ngoại lệ, và cần đọc đúng để không sửa thứ không phải lỗi: chữ trang trí, logo, chữ ẩn và thành phần đang bị vô hiệu hóa không thuộc phạm vi. Ngược lại, chữ trong ảnh chụp giao diện lại thuộc phạm vi nếu nó mang thông tin, nên trước khi hạ độ sáng của một khối, hãy xét xem chữ trong ảnh của khối đó còn đọc được không.

Trên WordPress, hai nguồn gây lỗi phổ biến là bảng màu trong theme.json và các màu chữ do page builder đặt trực tiếp vào từng khối. Sửa ở bảng màu là sửa một lần cho cả website, còn sửa từng khối là việc lặp lại vô hạn. Điều kiện nghiệm thu: mọi cặp màu trong bảng màu đạt ngưỡng khi dùng làm chữ trên nền tương ứng, và không còn màu chữ đặt cứng ngoài bảng.

4. Tiêu chí 155: Skip link hoạt động

Skip link là liên kết đầu tiên trong tài liệu, cho người dùng bàn phím bỏ qua khối điều hướng lặp lại để tới thẳng nội dung chính, và nó phải hiện ra khi nhận tiêu điểm rồi nhảy đúng đích. Đây là tiêu chí 2.4.1 Bypass Blocks, mức A, tức mức thấp nhất của WCAG.

Cách kiểm rất nhanh: mở trang, bấm Tab một lần. Phần tử đầu tiên nhận tiêu điểm phải là skip link và nó phải hiện ra nhìn thấy được. Bấm Enter rồi bấm Tab tiếp: tiêu điểm phải nằm trong nội dung chính, không quay về đầu trang. Nếu bấm Enter mà không có gì đổi, đích của link không tồn tại hoặc đích không nhận được tiêu điểm.

Ba lỗi hay gặp theo đúng thứ tự tần suất: skip link bị ẩn bằng display none nên không bao giờ nhận tiêu điểm; skip link trỏ tới một id không còn trong trang sau khi đổi theme; và đích là một thẻ không nhận tiêu điểm được, cần thêm tabindex bằng âm một để nó nhận được tiêu điểm theo lập trình. Cách ẩn đúng là đẩy ra ngoài vùng nhìn rồi đưa về khi focus, không phải display none.

Trên WordPress, phần lớn theme in skip link qua hook wp_body_open, và theme khối có sẵn một skip link trong template. Sau khi đổi theme hoặc chèn một thanh thông báo lên đầu trang, hãy kiểm lại: một banner đặt trước skip link làm nó không còn là phần tử đầu tiên nữa. Điều kiện nghiệm thu: Tab lần đầu thấy skip link, Enter đưa tiêu điểm vào đúng vùng main, và đích của link tồn tại trên mọi template.

5. Tiêu chí 156: Điều khiển được bằng bàn phím

Điều khiển được bằng bàn phím nghĩa là mọi chức năng của trang dùng được mà không cần chuột, không có chỗ nào giữ tiêu điểm lại, và các phím Tab, Shift kèm Tab, Enter, Space cùng Escape hoạt động đúng vai trò của chúng. Đây là hai tiêu chí 2.1.1 Keyboard và 2.1.2 No Keyboard Trap, cả hai mức A.

Cách kiểm: bỏ chuột ra khỏi tay rồi đi Tab từ đầu tới cuối trang, ghi lại từng bước. Bốn dấu hiệu cần bắt: một thao tác chỉ làm được bằng hover hoặc bằng kéo thả, một lớp phủ mở ra mà Tab vẫn chạy vào phần nội dung phía sau, một thành phần vào được mà không ra được, và một nút mở popup nhưng sau khi đóng thì tiêu điểm rơi về đầu trang thay vì quay lại nút vừa bấm.

Về phím: Enter kích hoạt liên kết và nút, Space kích hoạt nút và hộp kiểm nhưng không kích hoạt liên kết, Escape đóng lớp phủ. Nếu một thành phần tự dựng bằng div phải nghe cả Enter và Space, đó chính là dấu hiệu nên thay bằng thẻ button gốc, vì thẻ đó đã có sẵn hành vi này.

Trên WordPress, nguồn lỗi thường là slider, tab, accordion và lightbox do plugin dựng, cùng các menu nhiều cấp chỉ mở bằng hover đã bàn ở bài #18 về điều hướng. Điều kiện nghiệm thu: đi hết trang bằng bàn phím không bị kẹt, mọi chức năng làm được bằng bàn phím, và tiêu điểm quay về đúng chỗ sau khi đóng lớp phủ.

6. Tiêu chí 157: Focus hiển thị rõ và không bị che

Focus hiển thị rõ nghĩa là thành phần đang nhận tiêu điểm có một chỉ báo nhìn thấy được, và chỉ báo đó không bị header cố định, modal, banner hay lớp phủ che mất hoàn toàn. Phần nhìn thấy được là tiêu chí 2.4.7 Focus Visible mức AA; phần không bị che là tiêu chí 2.4.11 Focus Not Obscured mức AA, mới có từ WCAG 2.2.

Cách kiểm: đi Tab qua toàn trang và ở mỗi bước hỏi một câu duy nhất, tôi có thấy tiêu điểm đang ở đâu không. Chỗ dễ trượt nhất là khi tiêu điểm đi vào một phần tử nằm ngay dưới header dính: trang tự cuộn tới phần tử đó nhưng header che lên, nên người dùng thấy trang nhảy mà không thấy tiêu điểm. Cách chữa gọn nhất là khai scroll-margin-top cho các đích nhận tiêu điểm, bằng chiều cao header.

Lỗi phổ biến nhất của cả nhóm accessibility nằm ở đây: outline bằng none đặt trong reset CSS. Nó xóa chỉ báo mặc định của trình duyệt trên mọi phần tử và không thay bằng gì. Nếu muốn đổi kiểu chỉ báo, hãy đổi bằng outline riêng hoặc box-shadow, và chỉ nhắm vào focus-visible để chuột bấm không làm hiện viền.

Với WordPress, hãy kiểm cả trong trạng thái đã mở lớp phủ: popup, cookie banner và chat thường được plugin chèn cuối trang với z-index cao. Điều kiện nghiệm thu: mọi bước Tab đều thấy chỉ báo, không có outline bằng none nào còn lại mà chưa có chỉ báo thay thế, và chỉ báo không bị che ở cả trạng thái có header dính.

7. Tiêu chí 158: Landmark và vùng nội dung có ngữ nghĩa

Landmark có ngữ nghĩa nghĩa là dùng đúng vai trò của header, nav, main, footer, search và aside, mỗi tài liệu có đúng một main, còn các vùng cùng loại thì có tên truy cập phân biệt khi cần. Đây là tiêu chí 1.3.1 Info and Relationships mức A, và cũng chính là phần giao nhau rõ nhất giữa accessibility và việc máy hiểu cấu trúc trang.

Cách kiểm: mở cây tiếp cận trong Chrome DevTools và đọc danh sách landmark, hoặc dùng lệnh liệt kê vùng của trình đọc màn hình. Trang tốt cho ra một danh sách ngắn và đọc lên hiểu ngay: banner, navigation tên Chính, search, main, complementary tên Bài liên quan, contentinfo. Trang có vấn đề cho ra một danh sách dài toàn div hoặc hai vùng navigation không tên, không phân biệt được cái nào là menu chính.

Hai vùng navigation trên cùng một trang là bình thường, ví dụ menu chính và breadcrumb. Điều cần làm là đặt tên cho chúng bằng aria-label, để danh sách vùng của trình đọc màn hình không hiện ra hai dòng giống nhau. Cấu trúc heading là lớp thứ hai của cùng việc này, đã bàn ở bài #10 về thẻ heading.

Điều kiện nghiệm thu: đúng một main trên mỗi trang, mọi vùng lặp lại đều là thẻ có ngữ nghĩa chứ không phải div, và mỗi cặp vùng cùng loại đều có tên riêng đọc lên phân biệt được.

8. Tiêu chí 159: Tên truy cập của nút và trường nhập

Tên truy cập là cái tên mà trình đọc màn hình đọc ra khi tiêu điểm đi vào một nút, một liên kết hay một trường nhập, và nó phải nói rõ thành phần đó làm gì. Yêu cầu kèm theo: nhãn hiển thị phải nằm trong tên truy cập, theo tiêu chí 2.5.3 Label in Name, để người dùng điều khiển bằng giọng nói đọc đúng chữ đang thấy.

Cách kiểm: bật trình đọc màn hình rồi Tab qua từng control và nghe. Cách nhanh hơn để rà số lượng là mở bảng Accessibility trong DevTools, chọn từng phần tử và đọc trường Name. Nút chỉ có icon là nhóm cần soát trước, vì chúng thường không có chữ nào: nút đóng, nút tìm kiếm, nút giỏ hàng, nút chia sẻ, nút mở menu.

Cách đặt tên theo thứ tự ưu tiên: chữ thật nằm trong thẻ là tốt nhất, kế đó là chữ thật nhưng ẩn bằng lớp chỉ dành cho trình đọc màn hình, sau cùng mới tới aria-label. Với trường nhập, label phải liên kết đúng bằng thuộc tính for khớp id, và placeholder không phải nhãn: nó biến mất ngay khi người dùng bắt đầu nhập.

Trên WordPress, hai chỗ hay thiếu tên là biểu mẫu liên hệ do plugin dựng và các nút icon của theme. Cả hai đều sửa được không cần đổi thiết kế. Điều kiện nghiệm thu: mọi control có tên đọc lên hiểu ngay, mọi trường nhập có label liên kết đúng, và không control nào chỉ dựa vào placeholder để mô tả.

9. Tiêu chí 160: ARIA role và trạng thái đúng

ARIA đúng nghĩa là ưu tiên HTML gốc trước, và khi buộc phải dùng ARIA thì role, state cùng value phải khớp hành vi thật và phải cập nhật mỗi lần trạng thái đổi. Luật đầu tiên trong tài liệu ARIA của W3C nói thẳng: đừng dùng ARIA nếu một thẻ HTML gốc đã mang đúng ngữ nghĩa đó.

Cách kiểm: chạy axe DevTools để bắt các role không hợp lệ và các thuộc tính đặt sai chỗ, rồi mở cây tiếp cận và thao tác thật. Phép kiểm quan trọng nhất là phép thứ hai: bấm mở một accordion rồi xem aria-expanded có đổi từ false sang true hay không. Một trạng thái khai một lần rồi đứng yên còn tệ hơn không khai, vì nó nói sai chứ không phải nói thiếu.

Bốn lỗi hay gặp: aria-label đặt trên một div không có role nào nên không sinh ra tên; role button gắn vào một span rồi thiếu tabindex và thiếu xử lý phím; aria-hidden đặt trên một phần tử đang chứa control nhận được tiêu điểm, tạo ra thứ Tab tới được mà trình đọc màn hình không thấy; và role tự dựng cho tab hay dialog nhưng thiếu các thuộc tính bắt buộc của mẫu đó.

Cần nói thêm một chi tiết về phiên bản: tiêu chí 4.1.1 Parsing đã được W3C đánh dấu lỗi thời trong WCAG 2.2, nên lỗi HTML không hợp lệ không còn là vi phạm riêng. Điều đó không làm HTML sai trở nên vô hại, vì hậu quả của nó vẫn hiện ra ở 4.1.2 và 1.3.1. Điều kiện nghiệm thu: không còn role không hợp lệ, mọi trạng thái đổi theo thao tác, và mọi thành phần tự dựng đều có lý do rõ vì sao không dùng được thẻ gốc.

10. Tiêu chí 161: Ngôn ngữ trang được khai báo

Ngôn ngữ trang được khai báo nghĩa là thẻ html mang thuộc tính lang đúng với ngôn ngữ chính của trang, và những đoạn nội dung viết bằng ngôn ngữ khác được gắn lang riêng khi cần. Hai tiêu chí tương ứng là 3.1.1 Language of Page mức A và 3.1.2 Language of Parts mức AA.

Đây là tiêu chí rẻ nhất trong cả nhóm và cũng dễ kiểm nhất: xem mã nguồn, đọc thẻ html. Với website tiếng Việt, giá trị đúng là vi hoặc vi-VN. Hệ quả khi sai rất cụ thể: trình đọc màn hình chọn bộ phát âm theo giá trị này, nên một trang tiếng Việt khai lang bằng en sẽ được đọc bằng giọng tiếng Anh, và nội dung trở thành không hiểu được dù chữ vẫn đúng.

Phần lang cho từng đoạn thì cần cân nhắc chứ không gắn tràn lan. Tên riêng và thuật ngữ đã thành từ dùng chung trong tiếng Việt thì không cần. Cần gắn khi có một đoạn thật sự bằng ngôn ngữ khác, ví dụ một câu trích nguyên văn tiếng Anh dài hoặc một khối nội dung song ngữ.

Trên WordPress, giá trị này do hàm language_attributes của theme in ra theo cài đặt ngôn ngữ của website, nên lỗi thường đến từ theme tự đặt cứng chuỗi lang trong template header. Website có bản song ngữ cần kiểm thêm rằng trang bản tiếng Anh khai en, không khai theo ngôn ngữ mặc định. Điều kiện nghiệm thu: mọi template khai lang đúng, bản dịch khai theo ngôn ngữ của chính nó, và không còn chuỗi lang đặt cứng trong theme.

11. Tiêu chí 162: Phụ đề và bản thay thế cho media

Media cần bản thay thế nghĩa là video ghi sẵn có âm thanh mang thông tin phải có phụ đề đồng bộ, nội dung chỉ có âm thanh phải có transcript, và thông tin quan trọng nằm trong hình ảnh phải có bản thay thế phù hợp. Ba tiêu chí tương ứng là 1.2.2 Captions mức A, 1.2.1 Audio-only and Video-only mức A và 1.1.1 Non-text Content mức A.

Cách kiểm: liệt kê mọi media đang nhúng trên website rồi hỏi từng cái một câu, nếu tắt tiếng thì còn hiểu được nội dung không. Video hướng dẫn có người nói mà không có phụ đề là chưa đạt. Video nền không có tiếng và chỉ để trang trí thì không thuộc phạm vi, nhưng nó lại thuộc phạm vi tiêu chí khác nếu tự động chạy quá năm giây.

Phụ đề tự động không phải phụ đề đã đạt. Chúng sai nhiều nhất ở đúng những chỗ quan trọng: tên riêng, thuật ngữ kỹ thuật và số liệu. Cách làm đủ là xuất bản phụ đề tự động ra tệp, sửa lại bằng tay rồi nhúng lại. Với khối video của WordPress, phụ đề đi kèm bằng thẻ track dạng tệp VTT; với video nhúng từ nền tảng ngoài, phụ đề phải bật và phải được soát ở chính nền tảng đó.

Phần bản thay thế cho hình ảnh thì trùng với việc đã làm ở bài #11 về hình ảnh: alt mô tả thông tin mà ảnh mang, ảnh trang trí để alt rỗng, và biểu đồ hay ảnh chụp giao diện cần mô tả dài đặt ngay trong nội dung. Điều kiện nghiệm thu: mọi video có tiếng đều có phụ đề đã soát, mọi audio có transcript, và mọi ảnh mang thông tin có bản thay thế.

12. Tiêu chí 163: Phóng to và reflow không mất nội dung

Phóng to và reflow đạt yêu cầu nghĩa là văn bản tăng được tới 200% mà nội dung vẫn đọc được, và nội dung bố trí lại được ở mức tương đương 320 CSS px hoặc 400% zoom mà không mất nội dung, không mất chức năng và không phải cuộn hai chiều. Hai tiêu chí tương ứng là 1.4.4 Resize Text và 1.4.10 Reflow, cả hai mức AA.

Cách kiểm: mở trang ở chiều rộng 1280px rồi zoom 400%, tương đương khung nhìn 320px. Đi từ đầu tới cuối trang và tìm ba dấu hiệu: một khối bị cắt mất phần chữ, một nút bị đẩy ra ngoài vùng nhìn, và trang phải cuộn ngang để đọc một đoạn văn. Kiểm thêm ở mức chỉ phóng to chữ chứ không phóng cả trang, vì hai chế độ này làm hỏng hai kiểu bố cục khác nhau.

WCAG có ngoại lệ cho nội dung cần hai chiều mới dùng được hoặc mới có nghĩa, gồm bảng dữ liệu lớn, bản đồ, sơ đồ và thanh công cụ. Ngoại lệ đó cho phép chính khối đó cuộn ngang trong vùng riêng của nó; nó không cho phép cả trang và các đoạn văn xung quanh bị tràn ngang. Người đọc vẫn phải hiểu được tiêu đề cột và thao tác được trong vùng bảng.

Nguyên nhân hay gặp trên WordPress là chiều rộng cố định tính bằng px trong widget và trong khối do page builder sinh ra, cùng các giá trị đặt cứng trong CSS của plugin. Phần bố cục mobile và vùng chạm đã bàn ở bài #17 về mobile. Điều kiện nghiệm thu: ở 400% zoom không mất nội dung hay chức năng nào, không cuộn ngang ngoài các khối thuộc ngoại lệ, và phóng to chữ riêng cũng không làm chồng chữ.

13. Bảng dữ liệu, biểu mẫu và thông báo lỗi

Ba thành phần này là nơi tập trung nhiều lỗi tiếp cận nhất trên một website thương mại, vì chúng vừa có cấu trúc phức tạp vừa là chỗ người dùng phải hoàn tất một việc. Chúng không nằm trong mười tiêu chí ở trên nhưng dùng chung bộ phép kiểm, nên gom vào cùng một lượt nghiệm thu.

Bảng dữ liệu cần ô tiêu đề là thẻ th kèm thuộc tính scope, để trình đọc màn hình đọc được tên cột lúc đi vào từng ô. Bảng dùng để dàn trang thì không nên tồn tại; nếu buộc phải giữ, hãy khai role presentation để nó không được đọc như một bảng dữ liệu.

Biểu mẫu cần ba thứ cùng lúc: label liên kết đúng, hướng dẫn định dạng nêu trước khi nhập, và thông báo lỗi nói rõ lỗi ở trường nào cùng cách sửa. Thông báo dạng một dòng đỏ ở đầu trang nói đã có lỗi là chưa đủ. Ba tiêu chí tương ứng là 3.3.2 Labels or Instructions, 3.3.1 Error Identification và 3.3.3 Error Suggestion.

Thông báo xuất hiện sau thao tác cần được trình đọc màn hình nhận ra. Một dòng chữ chèn thêm vào DOM mà không khai vùng thông báo sẽ không được đọc ra, nên người dùng trình đọc màn hình bấm gửi rồi không biết gì đã xảy ra. Vùng thông báo khai bằng role status cho thông tin thường và role alert cho lỗi cần biết ngay.

14. Accessibility trên WordPress: theme, plugin và overlay

Trên WordPress, phần lớn kết quả accessibility được quyết định bởi theme, vì theme in ra landmark, skip link, bảng màu và kiểu chỉ báo focus cho mọi trang. Vì vậy việc đầu tiên nên làm không phải cài thêm plugin mà là đo chính theme đang dùng trên ba template đại diện.

Thư mục theme của WordPress có nhãn Accessibility Ready với một bộ yêu cầu được kiểm trước khi cấp, gồm điều hướng bằng bàn phím, skip link, tương phản và tên truy cập. Nhãn đó là điểm khởi đầu tốt, không phải một chứng nhận WCAG: nó nói theme đạt bộ yêu cầu của thư mục, còn nội dung và plugin anh chị thêm vào sau đó vẫn có thể phá vỡ mọi thứ.

Cần nói rõ về nhóm plugin overlay, tức các widget gắn một nút tròn vào góc màn hình rồi mời người dùng bật chế độ tương phản cao, tăng chữ hoặc đọc to. Overlay không sửa được nguyên nhân. Một nút không có tên truy cập vẫn không có tên sau khi cài overlay, một menu chỉ mở bằng hover vẫn chỉ mở bằng hover. Overlay thay đổi lớp trình bày, còn các lỗi ở nhóm 155 tới 160 nằm trong markup. Cài overlay và coi đó là đã đạt là mua một cảm giác an tâm không đúng chỗ.

Nhóm plugin có ích thật là nhóm giúp kiểm chứ không giúp che: công cụ quét trong trang quản trị, công cụ cảnh báo lúc biên tập khi ảnh thiếu alt hoặc khi nhảy bậc heading. Điều kiện nghiệm thu cho lớp nền tảng: theme đạt mười tiêu chí trên ba template đại diện khi chưa có nội dung, và mọi plugin thêm vào được kiểm lại bằng đúng bộ phép đó.

15. Quan hệ thật giữa Accessibility và SEO

Accessibility và SEO giao nhau ở một phần cụ thể, không phải trùng nhau và cũng không phải tách rời, nên cần biết phần nào mang lại cả hai và phần nào chỉ mang lại một. Biết ranh giới này giúp giải thích được với chủ website vì sao nên làm, mà không phải hứa một điều Google chưa từng nói.

Phần giao nhau gồm bốn thứ: liên kết dùng thẻ a có href, alt text cho ảnh mang thông tin, HTML có ngữ nghĩa gồm heading và landmark, và nội dung có sẵn trong trang mà không cần thao tác mới hiện ra. Bốn thứ này vừa là điều kiện tiếp cận vừa là điều kiện để máy đọc được trang, nên chúng là chỗ nên bắt đầu nếu cần một lý do kép.

Phần chỉ thuộc accessibility gồm tương phản màu, chỉ báo focus, thứ tự tiêu điểm, trạng thái ARIA và phụ đề. Chúng không đổi cách Google hiểu trang. Lý do làm chúng là người dùng thật, là yêu cầu hợp đồng, và là chất lượng sản phẩm.

Phần chỉ thuộc SEO thì ngược lại: canonical, sitemap, dữ liệu có cấu trúc và tốc độ tải không liên quan tới khả năng tiếp cận. Nói accessibility làm tăng hạng là nói quá; nói nó không liên quan gì tới SEO cũng sai. Cách nói đúng là bốn thứ ở phần giao nhau nên được làm trước, vì chúng trả về hai thứ cùng lúc.

16. Ma trận kiểm tra theo thành phần và cách kiểm

Ma trận dưới đây gom phép kiểm theo thành phần giao diện, vì lỗi accessibility thường thuộc về một thành phần chứ không thuộc về một URL. Cách dùng là chọn một trang có chứa thành phần đó, đi hết dòng của thành phần rồi sửa ở template, nhờ vậy một lần sửa là hết cho mọi trang.

Ba trang đại diện là đủ cho lượt đầu: một trang chủ, một bài viết đơn và một trang có biểu mẫu. Sau khi lớp nền của theme đã đạt, mở rộng sang các template còn lại theo đúng danh sách nhóm trang đã dùng ở bài trước.

17. Ưu tiên sửa theo mức chặn người dùng

Thứ tự sửa nên theo mức chặn, tức mỗi lỗi đang làm một người không thể làm gì, chứ không theo số lượng cảnh báo mà công cụ đếm được. Một báo cáo có 300 cảnh báo thiếu alt cho ảnh trang trí ít nghiêm trọng hơn một bẫy tiêu điểm trong biểu mẫu thanh toán.

Nhóm một, chặn hẳn: bẫy tiêu điểm, lớp phủ không đóng được bằng bàn phím, biểu mẫu có control không nhận được tiêu điểm, chỉ báo focus bị xóa sạch. Người dùng bàn phím gặp bất kỳ lỗi nào trong nhóm này là dừng lại tại đó, nên chúng đứng trước mọi thứ khác.

Nhóm hai, chặn một phần: thiếu tên truy cập ở control quan trọng, thiếu label trong biểu mẫu, thiếu skip link, tương phản dưới ngưỡng ở chữ nội dung, thiếu phụ đề ở video hướng dẫn. Việc vẫn làm được nhưng phải đoán hoặc phải mất nhiều bước hơn hẳn.

Nhóm ba, làm giảm chất lượng: tương phản dưới ngưỡng ở chữ phụ, thiếu tên phân biệt cho hai vùng cùng loại, trạng thái ARIA không cập nhật ở thành phần ít dùng, thiếu lang cho một đoạn ngắn. Nên sửa, nhưng không nên để nhóm này chiếm thời gian của hai nhóm trên. Xếp theo mức chặn còn một lợi ích nữa: nó cho một thứ tự giải thích được với người không làm kỹ thuật.

18. Quy trình nghiệm thu Accessibility trước và sau triển khai

Quy trình nghiệm thu accessibility chỉ đáng tin khi ba lớp phép kiểm đều chạy và chạy theo cùng một thứ tự mỗi lần: công cụ tự động, đi bàn phím, rồi nghe bằng trình đọc màn hình. Bỏ lớp nào cũng để lọt một nhóm lỗi mà hai lớp còn lại không thấy.

Trước khi triển khai, chốt bốn thứ: ba template đại diện, danh sách thành phần theo ma trận ở trên, mức đạt là AA cùng phiên bản WCAG đang tham chiếu, và người chịu trách nhiệm từng nhóm. Lưu kết quả gốc gồm báo cáo axe xuất ra tệp, bản ghi các bước Tab, và ảnh chụp chỉ báo focus. Ba thứ này là bản gốc để so, không phải tài liệu để lưu trữ cho đẹp.

Sau khi triển khai, chạy lại đúng chuỗi đó rồi đối chiếu từng dòng. Với thay đổi theme hoặc plugin điều hướng, hãy chạy trên staging trước, vì một thay đổi ở header là thay đổi trên mọi trang. Hai chỗ dễ hồi quy nhất là chỉ báo focus khi ai đó thêm một reset CSS mới, và tương phản khi ai đó đổi một màu trong bảng màu.

Về cách công bố, nếu website cần khai mức tuân thủ thì nên khai đúng phạm vi đã kiểm: kiểm trên những template nào, phiên bản WCAG nào, mức nào, và ngày kiểm. Một dòng khai chung chung rằng website đạt chuẩn mà không nói phạm vi là một lời khẳng định không kiểm lại được, và nó sẽ sai ngay lần cập nhật nội dung kế tiếp.

19. Công cụ Novaverb, tài liệu gốc và hướng thực hành

Với nhóm accessibility, công cụ tự động chỉ là lớp đầu, nên hãy dùng Novaverb để rà phần kỹ thuật của trang rồi dành phần lớn thời gian cho bàn phím và trình đọc màn hình. Mỗi công cụ chỉ quan sát một phần, và phần lớn tiêu chí WCAG không kiểm được bằng máy.

• PageSpeed Checker của Novaverb: chạy Lighthouse, nên ngoài hiệu năng nó còn cho điểm nhóm Accessibility của Lighthouse; đọc đúng phạm vi, đó là một tập con các phép kiểm tự động, không phải một lần nghiệm thu WCAG.
• axe DevTools và WAVE: hai bộ quét trong trình duyệt, dùng để loại các lỗi máy nhận ra được trước khi kiểm tay.
• Colour Contrast Analyser: đo cặp màu mà bộ quét không đọc được, gồm chữ trên ảnh và chữ trong SVG.
• Trình đọc màn hình có sẵn trong hệ điều hành: VoiceOver trên macOS và iOS, Narrator trên Windows, TalkBack trên Android.

Tài liệu nên giữ trong hồ sơ dự án: WCAG 2.2 Quick Reference, ARIA Authoring Practices Guide, ACT Rules của W3C và WordPress Accessibility Handbook. Dùng tài liệu gốc để phân biệt quy định, khuyến nghị và quy ước nội bộ.

Nếu đang tìm lộ trình đào tạo SEO, có thể dùng checklist này làm bài thực hành: chọn một template, đi Tab hết trang, ghi bằng chứng, sửa rồi nghiệm thu lại. Trang khóa học SEO giúp đối chiếu chương trình theo nền tảng hiện tại.

Muốn đưa audit accessibility vào quy trình SEO trên website thật, anh chị có thể xem phạm vi và cách học của khóa học SEO Master. Giá trị của bài thực hành nằm ở khả năng giải thích lỗi và chứng minh đã sửa bằng cùng một phép kiểm.

Kết hợp bài này với điều hướng và UX cùng tối ưu mobile: ba bài dùng chung một bộ phép kiểm bằng bàn phím và bằng thao tác thật.

20. Câu hỏi thường gặp và kết luận

Các câu trả lời dưới đây giúp phân biệt tiêu chuẩn WCAG, khuyến nghị thiết kế và bằng chứng nghiệm thu trong WordPress. Khi gặp một kết quả không rõ, hãy quay về thành phần cụ thể và mã tiêu chí cụ thể để chọn phép kiểm phù hợp trước khi sửa theme hoặc cài thêm plugin.

Accessibility có phải yếu tố xếp hạng của Google không?

Không. Không có tài liệu nào của Google nói website đạt WCAG thì xếp hạng cao hơn. Phần giao nhau thật nằm ở liên kết crawlable, alt text, HTML có ngữ nghĩa và nội dung có sẵn không cần thao tác, tức bốn thứ vừa giúp người dùng vừa giúp máy đọc trang.

axe báo 0 lỗi thì website đã đạt WCAG chưa?

Chưa. Phần lớn tiêu chí WCAG không kiểm được bằng máy, ví dụ thứ tự tiêu điểm có hợp lý không, tên truy cập có nói đúng việc không, phụ đề có chính xác không. Công cụ tự động chỉ loại được nhóm lỗi máy nhận ra, nên vẫn phải đi bàn phím và nghe bằng trình đọc màn hình.

Plugin overlay có giúp website đạt chuẩn không?

Không. Overlay chỉ thêm một lớp tùy chỉnh trình bày, còn phần lớn lỗi nằm trong markup: nút thiếu tên truy cập vẫn thiếu tên, menu chỉ mở bằng hover vẫn chỉ mở bằng hover. Hãy sửa nguyên nhân ở theme và plugin, rồi kiểm lại bằng bàn phím.

Màu thương hiệu không đủ tương phản thì làm sao?

Giữ màu thương hiệu cho khối lớn và nền, rồi chọn một biến thể đậm hơn dành riêng cho chữ và cho viền thành phần. Cách này giữ được nhận diện mà vẫn đạt ngưỡng, và nên khai thẳng hai biến thể đó trong bảng màu để không ai phải chọn lại từng lần.

Có cần thêm ARIA vào mọi thành phần không?

Không nên. Luật đầu tiên của ARIA là đừng dùng ARIA nếu một thẻ HTML gốc đã mang đúng ngữ nghĩa. Thẻ button, nav, main và label đã có sẵn vai trò lẫn hành vi bàn phím; thêm role lên một div rồi tự dựng lại hành vi là thêm chỗ để sai.

Xóa outline để thiết kế gọn hơn có được không?

Không, trừ khi có chỉ báo thay thế rõ ràng. Đặt outline bằng none trong reset CSS là xóa chỉ báo trên toàn website và làm người dùng bàn phím mất dấu tiêu điểm. Nếu muốn đổi kiểu, hãy đổi bằng outline riêng hoặc box-shadow và chỉ nhắm vào focus-visible.

Video nhúng từ nền tảng ngoài thì phụ đề tính thế nào?

Vẫn tính, vì người dùng xem nó trên trang của anh chị. Hãy bật phụ đề ở chính nền tảng đó và soát lại bản tự động, nhất là tên riêng, thuật ngữ và số liệu. Phụ đề tự động chưa soát không được coi là phụ đề đã đạt.

Nên kiểm accessibility trên bao nhiêu trang?

Bắt đầu bằng ba template đại diện: trang chủ, một bài viết đơn và một trang có biểu mẫu. Lỗi accessibility thường thuộc về thành phần và template, nên sửa ở đó là hết cho mọi trang dùng chung template, rồi mới mở rộng sang các nhóm trang còn lại.

Kết luận: accessibility đạt yêu cầu là website mà người dùng bàn phím, người dùng trình đọc màn hình và người cần phóng to chữ đều hoàn tất được việc của họ, không phải website có một báo cáo xanh. Kiểm đủ mười tiêu chí 154-163 bằng cả ba lớp phép kiểm, sửa theo mức chặn và lặp lại sau mỗi lần cập nhật theme hoặc plugin giúp SEO WordPress có một quy trình cải thiện rõ ràng.