Thứ tự phím Tab: kiểm tra và sửa mà không cần lập trình viên

Thứ tự Tab bị hỏng không chỉ trông lộn xộn, nó có thể chặn ai đó không dùng được website của bạn chút nào. Nhấn Tab nên di chuyển tiêu điểm qua mọi phần tử tương tác theo một thứ tự hợp lý, và bất cứ thứ gì tiêu điểm không bao giờ tới được thì người chỉ dùng bàn phím không thể kích hoạt. Bạn có thể tự kiểm tra website của mình trong khoảng 60 giây chỉ với phím Tab.

Những điểm chính

• Thứ tự Tab là chuỗi mà tiêu điểm di chuyển qua khi ai đó nhấn phím Tab, không dùng chuột. Shift+Tab di chuyển ngược lại qua cùng chuỗi đó.
• Đây không phải mối quan tâm ngách. Bất kỳ ai không thể dùng chuột đáng tin cậy, do run tay, liệt, chấn thương do vận động lặp lại, hoặc chấn thương tạm thời, đều phụ thuộc hoàn toàn vào điều hướng bàn phím để dùng website.
• Có hai kiểu lỗi khác biệt, và một kiểu tệ hơn nhiều. Thứ tự gây rối thì khó chịu. Một phần tử tương tác mà Tab không bao giờ tới được là một sự chặn cứng, không phải phàn nàn về tính dễ dùng.
• Bạn có thể tự kiểm tra ngay bây giờ, không cần lập trình viên hay công cụ đặc biệt. Nhấp vào thanh địa chỉ, rồi nhấn Tab liên tục và xem tiêu điểm đi đâu.
• axe-core tự động sửa một phiên bản cụ thể của vấn đề này với độ tin cậy cao, giá trị tabindex dương, và đánh dấu vài vấn đề liên quan thực sự cần con người phán đoán, vì đánh giá thứ tự có "hợp lý" không đòi hỏi hiểu trang.

Thứ tự Tab thực sự là gì

Nhấn Tab chuyển tiêu điểm bàn phím sang phần tử tương tác tiếp theo trên trang, liên kết, nút, trường biểu mẫu, mọi thứ người dùng có thể thao tác. Shift+Tab di chuyển ngược lại. Mặc định, chuỗi đó theo thứ tự các phần tử xuất hiện trong HTML bên dưới, thường là cùng thứ tự mà người nhìn thấy được sẽ gặp khi đọc từ trên xuống dưới.

Một chỉ báo tiêu điểm nhìn thấy được, thường là đường viền quanh thứ đang có tiêu điểm, cho người dùng bàn phím biết họ đang ở đâu. Thiếu nó, hoặc thiếu thứ tự hợp lý phía sau, điều hướng bàn phím không còn dùng được, dù không có gì trông hỏng với người dùng chuột.

Vì sao điều này quan trọng

Ai đó không thể dùng chuột, do run tay, liệt, thiếu chi, Parkinson, ALS, hay điều bình thường như gãy cổ tay, vẫn cần thanh toán, điền biểu mẫu và điều hướng menu. Bàn phím là cách họ làm mọi việc đó. Người dùng trình đọc màn hình cũng nhấn Tab qua các phần tử tương tác như một trong vài cách họ di chuyển trên trang, nên điều này chồng lấn với, nhưng không đồng nhất với, khả năng tiếp cận cho trình đọc màn hình.

Thứ tự Tab gây rối là vấn đề dễ dùng thực sự: tiêu điểm nhảy từ liên kết đầu trang thẳng xuống nút chân trang, bỏ qua toàn bộ phần giữa trang, buộc người ta phải đoán và quay lại. Nhưng rốt cuộc vẫn điều hướng được. Một phần tử tương tác mà tiêu điểm không bao giờ tới là khác về bản chất, không phải về mức độ: một nút mà người dùng bàn phím thực sự không thể Tab tới là nút họ không thể nhấn, hết, không có cách nào khác từ riêng bàn phím.

Bài kiểm tra phím Tab trong 60 giây

