Các đội ngũ sản phẩm thường có thói quen coi khả năng tiếp cận (accessibility) như một lớp sơn phủ cuối cùng. Họ xây dựng tính năng, trau chuốt giao diện, và rồi—chỉ hai ngày trước khi ra mắt—họ mới chạy trình quét. Đột nhiên, bảng điều khiển hiện lên màu đỏ rực. Thiếu nhãn biểu mẫu. Các nút bấm không có tên có thể tiếp cận. Các cấp độ tiêu đề nhảy vọt từ h1 sang h4 mà không có cảnh báo. Các tổ hợp màu sắc biến văn bản thành những mảng nhiễu với nền. Danh sách lỗi trông thật choáng ngợp vì chúng đã quá hạn.

Sự hoảng loạn vào phút chót này xảy ra vì công việc về khả năng tiếp cận mang lại cảm giác thủ công và chậm chạp. Một kiểm thử viên phải nhấp qua từng template bằng tay thì chỉ có thể bao quát được một phần nhỏ trong một sprint. Nhưng đây là phần thường bị bỏ qua: hầu hết các lỗi được tìm thấy muộn không phải là những lựa chọn nghệ thuật tinh vi hay đơn lẻ. Chúng là những vấn đề mang tính cấu trúc, lặp đi lặp lại trên hàng chục hoặc hàng trăm trang. Sự lặp lại đó chính là lý do tại sao tự động hóa lại hiệu quả.

Những gì máy móc thực sự làm tốt nhất

Các đội ngũ làm về khả năng tiếp cận không cần phép màu. Họ cần sự bao phủ (coverage). Một kiểm toán viên lành nghề có thể kiểm tra một mẫu đại diện của các trang, đưa ra phán đoán và bắt được các vấn đề sắc thái đòi hỏi ngữ cảnh. Trong khi đó, máy móc có thể kiểm tra mọi trang, mỗi đêm, mà không bỏ sót bước nào hay cảm thấy mệt mỏi. Giá trị của AI trong phương trình này không phải là thay thế các tiêu chuẩn WCAG. Nó thay đổi cách các đội ngũ làm việc. Thay vì để một kiểm thử viên chìm nghỉm trong các nhật ký lỗi (error logs) thô hoặc phải nhấp vào mọi template, AI có thể nhóm các vấn đề trùng lặp, xếp hạng chúng theo tần suất và cho bạn biết lỗi nào đang ảnh hưởng nặng nề nhất đến trải nghiệm người dùng.

Hãy sử dụng AI cho khối lượng công việc lớn, phân loại (triage) và nhận diện quy luật. Hãy để nó xử lý tải trọng quét thô để đội ngũ của bạn có thể tập trung vào việc sửa lỗi.

Những tín hiệu tiết lộ các lỗi phổ biến

Hầu hết các lỗi về khả năng tiếp cận đều phát ra những tín hiệu rõ ràng, có thể phát hiện được. Một trình quét có thể phát hiện một hình ảnh thiếu thuộc tính alt. Nó có thể tìm thấy các nút bấm tồn tại trong DOM nhưng không chứa văn bản hoặc aria-label, khiến người dùng trình đọc màn hình (screen reader) không biết nút đó dùng để làm gì. Nó có thể gắn cờ các liên kết chỉ ghi "click here" hoặc "read more", khiến những người dùng điều hướng bằng phím tab không biết đích đến là gì. Nó bắt được các tổ hợp màu sắc không đáp ứng yêu cầu về độ tương phản. Nó ghi nhận các phân cấp tiêu đề bị nhảy cấp, làm gián đoạn việc điều hướng đối với những người dựa vào tiêu đề để nắm bắt cấu trúc trang.

Đây là những vấn đề dựa trên quy luật. Chúng xuất hiện dưới dạng các dấu hiệu mã (code markers) có thể dự đoán được, điều đó có nghĩa là chúng chính xác là loại công việc mà tự động hóa cực kỳ xuất sắc trong việc tìm kiếm.

Xây dựng một pipeline giúp bắt được các vấn đề thực sự

Một thiết lập tốt không dựa vào một công cụ duy nhất chạy một lần. Nó kết hợp nhiều lớp. Lớp đầu tiên là một công cụ quy tắc (rule engine) quét chính mã nguồn. Các công cụ này kiểm tra markup dựa trên các hướng dẫn WCAG khi các nhà phát triển viết các component, gắn cờ các input không có nhãn hoặc các thuộc tính không hợp lệ trước khi chúng hiển thị trên trình duyệt.

Lớp thứ hai là tự động hóa trình duyệt. Phân tích mã tĩnh (static code analysis) không thể bắt được những gì xảy ra sau khi một modal mở ra, một dropdown mở rộng, hoặc một lỗi xác thực biểu mẫu xuất hiện. Các trình duyệt tự động cần phải đi qua các hành trình người dùng thực tế—luồng đăng ký, quy trình thanh toán, bảng điều khiển tài khoản—nơi nội dung thay đổi linh hoạt dựa trên hành động của người dùng. Nếu các yêu cầu về mật khẩu của bạn chỉ xuất hiện sau khi con trỏ rời khỏi một trường nhập liệu, thì chỉ riêng trình quét mã có thể sẽ không bao giờ thấy được lỗi thông báo đó.

Lớp thứ ba là nơi AI diễn giải các kết quả tìm thấy và hợp nhất các lỗi trùng lặp. Nếu cùng một nút biểu tượng không có nhãn nằm trong một component header được sử dụng trên tám mươi trang, hệ thống nên báo cáo nó một lần như một lỗi ở cấp độ component, chứ không phải tám mươi lỗi riêng biệt ở cấp độ trang. Điều này giúp ngăn đội ngũ bị chìm nghỉm trong mớ hỗn độn.

