Xây dựng chương trình kiểm thử khả năng tiếp cận theo vai trò

Một chương trình hiệu quả biến mỗi thay đổi thành chuỗi trách nhiệm và bằng chứng có thể truy vết, thay vì chờ chuyên gia rà soát cuối dự án. Trước khi làm, nhóm phải xác định phạm vi, phương pháp, người thực hiện, người chấp nhận và chủ kiểm thử lại. Bản quét tự động vì thế không thể thay cho kiểm tra bàn phím, tái bố cục hay ý nghĩa của nhãn.

Điều gì biến kiểm thử khả năng tiếp cận thành một chương trình thay vì cuộc rà soát cuối kỳ?

Một chương trình phối hợp bốn loại bằng chứng ở đúng giai đoạn: tự động phát hiện điều kiện máy nhận biết; kiểm tra thủ công xem hành vi và ý nghĩa; công nghệ hỗ trợ kiểm tra tính tương thích trong nhiệm vụ; đánh giá với người khuyết tật tìm vấn đề về tính khả dụng. Các loại bằng chứng bổ sung, không thay thế nhau.

W3C khuyến nghị đánh giá sớm và xuyên suốt quá trình phát triển, đồng thời nêu rõ không công cụ nào tự xác định website đáp ứng tiêu chuẩn. Người thiết kế, biên tập và lập trình vẫn chịu trách nhiệm cho công việc của mình; QA kiểm tra độc lập. Đầu mối khả năng tiếp cận quản lý chính sách, phương pháp, đào tạo và diễn giải khó.

Độ sâu kiểm thử nên thay đổi thế nào theo phần việc sắp phát hành?

Độ sâu tăng theo mức tương tác, khả năng tái sử dụng, tính mới, tầm quan trọng của hành trình và tác động đến người dùng. Trước tiên, hãy kiểm kê trang, mẫu, thành phần, trạng thái, nội dung, tài liệu, phương tiện và công nghệ bị ảnh hưởng. Bốn lớp sau là mô hình có thể điều chỉnh, không phải tiêu chuẩn rủi ro hay căn cứ tuyên bố phần chưa kiểm tra đã đáp ứng WCAG.

• Chỉ sửa nội dung: con người đánh giá nội dung và chạy kiểm tra tự động phù hợp; thêm kiểm tra cấu trúc, bàn phím, phóng to hoặc công nghệ hỗ trợ khi phần tương ứng thay đổi.
• Sửa hình ảnh hoặc bố cục: đánh giá thiết kế, phóng to và tái bố cục; kiểm tra tiêu điểm khi hành vi tương tác thay đổi.
• Sửa thành phần hoặc tương tác: đặt tiêu chí chấp nhận trước khi xây dựng; yêu cầu lập trình viên kiểm tra cục bộ, QA kiểm tra độc lập và bổ sung hồi quy khi tái sử dụng.
• Mẫu mới, hành trình trọng yếu hoặc phát hành lớn: dùng mọi lớp phù hợp, nhiệm vụ đại diện, công nghệ hỗ trợ, đánh giá mức đáp ứng theo mẫu và đánh giá với người khuyết tật đủ sớm để thay đổi thiết kế.

Theo WCAG-EM, đánh giá mức đáp ứng cần xác định phạm vi, mục tiêu, chức năng chính, mẫu đại diện khi cần và báo cáo kết quả. Không được suy rộng tùy tiện sang đường dẫn ngoài phạm vi. Phân loại ít rủi ro chỉ điều chỉnh độ sâu, không cho phép bỏ qua rào cản đã biết hay bằng chứng.

Ma trận sở hữu kiểm thử cần có gì, và ai chịu trách nhiệm ở mỗi điểm bàn giao?

Mỗi hàng của ma trận phải nêu điều kiện và phạm vi, giai đoạn sớm nhất, người thực hiện, người chấp nhận, năng lực, môi trường, bằng chứng, quy tắc chặn và chủ kiểm thử lại. Trong nhóm nhỏ, một người có thể giữ nhiều vai trò nhưng phải nêu rõ vai trò đang đảm nhiệm; công việc rủi ro cao vẫn cần đánh giá độc lập hoặc có chuyên môn.

Khả năng tiếp cận không còn là việc kiểm tra cuối cùng của người khác khi mỗi thay đổi đều có bằng chứng, chủ sở hữu và đường kiểm thử lại.

WebChorus Editorial Team

Mỗi kiểm tra khả năng tiếp cận cốt lõi thực sự phải xem xét điều gì?

Kiểm tra cốt lõi phải quan sát nhiệm vụ trong ngữ cảnh, không chỉ xác nhận công cụ đã chạy hay phần tử tồn tại. Tự động hóa phát hiện điều kiện máy nhận biết, nhưng kết quả sạch không chứng minh mức đáp ứng. Con người vẫn phải đánh giá liệu tiêu đề, nhãn, liên kết và thông báo lỗi có truyền đạt đúng ý nghĩa.

