THIẾT KẾ WEBSITE THEO WCAG 2.2: CHECKLIST KHẢ NĂNG TIẾP CẬN

WCAG 2.2 giúp website dễ sử dụng hơn với người khuyết tật và nhiều nhóm người dùng khác. Tham khảo checklist thiết kế website từ màu sắc, bàn phím, biểu mẫu, nội dung đến kích thước vùng tương tác và xác thực.

Mục lục

Thiết kế website theo WCAG 2.2: Checklist khả năng tiếp cận là gì?

Thiết kế website WCAG 2.2 là quá trình xây dựng giao diện, nội dung và chức năng website theo các nguyên tắc về khả năng tiếp cận của Web Content Accessibility Guidelines 2.2. Mục tiêu là giúp nhiều nhóm người dùng có thể nhận biết nội dung, điều hướng, tương tác và hoàn thành tác vụ trên website thuận lợi hơn, kể cả khi họ sử dụng bàn phím, trình đọc màn hình, thiết bị cảm ứng hoặc các công nghệ hỗ trợ khác.

Khả năng tiếp cận không nên được hiểu đơn giản là “thiết kế website dành cho người khuyết tật”. Khi một giao diện có độ tương phản tốt, nút bấm đủ lớn, biểu mẫu rõ ràng, keyboard navigation hợp lý và nội dung được tổ chức có cấu trúc, trải nghiệm của phần lớn người dùng cũng được cải thiện.

Thiết kế website WCAG 2.2 là gì?

Nếu cần giải thích ngắn gọn thiết kế website WCAG 2.2 là gì, có thể hiểu đây là phương pháp thiết kế và phát triển website dựa trên bốn nguyên tắc lớn: nội dung có thể nhận biết, giao diện có thể thao tác, thông tin dễ hiểu và mã nguồn đủ tương thích với trình duyệt cũng như công nghệ hỗ trợ.

Bốn nguyên tắc thường được triển khai theo hướng:

Perceivable – Có thể nhận biết: nội dung phải có cách trình bày để người dùng có thể tiếp nhận bằng những phương thức phù hợp.
Operable – Có thể thao tác: chức năng không được phụ thuộc hoàn toàn vào một phương thức điều khiển gây trở ngại cho người dùng.
Understandable – Có thể hiểu: nội dung và cách hoạt động của giao diện cần rõ ràng, nhất quán và có khả năng dự đoán.
Robust – Tương thích: cấu trúc kỹ thuật cần đủ rõ để trình duyệt và công nghệ hỗ trợ có thể diễn giải chính xác.

WCAG 2.2 có các mức tuân thủ nào?

Các Success Criteria của WCAG được phân thành ba cấp độ A, AA và AAA. Trong các dự án website doanh nghiệp, mức AA thường là mục tiêu thực tế được sử dụng để xây dựng phạm vi kiểm tra vì nó bao gồm các tiêu chí nền tảng ở mức A và bổ sung nhiều yêu cầu quan trọng về khả năng sử dụng.

Level A: nhóm yêu cầu nền tảng tối thiểu.
Level AA: mở rộng các yêu cầu quan trọng về trải nghiệm và khả năng tiếp cận.
Level AAA: mức yêu cầu cao hơn nhưng không phải lúc nào cũng phù hợp để áp dụng cho toàn bộ nội dung của mọi website.

Doanh nghiệp không nên hiểu việc đạt WCAG như một danh sách checkbox chỉ cần kiểm tra một lần. Accessibility cần được đưa vào quy trình thiết kế, lập trình, biên tập nội dung, kiểm thử và bảo trì website.

WCAG 2.2 khác gì so với WCAG 2.1?

WCAG 2.2 tiếp tục kế thừa phần lớn các Success Criteria trước đó và bổ sung những yêu cầu mới nhằm xử lý tốt hơn các tình huống liên quan đến focus, thao tác kéo thả, kích thước vùng tương tác, trợ giúp nhất quán, nhập dữ liệu lặp lại và quá trình xác thực.

Các tiêu chí mới đáng lưu ý khi xây dựng website doanh nghiệp gồm:

Focus Not Obscured (Minimum).
Focus Not Obscured (Enhanced).
Focus Appearance.
Dragging Movements.
Target Size (Minimum).
Consistent Help.
Redundant Entry.
Accessible Authentication (Minimum).
Accessible Authentication (Enhanced).

Do đó, cách thiết kế website WCAG 2.2 không chỉ tập trung vào màu sắc hoặc alt text. Nó tác động đến toàn bộ kiến trúc trải nghiệm, từ menu, form, modal, button, carousel cho đến đăng nhập và quy trình đặt hàng.

Để accessibility không trở thành một lớp xử lý bổ sung sau khi website đã hoàn thiện, doanh nghiệp nên tích hợp yêu cầu này ngay trong chiến lược Thiết kế giao diện website doanh nghiệp chuẩn UI/UX. Khi hệ thống UI được chuẩn hóa từ đầu, việc kiểm soát contrast, focus, input, button và component trở nên nhất quán hơn.

Thiết kế website chuyên nghiệp cho doanh nghiệp

Sở hữu website chuẩn giao diện, tối ưu tốc độ, dễ quản trị và phù hợp với nhu cầu phát triển kinh doanh online.

Xem dịch vụ thiết kế website

Vì sao chủ đề này quan trọng với doanh nghiệp?

Website doanh nghiệp ngày nay không chỉ được sử dụng bằng máy tính với chuột. Người dùng có thể truy cập từ smartphone, tablet, bàn phím, màn hình cảm ứng hoặc những công nghệ hỗ trợ khác nhau. Một giao diện chỉ được kiểm thử trong điều kiện lý tưởng có thể phát sinh nhiều rào cản ngoài thực tế.

Khả năng tiếp cận giúp mở rộng phạm vi người dùng

Một website khó đọc, khó bấm hoặc không sử dụng được bằng bàn phím vô tình loại bỏ một nhóm người dùng khỏi hành trình chuyển đổi. Điều này đặc biệt đáng lưu ý với các website thương mại điện tử, giáo dục, tài chính, y tế, dịch vụ công và hệ thống B2B có lượng người dùng đa dạng.

Accessibility giúp doanh nghiệp tiếp cận một phạm vi người dùng rộng hơn bằng cách giảm những rào cản không cần thiết trong giao diện.

