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ư là một nhiệm vụ quá sức. Nếu đây là lần đầu tiên bạn tiếp cận chủ đề hỗ trợ tiếp cận, thì phạm vi rộng lớn 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. Xét cho cùng, việc điều chỉnh để phù hợp với nhiều loại khả năng đồng nghĩa với việc có nhiều vấn đề tương ứng cần cân nhắc.

Bài đăng này chia nhỏ các vấn đề này thành một quy trình hợp lý, từng bước để 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, thao tác trên bàn phím là phương tiện 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 trên bàn phím, hãy cố gắng sắp xếp thứ tự thẻ một cách hợp lý và có các kiểu tiêu điểm dễ phân biệt.

  • Bắt đầu bằng cách nhấn phím tab để di chuyển 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ẽ nhận được tiêu điểm, hãy tham khảo mô-đun về tiêu điểm trong khoá học Tìm hiểu về Hỗ trợ tiếp cận. Phương pháp hay nhất là mọi thành phần đ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ấy tiêu điểm và hiển thị chỉ báo tiêu điểm (chẳng hạn như vòng tiêu điểm).

  • Các chế độ điều khiển tương tác tuỳ chỉnh phải có thể đặt làm tâm điểm. Nếu bạn sử dụng JavaScript để biến <div> thành trình đơn thả xuống bắt mắt, thì trình đơn này sẽ không tự động được chèn vào thứ tự thẻ. Để có thể lấy tiêu điểm cho một thành phần điều khiển tuỳ chỉnh, hãy cung cấp cho thành phần đó một tabindex="0". Các 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 tiêu điểm 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 như tiêu đề sẽ làm chậm tốc độ của người dùng bàn phím có thể nhìn thấy màn hình và không giúp ích gì 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 phần tử đó.

  • Nếu bạn thêm nội dung mới vào một trang, trước tiên, hãy hướng sự chú ý của người dùng đến nội dung đó để họ có thể hành động. Hãy xem phần Quản lý tiêu điểm ở cấp trang để biết ví dụ.

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

Làm cho chế độ điều khiển tiêu điểm của bạn có thể sử dụng được

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 thành phầ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 bằng 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 có trong DOM nhưng không hiển thị, chẳng hạn như các đường liên kết bên trong trình đơn ngăn phản hồi hoặc nút bên trong cửa sổ phương thức chưa hiển thị. Việc để các phần tử này trong DOM có thể tạo ra trải nghiệm nhập liệu khó hiểu, đặc biệt là đối với trình đọc màn hình, trình đọc này sẽ thông báo nội dung ngoài màn hình như thể đó là một phần của trang.

Hãy xem phần 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 tính năng hỗ trợ bàn phím chung sẽ đặt nền tảng cho bước tiếp theo, đó là kiểm tra trang để đảm bảo việc gắn nhãn và ngữ nghĩa phù hợp cũng như không có bất kỳ trở ngại nào đối với việc điều hướng bằng trình đọc màn hình.

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

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

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

Mặc dù có vẻ khó khăn khi tìm hiểu về trình đọc màn hình, 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 được chỉ với một vài lệnh phím đơn giản.

Nếu bạn đang 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ở, được tài trợ cho Windows.

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

Điều 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ử; nó không ảnh hưởng đến hành vi của phần tử đó. Bạn có thể ẩn một phần tử khỏi trình đọc màn hình bằng aria-hidden="true", nhưng điều đó không làm thay đổi hành vi lấy tiêu điểm cho phần tử đó. Đố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ự bị xoá khỏi luồng bàn phím. Đối với các trình duyệt cũ, hãy kết hợp aria-hidden="true" với tabindex="-1".

Các thành phần tương tác phải cho biết mục đích và trạng thái của chúng

Việc cung cấp gợi ý trực quan (hay affordances) về chức năng của một thành phần điều khiển sẽ giúp nhiều người dùng trên nhiều thiết bị thao tác và điều hướng 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 khác với các phần tử không tương tác. Người dùng sẽ khó điều hướng trang web hoặc ứng dụng khi không biết liệu một phần tử có thể nhấp hay không. Có nhiều cách hợp lệ để chỉ báo các thành phần tương tác. Một phương pháp phổ biến là gạch chân các đườ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ề tiêu điểm, các phần tử tương tác như đường liên kết và nút yêu cầu trạng thái hover để cho người dùng chuột biết khi con trỏ của họ di chuyển qua một mục có thể nhấp. Tuy nhiên, để các phương thức nhập khác có thể truy cập vào các phần tử này, các phần tử đó phải có thể phân biệt được mà không cần trạng thái hover.

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

Tiêu đề và các phần tử điểm tham chiếu giúp trang của bạn có cấu trúc ngữ nghĩa, đồng thời 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 báo cáo rằng khi lần đầu truy cập vào một trang lạ, họ thường cố gắng 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 điểm mốc quan trọng như <main> và <nav>. Vì những lý do này, bạn cần cân nhắc cách sử dụng cấu trúc trang để hướng dẫn trải nghiệm của 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 dàn ý cho trang của bạn. Đừng dựa vào kiểu nội dung tiêu đề tích hợp sẵn. Thay vào đó, hãy coi các phần tử này giống như tất cả đều có cùng kích thước và sử dụng cấp độ phù hợp về ngữ nghĩa cho nội dung chính, phụ và trung gian. Sau đó, hãy sử dụng CSS để làm cho tiêu đề khớp với thiết kế của bạn.
  • Sử dụng các phần tử và vai trò điểm đánh dấu để 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 lối tắt do phần tử <main> hoặc <nav> xác định. Các phần tử này có vai trò điểm đánh dấu ngầm ẩn. Bạn cũng có thể sử dụng thuộc tính role 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à điều hướng nội dung để biết thêm ví dụ.
  • Tránh sử dụng role="application" trừ phi bạn có kinh nghiệm làm việc với lớp này. Vai trò điểm đánh dấu application cho công nghệ hỗ trợ biết tắt các phím 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 dùng để di chuyển trên 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àn phím.

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

Các trình đọc màn hình, chẳng hạn như VoiceOver và NVDA, cung cấp trình đơn theo bối cảnh để chuyển đến các khu vực quan trọng trên trang. Khi kiểm thử 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 cũng như những điểm đánh dấu đang được sử dụng.

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

Tự động hoá quy trình

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

  • Trang có vượt qua tất cả các bài kiểm thử từ tiện ích trình duyệt aXe hoặc WAVE không? Có các tuỳ chọn khác, nhưng các tiện ích này có thể là một 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 đề tinh vi như tỷ lệ tương phản không đạt 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 trình duyệt aXe, nhưng có thể chạy từ thiết bị đầu cuối.
  • Để 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 đưa một thư viện như axe-core vào bộ kiểm thử tự động của bạn. axe-core là công cụ tương tự như công cụ hỗ trợ tiện ích Chrome aXe, nhưng ở dạng 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ụ: trình bổ trợ hỗ trợ tiếp cận protractor 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 sử dụng thư viện axe-core để hỗ trợ các hoạt động kiểm thử chức 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 tra chức năng hỗ trợ tiếp cận không đạt trong báo cáo. Khắc phục các lỗi này để cải thiện trải nghiệm tổng thể của người dùng trên trang web.

Tài nguyên khác