Accessibility Testing với WCAG 2.2 cho Tester Mới

Accessibility testing với WCAG 2.2 giúp tester mới kiểm tra những rào cản cơ bản khiến người dùng không thể đọc, điều hướng hoặc hoàn thành một tác vụ trên website, thay vì chỉ xác nhận giao diện có hiển thị đẹp.

Accessibility testing là gì và tester mới cần kiểm tra điều gì?

Accessibility testing kiểm tra xem website hoặc ứng dụng có thể được sử dụng bởi người có các nhu cầu khác nhau hay không.

Tester không chỉ nhìn màu sắc hoặc kích thước chữ, mà còn kiểm tra khả năng đọc nội dung, điều hướng bằng bàn phím, nhận biết trạng thái focus, điền form và hiểu thông báo lỗi.

WCAG 2. 2 là bộ hướng dẫn của W3C với các success criteria được viết thành phát biểu có thể kiểm thử và không phụ thuộc một công nghệ cụ thể.

Phiên bản hiện hành được W3C công bố dưới dạng Recommendation vào ngày 12 tháng 12 năm 2024 và bổ sung 9 success criteria so với WCAG 2. 1.

Tuy nhiên, tester mới không cần học thuộc toàn bộ tiêu chuẩn trước khi chạy được những kiểm tra có giá trị. Điểm bắt đầu phù hợp là xem một trang như một user đang cố hoàn thành tác vụ.

Với form đăng nhập, tester có thể bắt đầu bằng checklist sau:

Làm checklist accessibility testing đầu tiên như thế nào?

W3C Easy Checks gọi đây là first review, tức review nhanh để phát hiện các vấn đề cơ bản chứ không phải đánh giá tuân thủ toàn diện.

Với một tester mới, checklist nên ngắn, có thể lặp lại và gắn với từng page hoặc user flow.

Hãy chọn một flow nhỏ như đăng nhập hoặc tìm kiếm. Chạy flow một lần bằng chuột để hiểu expected result, sau đó tải lại page và chạy lại chỉ bằng bàn phím.

Cách này giúp tester phân biệt lỗi nghiệp vụ với lỗi accessibility thay vì ghi mọi khác biệt thành một bug chung chung.

Kiểm tra bàn phím và focus ra sao để không bỏ sót lỗi?

Bàn phím là phép kiểm tra có giá trị cao vì tester có thể thực hiện ngay, không cần cài framework hoặc hiểu sâu về screen reader.

Mở page ở trạng thái mới, dùng Tab để đi qua các phần tử tương tác, Shift + Tab để đi ngược, Enter hoặc Space để kích hoạt và phím mũi tên khi component yêu cầu.

Một flow cơ bản gồm bảy bước: đặt con trỏ tại đầu page, nhấn Tab, ghi nhận phần tử focus đầu tiên, đi đến input, nhập data hợp lệ, đến nút Submit rồi gửi form.

Expected result không chỉ là form submit thành công.

Thứ tự focus phải hợp lý, focus phải nhìn thấy được, không có vùng tương tác bị bỏ qua và không xuất hiện keyboard trap khiến tester không thể rời khỏi component.

Focus bị che là một điểm mới đáng chú ý trong WCAG 2. 2.

Nếu khi Tab đến nút Submit mà sticky header hoặc cookie banner che mất phần tử, user vẫn có thể đang ở đúng DOM element nhưng không nhìn thấy nơi mình đang thao tác.

Tester nên ghi rõ phần tử bị che, chiều cao vùng che, trạng thái scroll và cách tái hiện.

Kiểm tra form, label và thông báo lỗi thế nào?

Form là nơi người mới dễ ghi bug mơ hồ nhất; một lỗi như “form không accessible” không giúp developer sửa nhanh.

Tester cần chỉ ra input nào thiếu label, message nào không gắn với field, lỗi có được đọc lại khi focus quay về hay không và người dùng có biết cách sửa hay không.

Hãy dùng một form có email, password và nút Login để thực hành: trước tiên để trống toàn bộ field rồi submit, sau đó nhập email sai định dạng, nhập password quá ngắn và thử xóa một field sau khi

đã có lỗi. Với mỗi case, expected result nên mô tả cả vị trí hiển thị lỗi, nội dung dễ hiểu, trạng thái field và việc user có thể tiếp tục flow.

Nếu form có lỗi, tester đừng chỉ kiểm tra màu đỏ. Người dùng có thể không phân biệt màu, không nhìn rõ hoặc đang dùng công nghệ hỗ trợ.

Hãy quan sát cả text message, vị trí, focus và mối quan hệ giữa field với lỗi. Đây là kỹ năng nền tảng liên quan trực tiếp đến cách viết test case rõ ràng cho tester mới.

Công cụ tự động giúp gì và không thể thay tester ở đâu?

Accessibility checker giúp phát hiện nhanh một số vấn đề như thiếu thuộc tính, màu tương phản thấp hoặc cấu trúc HTML đáng ngờ.

Công cụ này hữu ích khi tester muốn quét nhiều page hoặc bắt lỗi lặp lại sớm, nhưng kết quả scan không chứng minh rằng user thật sự hoàn thành được task.

Có những câu hỏi cần người kiểm tra: alt text có thể tồn tại nhưng mô tả sai mục đích của ảnh, heading có thể đúng cấp nhưng nội dung vẫn khó hiểu, và một component có thể không bị

báo lỗi tự động nhưng vẫn không dùng được bằng bàn phím. Vì vậy, hãy xem automated check là tín hiệu để điều tra, không phải giấy chứng nhận PASS.

Quy trình thực tế cho người mới có ba lớp. Lớp đầu là scan nhanh để tìm lỗi lặp lại. Lớp hai là keyboard và focus cho flow quan trọng.

Lớp ba là kiểm tra bằng user flow, form và nội dung hiển thị, rồi chuyển case khó sang người có kinh nghiệm hoặc accessibility specialist.

Ghi bug accessibility testing thế nào để developer sửa được?

Một bug report tốt cần chỉ ra user bị cản trở ở bước nào, không chỉ gọi tên tiêu chuẩn.

Title nên mô tả hành vi và thành phần, ví dụ “Không thể gửi form Login bằng bàn phím vì focus bị kẹt ở password visibility”. Trong description, ghi environment, precondition, steps, actual result, expected result và evidence.

Nếu biết success criterion liên quan, tester có thể ghi ở phần reference của bug, nhưng không nên dùng tên criterion thay cho mô tả lỗi.

Một report rõ ràng giúp team ưu tiên theo ảnh hưởng: không thể hoàn thành login thường nghiêm trọng hơn một heading chưa tối ưu trên trang phụ.

Tổng kết

Hãy bắt đầu accessibility testing bằng một flow nhỏ và kiểm tra keyboard, focus, form, heading, alt text và contrast. WCAG 2.

2 là nền để đặt câu hỏi kiểm thử, còn Easy Checks chỉ là first review, không thay thế đánh giá đầy đủ.

Automated checker giúp tìm tín hiệu nhanh, nhưng tester phải xác nhận bằng thao tác và evidence thực tế.

Nếu muốn củng cố nền tảng test case, API và tư duy kiểm thử trước khi mở rộng sang accessibility, hãy xem khóa học Testing cơ bản và luyện thi ISTQB.

Flow nào trong dự án hiện tại sẽ thay đổi kết luận nếu tester chỉ dùng chuột mà không thử bàn phím?