WCAG thúc đẩy chất lượng UI/UX tốt hơn

Nhiều nguyên tắc accessibility cũng chính là những nguyên tắc usability tốt.

Nội dung có contrast rõ sẽ dễ đọc hơn.
Button lớn hơn sẽ dễ thao tác trên điện thoại.
Form có label rõ ràng sẽ dễ hoàn thành hơn.
Focus state giúp người dùng nhận biết vị trí hiện tại.
Heading đúng cấu trúc giúp nội dung dễ quét.
Error message rõ ràng giúp giảm lỗi nhập liệu.

Do đó, doanh nghiệp không nên xem accessibility và UI/UX là hai hướng tối ưu độc lập.

Khả năng tiếp cận ảnh hưởng đến hành trình chuyển đổi

Hãy hình dung khách hàng đã đọc gần hết một trang dịch vụ nhưng không thể thao tác form bằng bàn phím, không nhìn rõ trạng thái focus hoặc không biết trường nào đang bị lỗi. Toàn bộ công sức tạo nội dung và thu hút traffic có thể bị gián đoạn ngay tại bước cuối.

Do đó, accessibility cần được kết hợp với Cách thiết kế trang dịch vụ giúp khách hàng dễ ra quyết định. Một trang dịch vụ chỉ thực sự hiệu quả khi người dùng không những hiểu giải pháp mà còn có thể thao tác thuận lợi để tiến tới bước liên hệ.

Accessibility giúp hệ thống giao diện nhất quán hơn

Khi doanh nghiệp áp dụng WCAG ngay từ design system, các component như button, input, dropdown, modal, pagination và alert đều có quy tắc rõ về màu sắc, focus, keyboard interaction và trạng thái lỗi.

Điều này giảm tình trạng mỗi trang được thiết kế và lập trình theo một kiểu khác nhau.

Khả năng tiếp cận có mối liên hệ với SEO kỹ thuật

WCAG không phải một bộ tiêu chí SEO và việc đáp ứng WCAG không đồng nghĩa website tự động tăng thứ hạng. Tuy nhiên, nhiều thực hành tốt về accessibility có sự giao thoa với cấu trúc website chất lượng như semantic HTML, heading rõ ràng, nội dung có cấu trúc, link dễ hiểu và hình ảnh có mô tả phù hợp.

Những yếu tố này cũng giúp công cụ tìm kiếm hiểu cấu trúc tài liệu tốt hơn.

Accessibility hỗ trợ khả năng hiểu nội dung trong môi trường GEO

Đối với GEO, nội dung có cấu trúc rõ ràng, heading mô tả đúng chủ đề, liên kết có anchor text cụ thể và semantic HTML hợp lý giúp nội dung trở nên dễ phân tích hơn đối với các hệ thống máy móc.

Accessibility và GEO không phải cùng một khái niệm, nhưng đều hưởng lợi từ việc xây dựng nội dung có cấu trúc, ngữ nghĩa và khả năng diễn giải rõ ràng.

Website dễ sử dụng giúp bảo vệ giá trị của nguồn khách hàng

Doanh nghiệp thường đầu tư nhiều chi phí để thu hút traffic từ SEO, quảng cáo và social media. Nếu website tạo ra rào cản sử dụng, một phần giá trị từ nguồn truy cập có thể bị lãng phí.

Song song với việc tối ưu trải nghiệm, doanh nghiệp cũng cần xây dựng quy trình quản lý lead sau chuyển đổi. Có thể tham khảo thêm Data khách hàng là gì? Cách thu thập khách hàng hiệu quả cho kinh doanh online để hiểu cách dữ liệu từ website có thể được thu thập và khai thác trong hoạt động kinh doanh.

Thiết kế website theo WCAG 2.2: Checklist khả năng tiếp cận

Tiêu chí hoặc thành phần cần đánh giá

Khi kiểm tra thiết kế website WCAG 2.2, không nên chỉ chạy một công cụ tự động rồi kết luận website đã đáp ứng accessibility. Nhiều vấn đề như keyboard navigation, focus order, nội dung thay đổi hoặc trải nghiệm với screen reader vẫn cần kiểm thử thủ công.

1. Cấu trúc HTML có ngữ nghĩa

Semantic HTML giúp trình duyệt và công nghệ hỗ trợ hiểu vai trò của từng thành phần.

Nên ưu tiên sử dụng đúng các phần tử như:

header cho đầu trang.
nav cho khu vực điều hướng.
main cho nội dung chính.
article cho nội dung độc lập.
section cho nhóm nội dung có ý nghĩa.
button cho hành động.
a cho liên kết điều hướng.
form, label và input cho biểu mẫu.
footer cho khu vực cuối trang.

Không nên sử dụng div hoặc span để giả lập button khi một phần tử button gốc có thể giải quyết đúng chức năng.

2. Heading phải có cấu trúc logic

Heading không chỉ được sử dụng để tăng kích thước chữ. Chúng tạo ra cấu trúc phân cấp nội dung.

H1 đại diện chủ đề chính của trang.
H2 chia các nhóm nội dung lớn.
H3 triển khai nội dung bên trong H2.
H4 tiếp tục chia nhỏ khi thực sự cần.

Không nên chọn H4 chỉ vì nó có font nhỏ hơn H3. Kích thước chữ nên được xử lý bằng CSS.

3. Độ tương phản của văn bản

Văn bản và nền cần có độ tương phản đủ rõ. Với mục tiêu WCAG 2.2 Level AA, cần kiểm tra contrast dựa trên loại chữ và kích thước chữ thay vì chỉ đánh giá bằng mắt.

Đặc biệt cần kiểm tra:

Text thông thường.
Text trên button.
Text trong banner.
Placeholder.
Link.
Text khi hover.
Text disabled nếu vẫn cần được đọc.

4. Không sử dụng màu sắc làm tín hiệu duy nhất

Nếu field lỗi chỉ chuyển từ viền xám sang viền đỏ mà không có thông báo, người dùng gặp khó khăn trong việc nhận biết vấn đề.

Nên kết hợp:

Màu sắc.
Icon khi phù hợp.
Thông báo bằng văn bản.
Trạng thái ARIA phù hợp.

Website cần được kiểm tra bằng bàn phím mà không sử dụng chuột.

Các thành phần cần kiểm tra gồm:

