Cách kiểm tra khả năng hỗ trợ tiếp cận

Rob Dodson

Việc xác định xem trang web hoặc ứng dụng của bạn có thể truy cập được hay không có vẻ như một công việc khó khăn. Nếu đây là lần đầu tiên bạn tiếp cận khả năng hỗ trợ tiếp cận, thì nội dung bao quát của chủ đề này có thể khiến bạn băn khoăn không biết nên bắt đầu từ đâu. Sau cùng, khi cố gắng đáp ứng nhiều khả năng, bạn sẽ cần xem xét nhiều vấn đề tương ứng.

Bài đăng này phân tích những vấn đề này thành một quy trình từng bước hợp lý để xem xét khả năng hỗ trợ tiếp cận của một trang web hiện có.

Bắt đầu với bàn phím

Đối với những người dùng không thể hoặc chọn không sử dụng chuột, di chuyển bằng bàn phím là phương thức chính để truy cập vào mọi nội dung trên màn hình. Đối tượng này bao gồm những người dùng bị suy giảm chức năng vận động, chẳng hạn như chấn thương do căng thẳng lặp đi lặp lại (RSI) hoặc bại liệt, cũng như người dùng trình đọc màn hình.

Để có trải nghiệm tốt khi dùng bàn phím, hãy cố gắng sắp xếp thứ tự thẻ hợp lý và kiểu tiêu điểm rõ ràng.

  • Hãy bắt đầu bằng cách duyệt qua trang web của bạn. Thứ tự các phần tử được lấy tiêu điểm phải tuân theo thứ tự DOM. Nếu bạn không chắc chắn phần tử nào sẽ được lấy nét, hãy xem Kiến thức cơ bản về tiêu điểm để ôn lại kiến thức. Phương pháp hay nhất là mọi chế độ điều khiển mà người dùng có thể tương tác hoặc cung cấp dữ liệu đầu vào đều phải có thể làm tâm điểm và hiển thị một chỉ báo lấy nét (chẳng hạn như vòng lấy nét).

  • Các thành phần điều khiển tương tác tuỳ chỉnh phải có thể làm tâm điểm. Nếu bạn sử dụng JavaScript để chuyển <div> thành một trình đơn thả xuống ưa thích, thì trình đơn này sẽ không tự động được chèn vào thứ tự thẻ. Để một chế độ điều khiển tuỳ chỉnh có thể làm tâm điểm, hãy cung cấp tabindex="0" cho chế độ đó. Giá trị tabindex lớn hơn 0 sẽ thay đổi thứ tự thẻ và có thể gây nhầm lẫn cho người dùng trình đọc màn hình.

  • Chỉ tập trung vào nội dung tương tác. Việc thêm tabindex vào các phần tử không tương tác (chẳng hạn như tiêu đề) sẽ làm chậm những người dùng bàn phím có thể nhìn thấy màn hình, đồng thời không giúp ích cho người dùng trình đọc màn hình vì trình đọc màn hình đã biết thông báo các thông báo này.

  • Nếu bạn thêm nội dung mới vào một trang, hãy hướng người dùng tập trung vào nội dung đó trước tiên để họ có thể thực hiện hành động đối với nội dung đó. Hãy xem bài viết Quản lý tiêu điểm ở cấp trang để biết các ví dụ.

  • Hãy thiết kế trang web của bạn để người dùng luôn có thể tập trung vào thành phần tiếp theo khi họ muốn. Hãy cảnh giác với các tiện ích tự động hoàn thành và các ngữ cảnh khác có thể chặn sự tập trung của bàn phím. Bạn có thể tạm thời giữ lại tiêu điểm khi muốn người dùng tương tác với một cửa sổ phụ chứ không phải với phần còn lại của trang. Tuy nhiên, bạn phải luôn cung cấp một cách mà bạn có thể truy cập bằng bàn phím để thoát khỏi cửa sổ phụ. Hãy xem bài viết Modals và Bẫy bàn phím để biết ví dụ.

