“Khả năng nhận biết” trong JIS X 8341-3:2016: Tiêu chí 1.3.1–1.3.3

JIS X 8341-3:2016 là tiêu chuẩn quy định các yêu cầu về khả năng tiếp cận của nội dung web. Trong nguyên tắc “Khả năng nhận biết”, nhóm 1.3 “Có thể thích ứng” yêu cầu thông tin vẫn giữ được cấu trúc, thứ tự và ý nghĩa khi cách trình bày thay đổi hoặc khi người dùng tiếp nhận nội dung bằng công nghệ hỗ trợ.

Ba tiêu chí được đề cập trong bài viết là 1.3.1 “Thông tin và các mối quan hệ”, 1.3.2 “Thứ tự có ý nghĩa” và 1.3.3 “Đặc điểm cảm giác”. Mỗi tiêu chí xử lý một vấn đề khác nhau, vì vậy cần kiểm tra riêng thay vì gộp chúng thành một yêu cầu chung.

Ba tiêu chí 1.3.1–1.3.3 yêu cầu gì?

1.3.1: Thông tin và các mối quan hệ

Tiêu chí 1.3.1 yêu cầu thông tin, cấu trúc và các mối quan hệ được thể hiện qua phần trình bày phải có thể được xác định bằng chương trình hoặc được mô tả bằng văn bản. “Có thể được xác định bằng chương trình” nghĩa là trình duyệt và công nghệ hỗ trợ có thể nhận ra vai trò hoặc quan hệ từ mã, thay vì phải suy đoán từ kích thước chữ, màu sắc hay vị trí trên màn hình.

Điều này đặc biệt quan trọng với người dùng trình đọc màn hình. Nếu một dòng chỉ được làm to và in đậm bằng CSS nhưng không được đánh dấu là tiêu đề, phần mềm có thể đọc dòng đó như một đoạn văn thông thường và không đưa nó vào danh sách tiêu đề.

Cách triển khai

• Tiêu đề: dùng các phần tử <h1> đến <h6> theo cấp bậc nội dung. Không chọn cấp tiêu đề chỉ để đạt kích thước chữ mong muốn.
• Danh sách: dùng <ul>, <ol> hoặc <dl> khi các mục thực sự tạo thành một danh sách. Ký tự đầu dòng được gõ thủ công không tự tạo ra quan hệ danh sách trong mã.
• Bảng dữ liệu: dùng <th> cho ô tiêu đề và <td> cho ô dữ liệu. Thuộc tính scope, hoặc headers khi cấu trúc phức tạp hơn, giúp làm rõ ô tiêu đề nào áp dụng cho ô dữ liệu nào.
• Biểu mẫu: cung cấp nhãn rõ nghĩa và liên kết <label> với trường nhập liệu bằng thuộc tính for và id tương ứng.
• Vùng và thành phần giao diện: ưu tiên phần tử HTML có ngữ nghĩa. Khi HTML không thể hiện đủ vai trò hoặc mối quan hệ, WAI-ARIA có thể bổ sung thông tin cần thiết cho công nghệ hỗ trợ.

Ví dụ dễ nhầm

Một biểu mẫu đặt chữ “Bắt buộc” màu đỏ cạnh một số trường. Nếu màu đỏ là dấu hiệu duy nhất, người không nhận biết được màu hoặc người nghe nội dung qua trình đọc màn hình có thể bỏ lỡ quan hệ này. Thêm chữ “Bắt buộc” vào nhãn và liên kết nhãn với trường nhập liệu giúp thông tin không còn phụ thuộc vào cách trình bày.

1.3.2: Thứ tự có ý nghĩa

Tiêu chí 1.3.2 áp dụng khi thứ tự trình bày ảnh hưởng đến ý nghĩa. Trong trường hợp đó, ít nhất một thứ tự đọc đúng phải có thể được xác định từ mã. Đây không phải là yêu cầu buộc mọi bố cục trực quan phải trùng hoàn toàn với thứ tự HTML; điều cần giữ là trình tự cần thiết để người đọc hiểu nội dung.

Ví dụ, một thẻ sản phẩm có thể được bố trí bằng CSS để giá xuất hiện bên cạnh tên sản phẩm. Nếu thứ tự trong mã lại khiến phần mô tả của sản phẩm tiếp theo được đọc xen giữa tên và giá, người nghe nội dung tuần tự có thể hiểu nhầm giá thuộc về sản phẩm nào. Cách sửa là sắp xếp các phần tử liên quan gần nhau theo một thứ tự đọc hợp lý, sau đó dùng CSS để trình bày.

