Modal website: nghiệm thu bàn phím và điểm quay lại

Một hộp thoại tư vấn có thể nhìn đẹp trên ảnh chụp nhưng làm người dùng bàn phím mất vị trí sau khi đóng. Nút mở ở đầu trang, form hiện giữa màn hình, rồi focus biến mất hoặc nhảy về một chỗ không liên quan. Người dùng phải lần lại nhiều thành phần để tiếp tục công việc vốn chỉ cần vài bước.

Nghiệm thu modal website cần đi theo cả hành trình mở, thao tác, đóng và quay lại công việc. Bài này dùng một hộp thoại tư vấn giả định để làm rõ các quyết định về focus và bàn phím. Đây là hướng dẫn thiết kế phép kiểm, không phải chứng nhận website đáp ứng toàn bộ tiêu chuẩn tiếp cận hoặc kết quả thử với công nghệ hỗ trợ.

Đi hết hành trình trước khi đánh giá hiệu ứng mở

Giả sử trang dịch vụ có nút yêu cầu tư vấn mở một form trong modal. Người dùng đang đọc nội dung và muốn hỏi một câu, sau đó quay về đúng phần vừa xem. Cần xác định modal có thật sự cần thiết hay một trang riêng phù hợp hơn. Nếu quyết định dùng modal, đội thiết kế phải chịu trách nhiệm cho đường điều hướng bên trong nó.

Dialog Modal Pattern của W3C APG mô tả việc focus vào trong khi mở, giữ vòng Tab trong hộp thoại và trả focus theo luồng khi đóng. Đây là hành vi chức năng, không phải một lớp trang trí thêm sau khi hoàn thành giao diện.

Thử hành trình bằng bàn phím từ nút mở. Sau khi kích hoạt, người kiểm cần biết mình đang ở đâu và có thể đi tới các điều khiển cần thiết. Nếu vẫn Tab tới menu phía sau trong khi màn hình đang hiển thị một modal chặn nội dung, lời hứa tương tác của hai lớp đã không thống nhất.

Đừng bắt đầu bằng việc thêm một thuộc tính ARIA rồi coi công việc xong. Tên hoặc trạng thái được khai báo cần khớp cách giao diện thật hoạt động. APG lưu ý về việc đánh dấu modal khi phần nội dung ngoài nó không thực sự bị ngăn tương tác. Một khai báo không đúng có thể làm trải nghiệm công nghệ hỗ trợ khó hơn.

Đội sản phẩm nên mô tả mục đích hộp thoại bằng một câu: người dùng cần làm gì trong đó và sẽ tiếp tục ở đâu sau khi kết thúc? Nếu câu trả lời không rõ, rất khó chọn điểm focus đầu, nút đóng và vị trí quay lại hợp lý. Câu hỏi này cũng giúp tránh đưa quá nhiều công việc không liên quan vào một modal.

Focus đầu tiên phụ thuộc nội dung cần đọc

Không phải modal nào cũng nên đặt focus vào ô nhập đầu tiên. Với form ngắn và nhãn rõ, đó có thể là lựa chọn phù hợp. Nhưng nếu có hướng dẫn quan trọng, nội dung dài hoặc cấu trúc người dùng cần đọc trước, việc nhảy thẳng xuống một điều khiển có thể bỏ qua bối cảnh.

Trong ví dụ tư vấn, giả sử trước form có đoạn giải thích loại thông tin được yêu cầu và cách phản hồi. Đội thiết kế cần cân nhắc liệu người dùng bàn phím có nhận được phần đó trước khi nhập hay không. Chọn một phần tử tĩnh ở đầu để nhận focus là một cách được APG đề cập trong những tình huống nội dung cần đọc theo cấu trúc.

Tuy nhiên, không biến khuyến nghị thành công thức cứng. Một modal chỉ có câu xác nhận ngắn khác một hộp có bảng hoặc nhiều đoạn. Cần chọn theo công việc, độ dài và cấu trúc thực tế. Đừng thêm nhiều điểm dừng Tab không cần thiết chỉ để trông như đã hỗ trợ bàn phím.

Tiêu đề nhìn thấy và tên được công nghệ hỗ trợ nhận biết cần thống nhất. Một hộp thoại không nên có nhãn kỹ thuật khó hiểu trong khi người dùng nhìn thấy lời mời tư vấn khác. Khi có nội dung mô tả, cách gắn mô tả cũng cần phù hợp; không gom cả bảng hoặc nhiều đoạn thành một chuỗi dài khó theo dõi.

Bảng này là cách đặt câu hỏi để đội triển khai ra quyết định, không phải yêu cầu mọi modal có ba kiểu xử lý. Hộp tư vấn thông thường cũng không nên bị biến thành cảnh báo nghiêm trọng chỉ vì một thành phần giao diện có sẵn kiểu đó.

