Khả năng truy cập web giúp nhiều người có thể nhận biết nội dung, hiểu thông tin và sử dụng các chức năng của trang web, kể cả khi họ không nhìn thấy màn hình, không nghe được âm thanh hoặc không thể thao tác bằng chuột. API có thể hỗ trợ mục tiêu này bằng cách cung cấp dữ liệu và trạng thái cho giao diện, nhưng bản thân API không tự làm cho một trang web trở nên dễ tiếp cận.
Nhà phát triển vẫn phải trình bày dữ liệu bằng HTML có ngữ nghĩa, đặt tên rõ ràng cho các điều khiển, quản lý tiêu điểm và cung cấp phản hồi mà công nghệ hỗ trợ có thể nhận biết. Bài viết này giải thích mối liên hệ đó và đưa ra một quy trình triển khai có thể kiểm tra được.
API tham gia vào khả năng truy cập web như thế nào?
API (giao diện lập trình ứng dụng) là cơ chế để các phần mềm trao đổi dữ liệu hoặc gọi chức năng của nhau. Trong một ứng dụng web, API có thể trả về kết quả tìm kiếm, trạng thái của một thao tác, dữ liệu bản đồ, phụ đề hoặc nội dung dùng cho tính năng giọng nói.
Dữ liệu chỉ trở nên hữu ích với người dùng khi giao diện truyền đạt được ý nghĩa của nó. Có thể hình dung quá trình này theo bốn bước:
- API cung cấp dữ liệu, kết quả hoặc trạng thái.
- Ứng dụng chuyển thông tin đó thành nội dung, thông báo hoặc điều khiển trên trang.
- HTML và WAI-ARIA mô tả tên, vai trò, trạng thái và mối quan hệ của các thành phần giao diện.
- Trình duyệt chuyển thông tin phù hợp đến công nghệ hỗ trợ, chẳng hạn như trình đọc màn hình.
Nếu một bước bị thiếu, API vẫn có thể trả về dữ liệu chính xác nhưng một số người dùng không biết dữ liệu đã thay đổi, không tìm được điều khiển hoặc không thể hoàn thành tác vụ.
Năm điểm cần xử lý khi kết hợp API với giao diện
1. Bắt đầu bằng HTML có ngữ nghĩa
Các liên kết, nút và trường biểu mẫu HTML thông dụng đã có ý nghĩa và hành vi quen thuộc. Vì vậy, nên chọn phần tử phù hợp với chức năng trước khi bổ sung JavaScript hoặc thuộc tính ARIA. Một phần tử trông giống nút nhưng chỉ phản hồi khi nhấp chuột sẽ tạo thêm việc quản lý bàn phím, tiêu điểm và trạng thái.
Với dữ liệu lấy từ API, tiêu đề, danh sách, bảng và thông báo cũng cần được đánh dấu đúng cấu trúc. Cách trình bày này giúp người dùng đọc lướt bằng mắt và giúp công nghệ hỗ trợ hiểu được quan hệ giữa các phần nội dung.
2. Dùng WAI-ARIA để bổ sung ý nghĩa còn thiếu
WAI-ARIA không phải là API ứng dụng theo nghĩa thông thường. Đây là một bộ tiêu chuẩn gồm vai trò, trạng thái và thuộc tính giúp mô tả giao diện, đặc biệt với nội dung động hoặc thành phần tùy chỉnh. Có thể xem thêm hướng dẫn về WAI-ARIA và cách áp dụng.
aria-label: cung cấp tên có thể nhận biết cho một điều khiển khi không có nhãn chữ phù hợp.aria-hidden: loại một phần tử khỏi thông tin mà công nghệ hỗ trợ nhận được; thuộc tính này không làm phần tử biến mất khỏi màn hình.aria-live: giúp thông báo những thay đổi động thích hợp mà không buộc người dùng phải tự tìm lại vị trí vừa cập nhật.
ARIA cần phản ánh đúng trạng thái thật của giao diện. Nếu API báo một thao tác đã hoàn tất nhưng trạng thái ARIA không được cập nhật, người dùng có thể nhận thông tin cũ hoặc không nhận được phản hồi nào.
3. Bảo đảm thao tác bàn phím và tiêu điểm
Người dùng không thể hoặc không muốn dùng chuột cần truy cập được toàn bộ chức năng bằng bàn phím. Điều này bao gồm việc đi đến các điều khiển theo thứ tự hợp lý, nhìn thấy vị trí tiêu điểm và đóng được hộp thoại hoặc menu đã mở.
Với thành phần tùy chỉnh, JavaScript có thể lắng nghe sự kiện bàn phím và chuyển tiêu điểm khi cần. Tuy nhiên, chỉ thêm tabindex không bảo đảm thành phần hoạt động đúng. Nhà phát triển còn phải kiểm tra thao tác kích hoạt, thứ tự tiêu điểm và việc tiêu điểm có bị mắc kẹt hay không. Bài viết về thiết kế điều hướng chỉ bằng bàn phím trình bày kỹ hơn phần này.
4. Biến phản hồi của API thành thông báo dễ nhận biết
Phản hồi theo thời gian thực chỉ có ích khi người dùng nhận biết được nó. Chẳng hạn, sau khi biểu mẫu gửi dữ liệu đến API, giao diện có thể hiển thị thông báo “Đã lưu” hoặc mô tả lỗi ngay tại trường liên quan. Thông báo quan trọng không nên chỉ được biểu thị bằng màu sắc, biểu tượng hoặc hiệu ứng tải.
Với nội dung cập nhật mà không tải lại trang, một vùng thông báo phù hợp có thể giúp trình đọc màn hình nhận ra thay đổi. Mức độ thông báo cần vừa đủ: cập nhật quan trọng phải được truyền đạt, còn những thay đổi liên tục nhưng không cần hành động không nên làm gián đoạn người dùng.
5. Xem giọng nói là một lựa chọn bổ sung
API nhận dạng và tổng hợp giọng nói có thể hỗ trợ nhập lệnh hoặc đọc văn bản thành âm thanh. Đây là một cách tương tác bổ sung, không thay thế cho nhãn rõ ràng, thao tác bàn phím và nội dung có cấu trúc.
Nếu sản phẩm có chức năng phát lại bằng giọng nói, các nút bắt đầu, tạm dừng và dừng cũng phải dễ tìm, có tên rõ ràng và sử dụng được bằng bàn phím. Có thể tham khảo thêm hướng dẫn thiết kế chức năng phát lại giọng nói.
Khi API của bên thứ ba cung cấp dữ liệu
Dịch vụ bản đồ, nền tảng video và các hệ thống nội dung có thể cung cấp dữ liệu qua API. Khả năng truy cập của sản phẩm cuối cùng vẫn phụ thuộc vào cách ứng dụng lựa chọn và trình bày dữ liệu đó.
Với dữ liệu bản đồ, thông tin tuyến đường hoặc địa điểm cần có cách trình bày phù hợp ngoài hình ảnh trực quan. Với video, nếu API hỗ trợ thêm hoặc quản lý phụ đề, giao diện vẫn phải cho phép người dùng tìm và điều khiển chức năng phụ đề. Không nên giả định rằng một tính năng cụ thể luôn tồn tại hoặc cho kết quả giống nhau ở mọi dịch vụ; cần đối chiếu tài liệu của nhà cung cấp trước khi triển khai.
Bảng kiểm trước khi phát hành
| Hạng mục | Câu hỏi cần kiểm tra | Kết quả mong đợi |
|---|---|---|
| Cấu trúc | Nội dung từ API có tiêu đề, danh sách, bảng hoặc nhãn phù hợp không? | Người dùng hiểu được quan hệ giữa các phần thông tin. |
| Trình đọc màn hình | Tên, vai trò và trạng thái của điều khiển có được truyền đạt đúng không? | Điều khiển được nhận biết và trạng thái thay đổi được thông báo. |
| Bàn phím | Có thể hoàn thành tác vụ mà không cần chuột không? | Thứ tự tiêu điểm hợp lý, tiêu điểm nhìn thấy được và không bị mắc kẹt. |
| Nội dung động | Kết quả thành công, lỗi và trạng thái tải có dễ nhận biết không? | Thông báo xuất hiện đúng lúc và không chỉ dựa vào màu sắc. |
| Dữ liệu bên thứ ba | Ứng dụng xử lý thế nào khi dữ liệu thiếu hoặc API không phản hồi? | Người dùng nhận được thông báo rõ ràng và vẫn biết bước tiếp theo. |
| Giọng nói | Chức năng âm thanh có điều khiển rõ ràng không? | Người dùng có thể bắt đầu, tạm dừng hoặc dừng bằng các điều khiển dễ tiếp cận. |
Quy trình triển khai ngắn gọn
- Xác định tác vụ người dùng cần hoàn thành và dữ liệu API cần cung cấp.
- Thiết kế giao diện bằng các phần tử HTML phù hợp với chức năng.
- Chỉ bổ sung WAI-ARIA khi HTML chưa diễn đạt đủ vai trò, trạng thái hoặc quan hệ.
- Kết nối phản hồi của API với nội dung hiển thị, thông báo và trạng thái truy cập.
- Kiểm tra toàn bộ luồng bằng bàn phím và trình đọc màn hình, gồm cả trường hợp thành công, lỗi và chờ phản hồi.
Kết luận
API có thể mở rộng cách một ứng dụng cung cấp dữ liệu, phản hồi và phương thức tương tác. Khả năng truy cập chỉ được cải thiện khi dữ liệu đó được trình bày bằng cấu trúc rõ ràng, điều khiển được bằng bàn phím và truyền đạt đúng cho công nghệ hỗ trợ.
Thay vì bắt đầu từ câu hỏi “nên dùng API nào”, nhóm phát triển nên bắt đầu từ tác vụ của người dùng, sau đó xác định API, HTML, WAI-ARIA và cách kiểm tra cần thiết cho từng bước. Cách tiếp cận này giúp phát hiện các khoảng trống mà một tích hợp kỹ thuật đơn thuần có thể bỏ sót.
Chúng tôi đã phát hành UUU Web Accessibility Widget Tool. Nếu đang xem xét cải thiện khả năng truy cập cho trang web, bạn có thể truy cập liên kết để tìm hiểu thêm về công cụ.