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—tự động, thủ công và công nghệ hỗ trợ—là rất quan trọng để đạt được sản phẩm dễ tiếp cận nhất có thể.
Các bài kiểm thử của chúng tôi dựa trên cấp độ tuân thủ A và AA của Nguyên tắc truy cập nội dung web (WCAG) 2.1 làm tiêu chuẩn. Hãy nhớ rằng luật pháp ngành, loại sản phẩm, luật địa phương và quốc gia của bạn chính sách hoặc mục tiêu hỗ trợ tiếp cận tổng thể nào quy định 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. Hãy tham khảo lại bài viết "Cách đo lường khả năng hỗ trợ tiếp cận kỹ thuật số?" để biết thông tin chung về quy trình kiểm tra khả năng hỗ trợ tiếp cận, các loại/cấp độ tuân thủ, WCAG và POUR.
Như bạn đã biết, việc tuân thủ các nguyên tắc 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à một bước khởi đầu tốt vì nó cung cấp chỉ số để bạn có thể kiểm tra. Bạn nên thực hiện thêm các hành động ngoài việc kiểm thử tuân thủ khả năng hỗ trợ tiếp cận, chẳng hạn như chạy kiểm thử khả năng hữu dụng với người khuyết tật, tuyển dụng 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ề khả năng hỗ trợ tiếp cận kỹ thuật số để giúp bạn xây dựng các sản phẩm phù hợp hơn.
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 được xác định trước về tính tuân thủ về khả năng 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 các bài kiểm thử ở nhiều giai đoạn trong vòng đời sản phẩm.
- Bạn chỉ cần thực hiện vài bước và có kết quả rất nhanh chóng.
- Cần có một chú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 kiểm thử 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à lỗi vi phạm WCAG thực sự)
- 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 quan trọng để kiểm tra khả năng hỗ trợ tiếp cận của trang web hoặc ứng dụng, nhưng không phải tất cả các bước kiểm tra đều có thể đượ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 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 thử chức năng hỗ trợ tiếp cận tự động trực tuyến đầ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 Bobby". Hiện nay, có hơn 100 công cụ kiểm thử tự động để bạn lựa chọn!
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 đang kiểm thử sản phẩm của mình ở 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, bộ phận đảm bảo chất lượng hay người khác?
- Bạn muốn kiểm tra chức 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ó nên được liên kết trực tiếp với hệ thống tạo phiếu yêu cầu hỗ trợ không?
- Công cụ nào hoạt động hiệu quả 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 về "Cách chọn công cụ đánh giá chức 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 thử chức năng hỗ trợ tiếp cận tự động, chúng ta sẽ sử dụng Lighthouse của Chrome. Lighthouse là một 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ạ. Bạn có thể thấy một số vấn đề về khả năng hỗ trợ tiếp cận này và một số (nhưng không phải tất cả) sẽ được phát hiện 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 Chrome cho bản minh hoạ này.
Bước 2
Chúng tôi đã tạo 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 rồi chuyển đến thẻ Lighthouse. Xóa tất cả các tùy chọn danh mục ngoại trừ "Hỗ trợ tiếp cận". Giữ chế độ này làm chế độ mặc định và chọn loại thiết bị mà bạn đang chạy kiểm thử.
Bước 4
Nhấp vào Phân tích việc tải trang và chờ Lighthouse chạy các bài kiểm thử.
Sau khi kiểm thử xong, Lighthouse sẽ hiển thị một điểm số đo lường mức độ dễ tiếp cận của sản phẩm mà bạn đang kiểm thử. Điểm số Lighthouse được tính theo số lượng vấn đề, loại vấn đề và tác động của các vấn đề đã phát hiện được đối với người dùng.
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ó [role] ARIA yêu cầu phần tử con phải chứa một [role] cụ thể hiện đ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 Ứng dụng Internet phong phú dễ dùng (ARIA) phải chứa vai trò con cụ thể để thực hiện các chức năng hỗ trợ tiếp cận chủ định tương ứng". Tìm hiểu thêm về các 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>
Nút "đăng ký" bên cạnh trường nhập có vai trò ARIA không chính xác được áp dụng cho nút đó. 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: Ẩn ARIA
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ác phần tử con có thể lấy tiêu điểm trong một phần tử [aria-hidden="true"]
sẽ giúp ngăn người dùng công nghệ hỗ trợ, chẳng hạn như trình đọc màn hình, tiếp cận với các phần tử tương tác đó. Tìm hiểu thêm về 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 đã đượ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 dễ đọc. 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 có 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 alt của hình ảnh
Các phần tử hình ảnh bị 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ề các quy tắc về văn bản thay thế 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 bạn biết từ mô-đun hình ảnh rằng hình ảnh này được gọi là hình ảnh có thể hành động 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à biểu trưng, vì vậy, bạn có thể giả định một cách hợp lý rằng người dùng công cụ hỗ trợ tiếp cận 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 nội dung 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
Đườ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 dùng làm phần tử liên kết) có thể thấy rõ, là duy nhất và có thể lấy tiêu điểm sẽ cải thiện trải nghiệm khám phá cho người dùng trình đọc màn hình. Tìm hiểu thêm về các quy tắc về văn bản của đườ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 liên kết đưa người dùng đến. 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ụ: Phương thức này hoạt động hiệu quả đối với hình ảnh sử dụng thẻ <img>
, nhưng 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ể sử dụng một mẫu mô tả thay thế khác nhắm đến SVG, thêm thông tin giữa thẻ <a>
và <svg>
, sau đó ẩ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ề 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.
Sử dụng tuỳ chọn mẫu đơn giản nhất với 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à 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.
Có hai ví dụ được báo cáo.
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ó kích thướ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ó kích thước lớn (ít nhất 18pt/24px hoặc 14pt/18,5px in đậ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 lục lam cần đáp ứng yêu cầu về độ 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 lục lam được coi là văn bản cỡ thông thường, in đậ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 4,5:1.
Trong trường hợp này, chúng ta có thể tìm thấy một màu xanh lục lam đủ tối để đáp ứng tỷ lệ tương phản 4,5:1 hoặc chúng ta có thể tăng kích thước văn bản của nút thành 18,5 px in đậm và thay đổi một chút giá trị màu xanh lục lam. Một trong hai phương pháp vẫn 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 để nhìn được các yêu cầu về độ tương phản màu 4,5:1.
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á 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 thẻ <ul>
thực và sửa đổi CSS có liên quan, chúng ta có thể giải quyết 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 đề 8: tabindex
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ù 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. Để giữ nguyên thứ tự nhấn phím tab tự nhiên, chúng ta có thể thay đổi tabindex thành 0
hoặc xoá hoàn toàn thuộc tính này.
<button type="submit">Subscribe</button>
Bước 6
Giờ đây, 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 mới. Chạy lại quy trình kiểm tra khả năng hỗ trợ tiếp cận của 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 tự động về khả năng hỗ trợ tiếp cận này vào CodePen.
Bước tiếp theo
Tốt lắm! Bạn đã làm được rất nhiều việc, nhưng chúng ta vẫn chưa hoàn tất! Tiếp theo, chúng tôi sẽ chuyển sang các 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 mức độ hiểu biết
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?