Cách kiểm tra

• Đọc trang theo thứ tự xuất hiện của các phần tử trong mã HTML.
• Kiểm tra các bố cục nhiều cột, thẻ nội dung và thành phần được định vị lại bằng CSS.
• Xác nhận rằng tiêu đề, nội dung giải thích, nút thao tác và thông báo liên quan không bị tách sang một ngữ cảnh khác.

Thứ tự đọc và thứ tự di chuyển tiêu điểm bằng phím Tab có liên quan nhưng không đồng nhất. Tab chỉ đi qua các thành phần có thể nhận tiêu điểm, còn tiêu chí 1.3.2 xem xét thứ tự đọc của nội dung. Vì vậy, thứ tự tiêu điểm cần được kiểm tra riêng thay vì dùng nó làm phép kiểm duy nhất cho 1.3.2.

1.3.3: Đặc điểm cảm giác

Tiêu chí 1.3.3 yêu cầu hướng dẫn sử dụng hoặc hiểu nội dung không được chỉ dựa vào đặc điểm cảm giác như hình dạng, màu sắc, kích thước, vị trí trực quan, hướng hoặc âm thanh. Tiêu chí này không cấm sử dụng những dấu hiệu đó. Dấu hiệu trực quan hoặc âm thanh vẫn hữu ích, miễn là có thêm cách nhận biết không phụ thuộc vào giác quan tương ứng.

Cách viết hướng dẫn rõ nghĩa

• Thay “Nhấn nút màu đỏ” bằng “Nhấn nút ‘Xóa’ màu đỏ”. Tên nút cho biết chính xác thành phần cần thao tác.
• Thay “Xem hộp bên phải” bằng “Xem mục ‘Thông tin liên hệ’ ở bên phải”. Tiêu đề của mục vẫn có ý nghĩa khi bố cục đổi trên màn hình nhỏ.
• Khi dùng âm thanh cảnh báo, hiển thị đồng thời một thông báo bằng văn bản để người không nghe được âm thanh vẫn nhận biết tình trạng.
• Không dùng riêng biểu tượng để báo lỗi. Kết hợp biểu tượng với thông báo như “Lỗi: vui lòng nhập địa chỉ email”.

Nếu màu sắc được dùng để truyền đạt trạng thái, việc bổ sung nhãn văn bản hoặc biểu tượng có tên dễ hiểu giúp người dùng nhận được cùng một thông tin. Việc đánh giá màu sắc còn cần được thực hiện cùng tiêu chí riêng về sử dụng màu, không nên xem 1.3.3 là phép kiểm duy nhất.

Danh sách kiểm tra trước khi công bố

1. Kiểm tra cấp tiêu đề, danh sách, bảng dữ liệu và nhãn biểu mẫu trong mã HTML.
2. Đọc nội dung theo thứ tự trong mã để phát hiện đoạn bị đảo hoặc bị tách khỏi ngữ cảnh.
3. Tìm các chỉ dẫn như “bên phải”, “ở trên”, “nút tròn”, “màu đỏ” hoặc “khi nghe tiếng báo”.
4. Bổ sung tên, nhãn hoặc mô tả bằng văn bản cho từng chỉ dẫn đang phụ thuộc vào cảm giác.
5. Thử lại bằng công nghệ hỗ trợ phù hợp và bằng bàn phím, đồng thời ghi nhận thứ tự đọc và thứ tự tiêu điểm như hai nội dung kiểm tra riêng.

Kết luận

Ba tiêu chí 1.3.1–1.3.3 cùng hướng đến việc giữ nguyên ý nghĩa khi nội dung không được tiếp nhận theo cách trình bày trực quan ban đầu. 1.3.1 bảo toàn cấu trúc và các mối quan hệ, 1.3.2 bảo toàn thứ tự đọc có ý nghĩa, còn 1.3.3 giúp hướng dẫn không phụ thuộc vào một dấu hiệu cảm giác duy nhất. Phân biệt rõ ba phạm vi này giúp quá trình thiết kế và kiểm tra tránh bỏ sót hoặc kiểm tra trùng lặp.

Chúng tôi đã phát hành UUU Web Accessibility Widget Tool, công cụ giúp dễ dàng triển khai khả năng truy cập web. Nếu bạn quan tâm đến việc cải thiện khả năng truy cập, hãy xem thêm thông tin chi tiết.