1. Trước tiên nhấp vào một chỗ trung tính, như thanh địa chỉ của trình duyệt, để bắt đầu từ vị trí đã biết thay vì nơi tiêu điểm tình cờ rơi vào.
2. Nhấn Tab liên tục và xem đường viền nhìn thấy được di chuyển qua trang. Nó có di chuyển theo chuỗi gần khớp với những gì bạn thấy khi quét trang bằng mắt, từ trên xuống, từ trái sang phải không?
3. Thử kích hoạt thứ bạn đến được. Nhấn Enter trên liên kết hay nút, Space để bật ô chọn. Nó có thực sự hoạt động từ bàn phím, chứ không chỉ nhận tiêu điểm về mặt hình ảnh?
4. Kiểm tra mọi thứ tương tác đều có lượt. Mục menu, trường biểu mẫu, nút, widget tùy chỉnh như bộ chọn ngày hay accordion, tất cả nên tới được theo cách này.
5. Chú ý bẫy. Nếu Tab hoặc Shift+Tab bao giờ bị kẹt và không đưa bạn ra khỏi một phần tử, đó là vấn đề nghiêm trọng hơn riêng thứ tự, một bẫy bàn phím theo WCAG 2.1.2, và cần sửa ngay.
6. Xác nhận bạn thực sự thấy mình đang ở đâu. Nếu tiêu điểm di chuyển nhưng không có đường viền nào cho thấy ở đâu, đó là một lỗi riêng nhưng liên quan, WCAG 2.4.7 Tiêu điểm nhìn thấy được, đáng ghi nhận dù không phải chủ đề chính ở đây.

Thứ tự Tab bị hỏng thực sự trông như thế nào

Giá trị tabindex dương. Lập trình viên cố ép một thứ tự cụ thể đôi khi thêm số rõ ràng: tabindex="1", tabindex="2", v.v. Điều này ghi đè thứ tự tài liệu tự nhiên, và nó hỏng ngay khi ai đó thêm một phần tử mới về sau mà không đánh số lại mọi thứ xung quanh.

<!-- Lỗi: đánh số ép buộc sẽ dần lệch pha -->
<input tabindex="3" name="email">
<input tabindex="1" name="name">
<input tabindex="2" name="phone">

<!-- Đạt: không ghi đè, thứ tự tài liệu tự nhiên xử lý -->
<input name="name">
<input name="phone">
<input name="email">

Sắp xếp lại về mặt hình ảnh mà không chạm đến thứ tự bên dưới. Các thuộc tính CSS như order trong bố cục flexbox hoặc grid có thể thay đổi những gì người nhìn thấy được thấy mà không đổi chuỗi HTML thực tế mà Tab theo. Kết quả: người dùng chuột và người dùng bàn phím trải nghiệm hai thứ tự khác nhau trên cùng một trang, và không có gì trông sai trên màn hình.

Phần tử tùy chỉnh không có hỗ trợ bàn phím thật. Một <div> được tạo kiểu như nút, có gắn trình xử lý nhấp chuột, nhưng không có tabindex="0" và không xử lý sự kiện bàn phím, hoàn toàn vô hình với điều hướng Tab. Đây không phải thứ tự gây rối, mà là sự chặn hoàn toàn, vì người dùng bàn phím không bao giờ tới được nó.

Phần tử ẩn nhưng vẫn nhận tiêu điểm. Menu di động đã thu gọn mà các liên kết vẫn về mặt kỹ thuật có mặt trên trang, hoặc phần tử đáng lẽ vô hình nhưng vẫn nhận tiêu điểm, tạo ra điểm dừng Tab "ma": tiêu điểm di chuyển nhìn thấy được, nhưng tới thứ người dùng không thấy.

axe-core bắt được gì, và chỉ bạn mới đánh giá được gì

Quy tắc	Kiểm tra gì	Cách sửa
tabindex	Một phần tử có giá trị tabindex dương	Luôn tự động sửa, viết lại thành 0
aria-hidden-focus	Một phần tử ẩn vẫn nhận tiêu điểm riêng lẻ	Tự động sửa, cố gắng hết mức, phạm vi hẹp: sửa chính phần tử đó, không sửa vùng chứa ẩn chỉ đơn thuần chứa một phần tử nhận tiêu điểm bên trong
focus-order-semantics	Thứ tự Tab thực tế có khớp với thứ tự trực quan và logic của trang không	Thủ công
scrollable-region-focusable	Vùng cuộn được mà bàn phím không tới hay thao tác được	Thủ công

Mẫu hình ở đây nhất quán với mọi nhóm sửa lỗi khác đáng nói thật. Giá trị tabindex dương là rõ ràng, không có lý do chính đáng nào cho nó, nên axe-core viết lại nó hoàn toàn tin cậy mỗi khi tìm thấy. Thứ tự Tab của cả một trang có thực sự hợp lý về logic hay không là phán đoán về điều trang cụ thể đó muốn truyền đạt, và cần một người có thể nhìn trang và quyết định.

