Vì sao kiểm thử khả năng tiếp cận tự động bỏ sót một nửa vấn đề của bạn

Sự thật khó chịu về kiểm thử khả năng tiếp cận tự động

Kiểm thử khả năng tiếp cận tự động là một trong những thói quen tốt nhất mà một nhóm web có thể xây dựng. Nó bắt được nhãn biểu mẫu bị thiếu, văn bản có độ tương phản thấp, ARIA không hợp lệ, ID trùng lặp, nút rỗng và những lỗi khác lẽ ra không bao giờ được đưa lên production.

Nó cũng thường xuyên bị hiểu sai.

Một báo cáo kiểm thử khả năng tiếp cận tự động đạt yêu cầu không có nghĩa là một trang có khả năng tiếp cận. Nó có nghĩa là công cụ không tìm thấy tập hợp con các vấn đề mà nó biết cách phát hiện. Tập hợp con đó có giá trị, nhưng có giới hạn. Nhiều lỗi khả năng tiếp cận phụ thuộc vào ý nghĩa, thứ tự, ý định, ngữ cảnh và tương tác của con người. Phần mềm có thể kiểm tra markup. Nó không thể hiểu một cách đáng tin cậy liệu trải nghiệm có hoạt động với một người dùng trình đọc màn hình, bàn phím, phóng đại, điều khiển bằng giọng nói, phụ đề hoặc hỗ trợ nhận thức hay không.

Đó là lý do vì sao nhận định rằng kiểm thử tự động bỏ sót khoảng một nửa vấn đề của bạn không phải là bi quan. Nó còn là hào phóng. Một số nhóm vấn đề có thể tự động hóa rất cao. Những nhóm khác hầu như không thể tự động hóa.

Câu trả lời thực tế không phải là từ bỏ công cụ tự động. Mà là đặt chúng đúng chỗ: sớm, thường xuyên và như một phần của quy trình kiểm thử rộng hơn.

Kiểm thử tự động làm tốt điều gì

Các công cụ tự động rất giỏi trong việc tìm các lỗi có tính xác định. Nếu một quy tắc có thể được diễn đạt như một điều kiện máy đọc được, một scanner thường có thể kiểm tra nhanh chóng và nhất quán.

Các ví dụ phổ biến gồm:

• Hình ảnh thiếu thuộc tính alt
• Trường nhập biểu mẫu không có nhãn liên kết
• Nút không có tên tiếp cận được
• Văn bản không đạt ngưỡng tương phản
• Thuộc tính hoặc vai trò ARIA không hợp lệ
• Cấp tiêu đề bị nhảy theo cách đáng ngờ
• Landmark bị thiếu hoặc trùng lặp
• Liên kết có tên tiếp cận được rỗng
• Bảng thiếu cấu trúc cơ bản

Những kiểm tra này đáng được tự động hóa vì con người không giỏi việc rà soát lặp đi lặp lại. Không ai nên quét thủ công từng trang để tìm nhãn bị thiếu nếu một công cụ có thể bắt chúng trong vài mili giây.

Các kiểm tra tự động cũng giúp khả năng tiếp cận dễ được thảo luận hơn trong quy trình kỹ thuật. Một bài kiểm thử thất bại trong CI là cụ thể. Một cảnh báo trong pull request là đúng lúc. Một đường xu hướng qua các template cho nhóm thứ gì đó để cải thiện.

Vấn đề bắt đầu khi các nhóm xem những kiểm tra này là bằng chứng về khả năng tiếp cận thay vì bằng chứng về vệ sinh cơ bản.

Tự động hóa đứt gãy ở đâu

Khả năng tiếp cận không chỉ là một thuộc tính của mã. Nó là một thuộc tính của việc sử dụng.

Một công cụ có thể cho bạn biết liệu một hình ảnh có văn bản alt hay không. Nó thường không thể cho bạn biết liệu văn bản alt đó có hữu ích hay không. Một hình ảnh sản phẩm có thể cần mô tả chi tiết trên trang sản phẩm, không cần mô tả trong một hero mang tính trang trí, và cần một mô tả hoàn toàn khác trong bài viết trợ giúp. Câu trả lời đúng phụ thuộc vào ngữ cảnh. Đó là lý do các nhóm cần hướng dẫn biên tập như một cách tiếp cận thực dụng với văn bản alt của hình ảnh, chứ không chỉ một quy tắc linter.