Menu.
Dropdown.
Button.
Link.
Form.
Modal.
Tabs.
Accordion.
Carousel.

Người dùng phải có khả năng di chuyển tới và thao tác các chức năng tương tác quan trọng.

6. Focus phải nhìn thấy được

Một lỗi phổ biến trong CSS là sử dụng outline: none nhưng không cung cấp trạng thái focus thay thế. Điều này khiến người sử dụng bàn phím không biết họ đang đứng ở đâu trên giao diện.

Focus state cần:

Dễ nhìn thấy.
Có độ tương phản phù hợp.
Không bị loại bỏ vì lý do thẩm mỹ.
Được áp dụng nhất quán cho component.

7. Focus không bị che khuất

WCAG 2.2 đặc biệt nhấn mạnh tình huống phần tử đang focus bị che bởi sticky header, cookie banner, sticky CTA hoặc một thành phần giao diện khác.

Khi người dùng di chuyển bằng phím Tab, ít nhất một phần tử đang focus cần duy trì khả năng nhận biết theo yêu cầu tương ứng.

Thiết Kế Website Chuyên Nghiệp Cho Doanh Nghiệp

Sở hữu website hiện đại, chuẩn SEO, tối ưu tốc độ và trải nghiệm người dùng. Giải pháp phù hợp cho doanh nghiệp Startup, SME và doanh nghiệp đang mở rộng kinh doanh online.

Xem Các Gói Thiết Kế Website

8. Kích thước vùng tương tác

WCAG 2.2 bổ sung Target Size (Minimum) nhằm giảm tình trạng các vùng click hoặc tap quá nhỏ và quá gần nhau. Khi xây dựng button, icon action hoặc những điều khiển tương tác, cần kiểm tra cả kích thước và khoảng cách theo tiêu chí áp dụng, đồng thời lưu ý các ngoại lệ của tiêu chuẩn.

Trong thực tế UI/UX, doanh nghiệp nên ưu tiên vùng tương tác rộng hơn mức tối thiểu nếu không bị giới hạn về thiết kế, đặc biệt đối với:

Nút gọi điện.
Nút gửi form.
Icon đóng modal.
Pagination.
Menu mobile.
Checkbox và radio.

9. Không bắt buộc người dùng phải kéo thả

Nếu một chức năng sử dụng thao tác dragging, cần cân nhắc phương án đơn giản hơn để thực hiện cùng chức năng bằng single pointer khi tiêu chí áp dụng.

Ví dụ, một danh sách cho phép drag để sắp xếp có thể cung cấp thêm:

Nút di chuyển lên.
Nút di chuyển xuống.
Control chọn vị trí.

Việc hỗ trợ keyboard riêng cho drag-and-drop vẫn cần được xem xét độc lập với yêu cầu về thao tác pointer.

10. Alt text cho hình ảnh

Không phải mọi hình ảnh đều cần alt text dài. Nội dung alt phải phụ thuộc vào vai trò của hình ảnh.

Ảnh chứa thông tin: mô tả thông tin cần thiết.
Ảnh sản phẩm: mô tả sản phẩm phù hợp ngữ cảnh.
Ảnh trang trí: có thể sử dụng alt rỗng phù hợp.
Ảnh chứa text quan trọng: nên hạn chế và cung cấp nội dung tương đương.

Tránh nhồi nhét từ khóa SEO vào alt text nếu nội dung đó không mô tả hình ảnh.

11. Video và audio

Với media được sử dụng trên website, cần xác định các yêu cầu về caption, transcript, audio description hoặc phương án thay thế tùy loại nội dung và tiêu chí cần đáp ứng.

12. Form phải có label rõ ràng

Placeholder không nên thay thế hoàn toàn label. Các field cần được liên kết đúng với label để trình đọc màn hình có thể xác định mục đích.

Form cần kiểm tra:

Label.
Required state.
Instructions.
Error message.
Success message.
Autocomplete khi phù hợp.
Keyboard operation.

Doanh nghiệp có thể kết hợp checklist accessibility này với hướng dẫn Cách thiết kế form liên hệ tăng tỷ lệ khách hàng để lại thông tin để vừa giảm rào cản sử dụng vừa nâng cao khả năng chuyển đổi.

13. Error message phải chỉ ra cách khắc phục

Không nên chỉ hiển thị:

“Dữ liệu không hợp lệ.”

Nên cụ thể hơn:

Vui lòng nhập email.
Email chưa đúng định dạng.
Vui lòng nhập số điện thoại.
Mật khẩu cần đáp ứng yêu cầu đã nêu.

14. Không yêu cầu nhập lại dữ liệu không cần thiết

Trong một quy trình nhiều bước, nếu người dùng đã cung cấp thông tin trước đó và dữ liệu vẫn có thể được hệ thống sử dụng, cần hạn chế việc yêu cầu nhập lại khi Success Criterion tương ứng áp dụng, trừ các trường hợp ngoại lệ.

Ví dụ trong checkout, thông tin người mua có thể được sử dụng để hỗ trợ điền thông tin giao hàng khi phù hợp.

15. Authentication cần dễ tiếp cận

Các quy trình đăng nhập hoặc xác thực không nên phụ thuộc vào việc người dùng phải thực hiện những bài kiểm tra nhận thức không cần thiết khi tiêu chí Accessible Authentication áp dụng.

Website cần xem xét khả năng:

Sử dụng password manager.
Cho phép paste mật khẩu.
Hỗ trợ autofill.
Cung cấp phương thức xác thực phù hợp.

16. Help cần xuất hiện nhất quán

Nếu doanh nghiệp cung cấp cùng một loại cơ chế hỗ trợ trên nhiều trang trong một tập hợp trang, vị trí tương đối của cơ chế này cần được duy trì nhất quán theo tiêu chí áp dụng.

Ví dụ:

Thông tin liên hệ.
Chat hỗ trợ.
FAQ.
Hệ thống tự hỗ trợ.

17. Link text cần có ý nghĩa

Nên hạn chế những anchor text quá chung chung như “Xem thêm” khi ngữ cảnh không đủ rõ.

Anchor text cụ thể vừa hỗ trợ accessibility vừa giúp người đọc hiểu đích đến trước khi click.

Khi modal mở, keyboard focus cần được quản lý hợp lý. Khi đóng modal, focus nên quay lại điểm phù hợp để người dùng có thể tiếp tục hành trình.