Đóng xong phải có nơi tiếp tục hợp lý

Khi người dùng đóng modal mà chưa gửi, điểm quay lại thường là nút đã mở nó. Điều này giúp họ tiếp tục đọc trang thay vì bắt đầu lại từ menu. Cần kiểm cả nút đóng nhìn thấy và phím Escape trong hành vi đã thiết kế.

APG có nêu ngoại lệ khi nút mở không còn tồn tại hoặc một bước tiếp theo hợp lý hơn xuất hiện sau tác vụ. Vì vậy, đừng viết một quy tắc luôn trả về cùng một selector mà không xét thay đổi của giao diện. Nếu modal thêm một dòng mới vào bảng, nơi tiếp tục có thể là dòng vừa tạo theo thiết kế workflow.

Với ví dụ tư vấn, nếu gửi thành công chỉ đóng hộp rồi thay nút bằng thông báo, cần chọn điểm nhận focus sau đó. Người dùng phải biết việc gì đã xảy ra và có thể tiếp tục theo cách được hỗ trợ. Bài này không khẳng định bấm gửi đồng nghĩa yêu cầu đã được hệ thống phía sau tiếp nhận; thông báo thành công cần bằng chứng riêng của luồng form.

Đừng dùng chuyển focus để che một lỗi lưu dữ liệu. Nếu server trả lỗi trường, người dùng cần được đưa tới thông tin sửa phù hợp bên trong hộp thoại. Nếu lỗi hệ thống, thông báo cần nói rõ bước tiếp theo mà không bắt họ nhập lại mọi thứ khi thiết kế có thể giữ dữ liệu trong phạm vi được phép.

Đối với form có dữ liệu riêng tư, việc đóng hay mở lại có giữ dữ liệu hay không cần được thống nhất. Một lựa chọn tiện dụng trên máy cá nhân có thể không phù hợp ở máy dùng chung. Không tự chọn lưu vào trình duyệt chỉ để bản demo ít mất dữ liệu; đây là phần của hợp đồng xử lý thông tin.

Modal cũng cần một cách đóng nhìn thấy, không chỉ dựa vào click vùng tối hoặc phím tắt. Vị trí và tên nút nên rõ, đặc biệt khi form dài trên mobile. Nếu người dùng không thể thoát bằng đường có thể nhận biết, họ đang bị giữ lại trong một luồng thiếu hoàn chỉnh.

Bộ kiểm cần quan sát cả đường thuận và đường quay lại

Chọn một bản xem trước có nội dung giả và không gửi thông báo thật. Ghi trình duyệt, viewport và phương thức kiểm. Bắt đầu từ trước nút mở để quan sát đường Tab bình thường; không click thẳng vào form rồi tuyên bố đã kiểm hành trình bàn phím.

Sau mở, đi qua các điều khiển theo thứ tự, thử quay ngược bằng Shift+Tab và kiểm nơi focus có thể tới. Quan sát dấu focus thật, không chỉ suy ra từ phần tử đang có màu khác. Nếu nội dung cuộn, xem người dùng có bị mất đầu hướng dẫn hay điểm đang thao tác không.

Đóng mà chưa gửi, rồi mở lại. Thử thêm nhánh lỗi trường bằng dữ liệu giả theo quy tắc đã duyệt. Nếu được phép kiểm gửi thành công trong môi trường cô lập, xác nhận thông báo và điểm tiếp tục cùng nhau. Mỗi kết quả chỉ áp dụng cho luồng và cấu hình đã thử.

Kiểm mobile và desktop vì chiều cao, cuộn và vị trí nút đóng có thể khác. Đừng đổi font hoặc thu nhỏ hộp chỉ để một ảnh chụp vừa màn hình. Vấn đề cần được giải quyết trong quy tắc giao diện chung và hành vi nội dung, sau đó thử lại đúng hành trình.

Thử bàn phím không thay toàn bộ đánh giá với công nghệ hỗ trợ, và dùng một pattern đúng chưa chứng minh cả website dễ tiếp cận. Báo cáo nên nêu rõ đã kiểm gì, chưa kiểm gì và lỗi nào còn ảnh hưởng. Không dùng một điểm công cụ tự động làm kết luận duy nhất về khả năng hoàn thành form.

So với các xu hướng giao diện website, đây là một lớp nghiệm thu khác: người dùng phải làm xong công việc và tiếp tục đúng chỗ. Nếu cần Onter rà một modal đang dùng trong hành trình tư vấn, hãy mô tả nút mở, các nhánh form và kết quả mong đợi. Nhận tư vấn & báo giá. Giá: Liên hệ.