Vấn đề tương tự xuất hiện ở khắp nơi.

Một scanner có thể xác nhận rằng mọi nút đều có tên tiếp cận được. Nó không phải lúc nào cũng cho biết được tên đó có hợp lý hay không. Một trang có năm nút tên là Submit có thể vượt qua một quy tắc cơ bản nhưng vẫn gây khổ sở cho người dùng trình đọc màn hình. Một modal có thể có đúng thuộc tính ARIA nhưng quản lý focus sai cách. Một dropdown tùy chỉnh có thể trông tuân thủ trong markup tĩnh và thất bại ngay khi ai đó cố dùng nó bằng bàn phím.

Tự động hóa gặp khó với những câu hỏi như:

• Thứ tự focus có khớp với thứ tự trực quan và logic không?
• Mọi tác vụ có thể hoàn thành chỉ bằng bàn phím không?
• Thông báo lỗi có cụ thể, đúng lúc và được liên kết với trường không?
• Trang vẫn hoạt động khi văn bản được đổi kích thước hoặc phóng to không?
• Thứ tự đọc có hợp lý đối với công nghệ hỗ trợ không?
• Hướng dẫn có dễ hiểu mà không dựa vào màu sắc hoặc vị trí không?
• Phụ đề, bản chép lời và nhãn có thực sự truyền đạt nội dung không?
• Thành phần có hành xử dự đoán được qua các trạng thái không?

Đây không phải là các trường hợp rìa. Chúng là cốt lõi của khả năng tiếp cận.

Sự an tâm giả tạo của điểm số cao

Điểm khả năng tiếp cận rất quyến rũ vì chúng nén một chủ đề lộn xộn thành một con số. Dashboard nói 98. Báo cáo hiển thị các dấu kiểm xanh. Bản phát hành có vẻ an toàn hơn.

Nhưng điểm số chỉ đo những gì công cụ đo.

Điều này tương tự kiểm thử hiệu năng. Một báo cáo Lighthouse có thể cho thấy những vấn đề quan trọng, nhưng nó không giống với việc nhìn một người dùng thật vật lộn qua quy trình checkout chậm trên một điện thoại tầm trung. Nếu nhóm của bạn đã dùng audit hiệu năng, cùng một tư duy cũng áp dụng ở đây: đọc báo cáo cẩn thận, rồi ưu tiên những phát hiện ảnh hưởng đến người dùng thật. Chúng tôi đã viết về sự khác biệt đó trong cách đọc báo cáo Lighthouse mà không hoảng loạn.

Báo cáo khả năng tiếp cận cần cùng sự tiết chế. Một lần quét tự động sạch là điểm khởi đầu. Nó không phải là chứng chỉ.

Rủi ro đặc biệt cao khi các nhóm chỉ chạy quét trên các trang tĩnh. Giao diện hiện đại có trạng thái: menu mở ra, drawer trượt vào, toast xuất hiện, thông báo xác thực cập nhật, tab chuyển panel, bộ lọc viết lại nội dung, và xác thực thay đổi mọi thứ. Nhiều lỗi khả năng tiếp cận nghiêm trọng nằm trong các tương tác đó.

Nếu scanner của bạn chỉ nhìn thấy DOM ban đầu, nó đang bỏ lỡ sản phẩm.

Những nhóm vấn đề thường bị bỏ sót nhất

1. Hành vi bàn phím và focus

Truy cập bằng bàn phím là một trong những ví dụ rõ nhất cho thấy vì sao tự động hóa là chưa đủ.

Một công cụ có thể phát hiện liệu một phần tử có thể nhận focus hay không. Nó có thể bắt các giá trị tabindex dương hoặc các bẫy focus hiển nhiên. Nhưng nó không thể đánh giá một cách đáng tin cậy liệu trình tự tab có mạch lạc hay không, liệu focus có chuyển đến đúng nơi sau một hành động hay không, hoặc liệu một thành phần bị đóng có trả focus về phần tử kích hoạt hay không.

Bạn cần một con người nhấn Tab, Shift+Tab, Enter, Space, Escape và các phím mũi tên qua quy trình thực tế.

Điều này đặc biệt quan trọng với các control tùy chỉnh. Các phần tử HTML gốc mang sẵn nhiều năm hành vi khả năng tiếp cận. Tự dựng lại button, select, checkbox, menu và dialog bằng div nghĩa là nhóm của bạn giờ sở hữu hành vi đó. Nếu bạn đang review các thành phần tương tác, hãy bắt đầu với một checklist ngắn cho nút web có khả năng tiếp cận và mở rộng cùng kỷ luật đó cho mọi control tùy chỉnh.