Modal không nên tạo keyboard trap khiến người dùng không thể thoát.

Quy trình triển khai từng bước

Cách thiết kế website WCAG 2.2 hiệu quả nhất là đưa accessibility vào từng giai đoạn của dự án thay vì chờ đến khi website hoàn thiện mới chạy audit.

Bước 1: Xác định phạm vi và mức mục tiêu

Doanh nghiệp cần xác định:

Những website hoặc ứng dụng nào nằm trong phạm vi.
Những template nào cần kiểm tra.
Những user flow quan trọng.
Mức WCAG mục tiêu.
Component của bên thứ ba.
Nội dung do người dùng tạo ra nếu có.

Bước 2: Audit website hiện tại

Nếu website đã tồn tại, hãy audit trước khi thiết kế lại để hiểu vấn đề thực tế.

Có thể phân nhóm lỗi:

Contrast.
Semantic HTML.
Keyboard.
Focus.
Form.
Image.
Media.
Navigation.
ARIA.
Authentication.

Bước 3: Kiểm tra các user flow quan trọng

Không nên chỉ kiểm tra từng trang riêng lẻ. Hãy kiểm tra theo hành trình thực tế.

Ví dụ website doanh nghiệp:

Trang chủ → trang dịch vụ → form tư vấn.
Trang chủ → bảng giá → liên hệ.
Google → bài viết → trang dịch vụ → CTA.
Trang sản phẩm → giỏ hàng → thanh toán.

Trang chủ thường là điểm khởi đầu quan trọng. Doanh nghiệp có thể kết hợp accessibility với kiến trúc trong bài Thiết kế trang chủ website doanh nghiệp cần những khu vực nào? để đảm bảo navigation, CTA và các thành phần chính được tổ chức hợp lý ngay từ đầu.

Bước 4: Xây dựng accessible design system

Không nên xử lý accessibility riêng cho từng trang. Hãy giải quyết từ component.

Design system nên quy định accessibility cho:

Typography.
Color palette.
Button.
Link.
Input.
Select.
Checkbox.
Radio.
Modal.
Alert.
Tabs.
Accordion.

Bước 5: Kiểm tra contrast ngay trong giai đoạn thiết kế

Designer nên kiểm tra contrast trước khi bàn giao UI. Không nên chờ frontend hoàn thiện mới phát hiện màu thương hiệu và màu nền không đáp ứng mục tiêu accessibility.

Bước 6: Thiết kế đầy đủ các state

Mỗi interactive component nên có trạng thái phù hợp:

Default.
Hover.
Focus.
Active.
Disabled.
Error.
Success.
Loading khi cần.

Bước 7: Lập trình bằng semantic HTML trước ARIA

Nguyên tắc thực tế là ưu tiên phần tử HTML gốc có đúng semantic trước khi sử dụng ARIA để mô phỏng hành vi.

Ví dụ, nếu cần một button, nên sử dụng phần tử button thay vì div rồi thêm role và nhiều JavaScript để mô phỏng.

Bước 8: Xây dựng keyboard interaction

Developer cần kiểm tra ngay khi phát triển component, đặc biệt đối với:

Dropdown.
Offcanvas menu.
Modal.
Tabs.
Autocomplete.
Custom select.
Carousel.

Thiết kế website theo WCAG 2.2: Checklist khả năng tiếp cận

Bước 9: Xây dựng accessible form

Form cần được kiểm tra như một user flow riêng.

Label liên kết đúng field.
Error được mô tả rõ.
Required field được nhận biết.
Focus chuyển hợp lý.
Không mất dữ liệu sau lỗi.
Status sau submit được thông báo.

Bước 10: Kiểm tra nội dung trước khi xuất bản

Content editor cũng có trách nhiệm với accessibility.

Checklist biên tập có thể bao gồm:

Heading đúng thứ tự.
Anchor text có ý nghĩa.
Alt text đúng ngữ cảnh.
Không dùng hình ảnh để thay văn bản khi không cần thiết.
Table có cấu trúc rõ ràng.
Video có phương án accessibility phù hợp.

Bước 11: Chạy automated accessibility testing

Các công cụ tự động có thể giúp phát hiện nhanh một phần lỗi như:

Contrast.
Thiếu label.
Thiếu alt.
Một số lỗi ARIA.
Một số vấn đề semantic.

Tuy nhiên kết quả tự động không thể thay thế hoàn toàn kiểm thử thủ công.

Bước 12: Kiểm thử bằng bàn phím

Tắt chuột và thử hoàn thành các tác vụ quan trọng chỉ bằng keyboard.

Kiểm tra:

Tab order.
Focus visibility.
Skip link.
Menu.
Form.
Modal.
Khả năng thoát khỏi component.

Những trang và chức năng quan trọng nên được kiểm thử bằng công nghệ hỗ trợ phù hợp để phát hiện các vấn đề mà automated tool không nhận biết được.

Bước 14: Kiểm tra responsive và zoom

Accessibility không chỉ được kiểm tra ở desktop 100%. Cần xem xét website trong những điều kiện như:

Viewport nhỏ.
Text phóng to.
Browser zoom.
Content reflow.
Mobile orientation.

Bước 15: Sửa lỗi theo mức ưu tiên

Nên ưu tiên các lỗi:

Ngăn người dùng hoàn thành tác vụ.
Ảnh hưởng nhiều template.
Xuất hiện trong component dùng chung.
Liên quan tới menu, đăng nhập, form và checkout.

Sửa một component trong design system thường hiệu quả hơn sửa cùng lỗi riêng lẻ trên hàng chục trang.

Bước 16: Kiểm tra lại sau khi sửa

Mỗi thay đổi cần regression test để đảm bảo việc sửa accessibility không làm phát sinh lỗi chức năng hoặc ảnh hưởng component khác.

Ví dụ và lỗi thường gặp

Ví dụ 1: Nút CTA không có focus state

Một website sử dụng CSS:

outline: none;

để loại bỏ đường focus mặc định nhưng không tạo focus style mới.

Kết quả là người dùng bàn phím vẫn có thể Tab tới button nhưng không biết phần tử nào đang được chọn.

Giải pháp là xây dựng focus indicator rõ ràng và thống nhất trong design system thay vì xóa hoàn toàn outline.

