Đăng ký để truy cập
Đọc thêm nội dung này khi bạn đăng ký ngay hôm nay.
Kiểm tra khả năng tiếp cận web giúp xác định liệu một website hoặc ứng dụng có thể được sử dụng thuận lợi bởi nhiều nhóm người dùng khác nhau hay không, bao gồm người khuyết tật, người cao tuổi và người dùng chỉ thao tác bằng bàn phím. Đây không chỉ là việc chạy một công cụ rồi đọc điểm số. Một lần kiểm tra tốt cần kết hợp mục tiêu rõ ràng, phạm vi hợp lý, công cụ tự động, kiểm tra thủ công và kế hoạch sửa lỗi cụ thể.
Bài hướng dẫn này trình bày một quy trình thực tế để đánh giá và cải thiện khả năng tiếp cận web, đồng thời giữ trọng tâm vào những vấn đề có ảnh hưởng trực tiếp đến người dùng.
Khả năng tiếp cận web là gì?
Khả năng tiếp cận web là cách thiết kế và vận hành nội dung web để nhiều người có thể nhận biết, hiểu, điều hướng và sử dụng được. Ví dụ, người không dùng chuột vẫn cần đi qua các nút bằng phím Tab, người dùng trình đọc màn hình cần nghe được nhãn của biểu mẫu, còn người có thị lực yếu cần văn bản có đủ tỷ lệ độ tương phản so với nền.
Khi kiểm tra, có thể tham chiếu các tiêu chuẩn quốc tế như WCAG, tên đầy đủ là Web Content Accessibility Guidelines. Tuy nhiên, tiêu chuẩn chỉ là một phần của công việc. Điều quan trọng là kiểm tra xem người dùng thực sự có hoàn thành được nhiệm vụ trên trang hay không.
1. Làm rõ mục đích và phạm vi kiểm tra
1.1 Xác định mục đích kiểm tra
Trước khi bắt đầu, hãy viết rõ kiểm tra này nhằm trả lời câu hỏi nào. Nếu không có mục tiêu, báo cáo thường chỉ là một danh sách lỗi rời rạc và khó ưu tiên.
- Xác nhận mức độ phù hợp với tiêu chuẩn: kiểm tra các điểm quan trọng theo WCAG hoặc tiêu chuẩn nội bộ của tổ chức.
- Cải thiện trải nghiệm người dùng: tìm những chỗ khiến người dùng khó đọc, khó thao tác, khó hiểu hoặc không thể hoàn thành nhiệm vụ.
- Giảm rủi ro vận hành và pháp lý: phát hiện sớm các vấn đề có thể ảnh hưởng đến việc cung cấp dịch vụ cho nhiều nhóm người dùng.
1.2 Quyết định phạm vi kiểm tra
Không phải lúc nào cũng cần kiểm tra toàn bộ website trong một lần. Với website lớn, nên ưu tiên các trang và chức năng có ảnh hưởng cao, chẳng hạn như trang chủ, trang liên hệ, biểu mẫu đăng ký, luồng mua hàng, trang đăng nhập hoặc các nội dung được truy cập thường xuyên.
| Điểm cần chốt | Ví dụ cần ghi rõ |
|---|---|
| Trang hoặc chức năng | Trang chủ, biểu mẫu liên hệ, trang thanh toán, trang tìm kiếm |
| Thiết bị | Máy tính, điện thoại thông minh, máy tính bảng |
| Trình duyệt | Các trình duyệt chính mà người dùng thực tế đang sử dụng |
| Nhóm người dùng cần lưu ý | Người dùng bàn phím, người dùng trình đọc màn hình, người cao tuổi |
Phạm vi càng rõ, việc báo cáo càng dễ hành động. Nhóm phát triển cũng biết lỗi nào cần sửa trước và lỗi nào có thể đưa vào kế hoạch cải thiện tiếp theo.
2. Chọn phương pháp kiểm tra
2.1 Dùng công cụ kiểm tra tự động
Công cụ tự động giúp quét nhanh các lỗi phổ biến. Chúng đặc biệt hữu ích ở giai đoạn đầu vì có thể phát hiện các vấn đề như thiếu nhãn biểu mẫu, cấu trúc tiêu đề chưa hợp lý hoặc độ tương phản văn bản không đạt yêu cầu.
- axe: thường được dùng như tiện ích hoặc công cụ hỗ trợ kiểm tra trong quá trình phát triển.
- WAVE: hiển thị lỗi và cảnh báo trực quan trên trang, giúp nhóm biên tập và thiết kế dễ nhìn thấy vị trí cần sửa.
- Lighthouse: hỗ trợ đánh giá nhiều khía cạnh của trang, trong đó có khả năng tiếp cận, hiệu suất và SEO.
Tuy vậy, công cụ tự động không thể thay thế kiểm tra thủ công. Một công cụ có thể phát hiện nút thiếu tên truy cập, nhưng khó đánh giá đầy đủ liệu dòng chữ trên nút có dễ hiểu trong bối cảnh thực tế hay không.
2.2 Kiểm tra thủ công
Kiểm tra thủ công nghĩa là người kiểm tra tự thao tác trên trang giống như người dùng. Đây là bước quan trọng để phát hiện các vấn đề công cụ tự động thường bỏ sót.
- Điều khiển bằng bàn phím: thử đi qua trang bằng Tab, Shift + Tab, Enter, phím mũi tên và Esc. Cần kiểm tra xem tiêu điểm có hiển thị rõ, đi theo thứ tự hợp lý và không bị kẹt trong hộp thoại hay không.
- Trình đọc màn hình: dùng các công cụ như NVDA, JAWS hoặc VoiceOver để nghe tiêu đề, liên kết, nút bấm và nhãn biểu mẫu. Văn bản liên kết nên mô tả đích đến, không nên chỉ là các cụm chung chung.
- Độ tương phản: kiểm tra màu chữ và nền. Với văn bản thông thường, tỷ lệ 4,5:1 trở lên thường được dùng làm mốc kiểm tra theo WCAG.
2.3 Kiểm tra khả năng sử dụng
Nếu có thể, hãy mời người dùng mục tiêu tham gia kiểm tra. Quan sát cách họ tìm thông tin, điền biểu mẫu, đọc nội dung hoặc hoàn thành một thao tác cụ thể. Sau đó, phỏng vấn ngắn để hiểu đoạn nào gây bối rối và vì sao.
Cách kiểm tra này giúp phát hiện các vấn đề thực tế hơn. Ví dụ, một biểu mẫu có thể vượt qua kiểm tra tự động nhưng vẫn khiến người dùng không biết lỗi nằm ở trường nào hoặc cần sửa như thế nào.
3. Đánh giá và báo cáo kết quả kiểm tra
3.1 Phân loại và ưu tiên vấn đề
Sau khi kiểm tra, không nên đưa mọi lỗi vào cùng một mức. Hãy phân loại theo mức ảnh hưởng đến người dùng và theo mức độ cần xử lý trước.
| Mức độ | Cách hiểu | Ví dụ |
|---|---|---|
| Nghiêm trọng | Người dùng không thể hoàn thành nhiệm vụ chính | Không gửi được biểu mẫu, thông tin quan trọng không được trình đọc màn hình đọc |
| Trung bình | Người dùng vẫn có cách thay thế nhưng thao tác khó hơn | Một số liên kết không thể truy cập thuận tiện bằng bàn phím |
| Nhỏ | Không chặn nhiệm vụ chính nhưng làm trải nghiệm kém hơn | Độ tương phản hơi thấp ở phần nội dung phụ |
3.2 Viết đề xuất cải thiện có thể hành động
Một báo cáo hữu ích không chỉ nói có lỗi. Nó cần cho biết lỗi nằm ở đâu, ảnh hưởng đến ai, vì sao cần sửa và nhóm phát triển nên sửa theo hướng nào. Khi có thể, hãy kèm ảnh chụp vị trí, đường dẫn trang, bước tái hiện và gợi ý sửa bằng ngôn ngữ cụ thể.
3.3 Tạo báo cáo kiểm tra
Báo cáo nên đủ ngắn để người phụ trách đọc được, nhưng đủ chi tiết để nhà phát triển có thể bắt tay vào sửa. Cấu trúc cơ bản có thể gồm:
- Tổng quan kiểm tra: mục đích, phạm vi, thiết bị, trình duyệt, công cụ và phương pháp đã dùng.
- Danh sách vấn đề: mô tả lỗi, mức ưu tiên, trang bị ảnh hưởng và bước tái hiện.
- Đề xuất cải thiện: hướng sửa cho từng lỗi hoặc từng nhóm lỗi.
- Các bước tiếp theo: người phụ trách, thời điểm sửa, thời điểm kiểm tra lại và kế hoạch kiểm tra định kỳ.
4. Thực hiện cải thiện và kiểm tra lại
Kiểm tra chỉ có giá trị khi kết quả được chuyển thành cải thiện thực tế. Sau khi báo cáo hoàn tất, hãy đưa các lỗi quan trọng vào kế hoạch sửa, xác nhận lại sau khi sửa và tiếp tục theo dõi khi nội dung hoặc chức năng mới được thêm vào.
Chúng tôi đã phát hành UUU Web Accessibility Widget Tool, công cụ giúp dễ dàng triển khai khả năng truy cập web. Nếu bạn quan tâm đến việc cải thiện khả năng truy cập, hãy xem thêm thông tin chi tiết.