2. Tên và mô tả có ý nghĩa

Các công cụ tự động có thể phát hiện sự vắng mặt. Chúng kém hơn nhiều trong việc phát hiện chất lượng.

Một liên kết tên Read more về mặt kỹ thuật có thể có tên tiếp cận được. Một nút gắn nhãn OK có thể hợp lệ. Một gợi ý biểu mẫu có thể hiện diện. Nhưng chúng có ý nghĩa trong ngữ cảnh không? Thường là không.

Tên tiếp cận được nên cho người dùng biết điều gì sẽ xảy ra hoặc phần tử đại diện cho điều gì. Điều đó đòi hỏi phán đoán. Nó cũng đòi hỏi kiểm thử với giao diện, không chỉ với mã.

3. Xử lý lỗi

Biểu mẫu chứa đầy lỗi khả năng tiếp cận mà scanner chỉ bắt được một phần.

Một công cụ có thể gắn cờ một trường không có nhãn. Nó có thể không bắt được việc thông báo xác thực xuất hiện quá muộn, biến mất quá nhanh, không được thông báo cho trình đọc màn hình, hoặc nói Invalid input trong khi nên nói Password must be at least 12 characters.

Xử lý lỗi tốt là thiết kế tương tác. Nó cần kiểm thử thủ công và, lý tưởng là, kiểm thử người dùng.

4. Thích ứng thị giác

WCAG bao gồm các yêu cầu về đổi kích thước văn bản, reflow, tương phản, khoảng cách và không dựa vào một tín hiệu giác quan duy nhất. Một phần trong số này có thể được kiểm tra tự động, nhưng câu hỏi thực sự là liệu giao diện có còn dùng được trong các điều kiện đã thay đổi hay không.

Hãy thử zoom 200%. Thử đổi kích thước văn bản của trình duyệt. Thử chế độ tương phản cao hoặc forced colors. Thử chiều rộng viewport hẹp. Thử reduced motion. Nhiều site trông trau chuốt ở thiết lập mặc định sẽ nhanh chóng vỡ khi người dùng khẳng định tùy chọn của họ.

5. Độ rõ ràng của nội dung

Không công cụ khả năng tiếp cận tự động nào có thể đánh giá đầy đủ liệu nội dung có dễ hiểu hay không.

Nó có thể gắn cờ tiêu đề bị thiếu hoặc văn bản liên kết mơ hồ. Nó không thể biết liệu trang có giải thích rõ một quy trình hay không, liệu nhãn có khớp với kỳ vọng của người dùng hay không, hoặc liệu nội dung dày đặc có tạo ra tải nhận thức có thể tránh được hay không.

Khả năng tiếp cận không chỉ là tương thích với công nghệ hỗ trợ. Nó còn là giảm ma sát cho những người đang căng thẳng, dùng ngôn ngữ không quen thuộc, đối mặt với giới hạn chú ý, hoặc điều hướng các tác vụ phức tạp.

Một quy trình kiểm thử tốt hơn

Một quy trình khả năng tiếp cận cân bằng có nhiều lớp.

Chạy kiểm tra tự động liên tục

Dùng kiểm thử tự động trong phát triển, pull request, bản xem trước component và CI. Chúng nên nhàm chán, nhanh và không thể thương lượng. Nhãn mới bị thiếu và ARIA không hợp lệ không nên cần đến một đợt audit hằng quý mới phát hiện ra.

Hãy đối xử với các lỗi này như lỗi linting. Mục tiêu không phải là hành động anh hùng; mà là ngăn hồi quy.

Thêm kiểm thử bàn phím thủ công

Với mọi luồng người dùng có ý nghĩa, hãy kiểm thử mà không dùng chuột. Điều này bao gồm điều hướng, tìm kiếm, tạo tài khoản, checkout, lọc, modal, menu và gửi biểu mẫu.

Tối thiểu, hãy xác minh:

• Mọi phần tử tương tác đều có thể tiếp cận
• Focus luôn hiển thị
• Thứ tự focus hợp lý
• Các phím mong đợi hoạt động
• Escape đóng các overlay có thể đóng
• Focus được quản lý sau khi mở và đóng component
• Không tồn tại bẫy bàn phím