Khi người dùng nhấn Tab đến một link nằm phía trên viewport, trình duyệt cuộn trang nhưng sticky header che mất link đó.

Đây là tình huống cần được đặc biệt kiểm tra khi triển khai WCAG 2.2.

Nút đóng modal được thiết kế chỉ như một dấu X nhỏ, vùng tương tác sát mép và khó bấm trên màn hình cảm ứng.

Thay vì chỉ tăng kích thước biểu tượng, có thể mở rộng vùng tương tác xung quanh icon mà vẫn giữ thiết kế trực quan gọn gàng.

Ví dụ 4: Carousel chỉ sử dụng thao tác kéo

Carousel trên mobile chỉ cho phép swipe hoặc drag mà không có control thay thế phù hợp.

Cần xem xét bổ sung các nút Next/Previous hoặc cơ chế single pointer phù hợp để tránh phụ thuộc hoàn toàn vào thao tác kéo.

Thiết Kế Website Chuyên Nghiệp Cho Doanh Nghiệp

Xây dựng website chuẩn SEO, giao diện hiện đại, tối ưu trải nghiệm người dùng và hỗ trợ phát triển kinh doanh trực tuyến hiệu quả. Các gói thiết kế phù hợp từ Startup đến doanh nghiệp vừa và nhỏ.

Xem Dịch Vụ Thiết Kế Website

Lỗi 1: Nghĩ rằng accessibility chỉ là alt text

Alt text chỉ là một phần nhỏ. Website còn cần xử lý keyboard, contrast, focus, form, navigation, semantic HTML, media và nhiều loại tương tác khác.

Lỗi 2: Chỉ chạy Lighthouse rồi kết luận đạt WCAG

Automated testing hữu ích nhưng không thể đánh giá toàn bộ yêu cầu. Một trang có điểm accessibility cao vẫn có thể tồn tại keyboard trap, focus order không hợp lý hoặc thông tin khó hiểu đối với screen reader.

Lỗi 3: Dùng màu để thể hiện trạng thái duy nhất

Ví dụ trường lỗi chỉ chuyển sang màu đỏ nhưng không có text giải thích. Nên bổ sung message và trạng thái kỹ thuật phù hợp.

Lỗi 4: Placeholder thay thế label

Placeholder biến mất khi nhập liệu và thường không phải giải pháp thay thế đầy đủ cho label của field.

Lỗi 5: Custom component nhưng không hỗ trợ keyboard

Custom dropdown có thể hoạt động hoàn hảo bằng chuột nhưng người dùng Tab không thể mở hoặc chọn option.

Đây là lỗi thường gặp khi component được xây dựng chủ yếu dựa trên JavaScript mà không xác định interaction model từ đầu.

Người dùng mở popup nhưng không thể di chuyển focus đúng cách hoặc không thể đóng bằng phương thức phù hợp.

Lỗi 7: Heading được chọn theo kích thước font

Developer sử dụng H4 vì muốn chữ nhỏ thay vì dựa trên cấu trúc nội dung. Điều này làm heading hierarchy mất logic.

Lỗi 8: Button và link bị sử dụng sai mục đích

Button nên được sử dụng cho hành động, link thường phục vụ điều hướng. Việc sử dụng sai semantic có thể tạo trải nghiệm khó dự đoán đối với công nghệ hỗ trợ.

Lỗi 9: Chỉ kiểm thử bằng chuột

Đây là một trong những kinh nghiệm thiết kế website WCAG 2.2 quan trọng: mọi user flow chính cần được thử mà không phụ thuộc vào mouse.

Lỗi 10: Accessibility chỉ được xử lý cuối dự án

Nếu accessibility chỉ được kiểm tra sau khi toàn bộ website hoàn thiện, doanh nghiệp có thể phải sửa lại design system, component và luồng tương tác, làm tăng chi phí đáng kể.

Lỗi 11: Lạm dụng ARIA

ARIA không phải công cụ để biến mọi div thành component tùy chỉnh. Nếu HTML native đã có phần tử phù hợp, nên ưu tiên semantic HTML và chỉ sử dụng ARIA khi cần thiết.

Lỗi 12: Chỉ tối ưu trang chủ

Accessibility cần được áp dụng xuyên suốt hành trình, đặc biệt tại:

Trang dịch vụ.
Trang sản phẩm.
Form liên hệ.
Đăng nhập.
Checkout.
Trang tìm kiếm.
Trang hỗ trợ.

Checklist áp dụng

Checklist dưới đây có thể sử dụng như tài liệu rà soát ban đầu cho một giải pháp website doanh nghiệp. Tuy nhiên, đây không phải tuyên bố chứng nhận tuân thủ WCAG và không thay thế việc đánh giá từng Success Criterion trong phạm vi cụ thể.

Checklist cấu trúc HTML

Có một khu vực nội dung chính rõ ràng.
Semantic HTML được ưu tiên.
Heading có thứ tự logic.
Button sử dụng đúng semantic.
Link có mục đích rõ ràng.
Danh sách sử dụng cấu trúc list phù hợp.
Table có cấu trúc header phù hợp khi cần.
ARIA chỉ được sử dụng khi có lý do rõ ràng.

Checklist keyboard

Tất cả chức năng quan trọng có thể thao tác bằng keyboard theo yêu cầu áp dụng.
Không có keyboard trap.
Tab order hợp lý.
Focus luôn dễ nhận biết.
Focus không bị sticky element che mất theo tiêu chí áp dụng.
Modal quản lý focus đúng.
Dropdown hỗ trợ keyboard.
Menu mobile hỗ trợ keyboard.

Checklist màu sắc và contrast

Text có contrast đạt mục tiêu đã xác định.
Button text dễ đọc.
Link không phụ thuộc duy nhất vào màu khi cần phân biệt.
Error không chỉ thể hiện bằng màu.
Focus indicator có khả năng nhận biết.
UI component có non-text contrast phù hợp khi tiêu chí áp dụng.

Checklist hình ảnh

Ảnh có alt phù hợp với ngữ cảnh.
Ảnh trang trí được xử lý phù hợp.
Không nhồi nhét từ khóa vào alt.
Thông tin quan trọng không chỉ tồn tại trong ảnh.
Logo có tên thay thế phù hợp khi cần.

Checklist form