• Với bàn phím, hoàn thành nhiệm vụ đại diện; vận hành điều khiển; kiểm tra thứ tự, khả năng nhìn thấy và thoát tiêu điểm; quan sát trạng thái và phục hồi sau lỗi.
• Với nội dung, đánh giá tiêu đề, đề mục, nhãn, liên kết, hướng dẫn, lỗi, chú thích, bản chép lời và văn bản thay thế trong đúng ngữ cảnh.
• Với thay đổi kích thước văn bản, kiểm tra đến 200% theo tiêu chí áp dụng và tìm nội dung hoặc chức năng bị mất, che khuất hay không thể thao tác.
• Với tái bố cục, phân biệt điều kiện rộng 320 CSS pixel không cuộn ngang và cao 256 CSS pixel không cuộn dọc, đồng thời giữ ngoại lệ bố cục hai chiều.

Phóng to và tái bố cục không nhằm giữ giao diện giống từng điểm ảnh. QA cần tìm thông tin hoặc chức năng bị mất, nội dung cản trở thao tác, tiêu điểm bị giấu, thay đổi ngoài vùng nhìn và kiểu cuộn không được phép. Hồ sơ ghi trang, nhiệm vụ, điều kiện kiểm tra, hành vi mong đợi, kết quả và lỗi.

Khi nào cần thêm kiểm thử công nghệ hỗ trợ, đánh giá với người khuyết tật và đánh giá mức đáp ứng?

Thêm phương pháp chuyên sâu cho thay đổi nhiều tương tác, được tái sử dụng rộng, ảnh hưởng hành trình trọng yếu hoặc cần bảo đảm cao. Người được đào tạo dùng công nghệ hỗ trợ đã chọn để hoàn thành nhiệm vụ và trạng thái đại diện. Một trình đọc màn hình chỉ kiểm tra tính tương thích trong một môi trường, không đại diện mọi người dùng hay chứng minh mức đáp ứng WCAG.

• Chọn tổ hợp trình duyệt, hệ điều hành và công nghệ hỗ trợ hiện hành từ dữ liệu người dùng, công nghệ sản phẩm, cam kết hỗ trợ và rủi ro đã biết; không sao chép một ma trận phổ quát.
• Ghi nhiệm vụ bị ảnh hưởng, tác động đến người dùng, hành vi mong đợi, trình duyệt, hệ điều hành, công nghệ, phiên bản, bằng chứng, chủ khắc phục và kết quả kiểm thử lại.
• Với đánh giá mức đáp ứng rộng, xác định phạm vi và mục tiêu, khảo sát trang cùng chức năng chính, chọn độ bao phủ đại diện khi không thể đánh giá toàn bộ, rồi báo cáo phát hiện và giới hạn.

Đánh giá với người khuyết tật nên diễn ra khi phát hiện còn có thể ảnh hưởng quyết định. Xử lý trước rào cản rõ ràng, đáng kể để buổi làm việc khám phá vấn đề sâu hơn, nhưng không cần đợi sản phẩm hoàn thiện. Không được khái quát trải nghiệm của một người cho cả cộng đồng; phương pháp này bổ sung, không thay thế đánh giá tiêu chuẩn.

Bằng chứng phải kiểm soát phát hành và cải thiện chương trình theo thời gian như thế nào?

Quyết định phát hành dựa trên bằng chứng bắt buộc cho lớp thay đổi, không dựa trên điểm số toàn cục. Người có thẩm quyền chỉ chấp nhận khi kiểm tra đã hoàn tất, lỗi chặn đã được sửa và kiểm thử lại, còn hồ sơ ghi phạm vi, phương pháp, môi trường, kết quả, chủ sở hữu, cách xử lý và trạng thái. Người tạo ra sản phẩm vẫn chịu trách nhiệm khắc phục.

Nếu chính sách cho phép ngoại lệ, hồ sơ phải ghi người phê duyệt, lý do, người dùng bị ảnh hưởng, biện pháp giảm thiểu, ngày hết hạn và hành động tiếp theo. Ngoại lệ không thay đổi kết quả hay xác lập mức đáp ứng. Sau phát hành, đưa rào cản và lỗi lặp lại về ma trận để cải thiện hồi quy, mẫu, hướng dẫn, đào tạo và phân lớp thay đổi.

1. Chọn một hành trình trọng yếu và lập đầy đủ dấu vết bằng chứng từ yêu cầu đến kiểm thử lại.
2. Nêu tên người sở hữu từng vai trò và đào tạo họ về phương pháp mình phải thực hiện hoặc chấp nhận.
3. Chuẩn hóa mẫu ghi phạm vi, môi trường, tác động, bằng chứng, chủ sửa và trạng thái kiểm thử lại.
4. Đưa tự động hóa phù hợp vào quy trình tạo nội dung, phát triển và tích hợp mà không dùng nó thay đánh giá con người.
5. Hiệu chỉnh quy tắc chặn bằng các tình huống thật và xem lại mẫu lỗi tái diễn sau mỗi đợt phát hành.
6. Mở rộng sang hành trình khác sau khi nhóm đầu tiên có thể vận hành ma trận mà không phụ thuộc vào một chuyên gia duy nhất.

Khi thiếu năng lực đánh giá tương tác phức tạp, công nghệ hỗ trợ, độ bao phủ hoặc phát hiện tranh luận, hãy mời người đánh giá được đào tạo. Nghiên cứu với người khuyết tật cần nhà nghiên cứu có kinh nghiệm. Diễn giải pháp lý, tuyên bố tuân thủ hoặc chứng nhận phải do chuyên gia có thẩm quyền xử lý; ma trận này chỉ là mô hình vận hành.