Dễ hiểu

Trong trường hợp nội dung của một trang bao gồm các từ hoặc cụm từ thuộc ngôn ngữ khác với ngôn ngữ chính, hãy dùng thuộc tính lang trên một phần tử bao bọc thuật ngữ đó (ví dụ: một <span> nếu không có phần tử ngữ nghĩa phù hợp) để đặt ngôn ngữ thích hợp cho nó.

Bạn không cần đặt ngôn ngữ khác cho các từ hoặc cụm từ giống nhau bất kể ngôn ngữ nào (ví dụ: tên riêng, thuật ngữ kỹ thuật không thuộc về một ngôn ngữ cụ thể).

Khi dùng chữ viết tắt, bạn nên cung cấp dạng đầy đủ của nó, hoặc định nghĩa nếu cần.

Phần tử <abbr> thường được xem là cách ưu tiên để cung cấp dạng mở rộng cho một chữ viết tắt — nó nhận một thuộc tính title chứa dạng mở rộng, và nội dung này xuất hiện khi chữ viết tắt được rê chuột qua. Tuy nhiên, nội dung title không thể truy cập bằng bàn phím, và cũng không được trình đọc màn hình đọc ra một cách đáng tin cậy. Cách tốt hơn là lại cung cấp liên kết tới các trang bảng thuật ngữ chứa phần giải thích và dạng mở rộng của chữ viết tắt, hoặc ít nhất đưa chúng vào văn bản xung quanh trong ngữ cảnh.

Nếu nội dung văn bản yêu cầu trình độ đọc cao hơn mức trung học cơ sở (thường là trẻ em khoảng 11-14 tuổi), hãy cung cấp tài liệu giải thích bổ sung để hỗ trợ những người không đọc được nó, hoặc cung cấp một phiên bản thay thế được viết ở mức trung học cơ sở.

Điều này không có nghĩa là mọi chủ đề phải được mọi người hiểu, mà là phong cách viết nên có thể tiếp cận được với mọi người. Tốt hơn là chỉ viết tất cả nội dung ở mức trung học cơ sở, kể cả tài liệu kỹ thuật như hướng dẫn lập trình, trừ khi có lý do tốt để không làm vậy (ví dụ: một phong cách khác để tạo hiệu ứng thơ ca), hoặc chúng phải được viết theo một phong cách nghiêm ngặt (ví dụ: đặc tả W3C).

Nên cung cấp một cơ chế để người dùng có thể tiếp cận cách phát âm của các từ khi điều đó cần thiết để hiểu đầy đủ nội dung.

Phần tử HTML <audio> có thể được dùng để tạo một điều khiển cho phép người đọc phát lại một tệp âm thanh chứa cách phát âm đúng, và cũng hợp lý khi thêm một hướng dẫn phát âm dạng văn bản sau các từ khó, theo cách bạn thấy trong các mục từ điển.

Khi một điều khiển hoặc tính năng trang khác nhận focus, nó không nên thay đổi ngữ cảnh theo cách có thể làm người dùng bối rối hoặc mất phương hướng.

Đây là vấn đề của thiết kế hợp lý - người dùng không muốn giao diện gây bất ngờ; họ muốn mọi thứ trực quan và hoạt động như mong đợi. Ví dụ, việc focus vào một tùy chọn menu điều hướng không nên thay đổi trang đang hiển thị - nó nên được kích hoạt trước khi hiển thị thay đổi.

Khi dữ liệu được nhập vào một điều khiển, hoặc một cài đặt thay đổi, ngữ cảnh không nên thay đổi một cách bất ngờ. Người dùng nên được cảnh báo/nhắc nhở về thay đổi sắp xảy ra trước khi nó diễn ra.

Một lần nữa, nên áp dụng thiết kế hợp lý. Ví dụ, nếu nhấn một nút khiến ứng dụng thoát khỏi chế độ xem hiện tại, người dùng nên được yêu cầu xác nhận hành động này, lưu công việc của họ nếu phù hợp, v.v.

Kiểu dáng và vị trí của menu/điều khiển điều hướng nên nhất quán giữa các trang hoặc chế độ xem khác nhau của một trang web, và các mục hiện có nên xuất hiện theo cùng một thứ tự, ngay cả khi ví dụ có thêm mục mới. Nếu người dùng đã khởi xướng một thay đổi, chẳng hạn chọn một bảng màu khác hoặc vị trí khác cho điều hướng, lựa chọn của họ nên được tôn trọng trên tất cả các trang.

Một lần nữa, thiết kế hợp lý - hãy làm cho các điều khiển điều hướng giống nhau trên tất cả các trang hoặc chế độ xem.

Các điều khiển hoặc thành phần có cùng chức năng nên được xác định theo cùng một cách trên các trang hoặc chế độ xem khác nhau. Ví dụ, một bộ chuyển đổi tiền tệ xuất hiện trên mọi trang của một trang web du lịch thế giới nên hoàn toàn giống nhau, cả về ngữ nghĩa lẫn nhãn.

Một lần nữa, thiết kế hợp lý!

