Yêu cầu ít hơn và giải thích lý do
Bắt đầu từ nhiệm vụ trực tiếp của người dùng, sau đó chỉ yêu cầu dữ liệu cần thiết để hoàn thành nhiệm vụ đó. Ví dụ: bản tin chỉ cần email; giao hàng cần địa chỉ. Không tự động yêu cầu ngày sinh, chức danh công việc hoặc sự đồng ý tiếp thị gộp chung. Hoãn các câu hỏi bổ sung trừ khi chúng cần thiết cho kết quả đầu tiên.
Trên biểu mẫu, nêu ai sẽ nhận dữ liệu và mục đích sử dụng, kèm liên kết dễ thấy tới thông báo quyền riêng tư đầy đủ. Các tổ chức thuộc phạm vi UK GDPR có nghĩa vụ minh bạch bao gồm mục đích và thời hạn lưu trữ, cùng các thông tin khác phụ thuộc vào ngữ cảnh. Đây không phải là tư vấn pháp lý toàn cầu: hãy có người đánh giá phù hợp phê duyệt việc thu thập và nội dung thông báo cho thị trường của bạn.
Nêu rõ trường bắt buộc và định dạng bất thường trước khi gửi; chỉ dấu sao hoặc chỉ dùng màu không đủ.
Giữ sự đồng ý tiếp thị tùy chọn tách biệt khỏi hành động cần thiết để gửi đơn hàng, yêu cầu hoặc tác vụ tài khoản.
Để nhãn và điều khiển gốc làm việc giúp bạn
Mỗi trường, checkbox, nhóm radio, select và nút đều cần một tên mô tả mục đích. Dùng nhãn hiển thị liên kết với điều khiển, thông thường bằng một label element có thuộc tính for khớp với id của input. Điều này mở rộng vùng kích hoạt và cho phép công nghệ hỗ trợ nhận diện điều khiển chính xác. Đặt nhãn gần input.
Văn bản gợi ý (hint text) không phải là tên trường. Đừng để nó là hướng dẫn duy nhất rồi biến mất khi gõ. Nếu ngữ cảnh trực quan khiến nhãn bị thừa, vẫn giữ tên truy cập được trong mã và kiểm tra tính truy cập. W3C lưu ý rằng văn bản title ít đáng tin cậy hơn khi thay thế nhãn chính.
Dùng email, tel, date, radio, checkbox hoặc select khi phù hợp thay vì mô phỏng bằng trường văn bản chung.
Dùng nhãn hành động như Create account hoặc Place order khi rõ ràng hơn chữ Submit.
Xác thực để sửa lỗi, rồi thực thi quy tắc trên máy chủ
Dùng ràng buộc gốc để kiểm tra ổn định: kiểu input phù hợp, required, length, range và pattern thích hợp. Cho ví dụ định dạng hữu ích trước khi nó trở thành lỗi. Kiểm tra phía khách cải thiện khả năng phục hồi nhưng không phải biên giới bảo mật. Yêu cầu có thể bỏ qua chúng, vì vậy máy chủ phải xác thực cú pháp và quy tắc nghiệp vụ trước khi xử lý dữ liệu.
Khi gửi thất bại, giữ các giá trị đã chấp nhận. Đặt một tóm tắt lỗi trước biểu mẫu, xác định từng trường, giải thích vấn đề và cách sửa, và liên kết tới nó. Lặp lại thông báo ngắn gọn cạnh trường. Liên kết thông báo với điều khiển, chỉ ra trạng thái không hợp lệ khi thích hợp, và chuyển tiêu điểm (focus) theo cách có thể dự đoán tới lỗi đầu tiên hoặc tóm tắt. Xác nhận thành công một cách rõ ràng.
Chỉ thực hiện xác thực trong khi gõ khi phản hồi ổn định và hữu ích, ví dụ kiểm tra tính khả dụng tên người dùng. Những thất bại về định dạng dễ xảy ra khi đang nhập thường tốt hơn khi kiểm tra sau khi rời focus khỏi trường hoặc khi gửi. Kiểm tra các thông điệp động với trình đọc màn hình; cập nhật trực tiếp có thể hữu ích nhưng liên tục làm gián đoạn là gây ma sát.
Trên máy chủ, định nghĩa ngày, tùy chọn, độ dài và định dạng được cho phép. Dùng denylist các ký tự đáng ngờ không phải là biện pháp kiểm soát chính đáng tin cậy.
Khi timeout hoặc gửi trùng lặp, thông báo xem yêu cầu có được nhận không và hướng dẫn bước tiếp theo an toàn.
Hỗ trợ tự điền của trình duyệt và nhập trên di động
Thêm các token autocomplete cụ thể mô tả dữ liệu: given-name, family-name, email, tel, shipping street-address, billing postal-code, username và new-password là các ví dụ phổ biến. Các token giúp trình duyệt và trình quản lý mật khẩu phân biệt các trường giống nhau. Autofill là trợ giúp chứ không phải cam kết; hành vi thay đổi và có thể phụ thuộc vào một biểu mẫu khả dụng, tên hoặc id và điều khiển gửi.
Dùng input type có thể hiển thị bàn phím di động phù hợp và cung cấp kiểm tra cơ bản của trình duyệt. Không chặn dán vào trường mật khẩu hoặc cản trở trình quản lý mật khẩu. Trình duyệt hiện đại có thể vẫn cung cấp điền thông tin đăng nhập khi autocomplete bị tắt trên biểu mẫu đăng nhập, vì vậy kiểm tra các hành trình thực tế trong các trình duyệt mà khán giả của bạn sử dụng.
Khi có cả thanh toán và giao hàng trên một trang, dùng các grouping token tương ứng để các trường giống nhau không bị nhầm lẫn.
Đảm bảo nhãn vẫn hiển thị và script không hiểu nhầm giá trị do trình duyệt điền là trường trống.
Đảm bảo có thể hoàn thành bằng bàn phím
Người dùng phải có thể hoàn thành biểu mẫu mà không cần con trỏ. Điều khiển bằng bàn phím cũng hỗ trợ nhập bằng giọng nói và các công nghệ hỗ trợ khác tạo phím bấm. Dùng Tab từ trước biểu mẫu đến sau nó: thứ tự nên theo nhiệm vụ, focus phải hiển thị, và không điều khiển, hộp thoại, chọn ngày, liên kết lỗi hay bảng trợ giúp nào được phép giữ chặt focus.
Các điều khiển gốc cung cấp phần lớn hành vi này. Dropdown tùy chỉnh, ngày đượcmask, tra cứu địa chỉ, phương án thay thế CAPTCHA và modal cần hành vi bàn phím có chủ đích, quản lý focus và tên truy cập được. Nếu một thành phần tùy chỉnh không thể đạt tới trải nghiệm tương đương với lựa chọn gốc, hãy đơn giản hóa nó. Kiểm tra ở độ rộng hẹp và mức thu phóng cao.
Dùng Tab, Shift+Tab, Enter, Space, Escape và các phím mũi tên liên quan để hoàn thành các luồng bình thường, lỗi và có điều kiện.
Phát hành cải tiến với ràng buộc và khả năng khôi phục
Trước khi thay đổi một biểu mẫu có giá trị, ghi lại đường cơ sở cho số lần gửi xác nhận, lỗi theo loại trường, lỗi kỹ thuật và thời gian hoàn thành. Không thu thập giá trị thô hoặc phát lại dữ liệu nhạy cảm chỉ để cải thiện chỉ số. Ghép các tín hiệu tổng hợp với các kiểm tra truy cập và bàn phím, vì một tỷ lệ đơn lẻ hiếm khi giải thích vì sao người dùng gặp khó khăn.
Phát hành một thay đổi mang tính vật chất mỗi lần khi có thể, như cách diễn đạt nhãn, loại bỏ trường tùy chọn hoặc cải thiện phục hồi. Xác định rào chắn (guardrails) trước khi thử: lỗi ủy quyền thanh toán, liên hệ hỗ trợ hoặc suy giảm khả năng truy cập có thể là các chỉ số liên quan. Kiểm tra cấu hình sản xuất với tài khoản an toàn và môi trường kiểm thử thanh toán. Script thanh toán, xử lý dữ liệu và tuân thủ cần đánh giá bảo mật, thanh toán và pháp lý có chuyên môn; bài viết này không chứng nhận tuân thủ.
SIU làm cho việc này an toàn hơn thông qua một kiểm tra trước khi ra mắt (launch preflight): xác nhận phụ thuộc, hành vi phía khách, phản hồi phía máy chủ, xác nhận và khôi phục. Đây là khắc phục chủ động, không thay thế quy trình giám sát trạng thái trực tiếp hoặc phát hiện sự cố của đội bạn.
Dùng giá trị thiếu và sai định dạng, phiên hết hạn, phản hồi chậm, tra cứu thất bại và nhấp đôi vào hành động cuối cùng.
Chuẩn bị cấu hình trước đó, một chủ sở hữu và bước triển khai có thể đảo ngược sẵn sàng trước khi mức độ phơi bày tăng.