Lớp thứ tư là sự xem xét của con người. Máy móc nên kiểm tra liên tục, nhưng con người nên xem xét các trường hợp biên (edge cases) trước khi phát hành. Không một quy trình tự động nào nên là người đưa ra phán quyết cuối cùng.

Chuyển đổi thuật ngữ kỹ thuật thành hành động

Kết quả đầu ra thô từ trình quét thường bị bỏ xó trong các backlog vì nó đọc giống như một bản đặc tả dành cho kiểm toán viên hơn là dành cho nhà phát triển. Một báo cáo ghi "tỷ lệ tương phản màu sắc không đủ" thường bị phớt lờ vì nghe có vẻ trừu tượng và ít ưu tiên. Nhưng nói rằng "văn bản trợ giúp màu xám rất khó đọc trên nền trắng" sẽ cho nhà phát triển biết chính xác cần sửa gì, tìm ở đâu và tại sao nó lại quan trọng đối với người dùng thực tế. AI có thể giúp thu hẹp khoảng cách này bằng cách dịch các lỗi WCAG kỹ thuật sang ngôn ngữ bình dân mà các đội ngũ sản phẩm thực sự đọc và thực hiện.

Bạn cũng cần gán mức độ tin cậy cho các phát hiện của mình thay vì coi mọi cảnh báo đều như nhau. Các vấn đề có độ tin cậy cao, chẳng hạn như các ô nhập liệu trong biểu mẫu không có nhãn, có thể tự động tạo ticket vì việc khắc phục hầu như luôn được yêu cầu bởi WCAG và giải pháp cũng rất đơn giản. Các phát hiện có độ tin cậy trung bình, như văn bản thay thế (alt text) đáng ngờ có thể đang bị nhồi nhét từ khóa thay vì mang tính mô tả, cần con người xem xét để đánh giá xem mô tả đó có hữu ích hay không. Các mục có độ tin cậy thấp nên được giữ lại trong báo cáo để kiểm thử thủ công. Một trình quét có thể thấy thiếu thuộc tính alt, nhưng nó không biết liệu một hình ảnh mang tính trang trí hay thiết yếu để hiểu nội dung. Ngữ cảnh đó vẫn cần đến con người.

Sửa một lần, khắc phục mọi nơi

AI giúp các nhóm tìm ra nơi các vấn đề tập trung lại. Nếu một thành phần (component) nút bấm được xây dựng kém xuất hiện trên năm mươi màn hình, việc sửa thành phần đó một lần sẽ làm giảm số lượng lỗi ngay lập tức. Điều này chuyển đổi công việc từ việc giải quyết lỗi kiểu "đập chuột" (whack-a-mole) rời rạc trên từng trang sang việc bảo trì thư viện thành phần một cách có hệ thống. Nhận diện quy luật là nơi AI mang lại lợi ích lớn nhất. Nó kết nối các điểm dữ liệu trên hàng trăm trang để các nhóm không còn phải sửa cùng một lỗi trong bốn mươi ticket Jira khác nhau.

Việc kết nối các trình quét với các pull request giúp vòng lặp phản hồi này trở nên chặt chẽ. Khi một lập trình viên nhận được cảnh báo rằng mã đánh dấu (markup) mới của họ đã làm nhảy cấp độ tiêu đề ngay cả trước khi họ merge, việc sửa lỗi chỉ mất vài phút. Khi cùng một vấn đề đó được đưa lên môi trường production và bị phát hiện hai ngày trước khi ra mắt, việc khắc phục sẽ đòi hỏi một bản sửa lỗi khẩn cấp (hotfix), kiểm thử hồi quy (regression testing) và trao đổi với các bên liên quan. Các vòng lặp chặt chẽ hơn giúp tiết kiệm thời gian và giảm thiểu nợ khả năng tiếp cận (accessibility debt).

Sự phân chia công việc

Tự động hóa sẽ không tự mình làm cho sản phẩm của bạn có khả năng tiếp cận. Tuy nhiên, nó sẽ ngăn đội ngũ của bạn lặp đi lặp lại những lỗi hiển nhiên tương tự. Hãy chạy các kiểm tra tự động trong CI pipeline của bạn. Quét (crawl) các trang staging mỗi đêm để bắt kịp các lỗi hồi quy do người biên tập nội dung hoặc các tính năng mới gây ra. Nhóm các vấn đề theo thành phần để giữ cho danh sách tồn đọng (backlog) ở mức có thể quản lý được. Hãy dành sự chú ý của con người cho những phần của trang web mà ngữ cảnh là quan trọng nhất: đánh giá xem một hình ảnh có cần văn bản thay thế hay không, đánh giá các thành phần tùy chỉnh phức tạp và kiểm thử các luồng yêu cầu sự hiểu biết về ý định của người dùng.

Hãy sử dụng AI cho khối lượng lớn, phân loại mức độ ưu tiên và nhận diện quy luật. Hãy để máy móc xử lý việc quét lặp đi lặp lại trên mọi trang mỗi đêm. Hãy để con người đưa ra các quyết định mang tính đánh giá. Sự phân chia công việc đó là cách mà khả năng tiếp cận chuyển từ trạng thái hoảng loạn trước khi ra mắt thành một thói quen kỹ thuật bình thường.

Nguồn: https://dev.to/henryv/automating-wcag-compliance-with-ai-4ogp

Tham gia thảo luận: https://t.me/GyaanSetuAi