Chỉ riêng thói quen này đã bắt được một lớp lớn vấn đề mà quét tự động bỏ sót.

Kiểm thử với ít nhất một trình đọc màn hình

Bạn không cần trở thành chuyên gia dùng trình đọc màn hình để học được những điều hữu ích. Bạn cần sự khiêm tốn. Kiểm thử trình đọc màn hình có đường cong học tập, và người mới bắt đầu có thể chẩn đoán sai vấn đề.

Dù vậy, kiểm thử cơ bản với VoiceOver, NVDA hoặc JAWS có thể phát hiện tên bị hỏng, thứ tự đọc gây nhầm lẫn, cập nhật không được thông báo và vấn đề landmark mà scanner có thể không bắt được.

Kết hợp điều này với HTML ngữ nghĩa. Bạn càng dùng nhiều phần tử gốc, khả năng tiếp cận của bạn càng ít mong manh.

Review nội dung và trạng thái

Kiểm tra trạng thái rỗng, trạng thái tải, trạng thái lỗi, trạng thái bị vô hiệu hóa, thông báo thành công và lỗi quyền truy cập. Lỗi khả năng tiếp cận thường ẩn ngoài happy path.

Cũng hãy review chính các từ ngữ. Nhãn, tiêu đề, hướng dẫn và thông báo lỗi là một phần của giao diện.

Bao gồm người dùng khuyết tật khi mức độ rủi ro cao

Với các luồng quan trọng, review thủ công bởi chuyên gia là chưa đủ. Kiểm thử người dùng với người tham gia là người khuyết tật tìm ra những vấn đề mà các nhóm không dự đoán được. Điều này đặc biệt quan trọng với dịch vụ công, y tế, tài chính, giáo dục và bất kỳ luồng nào mà sự loại trừ gây hậu quả nghiêm trọng.

Kiểm thử tự động có khả năng mở rộng. Kiểm thử con người thấu hiểu.

Cách diễn giải kết quả tự động một cách có trách nhiệm

Đừng hỏi, Chúng ta đã đạt chưa?

Hãy hỏi những câu tốt hơn:

• Công cụ này có thể phát hiện những nhóm vấn đề nào?
• Nó đã quét những template và trạng thái nào?
• Nó chạy sau các tương tác, hay chỉ khi tải ban đầu?
• Các vi phạm được nhóm theo nguyên nhân gốc hay được đếm lặp lại?
• Những lỗi nào chặn người dùng hoàn thành tác vụ?
• Điều gì vẫn cần review thủ công?

Cách đặt khung này thay đổi cuộc trò chuyện. Công cụ tự động trở thành bằng chứng, không phải thẩm quyền.

Nó cũng giúp các nhóm tránh việc bận rộn vô ích. Sửa một component duy nhất có thể loại bỏ hàng trăm vi phạm lặp lại. Ngược lại, một trang chỉ có một vấn đề được báo cáo vẫn có thể chứa một bẫy bàn phím nghiêm trọng. Số lượng không phải là tác động.

Tiêu chuẩn thực tế: tự động hóa điều hiển nhiên, kiểm thử thủ công trải nghiệm

Các nhóm khả năng tiếp cận tốt nhất không chống công cụ. Họ chống ảo tưởng.

Họ tự động hóa những gì máy có thể phát hiện đáng tin cậy. Họ kiểm thử thủ công những gì phụ thuộc vào hành vi và ý nghĩa. Họ dùng các tiêu chuẩn như WCAG làm đường cơ sở chung, không phải thay thế cho việc sử dụng sản phẩm.

Nếu quy trình hiện tại của bạn chỉ là một lần quét tự động trước khi ra mắt, hãy cải thiện theo thứ tự này:

1. Thêm kiểm tra tự động sớm hơn trong phát triển.
2. Kiểm thử bằng bàn phím thủ công các luồng cốt lõi.
3. Review tên, nhãn, lỗi và hướng dẫn.
4. Kiểm thử các component phổ biến với trình đọc màn hình.
5. Đưa vào kiểm thử chuyên gia và người dùng cho các hành trình rủi ro cao.

Đó không phải là một quy trình hoàn hảo. Đó là một quy trình thực tế. Và nó sẽ tìm ra nhiều hơn rất nhiều so với một điểm khả năng tiếp cận màu xanh từng có thể làm được.