Hướng dẫn tiếp cận Form: 8 ID kiểm tra Trusted Tester quan trọng nhất

Hướng dẫn dành cho nhà phát triển về nhãn, thay đổi ngữ cảnh, xử lý lỗi và phòng ngừa dựa trên quy trình tuân thủ Trusted Tester của DHS Section 508.

Bạn nghĩ rằng Truy cập bàn phím và Tiêu điểm (Focus) là một chủ đề lớn? Chà, phiên học thứ 4 của Nhóm nghiên cứu Trusted Tester Section 508 cũng vậy: Các biểu mẫu (Forms) bao gồm tổng cộng 8 ID kiểm tra. Form là nơi người dùng cung cấp dữ liệu cho chúng ta, và nơi các lỗi có thể chặn hoàn toàn hành trình của người dùng.

Bảng tóm tắt cho Form của bạn

Nhãn có nhiều lớp: Sự hiện diện trực quan (5.A.), chất lượng mô tả (5.B.), và sự liên kết lập trình (5.C.)
Thay đổi ngữ cảnh cần có cảnh báo: Hành vi không mong muốn gây mất phương hướng cho người dùng, nhưng các cảnh báo sẽ giúp những thay đổi đó trở nên chấp nhận được.
Lỗi cần cả nhận dạng và khắc phục: Biết rằng có gì đó sai chỉ là bước đầu tiên, người dùng cũng cần biết cách sửa lỗi.
Các đệ trình quan trọng đòi hỏi biện pháp bảo vệ: Các biểu mẫu pháp lý, tài chính và chỉnh sửa dữ liệu yêu cầu cơ chế xem lại trước khi gửi, tùy chọn để hoàn tác gửi hoặc trang phải gắn cờ lỗi và cho phép người dùng sửa trước khi gửi cuối cùng.

Một bảng tóm tắt cho tất cả các bước kiểm tra và đánh giá Trusted Tester cũng có sẵn trong Thư mục Tài nguyên (Resources Drive folder).

Ba trụ cột của Nhãn Form

Test IDs 5.A. - C bao gồm các nhãn form, chia thành 3 câu hỏi nhỏ hơn: Nhãn có hiển thị không? Nó có hợp lý không? Nó có lập trình đúng không?

Lưu ý rằng quy trình Trusted Tester được xây dựng dựa trên WCAG 2.0. Do đó, tôi đã bao gồm các so sánh giữa WCAG 2.0 và 2.2 trong mỗi phiên nhóm học. Đối với tất cả các tiêu chí thành công WCAG được trích dẫn liên quan đến ID kiểm tra form chủ đề 5, nội dung cũng như cấp độ đều không thay đổi giữa 2.0 và 2.2, do đó tôi chỉ liên kết đến 2.2.

5.A.: Nhãn được cung cấp (WCAG 3.3.2 Labels or Instructions)

Mọi trường form phải có nhãn hoặc hướng dẫn trực quan vẫn hiển thị, ngay cả khi trường nhận tiêu điểm. Vì vậy, văn bản giữ chỗ (placeholder text) biến mất khi tiêu điểm không được tính là nhãn. Tuy nhiên, tiêu đề bảng có thể được tính!

Lưu ý rằng bài kiểm tra này chỉ kiểm tra sự hiện diện, không phải độ chính xác. Đối với 5.A., chúng ta chỉ nhìn xem có nhãn ở đó không, chứ không xem nó có hợp lý hay không.

Văn bản giữ chỗ không phải là nhãn. Nếu nó biến mất khi nhận tiêu điểm, nó sẽ không đạt 5A.

5.B.: Nhãn mô tả (WCAG 2.4.6 Headings and Labels)

Nhãn phải mô tả đủ mục đích và yêu cầu dữ liệu của từng trường. Người dùng nên biết định dạng dữ liệu nào được mong đợi (định dạng số điện thoại, định dạng ngày tháng, v.v.), và chỉ báo trường bắt buộc phải rõ ràng. Cả hai trường hợp, làm rõ bằng văn bản cũng được chấp nhận. Nhãn nút phải mô tả rõ chức năng, và thông báo lỗi một mình không thể thay thế cho sự rõ ràng của nhãn ban đầu.

5.C.: Nhãn lập trình (WCAG 1.3.1 Info and Relationships, WCAG 4.1.2 Name, Role, Value)

Đây là nơi chúng ta đi xa hơn những gì hiển thị trên màn hình: Các thành phần form phải có các liên kết lập trình mà các công nghệ hỗ trợ có thể đọc được. Để xác định điều này, quy trình Trusted Tester sử dụng công cụ ANDI: Đầu ra của ANDI phải bao gồm tất cả các hướng dẫn và manh mối liên quan. Đối với mục đích kiểm tra khả năng truy cập web nói chung, bạn cũng có thể sử dụng các công cụ dành cho nhà phát triển của trình duyệt để kiểm tra nhãn. Tên có thể truy cập không cần khớp từng từ với nhãn trực quan, nhưng chúng vẫn phải đầy đủ.

Các nút radio và hộp kiểm phải được liên kết lập trình với các câu hỏi mà chúng dự định trả lời. Ngược lại, các tùy chọn thả xuống chính chúng không phải là một phần của mô tả trường form.

Trong nhóm nghiên cứu, ví dụ thất bại của chúng tôi là một form có nhiều hộp nhập số điện thoại (được định khoảng để bắt chước định dạng số điện thoại Mỹ là 3-3-4 chữ số) đều được đọc là "điện thoại" mà không phân biệt các đoạn cho mã khu vực (3 chữ số), tiền tố (3 chữ số) và số dòng (4 chữ số).