Giúp bạn dễ dàng điều khiển chế độ lấy nét

Nếu bạn đã tạo một thành phần điều khiển tuỳ chỉnh, hãy cho phép người dùng sử dụng tất cả các tính năng của tuỳ chọn đó chỉ bằng bàn phím. Hãy đọc bài viết Quản lý tiêu điểm trong các thành phần để biết các kỹ thuật cải thiện quyền truy cập vào bàn phím.

Quản lý nội dung ngoài màn hình

Nhiều trang web có nội dung ngoài màn hình xuất hiện trong DOM nhưng không hiển thị, chẳng hạn như đường liên kết bên trong trình đơn ngăn thích ứng hoặc nút bên trong cửa sổ phụ chưa được hiển thị. Việc để các thành phần này trong DOM có thể tạo ra trải nghiệm bàn phím khó hiểu, đặc biệt là đối với trình đọc màn hình, vì trình đọc màn hình sẽ thông báo nội dung ngoài màn hình như thể chúng là một phần của trang.

Hãy xem bài viết Xử lý nội dung ngoài màn hình để biết các mẹo xử lý những phần tử này.

Kiểm thử bằng trình đọc màn hình

Việc cải thiện khả năng hỗ trợ bàn phím nói chung đặt nền móng cho bước tiếp theo, đó là kiểm tra trang xem có gắn nhãn và ngữ nghĩa chính xác hay không, cũng như mọi trở ngại đối với việc điều hướng của trình đọc màn hình.

Nếu bạn chưa hiểu rõ cách đánh dấu ngữ nghĩa được diễn giải bằng công nghệ hỗ trợ, hãy đọc phần Cấu trúc nội dung.

  • Kiểm tra tất cả hình ảnh để tìm văn bản alt phù hợp. Trường hợp ngoại lệ của phương pháp này là khi hình ảnh chủ yếu dùng để trình bày và không phải là phần nội dung thiết yếu. Để biểu thị rằng trình đọc màn hình nên bỏ qua một hình ảnh, hãy đặt giá trị thành một chuỗi trống: alt="".
  • Kiểm tra tất cả chế độ kiểm soát cho một nhãn. Đối với các chế độ điều khiển tuỳ chỉnh, bạn có thể cần sử dụng aria-label hoặc aria-labelledby. Xem bài viết Nhãn và mối quan hệ của ARIA để biết ví dụ.
  • Đánh dấu tất cả chế độ điều khiển tuỳ chỉnh cho một role thích hợp và mọi thuộc tính ARIA bắt buộc thông báo trạng thái của các thuộc tính đó. Ví dụ: một hộp đánh dấu tuỳ chỉnh cần có role="checkbox" và aria-checked="true|false" để truyền tải đúng trạng thái của hộp đánh dấu. Xem phần Giới thiệu về ARIA để biết thông tin tổng quan chung về cách ARIA có thể cung cấp ngữ nghĩa bị thiếu cho các chế độ điều khiển tuỳ chỉnh.
  • Làm cho luồng thông tin trên trang của bạn hợp lý. Vì trình đọc màn hình di chuyển trang theo thứ tự DOM, nên trình đọc màn hình sẽ thông báo mọi phần tử mà bạn đã định vị lại một cách trực quan bằng CSS theo thứ tự vô nghĩa. Nếu bạn cần nội dung nào đó xuất hiện trước đó trên trang, hãy di chuyển nội dung đó sớm hơn trong DOM.
  • Cố gắng hỗ trợ điều hướng bằng trình đọc màn hình cho tất cả nội dung trên trang. Đảm bảo không có phần nào của trang web bị ẩn vĩnh viễn hoặc chặn quyền truy cập của trình đọc màn hình.
    • Nếu nội dung nên bị ẩn khỏi trình đọc màn hình, chẳng hạn như nếu nội dung ở ngoài màn hình hoặc chỉ để trình bày, hãy đặt nội dung đó thành aria-hidden="true". Để hiểu rõ hơn, hãy tham khảo phần Ẩn nội dung.