Các thay đổi ngữ cảnh có thể gây bối rối hoặc làm người dùng mất phương hướng chỉ nên xảy ra khi người dùng yêu cầu, HOẶC người dùng phải có thể tắt chúng.

Nếu bạn cần một thứ gì đó thay đổi đáng kể chế độ xem hiện tại (ví dụ: nội dung hoặc điều khiển), hãy để người dùng quyết định khi nào họ muốn thay đổi đó xảy ra (ví dụ: trang nào để hiển thị, khi nào chuyển sang ảnh tiếp theo trong bộ sưu tập...)

Nếu bạn cần một thứ như carousel trên trang, hãy cung cấp tùy chọn để dừng việc tự động chuyển trang. Tốt hơn là tránh chức năng như vậy nếu có thể.

Các trang web có cơ chế trợ giúp, bao gồm tùy chọn tự trợ giúp và thông tin liên hệ con người, nếu được lặp lại trên nhiều trang web, cần đặt các cơ chế đó theo cùng một thứ tự trên tất cả các trang, trừ khi thay đổi được người dùng khởi xướng.

Hãy xem tài liệu consistent help cho tiêu chuẩn này để biết thêm.

Khi người dùng đang điền form hoặc chọn giữa các tùy chọn, mọi lỗi được phát hiện nên được báo rõ cho người dùng, cùng với điều khiển form liên quan đến lỗi đó.

Nên triển khai phát hiện và xử lý lỗi phía client, thông qua các tính năng xác thực form HTML, và/hoặc JavaScript, tùy theo điều gì phù hợp nhất cho tình huống của bạn. Khi phát hiện lỗi, nên hiển thị một thông báo lỗi trực quan bên cạnh input form bị lỗi để giúp người dùng sửa dữ liệu nhập. Với người dùng trình đọc màn hình, bạn có thể dùng vùng sống aria để cảnh báo người dùng về thay đổi trên trang.

Cần cung cấp hướng dẫn rõ ràng khi yêu cầu nhập dữ liệu. Khi cần một hướng dẫn hoặc lời nhắc ngắn, bạn có thể dùng các phần tử <label> cho các input đơn như tên hoặc tuổi, hoặc kết hợp <label> và <fieldset>/<legend> cho các input nhiều phần đi cùng nhau (như các thành phần của ngày sinh hoặc địa chỉ bưu điện).

Khi cần giải thích phức tạp hơn, bạn luôn có thể thêm các đoạn văn giải thích, hoặc có lẽ bạn cần làm cho form của mình trực quan hơn.

• Dùng nhãn văn bản có ý nghĩa
• Cách cấu trúc form HTML
• Nhãn và tên văn bản

Khi phát hiện lỗi và biết được gợi ý sửa lỗi, hãy cung cấp chúng cho người dùng (ví dụ: gợi ý lựa chọn thay thế khi người dùng chọn tên người dùng và đã chọn một tên đã có người khác dùng), trừ khi làm vậy sẽ gây ra vấn đề bảo mật (ví dụ: khi nhập mật khẩu) hoặc vấn đề ngữ cảnh (ví dụ: họ đang cố trả lời câu hỏi trong ứng dụng quiz).

Trong những trường hợp như vậy, khi phù hợp, bạn có thể sẽ dùng kết hợp JavaScript và chức năng phía server để kiểm tra xem dữ liệu nhập có đúng không, và nếu không, có thể đưa ra những gợi ý khả thi nào cho người dùng. Những gợi ý đó nên được hiển thị một cách hữu ích trong ngữ cảnh, giống như các thông báo lỗi (xem 3.3.1).

Trong trường hợp các form liên quan đến việc nhập dữ liệu nhạy cảm (như thỏa thuận pháp lý, giao dịch thương mại điện tử, hoặc dữ liệu cá nhân), ít nhất một trong các điều sau phải đúng:

• Việc gửi biểu mẫu có thể đảo ngược.
• Dữ liệu được kiểm tra lỗi, và người dùng được cho cơ hội sửa chúng.
• Có sẵn một cơ chế để xác nhận và sửa thông tin trước khi gửi cuối cùng.

Có thể đảo ngược — đối với bất kỳ chế độ xem nào có thể nhập dữ liệu, hãy cung cấp một chế độ xem tương đương cho phép bạn chỉnh sửa hoặc thậm chí xóa một mục nhập, nếu phù hợp (ví dụ, xem khung web Django).

Kiểm tra dữ liệu — như đã nêu ở 3.3.1, nên dùng kết hợp xác thực phía client và phía server để phát hiện lỗi và hiển thị thông báo hữu ích cho người dùng để họ sửa dữ liệu nhập.

Xác nhận và sửa — khi phù hợp, sau khi điền một loạt trường form để thực hiện một tác vụ (như mua sản phẩm), người dùng nên được hiển thị một màn hình xác nhận nơi họ có thể xem lại dữ liệu nhập và sửa bất cứ gì trông không đúng. Mẫu này thường được dùng trên các site thương mại điện tử như Amazon.