Axeazy sửa gì ở đây

Axeazy tự động sửa các giá trị tabindex dương hoàn toàn tin cậy, viết lại thành 0 để thứ tự tự nhiên của trình duyệt tiếp quản. Nó cũng tự động sửa trường hợp hẹp hơn là ẩn nhưng vẫn nhận tiêu điểm, một phần tử riêng lẻ không nên tới được khi bị ẩn. Cả hai đều là bản sửa tự động thật, hoạt động được.

Mọi thứ về việc thứ tự có thực sự hợp lý không, hay widget tùy chỉnh có hỗ trợ bàn phím thật được tích hợp không, đều cần lập trình viên thực sự xem trang. Đó không phải khoảng trống Axeazy che giấu, mà là cùng ranh giới trung thực mà mọi nhóm sửa lỗi trong danh sách này rốt cuộc đều vạch ra: một đoạn mã có thể viết lại thuộc tính một cách tin cậy, nhưng không thể quyết định nội dung của trang nên đọc theo thứ tự nào về mặt logic.

Cách sửa cũng tùy vào nền tảng của bạn. Trên mã React, Next.js hoặc nền tảng khác kết nối GitHub, bản sửa tabindex đến với bạn dưới dạng pull request thật. Trên Shopify, lượt quét vẫn tìm thấy nó, nhưng không có thay đổi mã tự động, nó trở thành một mục trong danh sách kiểm tra hướng dẫn. Trên WordPress, nhóm này không nằm trong ba bản sửa tức thì của plugin miễn phí (điều hướng nhảy qua, thuộc tính ngôn ngữ, văn bản thay thế dự phòng), nên hiện cũng chưa có đường tự động cho WordPress. Xem bảng phân tích đầy đủ các nhóm sửa lỗi.

Câu hỏi thường gặp

Khác biệt giữa thứ tự Tab bị hỏng và bẫy bàn phím là gì?

Thứ tự Tab là chuỗi mà tiêu điểm di chuyển qua khi ai đó nhấn Tab. Bẫy bàn phím nghiêm trọng hơn: tiêu điểm bị kẹt trên một phần tử, và cả Tab lẫn Shift+Tab đều không đưa nó đi được. Thứ tự gây rối là vấn đề dễ dùng. Bẫy là sự chặn cứng, và nó là một yêu cầu WCAG riêng, 2.1.2 Không có bẫy bàn phím.

Thêm tabindex="0" có sửa được mọi thứ không?

Nó làm cho một phần tử vốn không nhận tiêu điểm, như <div> được tạo kiểu đóng vai nút, tới được bằng Tab, và đặt nó vào thứ tự tài liệu tự nhiên của trang. Nó không bảo đảm thứ tự đó hợp lý. Vị trí của phần tử trong HTML thực tế vẫn quyết định khi nào nó nhận tiêu điểm.

Vì sao lập trình viên lại dùng tabindex dương nếu nó gây vấn đề?

Thường là nỗ lực thiện chí để ép một thứ tự cụ thể mà không sắp xếp lại HTML thực tế. Thường ít việc hơn trong ngắn hạn và nhiều việc hơn về sau, vì mỗi phần tử mới thêm vào sau đó cần đánh số lại thủ công để tránh làm hỏng chuỗi lần nữa.

Tôi có thể kiểm tra thứ tự Tab theo cách tương tự trên điện thoại không?

Không hẳn. Điều hướng bằng phím Tab là tương tác bàn phím vật lý, nên bài kiểm tra cụ thể này xây dựng quanh trình duyệt máy tính. Khả năng tiếp cận bàn phím trên di động vẫn quan trọng, chủ yếu với người dùng bàn phím ngoài hoặc thiết bị truy cập bằng công tắc với trình duyệt di động, nhưng được kiểm tra theo cách khác.

Chỉ sửa thứ tự Tab có làm điều hướng bàn phím của tôi hoàn toàn dùng được không?

Không bản sửa đơn lẻ nào bao quát mọi thứ người chỉ dùng bàn phím có thể gặp. Thứ tự Tab là một phần thật, có ý nghĩa; một trang vẫn có thể có các vấn đề khác, như thiếu chỉ báo tiêu điểm hoặc bẫy bàn phím thật, cần được kiểm tra riêng.

Nguồn

• W3C: Tìm hiểu SC 2.1.1, Bàn phím
• W3C: Tìm hiểu SC 2.4.3, Thứ tự tiêu điểm
• W3C: Tìm hiểu SC 2.1.2, Không có bẫy bàn phím