Làm quen với trình đọc màn hình

Mặc dù việc học trình đọc màn hình có vẻ khó khăn, nhưng các trình đọc màn hình thực sự khá thân thiện với người dùng. Nhìn chung, hầu hết các nhà phát triển đều có thể sử dụng chỉ với một vài lệnh phím đơn giản.

Nếu bạn sử dụng máy Mac, hãy xem video này về VoiceOver, trình đọc màn hình đi kèm với Mac OS. Nếu bạn đang dùng máy tính, hãy xem video này về NVDA, một trình đọc màn hình nguồn mở và được hỗ trợ tính năng đóng góp dành cho Windows.

aria-hidden không ngăn tiêu điểm bằng bàn phím

Quan trọng là bạn phải hiểu rằng ARIA chỉ có thể ảnh hưởng đến ngữ nghĩa của một phần tử chứ không ảnh hưởng đến hành vi của phần tử. Bạn có thể ẩn một phần tử đối với trình đọc màn hình bằng aria-hidden="true", nhưng điều này không làm thay đổi hành vi lấy nét của phần tử đó. Đối với nội dung tương tác ngoài màn hình, Đối với nội dung tương tác ngoài màn hình, hãy sử dụng thuộc tính inert để đảm bảo nội dung đó thực sự được xoá khỏi quy trình của bàn phím. Đối với những trình duyệt cũ hơn, hãy kết hợp aria-hidden="true" với tabindex="-1".

Các phần tử tương tác phải chỉ rõ mục đích và trạng thái

Việc đưa ra các gợi ý trực quan (hoặc khả năng) về những việc mà thành phần điều khiển sẽ làm sẽ giúp nhiều người trên nhiều loại thiết bị vận hành và di chuyển trên trang web của bạn.

  • Các phần tử tương tác, chẳng hạn như đường liên kết và nút, phải được phân biệt với các phần tử không tương tác. Người dùng gặp khó khăn khi di chuyển trên một trang web hoặc ứng dụng khi họ không biết liệu có thể nhấp vào một phần tử hay không. Có nhiều cách hợp lệ để chỉ báo các phần tử tương tác. Một phương pháp phổ biến là gạch chân đường liên kết để phân biệt chúng với văn bản xung quanh.
  • Tương tự như yêu cầu về tâm điểm, các phần tử tương tác như đường liên kết và nút phải có trạng thái hover để cho người dùng chuột biết khi con trỏ của họ nằm trên thứ gì đó có thể nhấp vào. Tuy nhiên, để các phần tử này có thể truy cập được vào các phương thức nhập khác, bạn phải phân biệt được các phần tử này mà không cần trạng thái hover.

Tận dụng tiêu đề và điểm mốc

Tiêu đề và phần tử mốc tạo cấu trúc ngữ nghĩa cho trang và làm tăng đáng kể hiệu quả điều hướng của người dùng công nghệ hỗ trợ. Nhiều người dùng trình đọc màn hình cho biết rằng khi lần đầu truy cập vào một trang lạ, họ thường cố di chuyển theo tiêu đề.