Mỗi input có label phù hợp.
Required field dễ xác định.
Error message rõ ràng.
Error có hướng dẫn sửa khi phù hợp.
Không xóa dữ liệu hợp lệ sau một lỗi khác.
Keyboard navigation hoạt động.
Focus state rõ ràng.
Status sau submit được thông báo phù hợp.
Autocomplete được sử dụng khi thích hợp.
Không yêu cầu nhập lại dữ liệu không cần thiết khi tiêu chí áp dụng.

Checklist button và vùng tương tác

Button có accessible name rõ ràng.
Vùng click/tap được kiểm tra theo Target Size áp dụng.
Icon-only button có tên truy cập phù hợp.
Các target nhỏ không được đặt quá sát nhau nếu gây vi phạm tiêu chí.
Không bắt buộc drag nếu có yêu cầu cung cấp phương thức single pointer thay thế.

Có cách bỏ qua khối nội dung lặp lại khi cần.
Menu có thứ tự logic.
Link text có ý nghĩa.
Breadcrumb được xây dựng đúng semantic nếu sử dụng.
Navigation nhất quán giữa các trang.
Không có menu chỉ hoạt động khi hover bằng chuột.

Modal có tên hoặc tiêu đề rõ ràng.
Focus được đưa tới vị trí phù hợp khi mở.
Keyboard không thoát vào nội dung nền một cách không mong muốn.
Có phương thức đóng rõ ràng.
Focus được khôi phục hợp lý sau khi đóng.
Nút đóng có vùng tương tác phù hợp.

Checklist nội dung

Ngôn ngữ trang được xác định phù hợp.
Heading mô tả đúng nội dung.
Paragraph dễ đọc.
Link anchor rõ nghĩa.
Không sử dụng chỉ dẫn phụ thuộc hoàn toàn vào màu hoặc vị trí như “bấm nút màu đỏ bên phải”.
Từ viết tắt và thuật ngữ phức tạp được giải thích khi cần.

Checklist media

Video được kiểm tra yêu cầu caption.
Audio được kiểm tra yêu cầu transcript hoặc phương án thay thế.
Media không tự động phát gây cản trở khi không phù hợp.
Control media có thể thao tác.

Checklist responsive

Content reflow hợp lý.
Không phát sinh horizontal scroll không cần thiết.
Text vẫn đọc được khi phóng to trong điều kiện áp dụng.
Không khóa orientation nếu không có lý do phù hợp.
Button vẫn dễ bấm trên mobile.
Form không bị vỡ layout.

Checklist kiểm thử

Đã chạy automated accessibility testing.
Đã kiểm thử keyboard thủ công.
Đã kiểm tra focus order.
Đã kiểm tra các flow chuyển đổi chính.
Đã kiểm tra mobile.
Đã kiểm tra zoom và reflow phù hợp.
Đã kiểm thử công nghệ hỗ trợ đối với các chức năng quan trọng khi phạm vi dự án yêu cầu.
Đã regression test sau khi sửa lỗi.

Checklist quản trị dài hạn

Accessibility được đưa vào Definition of Done.
Designer có checklist contrast và focus.
Developer có checklist semantic và keyboard.
Content editor có hướng dẫn heading và alt text.
Component mới được kiểm tra accessibility trước khi đưa vào design system.
Các template quan trọng được audit định kỳ.

Thiết kế website theo WCAG 2.2: Checklist khả năng tiếp cận

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

Thiết kế website WCAG 2.2 là gì?

Thiết kế website WCAG 2.2 là quá trình xây dựng nội dung, giao diện và chức năng web dựa trên Web Content Accessibility Guidelines 2.2 nhằm giảm các rào cản trong việc nhận biết, điều hướng, tương tác và sử dụng website.

WCAG 2.2 có thay thế WCAG 2.1 không?

WCAG 2.2 kế thừa phần lớn các Success Criteria của WCAG 2.1 và bổ sung thêm các yêu cầu mới. Khi bắt đầu một dự án accessibility mới, doanh nghiệp nên đánh giá tiêu chuẩn phù hợp với yêu cầu pháp lý, hợp đồng và mục tiêu thực tế của dự án.

Website doanh nghiệp nên hướng đến WCAG mức nào?

Level AA thường được lựa chọn làm mục tiêu cho nhiều dự án vì bao gồm Level A và thêm nhiều yêu cầu quan trọng. Tuy nhiên, mức cần đáp ứng phải được xác định dựa trên thị trường, ngành nghề, hợp đồng và yêu cầu pháp lý cụ thể.

Đạt điểm Accessibility 100 trên Lighthouse có nghĩa là đạt WCAG 2.2 không?

Không. Công cụ tự động chỉ có thể kiểm tra một phần vấn đề. Nhiều tiêu chí cần đánh giá bằng keyboard, screen reader hoặc kiểm tra thủ công về nội dung và interaction.

WCAG 2.2 có yêu cầu button tối thiểu 24 x 24 CSS pixel không?

Success Criterion 2.5.8 Target Size (Minimum) ở Level AA sử dụng ngưỡng 24 x 24 CSS pixel hoặc yêu cầu về khoảng cách trong các trường hợp tương ứng, đồng thời tiêu chí có một số ngoại lệ. Khi thiết kế thực tế, nên ưu tiên vùng tương tác thoải mái hơn nếu giao diện cho phép thay vì coi con số tối thiểu là kích thước mục tiêu tối ưu.

Có phải tất cả hình ảnh đều phải có mô tả alt dài?

Không. Alt text phụ thuộc vào mục đích của hình ảnh. Hình ảnh trang trí thường có thể sử dụng alt rỗng phù hợp, trong khi hình ảnh truyền tải thông tin cần có phương án thay thế tương đương.

Placeholder có thể thay label của form không?

Không nên sử dụng placeholder như giải pháp thay thế duy nhất cho label. Label rõ ràng giúp cả người dùng thông thường và công nghệ hỗ trợ xác định mục đích của trường nhập liệu tốt hơn.

Có cần hỗ trợ sử dụng website hoàn toàn bằng bàn phím không?

Các chức năng thuộc phạm vi tiêu chí keyboard của WCAG cần có khả năng thao tác bằng giao diện bàn phím theo yêu cầu tương ứng, ngoại trừ những trường hợp mà thao tác phụ thuộc bản chất vào đường di chuyển của người dùng theo quy định của tiêu chí.

