Cho đến nay, trong khoá học này, bạn đã tìm hiểu về các khía cạnh cá nhân, hoạt động kinh doanh và pháp lý của việc hỗ trợ tiếp cận kỹ thuật số, cũng như các khái niệm cơ bản về sự tuân thủ của tính năng hỗ trợ tiếp cận kỹ thuật số. Bạn đã khám phá các chủ đề cụ thể liên quan đến thiết kế và lập trình toàn diện, như thời điểm sử dụng ARIA so với HTML, cách đo lường độ tương phản màu khi cần có JavaScript và nhiều chủ đề khác.
Trong các mô-đun còn lại, chúng tôi chuyển hướng từ thiết kế và xây dựng sang kiểm thử khả năng hỗ trợ tiếp cận. Chúng tôi sẽ sử dụng một quy trình kiểm thử 3 bước, bao gồm các công cụ và kỹ thuật kiểm thử công nghệ tự động, thủ công và hỗ trợ. Chúng tôi sẽ sử dụng cùng một bản minh hoạ trong suốt các mô-đun kiểm thử này để cải thiện trang web từ không thể truy cập thành không truy cập được.
Mỗi hoạt động kiểm thử (công nghệ tự động, thủ công và hỗ trợ) đều đóng vai trò quan trọng để mang đến sản phẩm dễ tiếp cận nhất có thể.
Các thử nghiệm của chúng tôi dựa vào Nguyên tắc hỗ trợ tiếp cận nội dung web (WCAG) 2.1 mức độ tuân thủ A và AA làm tiêu chuẩn. Hãy nhớ rằng ngành, loại sản phẩm, luật và chính sách địa phương/quốc gia hoặc mục tiêu hỗ trợ tiếp cận tổng thể sẽ cho biết nguyên tắc nào cần tuân thủ và các cấp độ cần đáp ứng. Nếu dự án của bạn không cần có tiêu chuẩn cụ thể, bạn nên làm theo phiên bản WCAG mới nhất. Hãy tham khảo phần "Tính năng hỗ trợ tiếp cận kỹ thuật số được đo lường như thế nào?" để biết thông tin chung về các bài kiểm tra khả năng hỗ trợ tiếp cận, các loại/mức độ tuân thủ, WCAG và POUR.
Như bạn đã biết, tính tuân thủ về hỗ trợ tiếp cận không phải là toàn bộ câu chuyện khi nói đến việc hỗ trợ người khuyết tật. Tuy nhiên, đây là điểm khởi đầu phù hợp vì nền tảng này cung cấp chỉ số mà bạn có thể kiểm thử. Bạn nên thực hiện thêm những hành động khác ngoài việc kiểm thử tính tuân thủ về hỗ trợ tiếp cận, chẳng hạn như chạy các bài kiểm thử về khả năng hữu dụng với người khuyết tật, thuê người khuyết tật làm việc trong nhóm của bạn hoặc tham khảo ý kiến của một cá nhân hoặc công ty có chuyên môn về hỗ trợ tiếp cận kỹ thuật số để giúp bạn xây dựng các sản phẩm hoà nhập hơn.
Kiến thức cơ bản về kiểm thử tự động
Tính năng kiểm thử khả năng hỗ trợ tiếp cận tự động dùng phần mềm để quét sản phẩm kỹ thuật số của bạn để tìm các vấn đề về hỗ trợ tiếp cận dựa trên các tiêu chuẩn tuân thủ định sẵn về hỗ trợ tiếp cận.
Ưu điểm của kiểm thử khả năng hỗ trợ tiếp cận tự động:
- Dễ dàng lặp lại thử nghiệm ở nhiều giai đoạn trong vòng đời sản phẩm
- Chỉ cần vài bước để chạy và nhận kết quả rất nhanh chóng
- Bạn không cần nhiều kiến thức về hỗ trợ tiếp cận để chạy thử nghiệm hoặc hiểu kết quả
Nhược điểm của kiểm thử khả năng hỗ trợ tiếp cận tự động:
- Các công cụ tự động không phát hiện được tất cả các lỗi hỗ trợ tiếp cận trong sản phẩm của bạn
- Báo cáo dương tính giả (có một vấn đề được báo cáo nhưng không phải là lỗi vi phạm WCAG thực sự)
- Có thể cần nhiều công cụ cho các loại sản phẩm và vai trò khác nhau
Kiểm thử tự động là bước đầu tiên tuyệt vời để kiểm tra khả năng hỗ trợ tiếp cận trên trang web hoặc ứng dụng của bạn. Tuy nhiên, không phải quy trình kiểm tra nào cũng được tự động hoá. Chúng ta sẽ đi sâu hơn về cách kiểm tra khả năng hỗ trợ tiếp cận của các phần tử không thể tự động hoá trong mô-đun kiểm thử khả năng hỗ trợ tiếp cận theo cách thủ công.
Các loại công cụ tự động
Một trong những công cụ kiểm tra khả năng hỗ trợ tiếp cận tự động đầu tiên được phát triển vào năm 1996 bởi Trung tâm công nghệ đặc biệt ứng dụng (CAST), có tên là "Báo cáo của Bobby". Hiện nay, có hơn 100 công cụ kiểm thử tự động cho bạn lựa chọn!
Cách triển khai công cụ tự động có thể khác nhau, từ các tiện ích trình duyệt hỗ trợ tiếp cận cho đến công cụ tìm lỗi mã nguồn, ứng dụng dành cho máy tính và thiết bị di động, trang tổng quan trực tuyến và thậm chí cả các API nguồn mở mà bạn có thể dùng để tạo công cụ tự động của riêng mình.
Việc bạn quyết định sử dụng công cụ tự động nào có thể phụ thuộc vào nhiều yếu tố, bao gồm:
- Bạn đang thử nghiệm theo những tiêu chuẩn và mức độ tuân thủ nào? Các nguyên tắc này có thể bao gồm WCAG 2.1, WCAG 2.0, Mục 508 của Hoa Kỳ hoặc một danh sách sửa đổi các quy tắc hỗ trợ tiếp cận.
- Bạn đang thử nghiệm loại sản phẩm kỹ thuật số nào? Đây có thể là trang web, ứng dụng web, ứng dụng gốc dành cho thiết bị di động, PDF, kiosk hoặc sản phẩm khác.
- Bạn đang kiểm thử sản phẩm của mình ở phần nào trong vòng đời phát triển phần mềm?
- Mất bao lâu để thiết lập và sử dụng công cụ này? Đối với cá nhân, đội nhóm hay công ty?
- Ai tiến hành kiểm thử: nhà thiết kế, nhà phát triển, nhà phát triển đảm bảo chất lượng, v.v.?
- Bạn muốn kiểm tra khả năng tiếp cận bao lâu một lần? Những thông tin chi tiết nào cần được đưa vào báo cáo? Có nên liên kết trực tiếp các vấn đề với hệ thống bán vé không?
- Những công cụ nào hoạt động hiệu quả nhất trong môi trường của bạn? Dành cho nhóm của bạn?
Ngoài ra, bạn cũng cần cân nhắc nhiều yếu tố khác. Hãy xem bài viết của WAI về "Chọn Công cụ đánh giá khả năng hỗ trợ tiếp cận web" của WAI để biết thêm thông tin về cách chọn công cụ phù hợp nhất cho bạn và nhóm của bạn.
Bản minh hoạ: Thử nghiệm tự động
Đối với bản minh hoạ thử nghiệm tính năng hỗ trợ tiếp cận tự động, chúng ta sẽ dùng Lighthouse của Chrome. Lighthouse là một công cụ nguồn mở, tự động được tạo để cải thiện chất lượng của trang web thông qua nhiều loại hình kiểm tra, chẳng hạn như hiệu suất, SEO và khả năng tiếp cận.
Bản minh hoạ của chúng ta là một trang web được xây dựng cho một tổ chức thành lập, Câu lạc bộ Y tế bí ẩn. Trang web này bị bản minh hoạ cố ý không truy cập được. Bạn có thể nhìn thấy một số vấn đề về khả năng tiếp cận, và một số (nhưng không phải tất cả) sẽ nằm trong quy trình kiểm thử tự động của chúng tôi.
Bước 1
Sử dụng trình duyệt Chrome, cài đặt tiện ích Lighthouse.
Có nhiều cách để tích hợp Lighthouse vào quy trình kiểm thử. Chúng ta sẽ sử dụng tiện ích của Chrome cho bản minh hoạ này.
Bước 2
Chúng tôi đã xây dựng một bản minh hoạ trong CodePen.
Hãy xem mã này ở chế độ gỡ lỗi để tiếp tục với các hoạt động kiểm thử tiếp theo. Điều này rất quan trọng vì nó sẽ xoá <iframe> xung quanh trang web minh hoạ. Điều này có thể ảnh hưởng đến một số công cụ kiểm thử. Tìm hiểu thêm về chế độ gỡ lỗi của CodePen.
Bước 3
Mở Công cụ của Chrome cho nhà phát triển rồi chuyển đến thẻ Lighthouse. Bỏ đánh dấu tất cả các tuỳ chọn danh mục, ngoại trừ "Hỗ trợ tiếp cận". Giữ chế độ này làm mặc định và chọn loại thiết bị bạn đang chạy kiểm thử.
Bước 4
Nhấp vào nút "Phân tích tải trang" và cho Lighthouse có thời gian để chạy quy trình kiểm thử.
Sau khi kiểm thử hoàn tất, Lighthouse sẽ hiển thị điểm số đo lường khả năng truy cập vào sản phẩm bạn đang thử nghiệm. Điểm số của Lighthouse được tính theo số lượng vấn đề, loại vấn đề và mức tác động đến người dùng của các vấn đề được phát hiện.
Ngoài điểm số, báo cáo Lighthouse còn bao gồm thông tin chi tiết về những vấn đề đã phát hiện được và các đường liên kết đến các tài nguyên để tìm hiểu thêm về cách khắc phục. Báo cáo này cũng bao gồm các kiểm thử đã đạt hoặc không phù hợp và danh sách các mục bổ sung để kiểm tra theo cách thủ công.
Bước 5
Bây giờ, hãy cùng xem qua ví dụ về từng vấn đề về hỗ trợ tiếp cận tự động đã phát hiện, cũng như cách khắc phục các kiểu và mã đánh dấu có liên quan.
Vấn đề 1: Vai trò ARIA
Vấn đề đầu tiên nêu rõ: "Các phần tử có [vai trò] ARIA yêu cầu phần tử con chứa một [vai trò] cụ thể đang bị thiếu một số hoặc tất cả phần tử con bắt buộc đó. Một số vai trò mẹ của ARIA phải chứa các vai trò con cụ thể để thực hiện những chức năng hỗ trợ tiếp cận dự định của chúng." Tìm hiểu thêm về quy tắc vai trò ARIA.
Trong bản minh hoạ của chúng ta, nút đăng ký nhận bản tin không hoạt động:
<button role="list" type="submit" tabindex="1">Subscribe</button>
Hãy khắc phục vấn đề này.
Nút "đăng ký" bên cạnh trường nhập dữ liệu có vai trò ARIA không chính xác đã áp dụng cho trường đó. Trong trường hợp này, vai trò có thể bị xoá hoàn toàn.
<button type="submit" tabindex="1">Subscribe</button>
Vấn đề 2: ARIA bị ẩn
Phần tử "[aria-hidden="true"] chứa các thành phần con có thể làm tâm điểm. Con cháu có thể lấy tiêu điểm trong phần tử [aria-hidden="true"] ngăn các phần tử tương tác đó hiển thị với người dùng công nghệ hỗ trợ như trình đọc màn hình. Tìm hiểu thêm về các quy tắc aria-hidden.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Trường nhập dữ liệu đã áp dụng thuộc tính aria-hidden="true". Việc thêm thuộc tính này sẽ ẩn phần tử (và mọi nội dung lồng trong đó) khỏi công nghệ hỗ trợ.
<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>
Trong trường hợp này, bạn nên xoá thuộc tính này khỏi dữ liệu nhập để cho phép mọi người sử dụng công nghệ hỗ trợ truy cập và nhập thông tin vào trường của biểu mẫu.
Vấn đề 3: Tên nút
Các nút không có tên thành phần hỗ trợ tiếp cận. Khi một nút không có tên dễ tiếp cận, trình đọc màn hình sẽ thông báo đó là "nút", khiến người dùng trình đọc màn hình không sử dụng được nút này. Tìm hiểu thêm về các quy tắc tên nút.
<button role="list" type="submit" tabindex="1">Subscribe</button>
Khi bạn xoá vai trò ARIA không chính xác khỏi phần tử nút trong vấn đề 1, từ "Đăng ký" sẽ trở thành tên nút dễ tiếp cận. Chức năng này được tích hợp vào phần tử nút HTML ngữ nghĩa. Có các tuỳ chọn mẫu bổ sung cần xem xét đối với các tình huống phức tạp hơn.
<button type="submit" tabindex="1">Subscribe</button>
Vấn đề 4: Thuộc tính thay thế của hình ảnh
Phần tử hình ảnh thiếu thuộc tính [alt]. Các phần tử thông tin nên là đoạn văn bản thay thế ngắn, có tính mô tả. Bạn có thể bỏ qua các phần tử trang trí bằng thuộc tính alt trống. Tìm hiểu thêm về các quy tắc đối với văn bản thay thế cho hình ảnh.
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
Vì hình ảnh biểu trưng cũng là một đường liên kết, nên từ mô-đun hình ảnh, bạn biết rằng hình ảnh đó được gọi là hình ảnh thao tác và cần thông tin văn bản thay thế về mục đích của hình ảnh. Thông thường, hình ảnh đầu tiên trên trang là một biểu trưng, vì vậy, bạn có thể giả định rằng người dùng AT sẽ biết điều này và bạn có thể quyết định không thêm thông tin ngữ cảnh bổ sung này vào phần mô tả hình ảnh.
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png"
alt="Go to the home page.">
</a>
Vấn đề 5: Văn bản liên kết
Các đường liên kết không có tên rõ ràng. Văn bản liên kết (và văn bản thay thế cho hình ảnh, khi được dùng làm đường liên kết) có thể thấy rõ, duy nhất và có thể làm tâm điểm sẽ cải thiện trải nghiệm thao tác cho người dùng trình đọc màn hình. Tìm hiểu thêm về quy tắc đối với văn bản liên kết.
<a href="#!"><svg><path>...</path></svg></a>
Tất cả hình ảnh có thể thao tác trên trang phải bao gồm thông tin về nơi đường liên kết sẽ đưa người dùng đến. Một phương pháp để khắc phục vấn đề này là thêm văn bản thay thế vào hình ảnh về mục đích, như bạn đã làm với hình ảnh biểu trưng trong ví dụ ở trên. Cách này hiệu quả đối với hình ảnh sử dụng thẻ <img>, nhưng các thẻ <svg> không thể sử dụng phương thức này.
Đối với các biểu tượng mạng xã hội sử dụng thẻ <svg>, bạn có thể dùng một mẫu mô tả thay thế khác nhắm mục tiêu đến các SVG, thêm thông tin giữa thẻ <a> và <svg> rồi ẩn thông tin đó khỏi người dùng, thêm ARIA được hỗ trợ hoặc các tuỳ chọn khác. Tuỳ thuộc vào môi trường và các quy định hạn chế về mã, phương thức có thể được ưu tiên hơn phương thức khác. Hãy sử dụng tuỳ chọn mẫu đơn giản nhất có phạm vi công nghệ hỗ trợ nhiều nhất, đó là thêm role="img" vào thẻ <svg> và bao gồm phần tử <title>.
<a href="#!">
<svg role="img">
<title>Connect on our Twitter page.</title>
<path>...</path>
</svg>
</a>
Vấn đề 6: Độ tương phản màu
Màu nền trước và màu nền trước không có đủ tỷ lệ tương phản. Nhiều người dùng gặp khó khăn khi đọc hoặc không thể đọc được văn bản có độ tương phản thấp. Tìm hiểu thêm về các quy tắc tương phản màu.
Có 2 ví dụ được báo cáo.
Medical Mysteries Club , có giá trị màu hex là #01aa9d và giá trị hex nền là #ffffff. Tỷ lệ tương phản màu là 2,9:1.
Xem ảnh chụp màn hình ở kích thước đầy đủ.
Mermaid syndrome có giá trị hex văn bản là #7c7c7c, trong khi màu hex của nền là #ffffff. Tỷ lệ tương phản màu là 4,2:1.
Xem ảnh chụp màn hình ở kích thước đầy đủ.
Hãy khắc phục vấn đề này.
Phát hiện thấy nhiều vấn đề về độ tương phản màu trên trang web này. Như bạn đã tìm hiểu trong mô-đun màu sắc và độ tương phản, văn bản có kích thước thông thường (dưới 18 pt / 24 px) có yêu cầu về độ tương phản màu là 4,5:1, trong khi văn bản có kích thước lớn (đậm ít nhất 18 pt / 24px hoặc 14 pt / 18,5 px) và các biểu tượng thiết yếu phải đáp ứng yêu cầu 3:1.
Đối với tiêu đề trang, văn bản có màu xanh mòng két cần đáp ứng yêu cầu về độ tương phản màu 3:1 vì đó là văn bản có kích thước lớn ở 24px. Tuy nhiên, các nút màu xanh mòng két được coi là văn bản có kích thước thông thường ở độ đậm 16px, vì vậy, các nút này phải đáp ứng yêu cầu về độ tương phản màu sắc theo tỷ lệ 4,5:1.
Trong trường hợp này, chúng ta có thể tìm thấy màu xanh két đủ tối để đáp ứng tỷ lệ 4,5:1 hoặc có thể tăng kích thước của văn bản trên nút lên độ đậm 18,5px và thay đổi giá trị màu xanh mòng két một chút. Cả hai phương thức đều sẽ phù hợp với tính thẩm mỹ thiết kế.
Tất cả văn bản màu xám trên nền trắng cũng không đạt được độ tương phản màu, ngoại trừ 2 tiêu đề lớn nhất trên trang. Văn bản này phải được làm tối để đáp ứng các yêu cầu về độ tương phản màu 4,5:1.
Medical Mysteries Club , đã được cấp giá trị màu là #008576 và nền vẫn là #ffffff. Tỷ lệ tương phản màu cập nhật là 4,5:1.
Xem ảnh chụp màn hình ở kích thước đầy đủ.
Mermaid syndrome hiện có giá trị màu là #767676 và nền vẫn là #ffffff. Tỷ lệ tương phản màu là 4,5:1.
Xem ảnh chụp màn hình ở kích thước đầy đủ.
Vấn đề 7 - cấu trúc danh sách
Các mục trong danh sách (<li>) không có trong phần tử mẹ <ul> hoặc <ol>.
Trình đọc màn hình yêu cầu các mục danh sách (<li>) phải có trong một <ul> hoặc <ol> mẹ để được thông báo đúng cách.
Tìm hiểu thêm về quy tắc danh sách.
<div class="ul">
<li><a href="#">About</a></li>
<li><a href="#">Community</a></li>
<li><a href="#">Donate</a></li>
<li><a href="#">Q&A</a></li>
<li><a href="#">Subscribe</a></li>
</div>
Chúng tôi sử dụng một lớp CSS trong bản minh hoạ này để mô phỏng danh sách không theo thứ tự thay vì
sử dụng thẻ <ul>. Khi viết mã này không đúng cách, chúng tôi đã xoá các tính năng HTML ngữ nghĩa vốn có được tích hợp trong thẻ này. Bằng cách thay thế lớp này bằng một thẻ <ul> thực và sửa đổi CSS liên quan, chúng tôi sẽ giải quyết vấn đề về khả năng hỗ trợ tiếp cận này.
<ul>
<li><a href="#">About</a></li>
<li><a href="#">Community</a></li>
<li><a href="#">Donate</a></li>
<li><a href="#">Q&A</a></li>
<li><a href="#">Subscribe</a></li>
</ul>
Vấn đề #8 – Chỉ mục thẻ
Một số phần tử có giá trị [tabindex] lớn hơn 0. Giá trị lớn hơn 0 ngụ ý thứ tự điều hướng rõ ràng. Mặc dù hợp lệ về mặt kỹ thuật, nhưng điều này thường gây ra trải nghiệm khó chịu cho những người dùng dựa vào công nghệ hỗ trợ. Tìm hiểu thêm về quy tắc lập chỉ mục thẻ.
<button type="submit" tabindex="1">Subscribe</button>
Trừ phi có một lý do cụ thể để làm gián đoạn thứ tự gắn thẻ thông thường trên trang web, thì thuộc tính thẻ chỉ mục không cần phải có số nguyên dương. Để giữ thứ tự thẻ thông thường, chúng ta có thể thay đổi chỉ mục thẻ thành 0 hoặc xoá hoàn toàn thuộc tính này.
<button type="submit">Subscribe</button>
Bước 6
Bây giờ, bạn đã khắc phục mọi vấn đề hỗ trợ tiếp cận tự động, hãy mở một trang chế độ gỡ lỗi mới. Chạy lại bài kiểm tra khả năng hỗ trợ tiếp cận của Lighthouse. Điểm số của bạn đáng lẽ sẽ tốt hơn nhiều so với trong lần chạy đầu tiên.
Chúng tôi đã áp dụng tất cả các bản cập nhật hỗ trợ tiếp cận tự động này cho một CodePen mới.
Bước tiếp theo
Tuyệt vời! Bạn đã làm được rất nhiều việc nhưng chúng ta vẫn chưa hoàn thành! Tiếp theo, chúng ta sẽ chuyển sang bước kiểm tra thủ công, như đã nêu chi tiết trong mô-đun kiểm thử chức năng hỗ trợ tiếp cận theo cách thủ công.
Kiểm tra mức độ hiểu biết của bạn
Kiểm tra kiến thức của bạn về tính năng kiểm thử khả năng hỗ trợ tiếp cận tự động
Bạn nên tiến hành loại thử nghiệm nào để đảm bảo mọi người có thể truy cập vào trang web của mình?
Kiểm thử tự động phát hiện được những lỗi nào?