Tương tự, trình đọc màn hình cũng có thể chuyển đến các mốc quan trọng như <main> và <nav>. Vì những lý do này, bạn nên xem xét cách sử dụng cấu trúc của trang để định hướng trải nghiệm người dùng.

  • Sử dụng hệ phân cấp h1-h6. Hãy coi tiêu đề là công cụ để tạo đường viền cho trang. Đừng dựa vào kiểu tích hợp của tiêu đề. Thay vào đó, hãy xử lý các lớp này như thể chúng có cùng kích thước và sử dụng cấp độ ngữ nghĩa phù hợp cho nội dung chính, phụ và cấp ba. Sau đó, sử dụng CSS để làm cho các tiêu đề phù hợp với thiết kế của bạn.
  • Sử dụng các phần tử và vai trò mốc để người dùng có thể bỏ qua nội dung lặp lại. Nhiều công nghệ hỗ trợ cung cấp lối tắt để chuyển đến các phần cụ thể của trang, chẳng hạn như các phần được xác định bằng các phần tử <main> hoặc <nav>. Các phần tử này có vai trò điểm mốc ngầm ẩn. Bạn cũng có thể dùng thuộc tính role của ARIA để xác định rõ ràng các vùng trên trang, như trong <div role="search">. Hãy xem phần Ngữ nghĩa và cách điều hướng nội dung để biết thêm ví dụ.
  • Hãy tránh dùng role="application" trừ phi bạn có kinh nghiệm xử lý thuộc tính này. Vai trò mốc application yêu cầu công nghệ hỗ trợ vô hiệu hoá các lối tắt và chuyển tất cả các thao tác nhấn phím đến trang. Điều này có nghĩa là các phím mà người dùng trình đọc màn hình thường sử dụng để di chuyển xung quanh trang không còn hoạt động nữa và bạn sẽ phải tự triển khai tất cả thao tác xử lý bằng bàn phím.

Xem lại các tiêu đề và điểm mốc bằng trình đọc màn hình

Các trình đọc màn hình, như VoiceOver và NVDA, cung cấp một trình đơn theo bối cảnh để bỏ qua các vùng quan trọng trên trang. Khi kiểm tra khả năng hỗ trợ tiếp cận, bạn có thể sử dụng các trình đơn này để xem thông tin tổng quan về trang và xác định xem các cấp tiêu đề có phù hợp hay không và xem mốc nào đang được sử dụng.

Để tìm hiểu thêm, hãy tham khảo các video hướng dẫn cơ bản về VoiceOver và NVDA.

Tự động hoá quy trình

Việc kiểm tra khả năng tiếp cận của một trang web theo cách thủ công có thể tẻ nhạt và dễ xảy ra lỗi. Bạn nên kiểm thử tự động nhiều nhất có thể. Bạn có thể sử dụng các tiện ích của trình duyệt và bộ kiểm thử khả năng hỗ trợ tiếp cận của dòng lệnh.

  • Trang có vượt qua mọi bài kiểm thử trên tiện ích trình duyệt aXe hoặc WAVE không? Ngoài ra còn có các tuỳ chọn khác, nhưng các tiện ích này có thể là phần bổ sung hữu ích cho mọi quy trình kiểm thử thủ công, vì chúng có thể phát hiện các vấn đề nhỏ như không đạt tỷ lệ tương phản và thiếu thuộc tính ARIA.
    • Nếu bạn muốn làm việc trên dòng lệnh, axe-cli cung cấp các tính năng tương tự như tiện ích aXe của trình duyệt, nhưng bạn có thể chạy tiện ích này trên thiết bị đầu cuối của mình.
  • Để tránh hiện tượng hồi quy, đặc biệt là trong môi trường tích hợp liên tục, hãy tích hợp một thư viện như axe-core vào bộ thử nghiệm tự động của bạn. Axe-core cũng là công cụ hỗ trợ tiện ích aXe Chrome, nhưng trong tiện ích dòng lệnh.
  • Nếu bạn đang sử dụng một khung hoặc thư viện, thì khung hoặc thư viện đó có cung cấp các công cụ hỗ trợ tiếp cận riêng không? Ví dụ: protractor-accessibility-plugin cho Angular. Hãy tận dụng các công cụ có sẵn bất cứ khi nào có thể.

Sử dụng Lighthouse để kiểm thử PWA

Lighthouse là một công cụ đo lường hiệu suất của ứng dụng web tiến bộ (PWA). Ngoài ra, công cụ này còn sử dụng thư viện Axe-core để hỗ trợ các bài kiểm thử khả năng hỗ trợ tiếp cận.

Nếu bạn đã sử dụng Lighthouse, hãy tìm các bài kiểm thử khả năng hỗ trợ tiếp cận không thành công trong báo cáo. Sửa các lỗi để cải thiện trải nghiệm người dùng tổng thể trên trang web của bạn.

Tài nguyên bổ sung