Có nên xóa outline của button vì không đẹp không?

Không nên xóa focus indicator mà không cung cấp giải pháp thay thế phù hợp. Designer hoàn toàn có thể thiết kế focus state đẹp, đồng nhất thương hiệu nhưng vẫn dễ nhận biết.

ARIA có thể sửa mọi vấn đề accessibility không?

Không. ARIA bổ sung thông tin accessibility cho những trường hợp phù hợp nhưng không thay thế semantic HTML, keyboard interaction hoặc thiết kế UI tốt. Ưu tiên sử dụng HTML native đúng mục đích trước khi xây dựng component tùy chỉnh.

WCAG có giúp SEO tốt hơn không?

WCAG không phải tiêu chuẩn SEO. Tuy nhiên nhiều thực hành tốt như semantic HTML, heading hợp lý, nội dung có cấu trúc và link rõ nghĩa cũng tạo ra nền tảng website dễ hiểu và dễ sử dụng hơn.

WCAG 2.2 có hỗ trợ GEO không?

WCAG và GEO phục vụ những mục tiêu khác nhau. Tuy nhiên nội dung có cấu trúc semantic rõ, heading chính xác, liên kết mô tả cụ thể và thông tin dễ hiểu đều thuận lợi cho việc máy móc phân tích và diễn giải nội dung.

Có thể bổ sung accessibility sau khi website đã hoàn thiện không?

Có thể, nhưng chi phí thường cao hơn nếu vấn đề nằm trong design system hoặc kiến trúc component. Kinh nghiệm thiết kế website WCAG 2.2 hiệu quả là đưa accessibility vào ngay từ giai đoạn wireframe, UI design và phát triển component.

Có cần kiểm tra accessibility trên mọi trang không?

Việc xác định mẫu kiểm thử phụ thuộc quy mô website và phạm vi đánh giá. Với website lớn, cần đặc biệt kiểm tra tất cả template, component dùng chung và user flow quan trọng, đồng thời lấy mẫu nội dung đại diện phù hợp thay vì chỉ kiểm tra trang chủ.

Thiết kế website WCAG 2.2 không nên được xem là một lớp kỹ thuật bổ sung sau khi website đã hoàn thiện. Accessibility cần trở thành một phần của quá trình thiết kế UI/UX, phát triển frontend, biên tập nội dung, kiểm thử và bảo trì website.

Đối với doanh nghiệp, những khu vực nên được ưu tiên kiểm tra đầu tiên là navigation, keyboard interaction, focus, contrast, form, button, modal, media và các user flow chuyển đổi quan trọng. Đây là những nơi rào cản accessibility có thể trực tiếp khiến người dùng không hoàn thành được mục tiêu.

Về thiết kế, hãy xây dựng accessibility từ design system. Một button được chuẩn hóa tốt về kích thước, contrast, hover và focus có thể giải quyết vấn đề đồng thời trên hàng trăm vị trí thay vì sửa từng trang riêng lẻ.

Về lập trình, hãy ưu tiên semantic HTML, keyboard interaction đúng hành vi và chỉ sử dụng ARIA khi thực sự cần. Với component tùy chỉnh như modal, dropdown, tabs hoặc autocomplete, accessibility phải được đưa vào đặc tả ngay từ đầu.

Về nội dung, đội ngũ quản trị website cần được hướng dẫn cách sử dụng heading, alt text, link và media đúng cách. Một website đạt accessibility tại thời điểm bàn giao vẫn có thể xuống cấp nhanh chóng nếu nội dung mới được đăng không tuân theo cùng nguyên tắc.

Bước tiếp theo phù hợp là xây dựng một accessibility audit cho các template và hành trình quan trọng, sau đó phân loại vấn đề theo mức ảnh hưởng. Những lỗi nằm trong component dùng chung nên được ưu tiên xử lý vì một thay đổi có thể cải thiện đồng thời nhiều trang.

Sau khi xử lý các vấn đề chính, doanh nghiệp cần kết hợp automated testing với kiểm thử thủ công bằng keyboard và các phương pháp kiểm tra phù hợp khác. Accessibility không thể được xác nhận đáng tin cậy chỉ bằng một điểm số tự động.

Khi WCAG 2.2 được đưa vào thiết kế ngay từ đầu, doanh nghiệp không chỉ giảm rào cản sử dụng mà còn tạo ra một giải pháp website doanh nghiệp rõ ràng, nhất quán, dễ thao tác và bền vững hơn trong quá trình phát triển lâu dài.

Mục tiêu cuối cùng của cách thiết kế website WCAG 2.2 không phải để hoàn thành một danh sách checkbox, mà là xây dựng website mà nhiều người dùng hơn có thể thực sự đọc, hiểu, điều hướng, tương tác và hoàn thành mục tiêu một cách độc lập và thuận lợi.

Doanh nghiệp của bạn đã sẵn sàng sở hữu website chuyên nghiệp, chuẩn SEO và dễ mở rộng?

3T Software đồng hành cùng doanh nghiệp xây dựng website giới thiệu sản phẩm, dịch vụ và bán hàng trực tuyến với giao diện chỉn chu, tốc độ tốt, cấu trúc thân thiện SEO, AEO, GEO và HEO — giúp khách hàng dễ tìm thấy, dễ hiểu và dễ đưa ra quyết định liên hệ.

Thiết kế UI/UX chuyên nghiệp theo ngành nghề
Tối ưu nội dung và cấu trúc chuẩn SEO
Website dễ quản trị, dễ nâng cấp tính năng
Phù hợp doanh nghiệp nhỏ, vừa và startup

Xem dịch vụ thiết kế website Tư vấn định hướng website phù hợp với mô hình kinh doanh của bạn

WCAG 2.2 là bộ hướng dẫn về khả năng tiếp cận nội dung web do W3C phát triển nhằm giúp website và ứng dụng web dễ sử dụng hơn đối với người khuyết tật. Khi thiết kế website theo WCAG 2.2, doanh nghiệp cần chú ý đến cấu trúc nội dung, văn bản thay thế cho hình ảnh, độ tương phản, thao tác bàn phím, trạng thái focus, kích thước vùng tương tác, biểu mẫu, thông báo lỗi và quy trình xác thực.

WCAG 2.2 kế thừa WCAG 2.1 và bổ sung 9 tiêu chí mới, trong đó có các yêu cầu liên quan đến focus, thao tác kéo thả, kích thước vùng tương tác, trợ giúp nhất quán, nhập dữ liệu lặp lại và xác thực dễ tiếp cận.

WCAG 2.2 là viết tắt của Web Content Accessibility Guidelines 2.2, một tiêu chuẩn hướng dẫn khả năng tiếp cận nội dung web của W3C. Tiêu chuẩn này cung cấp các tiêu chí giúp nội dung và chức năng website dễ tiếp cận hơn đối với người sử dụng công nghệ hỗ trợ, bàn phím, trình đọc màn hình hoặc những người gặp hạn chế về thị giác, vận động và nhận thức.

Để thiết kế website theo WCAG 2.2, cần kiểm tra ít nhất các nhóm yếu tố: nội dung văn bản, alt text của hình ảnh, cấu trúc heading, độ tương phản, keyboard navigation, focus, vùng tương tác, form, thông báo lỗi, audio/video, responsive, zoom và xác thực. Website doanh nghiệp thường nên xem WCAG 2.2 Level AA là một mục tiêu accessibility thực tế để đánh giá trong quá trình thiết kế và phát triển.

WCAG 2.2 là phiên bản của Web Content Accessibility Guidelines do W3C phát triển nhằm hướng dẫn xây dựng nội dung web dễ tiếp cận hơn cho người khuyết tật. WCAG 2.2 trở thành W3C Recommendation ngày 5/10/2023.

WCAG 2.2 kế thừa WCAG 2.1 và bổ sung 9 success criteria mới liên quan đến focus, dragging, target size, consistent help, redundant entry và accessible authentication. W3C cũng cho biết tiêu chí 4.1.1 Parsing đã được loại khỏi WCAG 2.2.

WCAG sử dụng ba mức độ tuân thủ chính: A, AA và AAA. Level A bao gồm các yêu cầu cơ bản; AA bổ sung các yêu cầu accessibility quan trọng hơn; AAA là mức cao nhất với các tiêu chí bổ sung nghiêm ngặt hơn.

Trong thực tế triển khai, Level AA thường là mục tiêu hợp lý để tổ chức checklist thiết kế và kiểm thử website. Tuy nhiên, yêu cầu pháp lý hoặc hợp đồng cụ thể có thể khác nhau theo thị trường và loại hình tổ chức.

WCAG 2.2 mở rộng WCAG 2.1 và được W3C khuyến nghị làm mục tiêu mới khi triển khai accessibility. Website conform WCAG 2.2 cũng đáp ứng WCAG 2.1 theo cấu trúc mở rộng của tiêu chuẩn, với lưu ý liên quan đến tiêu chí Parsing đã bị loại bỏ.

Web accessibility là việc thiết kế và phát triển website để người dùng với nhiều khả năng khác nhau có thể nhận biết nội dung, điều hướng và sử dụng chức năng của website.

Không. Các cải tiến accessibility còn có thể hỗ trợ người lớn tuổi, người bị chấn thương tạm thời, người sử dụng điện thoại trong điều kiện khó thao tác và nhiều tình huống sử dụng khác.

Hình ảnh truyền tải thông tin cần có text alternative phù hợp. Hình ảnh chỉ mang tính trang trí có thể sử dụng alt rỗng trong trường hợp phù hợp để công nghệ hỗ trợ bỏ qua.

Các chức năng thuộc phạm vi yêu cầu accessibility cần có khả năng thao tác bằng keyboard khi phù hợp. Điều này đặc biệt quan trọng với menu, form, modal, dropdown và các thành phần tương tác.

Focus cho biết thành phần tương tác nào đang được điều khiển bằng bàn phím. WCAG 2.2 bổ sung các tiêu chí mới yêu cầu focus không bị che khuất và, ở mức AAA, có hình thức hiển thị đủ rõ.

Success Criterion 2.5.8 yêu cầu target cho pointer input đạt tối thiểu 24 × 24 CSS pixels hoặc đáp ứng một trong các ngoại lệ được quy định. Mục tiêu là giảm nguy cơ người dùng nhấn nhầm các vùng tương tác nhỏ hoặc quá gần nhau.

Có. Success Criterion 3.3.8 Accessible Authentication (Minimum) ở Level AA nhằm giảm việc bắt người dùng ghi nhớ, giải câu đố hoặc nhập lại thông tin trong quá trình xác thực khi không có cơ chế hỗ trợ hoặc phương án thay thế phù hợp.

Từ góc độ accessibility, không nên tạo trở ngại không cần thiết. W3C đưa khả năng sử dụng password manager và copy/paste làm ví dụ về các cơ chế giúp giảm gánh nặng nhận thức trong quá trình xác thực.

Nên sử dụng công cụ tự động nhưng không nên chỉ phụ thuộc vào chúng. Accessibility còn cần kiểm thử thủ công như keyboard navigation, screen reader, focus order, nội dung thay thế và trải nghiệm của các thành phần tương tác.

Không nên xem ARIA là phương án thay thế mặc định cho HTML semantic. Nếu HTML native đã cung cấp đúng semantics và hành vi cần thiết thì thường nên ưu tiên HTML native trước.

Accessibility và SEO không phải cùng một hệ thống tiêu chí, nhưng nhiều thực hành tốt có vùng giao nhau như HTML semantic, heading rõ ràng, nội dung có cấu trúc, alt text và khả năng sử dụng tốt. Vì vậy, accessibility có thể hỗ trợ chất lượng tổng thể của website nhưng không nên được xem là một “SEO ranking factor” đơn giản.

Gián tiếp có lợi. Nội dung có cấu trúc semantic rõ ràng, heading logic, text thay thế và thông tin dễ hiểu giúp máy tìm kiếm và hệ thống AI xử lý nội dung tốt hơn. Tuy nhiên, WCAG là tiêu chuẩn accessibility, không phải tiêu chuẩn GEO.

Việc tuyên bố conform WCAG cần dựa trên việc đánh giá đầy đủ các yêu cầu áp dụng cho toàn bộ phạm vi website được tuyên bố. Một lần chạy công cụ tự động không đủ để kết luận website đạt WCAG.

Bài viết mới nhất

Thiết kế website theo WCAG 2.2: Checklist khả năng tiếp cận