Quản lý thay đổi ngữ cảnh

2 ID kiểm tra tiếp theo xử lý những gì xảy ra khi người dùng tương tác với các thành phần form và đảm bảo họ không bao giờ bị bất ngờ bởi hành vi không mong muốn.

5.D.: Forms on Input (WCAG 3.2.2 On Input)

Thay đổi giá trị trường form không được kích hoạt thay đổi ngữ cảnh bất ngờ.

Đối với người thường xuyên của nhóm nghiên cứu tận tụy, điều này có vẻ quen thuộc! Chúng tôi có một bài kiểm tra rất giống nhau trong phiên cuối cùng: Truy cập bàn phím và Tiêu điểm, phần tiêu điểm. Khái niệm là giống nhau, chỉ khác tên ID kiểm tra và giới hạn ở các thành phần form thay vì mọi thành phần có thể truy cập bàn phím trên trang.

Người dùng phải được cảnh báo trước khi một form tự động gửi, cửa sổ mới mở, tiêu điểm chuyển đổi hoặc trang chuyển hướng. "Bất ngờ" là từ khóa ở đây: các thay đổi mong đợi có cảnh báo là chấp nhận được.

Ví dụ thất bại kinh điển từ nhóm nghiên cứu là lựa chọn nút radio cho năm sinh của chúng tôi ngay lập tức chuyển hướng đến một trang Wikipedia, mà không có cảnh báo.

5.E.: Forms Change Notification (WCAG 4.1.2 Name, Role, Value)

Người dùng phải được thông báo về bất kỳ thay đổi nào liên quan đến form trên cùng một trang.

Các phương thức thông báo đạt tiêu chuẩn:

Vùng live ARIA mà thông báo lỗi bật lên trong đó.
Hộp thoại có thể truy cập bằng bàn phím.
Di chuyển tiêu điểm đến nội dung đã thay đổi với mô tả đầy đủ.
Các thành phần giao diện cung cấp mô tả đầy đủ về thay đổi.

Ví dụ thất bại của chúng tôi: Một thông báo tình trạng vé xuất hiện mà không có vùng live, di chuyển tiêu điểm hoặc bất kỳ thông báo hộp thoại nào. Làm sao chúng ta biết được chương trình đã hết vé?

Sự xuất sắc trong xử lý lỗi

Ba ID kiểm tra cuối cùng đảm bảo lỗi không chỉ được phát hiện mà còn được truyền đạt và sửa chữa hiệu quả.

5.F.: Nhận dạng lỗi (WCAG 3.3.1 Error Identification)

Các lỗi được phát hiện tự động phải được xác định và mô tả bằng văn bản, không chỉ bằng màu sắc hoặc biểu tượng. Trường cụ thể bị lỗi phải được xác định, không chỉ là một thông báo mơ hồ "đầu vào không hợp lệ", hãy chính xác trường nào đang gây rắc rối.

Lỗi phổ biến: Thông báo lỗi chỉ bao gồm biểu tượng dấu "X" màu đỏ hoặc viền đỏ mà không có mô tả văn bản đi kèm. Chúng ta, với tư cách là các chuyên gia thiết kế và phát triển web, hãy thoát khỏi việc xử lý lỗi phụ thuộc vào giác quan nhé? Nó đã làm ảnh hưởng đến khả năng truy cập UI trong quá lâu.

Lưu ý rằng bài kiểm tra này không yêu cầu gợi ý sửa lỗi (đó là nội dung của 5.G.).

5.G.: Gợi ý lỗi (WCAG 3.3.3 Error Suggestion)

Chúng ta đã có lỗi. Bây giờ sao? Khi phát hiện lỗi, phải có hướng dẫn về cách sửa chúng. Cung cấp gợi ý về cách khắc phục lỗi, trừ khi chúng sẽ gây nguy hiểm cho bảo mật hoặc mục đích.

Làm sao nó có thể gây nguy hiểm cho bảo mật hoặc mục đích? Câu hỏi hay! Trong khi hầu hết các lỗi đều nằm ngoài "con đường hạnh phúc" (happy path) của chúng ta, trong một số kịch bản, chúng có thể là một phần của trò chơi. Ví dụ: nếu bạn đang chơi một trò chơi đoán.

Các bài kiểm tra và bài thi trực tuyến cũng là ngoại lệ vì các gợi ý lỗi tự động ở đây sẽ đi ngược lại toàn bộ khái niệm kiểm tra kiến thức của bạn!

Ví dụ đạt tiêu chuẩn: Yêu cầu mật khẩu được hiển thị ngay từ đầu, hoặc chỉ định các phạm vi chấp nhận được cho đầu vào (ví dụ: "nhập một số từ 1 đến 10" cho khảo sát hài lòng của khách hàng).

Ví dụ thất bại: Một form yêu cầu nhập kinh nghiệm làm việc và chỉ trả lời "Lỗi: 5 không thể chấp nhận" mà không chỉ định đơn vị hoặc định dạng nào được mong đợi.

5.H.: Phòng ngừa lỗi (WCAG 3.3.4 Error Prevention)

Các giao dịch quan trọng (chúng ta đang nói về bối cảnh pháp lý, tài chính và chỉnh sửa dữ liệu cụ thể) phải cho phép xem xét, xác nhận hoặc hoàn tác.

Ba phương pháp chấp nhận được là: