Đăng ký để truy cập
Đọc thêm nội dung này khi bạn đăng ký ngay hôm nay.
Blog IT & Life Hacks|Ý tưởng để học hỏi và thực hành
Thủ thuật cuộc sống nhanh chóng cho mỗi ngày Hỗ trợ bởi AI

Đặt hàng một dự án web có yêu cầu về khả năng tiếp cận không chỉ là yêu cầu thêm một vài chức năng ở cuối dự án. Đây là cách mô tả ngay từ đầu rằng trang web phải dễ sử dụng với nhiều người dùng, bao gồm người khuyết tật, người cao tuổi và người dùng thiết bị hoặc môi trường thao tác khác nhau.
Trong bài viết này, đặt hàng có nghĩa là chuẩn bị yêu cầu cho nhà phát triển, nhà thiết kế hoặc đối tác vận hành web. Mục tiêu là giúp người đặt hàng nói rõ cần kiểm tra điều gì, giao nhận ra sao và ai chịu trách nhiệm, nhờ đó dự án không bị xử lý vá víu sau khi đã gần hoàn thành.
Khả năng tiếp cận web là mức độ một trang web có thể được đọc, hiểu và thao tác bởi nhiều nhóm người dùng. Với người dùng thực tế, điều đó có thể là hình ảnh có mô tả thay thế, biểu mẫu có nhãn rõ ràng, nút bấm dùng được bằng bàn phím, hoặc nội dung có thể được đọc bằng trình đọc màn hình.
Nói ngắn gọn, khả năng tiếp cận không chỉ là vấn đề kỹ thuật. Đó là yêu cầu về trải nghiệm: người dùng có thể tìm thông tin, hoàn tất thao tác và hiểu phản hồi của trang web mà không bị chặn bởi thiết kế hoặc cách triển khai.
Nếu yêu cầu đặt hàng mơ hồ, nhóm triển khai dễ hiểu khác nhau về mục tiêu. Khi đó, các lỗi như thiếu nhãn biểu mẫu, thứ tự tab lộn xộn hoặc hình ảnh không có mô tả thường chỉ được phát hiện ở giai đoạn kiểm tra cuối, làm tăng chi phí sửa chữa.
Trước tiên, hãy xác định dự án cần đạt điều gì. Ví dụ, trang web mới cần đáp ứng một cấp độ nhất định của WCAG, hoặc một phần quan trọng như biểu mẫu liên hệ, trang đăng ký, trang thanh toán cần được ưu tiên kiểm tra kỹ.
Mục tiêu nên gắn với hành động của người dùng. Thay vì chỉ viết cải thiện khả năng tiếp cận, hãy nêu rõ người dùng cần làm được gì: đọc nội dung chính, di chuyển qua menu, nhập biểu mẫu, gửi yêu cầu hoặc hoàn tất quy trình đăng ký.
Nếu đây là dự án cải tiến trang web đã có, hãy bắt đầu bằng một lần kiểm tra khả năng tiếp cận web. Việc đánh giá giúp phân biệt lỗi cần sửa ngay, điểm nên cải thiện theo lộ trình và phần cần xác nhận thêm với người phụ trách nội dung hoặc thiết kế.
Ở giai đoạn này, không cần biến mọi phát hiện thành yêu cầu kỹ thuật dài dòng. Điều quan trọng là nêu được phạm vi: trang nào được kiểm tra, chức năng nào quan trọng nhất và lỗi nào ảnh hưởng trực tiếp đến người dùng.
Khả năng tiếp cận liên quan đến nhiều nhóm: quản lý trang web, thiết kế, phát triển, tiếp thị, nội dung và vận hành. Nếu chỉ một nhóm hiểu mục tiêu, các quyết định sau đó rất dễ lệch hướng.
Trước khi đặt hàng, hãy thống nhất mục tiêu, phạm vi và cách đánh giá. Sự đồng thuận này giúp tránh tình trạng đến cuối dự án mới tranh luận về việc một lỗi có nằm trong phạm vi sửa chữa hay không.
Một bản yêu cầu tốt không cần dài, nhưng phải đủ cụ thể để nhà thầu hoặc nhóm triển khai biết cần làm gì. Bảng sau có thể dùng như khung kiểm tra nhanh.
| Hạng mục | Cần ghi rõ | Ví dụ yêu cầu |
|---|---|---|
| Mục tiêu | Tiêu chuẩn, cấp độ hoặc phạm vi ưu tiên | Nêu phiên bản WCAG, cấp độ mục tiêu và các trang cần ưu tiên |
| Hình ảnh | Cách xử lý mô tả hình ảnh | Hình ảnh truyền tải thông tin cần có văn bản thay thế phù hợp |
| Biểu mẫu | Nhãn, hướng dẫn nhập và thông báo lỗi | Mỗi trường nhập liệu có nhãn rõ ràng và lỗi được mô tả bằng ngôn ngữ dễ hiểu |
| Thao tác | Cách người dùng thao tác không cần chuột | Các yếu tố tương tác quan trọng hỗ trợ điều khiển bằng bàn phím |
| Kiểm tra | Phương pháp kiểm tra và tiêu chí nghiệm thu | Kết hợp kiểm tra tự động, kiểm tra thủ công và xác nhận trên các luồng chính |
Khi đặt hàng, hãy chuyển mong muốn chung thành các mục có thể kiểm tra. Ví dụ, thay vì viết tối ưu hình ảnh, hãy ghi rằng hình ảnh có ý nghĩa nội dung cần văn bản thay thế; hình ảnh trang trí có thể được xử lý để không gây nhiễu cho công nghệ hỗ trợ.
Tương tự, với biểu mẫu, yêu cầu nên nêu rõ nhãn trường, mô tả lỗi, trạng thái bắt buộc và cách người dùng nhận biết đã gửi thành công hay chưa. Với menu, nút và liên kết, cần làm rõ thao tác bằng bàn phím và trạng thái tiêu điểm.
Nếu dự án dùng WCAG làm cơ sở, hãy ghi rõ phiên bản, cấp độ và phạm vi áp dụng. Cấp độ A, AA hoặc AAA không nên được viết như một khẩu hiệu chung; cần chỉ rõ áp dụng cho trang nào, chức năng nào và cách kiểm tra ra sao.
Cũng nên tách yêu cầu bắt buộc khỏi yêu cầu nên làm. Việc này giúp nhóm dự án ưu tiên đúng: những lỗi chặn người dùng hoàn tất nhiệm vụ chính cần được xử lý trước các cải tiến ít ảnh hưởng hơn.
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.