Cho đến nay trong khoá học này, bạn đã tìm hiểu về từng các khía cạnh pháp lý của hỗ trợ tiếp cận kỹ thuật số và thông tin cơ bản về hỗ trợ tiếp cận kỹ thuật số tính tuân thủ. Bạn đã tìm hiểu các chủ đề cụ thể liên quan đến thiết kế toàn diện và lập trình, bao gồm thời điểm sử dụng ARIA so với HTML, cách đo độ tương phản màu, khi JavaScript là cần thiết, trong số các chủ đề khác.
Trong các mô-đun còn lại, chúng ta sẽ chuyển từ thiết kế, xây dựng sang kiểm thử để hỗ trợ tiếp cận. Chúng tôi sẽ sử dụng quy trình thử nghiệm ba bước bao gồm các công cụ và kỹ thuật kiểm tra công nghệ hỗ trợ, tự động và thủ công. Chúng tôi sẽ sử dụng cùng một bản minh hoạ trong các mô-đun kiểm thử này để tiến hành trang web từ không thể truy cập.
Mỗi thử nghiệm – công nghệ tự động, thủ công và hỗ trợ – đều đóng vai trò quan trọng để đạt được 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 trên 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à chuẩn. Hãy nhớ rằng luật pháp ngành, loại sản phẩm, luật địa phương/quốc gia và chính sách hoặc mục tiêu hỗ trợ tiếp cận chung sẽ cho biết cần hướng dẫn nào và các cấp độ cần đáp ứng. Nếu bạn không yêu cầu một tiêu chuẩn cụ thể cho bạn nên sử dụng phiên bản WCAG mới nhất. Xem lại phần "Khả 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ề việc kiểm tra khả năng hỗ trợ tiếp cận, các loại/cấp độ tuân thủ, WCAG và XUẤT HIỆN.
Như bạn đã biết, sự tuân thủ về khả năng hỗ trợ tiếp cận không phải là một câu chuyện trọn vẹn khi đến với việc hỗ trợ người khuyết tật. Tuy nhiên, đây là một bước khởi đầu tốt vì nó cung cấp chỉ số để bạn có thể kiểm tra. Chúng tôi khuyến khích bạn tận dụng các hành động bổ sung bên ngoài việc kiểm tra tính tuân thủ về khả năng hỗ trợ tiếp cận, chẳng hạn như thực hiện các bài kiểm tra khả năng sử dụng với người khuyết tật, tuyển dụng người khuyết tật khi làm việc trong nhóm của mình hoặc tham khảo ý kiến của cá nhân hay công ty kiến thức chuyên môn về hỗ trợ tiếp cận kỹ thuật số để giúp bạn tạo ra các sản phẩm dành cho tất cả mọi người.
Kiến thức cơ bản về kiểm thử tự động
Kiểm thử khả năng hỗ trợ tiếp cận tự động sử dụng phần mềm để quét tìm các sản phẩm kỹ thuật số của bạn vấn đề về khả năng hỗ trợ tiếp cận so với các tiêu chuẩn xác định trước về tính tuân thủ 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 ở các giai đoạn khác nhau trong vòng đời sản phẩm
- Chỉ cần vài bước để chạy và có kết quả rất nhanh
- Cần có rất ít kiến thức về khả năng hỗ trợ tiếp cận để chạy thử nghiệm hoặc hiểu được kết quả
Nhược điểm của việc 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 hết tất 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ả (một vấn đề được báo cáo nhưng không phải là trường hợp vi phạm thực sự về WCAG)
- Có thể cần nhiều công cụ cho nhiều loại sản phẩm và vai trò
Kiểm thử tự động là bước đầu tiên hiệu quả để kiểm tra trang web hoặc ứng dụng của bạn nhưng không phải bước kiểm tra nào cũng được tự động hoá. Chúng ta sẽ tìm hiểu chi tiết 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 kiểm thử khả năng hỗ trợ tiếp cận 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 trực tuyến đầu tiên được phát triển tại 1996, do Trung tâm ứng dụng công nghệ đặc biệt (CAST) gọi là "Báo cáo của Bobby." Ngày nay, có trên 100 công cụ kiểm tra tự động để lựa chọn từ!
Cách triển khai công cụ tự động có nhiều loại, từ các tiện ích hỗ trợ tiếp cận của trình duyệt đế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 API nguồn mở mà bạn có thể sử dụng để xây dựng 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 dựa trên các tiêu chuẩn và cấp độ tuân thủ nào? Việc này có thể bao gồm WCAG 2.1, WCAG 2.0, U.S. Mục 508 hoặc 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à một trang web ứng dụng, ứ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 sẽ kiểm thử sản phẩm của mình trong giai đoạ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, hay công ty?
- Ai sẽ tiến hành kiểm thử: nhà thiết kế, nhà phát triển, quy trình đảm bảo chất lượng, v.v.?
- Bạn muốn kiểm tra khả năng hỗ trợ tiếp cận bao lâu một lần? Thông tin chi tiết phải là gì có trong báo cáo không? Các vấn đề có được liên kết trực tiếp với trang bán vé không của YouTube không?
- Công cụ nào hoạt động tốt nhất trong môi trường của bạn? Cho nhóm của bạn?
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 "Chọn công cụ đánh giá khả năng hỗ trợ tiếp cận trên web" để 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ạ: Kiểm thử tự động
Đối với bản minh hoạ kiểm tra khả năng hỗ trợ tiếp cận tự động, chúng tôi sẽ sử dụng Lighthouse. Lighthouse là công cụ nguồn mở, tự động được tạo ra để cải thiện chất lượng trang web thông qua các loại quy trình kiểm tra khác nhau, chẳng hạn như kiểm tra hiệu suất, SEO và khả năng hỗ trợ tiếp cận.
Bản minh hoạ của chúng tôi là một trang web được xây dựng cho một tổ chức tự do, The Medical Mysteries Câu lạc bộ. Trang web này không được truy cập một cách có chủ đích trong bản minh hoạ. Một vài tính năng trong số này tiện ích hỗ trợ tiếp cận có thể hiển thị với bạn và một số (nhưng không phải tất cả) sẽ bị thử nghiệm tự động của chúng tôi.
Bước 1
Bằng cách sử dụng trình duyệt Chrome, hãy cài đặt Tiện ích Lighthouse.
Có nhiều cách để tích hợp Lighthouse vào quy trình thử nghiệm. 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 bản minh hoạ trong CodePen.
Hãy xem ở chế độ gỡ lỗi để tiếp tục với
các thử nghiệm tiếp theo. Thao tác này rất quan trọng vì thao tác này sẽ xoá <iframe> xung quanh
trang web minh hoạ. Trang web này có thể ảnh hưởng đến một số công cụ kiểm tra. 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 và hãy chuyển đến thẻ Lighthouse. Bỏ chọn 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 sử dụng chạy bài kiểm thử.
Bước 4
Nhấp vào nút "Phân tích tải trang" và cho Lighthouse thời gian để chạy các kiểm thử.
Sau khi quá trình kiểm thử hoàn tất, Lighthouse sẽ hiển thị điểm số đo lường cách có thể truy cập vào sản phẩm mà bạn đang thử nghiệm. Chiến lược phát hành đĩa đơn Điểm Lighthouse được tính theo số lượng vấn đề, loại vấn đề và tác động đối với người dùng các vấn đề phát hiện được.
Ngoài điểm số, báo cáo Lighthouse còn bao gồm thông tin chi tiết về những gì các vấn đề đã phát hiện và liên kết đến các tài nguyên để tìm hiểu thêm về cách khắc phục chúng. Báo cáo cũng bao gồm các thử nghiệm đã đạt hoặc không áp dụng 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 xem ví dụ về từng vấn đề hỗ trợ tiếp cận tự động đã phát hiện cũng như sửa các kiểu và đánh dấu 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 con phải chứa một [vai trò] cụ thể đang thiếu một số hoặc tất cả các phần tử con bắt buộc đó. Một số vai trò mẹ của ARIA phải chứa vai trò con cụ thể để thực hiện chức năng hỗ trợ tiếp cận dự định". Tìm hiểu thêm về quy tắc vai trò ARIA.
Trong bản minh hoạ của chúng tôi, nút đăng ký nhận bản tin sẽ không hoạt động được:
<button role="list" type="submit" tabindex="1">Subscribe</button>
Hãy khắc phục vấn đề này.
Nút "đăng ký" nút bên cạnh trường nhập dữ liệu có vai trò ARIA không chính xác được áp dụng cho nội dung đó. Trong trường hợp này, bạn có thể xoá hoàn toàn vai trò đó.
<button type="submit" tabindex="1">Subscribe</button>
Vấn đề 2: ARIA bị ẩn
Các phần tử "[aria-hidden="true"] chứa các phần tử con có thể làm tâm điểm. Có thể lấy tiêu điểm
các thành phần con trong phần tử [aria-hidden="true"] ngăn chặn các thành phần tương tác
các yếu tố được cung cấp cho người dùng công nghệ hỗ trợ như màn hình
độc giả. Tìm hiểu thêm về các quy tắc của aria-hidden.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Trường nhập dữ liệu đã được áp dụng thuộc tính aria-hidden="true". Đang thêm
thuộc tính này giúp ẩn phần tử (và mọi thứ được lồng trong nó)
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 đầu vào để 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 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 thành phần hỗ trợ tiếp cận, trình đọc màn hình sẽ thông báo tên này là "nút" khiến nó không sử dụng được cho những người dùng dựa vào trình đọc màn hình. Tìm hiểu thêm về 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ý" trở thành nút hỗ trợ 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ó là các lựa chọn mẫu bổ sung để xem xét cho 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 nhắm đến
cho văn bản thay thế ngắn gọn, có tính mô tả. Bạn có thể bỏ qua các thành phần trang trí bằng
một thuộc tính alt trống. Tìm hiểu thêm về văn bản thay thế cho hình ảnh
quy tắc.
<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 liên kết, nên bạn có thể biết từ mô-đun hình ảnh mà nó gọi là mô-đun có thể thao tác hình ảnh và yêu cầu 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 nên bạn có thể giả định một cách hợp lý người dùng AT của bạn sẽ biết điều này và bạn có thể quyết định không thêm thông tin theo ngữ cảnh 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) rõ ràng, duy nhất và có thể làm tâm điểm sẽ giúp cải thiện trải nghiệm điều hướng cho người dùng trình đọc màn hình. Tìm hiểu thêm về quy tắc văn bản đường liên kết.
<a href="#!"><svg><path>...</path></svg></a>
Tất cả hình ảnh hữu ích trên trang phải bao gồm thông tin về nơi
người dùng sẽ được nhấp vào. Một phương pháp để khắc phục vấn đề này là thêm giải pháp thay thế
nội dung 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 phù hợp với hình ảnh sử dụng thẻ <img>, nhưng <svg>
thẻ không thể sử dụng phương pháp 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ể sử dụng
mẫu mô tả thay thế khác
nhắm mục tiêu đến SVG, hãy thêm thông tin giữa các thẻ <a> và <svg>, sau đó
ẩn bảng điều khiển khỏi người dùng một cách trực quan, thêm ARIA được hỗ trợ hoặc các tuỳ chọn khác. Tuỳ thuộc vào
về môi trường và các hạn chế về mã, có thể bạn nên dùng một phương pháp
khác. Hãy sử dụng mẫu hoa văn đơn giản nhất với thông tin hữu ích nhất
mức độ phù hợp công nghệ, tức 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à nền sau 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 về độ tương phản màu.
Chúng tôi đưa ra 2 ví dụ.
Medical Mysteries Club có giá trị hex màu #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 cùng khắc phục nhé.
Có 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ỡ thông thường (dưới 18pt / 24px) có yêu cầu về độ tương phản màu là 4,5:1, trong khi văn bản cỡ lớn (ít nhất là 18pt / 24px hoặc 14pt / 18.5px đậm) 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 màu xanh két cần đáp ứng độ tương phản màu 3:1 vì đây 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 với độ đậm 16px, vì vậy chúng phải đáp ứng màu 4,5:1 yêu cầu về độ tương phản.
Trong trường hợp này, chúng ta có thể tìm thấy màu xanh mòng két đủ tối để đáp ứng 4,5:1, hoặc chúng ta có thể tăng cỡ chữ của nút lên 18,5 px đậm và thay đổi cho giá trị màu xanh két nhỏ. Một trong hai phương pháp sẽ phù hợp với thiết kế thẩm mỹ.
Tất cả văn bản màu xám trên nền trắng cũng không điều chỉnh được độ tương phản màu, ngoại trừ cho hai tiêu đề lớn nhất trên trang. Văn bản này phải được làm tối để trông vừa vặn các yêu cầu về độ tương phản màu 4,5:1.
Medical Mysteries Club đã được gán một giá trị màu là #008576 và nền được giữ nguyên #ffffff. Tỷ lệ tương phản màu mới 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 #767676 và nền vẫn giữ nguyên #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 trong danh sách (<li>) phải có trong phần tử mẹ
<ul> hoặc <ol> cần được thông báo chính xác.
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 lớp CSS trong bản minh hoạ này để mô phỏng danh sách không theo thứ tự thay vì
bằng cách sử dụng thẻ <ul>. Khi viết mã này không đúng cách, chúng tôi đã xoá bỏ các giá trị vốn có
tính năng HTML ngữ nghĩa được tích hợp vào thẻ này. Bằng cách thay thế lớp bằng một
<ul> và sửa đổi CSS có liên quan thì chúng tôi sẽ giải quyết được vấn đề 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 đề số 8 - chỉ mục thẻ
Một số phần tử có giá trị [chỉ mục thẻ] lớn hơn 0. Một giá trị lớn hơn 0 ngụ ý một thứ tự điều hướng rõ ràng. Mặc dù về mặt kỹ thuật hợp lệ, nhưng thông thường tạo 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 chỉ mục thẻ.
<button type="submit" tabindex="1">Subscribe</button>
Trừ phi có lý do cụ thể để làm gián đoạn thứ tự tab thông thường trên web
, bạn không cần phải có số nguyên dương trên thuộc tính tabindex. Người nhận
vẫn giữ nguyên thứ tự thẻ thông thường, chúng ta có thể thay đổi chỉ mục thẻ thành 0 hoặc
hãy xoá hoàn toàn thuộc tính đó.
<button type="submit">Subscribe</button>
Bước 6
Giờ đây, khi bạn đã khắc phục tất cả các vấn đề về hỗ trợ tiếp cận tự động, hãy mở một trang chế độ gỡ lỗi. Chạy lại quy trình kiểm tra khả năng hỗ trợ tiếp cận trên Lighthouse. Điểm số của bạn sẽ tốt hơn nhiều so với lần chạy đầu tiên.
Chúng tôi đã áp dụng tất cả những nội dung cập nhật hỗ trợ tiếp cận tự động này vào CodePen.
Bước tiếp theo
Thật tuyệt! Bạn đã đạt được rất nhiều thành quả, nhưng chúng ta vẫn chưa hoàn thành! Tiếp theo, chúng tôi sẽ chuyển sang bước kiểm tra thủ công, như được nêu chi tiết trong kiểm thử khả năng hỗ trợ tiếp cận thủ công.
Kiểm tra kiến thức
Kiểm tra kiến thức của bạn về kiểm thử khả năng hỗ trợ tiếp cận tự động
Bạn nên làm loại thử nghiệm nào để đảm bảo rằng trang web của mình có thể truy cập được?
Những lỗi nào bị phát hiện khi kiểm thử tự động?