Kintone là nền tảng tạo ứng dụng doanh nghiệp trên đám mây. Khi ứng dụng được dùng để nhập, tìm và quản lý dữ liệu hằng ngày, khả năng tiếp cận cần được xem như một phần của thiết kế, không phải bước chỉnh sửa ở cuối dự án.
Khả năng tiếp cận web là mức độ mà người dùng có thể nhận biết nội dung, hiểu giao diện và thực hiện thao tác trong những điều kiện sử dụng khác nhau. Với ứng dụng Kintone, điều này đặc biệt hữu ích cho người dùng trình đọc màn hình, người chỉ thao tác bằng bàn phím, người khó phân biệt màu sắc, người cao tuổi và người chưa quen với công nghệ.
Bài viết này tập trung vào năm điểm có thể kiểm tra trực tiếp trong ứng dụng: nhãn và văn bản thay thế, màu sắc, bàn phím, cấu trúc tiêu đề và biểu mẫu. Để tìm hiểu thêm về phạm vi có thể bắt đầu khi không chuyên HTML, CSS hoặc JavaScript, có thể đọc bài viết về các biện pháp khả năng tiếp cận trong Kintone.
Khả năng tiếp cận ảnh hưởng đến trải nghiệm Kintone như thế nào?
Một giao diện dễ tiếp cận giúp nhiều người hoàn thành cùng một công việc mà không phải phụ thuộc vào chuột, màu sắc hoặc khả năng nhìn rõ màn hình. Các cải tiến này cũng làm cho tên nút, thứ tự thao tác và thông báo lỗi rõ ràng hơn đối với người dùng nói chung.
- Nhiều người dùng hơn có thể tiếp cận và thao tác với ứng dụng.
- Thông tin và trạng thái của giao diện được truyền đạt rõ hơn.
- Nhóm vận hành có cơ sở cụ thể để đối chiếu ứng dụng với các hướng dẫn về khả năng tiếp cận.
Các yêu cầu pháp lý phụ thuộc vào quốc gia, khu vực và loại dịch vụ. Vì vậy, việc cải thiện theo các điểm dưới đây hỗ trợ khả năng tiếp cận, nhưng không nên được xem là sự xác nhận rằng ứng dụng đã đáp ứng mọi yêu cầu pháp lý.
Danh sách kiểm tra nhanh
| Hạng mục | Cách kiểm tra | Dấu hiệu cần sửa |
|---|---|---|
| Nhãn và nút | Đọc tên trường và tên nút mà không dựa vào vị trí | Tên quá chung như “Gửi” hoặc thiếu nhãn |
| Hình ảnh | Kiểm tra văn bản thay thế của hình mang thông tin | Không thể hiểu mục đích của hình khi không nhìn thấy hình |
| Màu sắc | Xem trạng thái khi bỏ qua màu | Lỗi hoặc trạng thái chỉ được biểu thị bằng màu |
| Bàn phím | Dùng Tab, Shift+Tab, Enter và Esc để đi qua tác vụ | Mất dấu vị trí, thứ tự nhảy khó hiểu hoặc không kích hoạt được nút |
| Tiêu đề và biểu mẫu | Đọc theo cấu trúc và thử gửi dữ liệu thiếu | Cấp tiêu đề lộn xộn, trường bắt buộc hoặc lỗi không rõ |
Năm điểm cần kiểm tra trong ứng dụng Kintone
1. Viết nhãn và văn bản thay thế rõ mục đích
Trình đọc màn hình đọc thành tiếng nội dung và tên của các thành phần giao diện. Vì vậy, tên trường, nút và liên kết cần cho biết thành phần đó là gì hoặc sẽ thực hiện hành động nào.
Ví dụ, nếu một màn hình có nhiều thao tác gửi, nhãn “Gửi” không đủ để phân biệt. “Gửi dữ liệu đăng ký” hoặc “Gửi yêu cầu phê duyệt” cho người dùng biết kết quả dự kiến trước khi kích hoạt nút.
Với hình ảnh truyền tải thông tin, văn bản thay thế nên diễn đạt ngắn gọn thông tin hoặc mục đích của hình. Không nên chỉ lặp lại tên tệp, vì tên tệp thường không giúp người dùng hiểu nội dung. Sau khi thiết lập, hãy kiểm tra cách nhãn và văn bản thay thế được đọc trong giao diện thực tế.
2. Không truyền đạt trạng thái chỉ bằng màu sắc
Màu có thể hỗ trợ nhận biết, nhưng không nên là dấu hiệu duy nhất. Nếu lỗi chỉ được đánh dấu bằng chữ đỏ, người khó phân biệt màu hoặc người dùng trình đọc màn hình có thể không nhận ra điều gì cần xử lý.
Hãy kết hợp màu với văn bản và, khi phù hợp, biểu tượng. Chẳng hạn, trường nhập có thể vừa được đánh dấu vừa hiển thị thông báo “Vui lòng nhập tên” ngay gần trường liên quan. Cách trình bày này cho biết cả vị trí lẫn cách sửa lỗi.
Độ tương phản giữa chữ và nền cũng cần được kiểm tra. Mốc 4,5:1 có thể dùng làm điểm tham khảo khi kiểm tra văn bản, nhưng không nên áp một con số cho mọi thành phần và mọi tình huống. Khi đánh giá, hãy đối chiếu tiêu chí phù hợp trong hướng dẫn tổng quan về WCAG.
3. Hoàn thành tác vụ bằng bàn phím
Một số người dùng không sử dụng chuột và di chuyển qua giao diện bằng bàn phím. Tiêu điểm bàn phím là vị trí của thành phần đang sẵn sàng nhận thao tác. Người dùng cần nhìn hoặc nhận biết được tiêu điểm đang ở đâu và nó sẽ di chuyển tới đâu tiếp theo.
Trong ứng dụng Kintone, hãy thử thực hiện trọn vẹn một tác vụ chỉ bằng bàn phím:
- Dùng Tab và Shift+Tab để di chuyển qua các trường và nút.
- Kiểm tra xem thứ tự di chuyển có theo luồng đọc và luồng công việc hay không.
- Dùng Enter hoặc phím thích hợp để kích hoạt điều khiển.
- Nếu có hộp thoại, kiểm tra thao tác đóng bằng Esc và vị trí tiêu điểm sau khi đóng.
Nếu cần làm rõ khái niệm và hành vi khi di chuyển, bài viết về tiêu điểm trong khả năng tiếp cận web cung cấp thêm bối cảnh.
4. Tổ chức tiêu đề theo đúng cấp
Tiêu đề không chỉ tạo chữ lớn trên màn hình. Chúng mô tả quan hệ giữa các phần nội dung và giúp người dùng trình đọc màn hình di chuyển nhanh đến phần cần đọc.
Tiêu đề bài viết hoặc trang giữ vai trò cấp cao nhất. Các phần chính dùng h2, còn nội dung nằm trong một phần dùng h3. Không nên chọn cấp tiêu đề theo kích thước chữ hoặc bỏ qua cấp chỉ để đạt kiểu trình bày mong muốn.
Ví dụ, “Năm điểm cần kiểm tra” là một phần chính ở cấp h2; “Hoàn thành tác vụ bằng bàn phím” là một nội dung con ở cấp h3. Cấu trúc này cho thấy mối quan hệ giữa phần tổng và từng biện pháp.
5. Làm rõ nhãn, trạng thái bắt buộc và lỗi của biểu mẫu
Mỗi trường biểu mẫu cần có nhãn giúp người dùng biết phải nhập dữ liệu gì. Phần hướng dẫn nên bổ sung cho nhãn, thay vì thay thế nhãn bằng một câu chung chung.
Với trường họ và tên, có thể trình bày thông tin theo thứ tự sau:
- Nhãn: “Họ và tên”.
- Trạng thái: “Bắt buộc”, nếu người dùng phải nhập trường này.
- Hướng dẫn: mô tả định dạng hoặc phạm vi dữ liệu khi cần.
- Thông báo lỗi: “Vui lòng nhập họ và tên” nếu trường bị bỏ trống.
Thông báo lỗi cần đặt gần trường liên quan và nêu cách sửa. Chỉ đổi viền sang màu đỏ không giải thích được vấn đề, còn thông báo chung “Có lỗi xảy ra” không cho biết người dùng phải quay lại trường nào.
Quy trình kiểm tra sau khi chỉnh sửa
Kiểm tra định kỳ giúp phát hiện vấn đề khi ứng dụng hoặc phần tùy chỉnh thay đổi. Có thể bắt đầu bằng quy trình ngắn sau:
- Quét tự động: dùng WAVE hoặc axe Accessibility Checker để tìm các điểm cần xem xét như độ tương phản và sự hiện diện của văn bản thay thế.
- Thử bằng bàn phím: hoàn thành một tác vụ thực tế từ đầu đến cuối mà không dùng chuột.
- Nghe nội dung: kiểm tra một luồng chính bằng trình đọc màn hình để đánh giá tên điều khiển, thứ tự đọc và thông báo lỗi.
- Kiểm tra lại: lặp lại đúng tác vụ sau khi sửa để xác nhận vấn đề đã được xử lý và luồng thao tác vẫn liền mạch.
Công cụ tự động giúp xác định nơi cần chú ý, còn thử nghiệm theo tác vụ giúp đánh giá cách các thành phần hoạt động cùng nhau. Việc kết hợp hai cách kiểm tra cho nhóm phát triển một danh sách sửa lỗi cụ thể hơn.
Bắt đầu từ một luồng công việc quan trọng
Không nhất thiết phải kiểm tra toàn bộ ứng dụng trong một lần. Có thể chọn một luồng thường dùng, chẳng hạn nhập bản ghi, gửi yêu cầu phê duyệt hoặc xử lý lỗi biểu mẫu, rồi rà soát lần lượt nhãn, màu sắc, bàn phím, tiêu đề và thông báo.
Sau khi hoàn thành một luồng, hãy ghi lại các quy tắc đã áp dụng để dùng lại cho màn hình khác. Cách làm này biến khả năng tiếp cận thành tiêu chí kiểm tra cụ thể trong quá trình xây dựng và vận hành ứng dụng Kintone.
Nếu cần tham khảo một giải pháp hỗ trợ khả năng tiếp cận trên trang web, có thể xem UUU Web Accessibility Widget Tool. Công cụ hỗ trợ không thay thế việc kiểm tra nội dung, cấu trúc và thao tác của ứng dụng, vì vậy vẫn cần rà soát các điểm nêu trong bài.