Một checklist ngắn, có chủ kiến về nút web dễ tiếp cận

Vấn đề với các lời khuyên về khả năng tiếp cận của nút

Phần lớn hướng dẫn về khả năng tiếp cận của nút rơi vào hai nhóm: hoặc là một bản diễn giải WCAG dài 40 trang mà không ai đọc, hoặc là một gợi ý mơ hồ kiểu "làm cho nút dễ tiếp cận" nhưng không có bước thực hiện cụ thể. Cả hai đều không giúp ích nhiều khi bạn phải phát hành một tính năng vào thứ Năm.

Checklist này bao quát năm lỗi phổ biến nhất về khả năng tiếp cận của nút mà chúng tôi thấy trong production. Nó sẽ không biến bạn thành chuyên gia WCAG, nhưng sẽ giúp phát hiện những vấn đề thực sự ảnh hưởng đến người dùng.

1. Dùng phần tử button cho nút

Nếu nó hoạt động như một nút, nó nên là phần tử <button>. Không phải một <div> với onclick, không phải một <span> với role="button", không phải một <a> với href="#" và preventDefault.

Phần tử <button> cung cấp sẵn điều hướng bằng bàn phím, quản lý focus và thông báo cho trình đọc màn hình. Khi bạn dùng một <div>, bạn đang xây dựng lại tất cả những thứ đó từ đầu — và bạn sẽ làm sai.

Ngoại lệ duy nhất: nếu hành động điều hướng đến một trang mới hoặc thay đổi URL, hãy dùng phần tử <a>. Liên kết và nút khác nhau về mặt ngữ nghĩa. Người dùng trình đọc màn hình điều hướng theo loại phần tử, và họ kỳ vọng nút thực hiện hành động còn liên kết dùng để điều hướng.

2. Đảm bảo vùng nhấn ít nhất 44×44 pixel

WCAG 2.5.5 (Mức AAA) yêu cầu các phần tử tương tác có kích thước mục tiêu tối thiểu là 44×44 pixel CSS. Đây không phải là kích thước hiển thị — mà là vùng có thể nhấp.

Bạn có thể có một nút hiển thị nhỏ với padding đủ lớn, hoặc mở rộng vùng nhấn bằng pseudo-element. Điều quan trọng là người dùng không phải nhắm thật chính xác.

Người dùng di động, người có suy giảm vận động và bất kỳ ai đang dùng thiết bị khi di chuyển đều sẽ dễ nhấn trượt các mục tiêu nhỏ. Một nút biểu tượng 24×24 pixel có thể trông gọn gàng, nhưng đó là một lỗi về khả dụng.

3. Cung cấp trạng thái focus nhìn thấy được, không chỉ dựa vào mặc định của trình duyệt

Vòng focus mặc định của trình duyệt vẫn tốt hơn là không có gì, nhưng nó không nhất quán giữa các trình duyệt và thường vô hình trên một số nền nhất định. Bạn cần một trạng thái focus tùy chỉnh hoạt động tốt trong design system của mình.

Một chỉ báo focus tốt có ba đặc điểm:

• Độ tương phản cao: ít nhất 3:1 so với các màu liền kề
• Khoảng lệch nhìn thấy được: không bị che bởi chính viền hoặc nền của nút
• Hình dạng nhất quán: người dùng nên nhận ra đó là chỉ báo focus trên toàn bộ giao diện của bạn

Đừng bỏ outline: none mà không thay thế bằng thứ gì tốt hơn. Và đừng làm trạng thái focus tinh tế đến mức chỉ bạn mới thấy được trong điều kiện ánh sáng hoàn hảo.

4. Viết nhãn nút có ý nghĩa ngay cả khi tách khỏi ngữ cảnh

Người dùng trình đọc màn hình thường điều hướng bằng cách nhảy qua các nút. Khi làm vậy, họ nghe một danh sách nhãn nút mà không có ngữ cảnh xung quanh.

Một nút có nhãn "Tìm hiểu thêm" là vô dụng trong danh sách đó. "Nhấp vào đây" hay "Gửi" cũng vậy. Nhãn nên mô tả hành động: "Tải xuống checklist về khả năng tiếp cận", "Đăng ký nhận cập nhật", "Xóa bình luận này".

Nếu thiết kế của bạn cần một nhãn hiển thị ngắn, hãy dùng aria-label để cung cấp một phương án mô tả thay thế. Nhưng giải pháp tốt hơn là viết nhãn phù hợp với tất cả mọi người.

Với các nút chỉ có biểu tượng, aria-label là bắt buộc. Một nút chỉ có biểu tượng kính lúp cần aria-label="Search" hoặc văn bản tương đương. Biểu tượng không tiếp cận được với trình đọc màn hình.

5. Đảm bảo độ tương phản màu đủ cao

WCAG 2.1 yêu cầu tỷ lệ tương phản ít nhất 4.5:1 cho văn bản thông thường và 3:1 cho văn bản lớn (18pt hoặc 14pt đậm). Nhãn nút thường là văn bản thông thường.

Chữ xám nhạt trên nút trắng là không đạt. Xanh lam nhạt trên nền xanh lam nhạt cũng không đạt. Những tổ hợp này có thể trông tinh tế, nhưng chúng loại trừ người dùng có thị lực kém, mù màu hoặc bất kỳ ai đang nhìn màn hình dưới ánh nắng mạnh.

Hãy dùng công cụ kiểm tra độ tương phản trong giai đoạn thiết kế, không phải sau khi ra mắt. Sửa vấn đề tương phản trong production rất tốn kém vì thường đòi hỏi thay đổi design system.

Nếu bạn đang làm việc với các công cụ xử lý hình ảnh, xử lý phía client có thể giúp bảo vệ quyền riêng tư khi tạo tài sản hình ảnh dễ tiếp cận — đặc biệt khi kiểm thử các tổ hợp màu hoặc tạo trạng thái xem trước.

Checklist này không bao quát điều gì

Danh sách này cố ý không đầy đủ. Nó không bao quát ngữ nghĩa của trạng thái disabled, trạng thái loading, xử lý lỗi, hay các mẫu nút phức tạp như split button hoặc dropdown trigger. Những mẫu đó cần hướng dẫn riêng.

Nó cũng không bao quát câu hỏi rộng hơn về khi nào nên dùng nút so với các phần tử tương tác khác. Với điều đó, bạn cần hiểu HTML ngữ nghĩa và cây khả năng tiếp cận — những chủ đề xứng đáng có bài viết riêng.

Điều nó bao quát là những vấn đề dễ xử lý: các lỗi xuất hiện trong hầu hết mọi lần review code, ảnh hưởng đến nhiều người dùng nhất, và dễ sửa nhất trong quá trình phát triển.

Cách tích hợp checklist này vào quy trình làm việc của bạn

Checklist về khả năng tiếp cận chỉ hiệu quả nếu chúng là một phần của quy trình phát triển, chứ không phải được gắn thêm sau đó. Đây là cách để làm điều đó:

Trong thiết kế: thêm trạng thái focus và chú thích về vùng nhấn vào file thiết kế của bạn. Đừng để các nhà phát triển phải đoán những điều này.

Trong review code: kiểm tra các phần tử <button>, aria-label trên nút biểu tượng và CSS cho trạng thái focus. Những thứ này rất nhanh để phát hiện.

Trong kiểm thử: dùng phím Tab để đi qua giao diện của bạn bằng bàn phím. Nếu bạn không thể tới một nút hoặc không thể thấy focus đang ở đâu, người dùng của bạn cũng vậy.

Trong tài liệu: đưa các yêu cầu về khả năng tiếp cận của nút vào thư viện component của bạn. Hãy làm cho việc làm đúng trở nên dễ hơn việc làm sai.

Nếu bạn đang debug vấn đề trong production, các công cụ kiểm tra HTTP headers và redirects có thể giúp bạn hiểu cách công nghệ hỗ trợ diễn giải markup của bạn — đặc biệt khi xử lý sự cố quản lý focus sau điều hướng.

Cái giá của việc bỏ qua công việc này

Nút không dễ tiếp cận không chỉ làm trượt tuân thủ WCAG — chúng phá vỡ quy trình làm việc. Người dùng không thể nhấp vào nút gửi thì không thể hoàn tất biểu mẫu. Người dùng không thể thấy trạng thái focus thì không thể điều hướng bằng bàn phím. Người dùng không thể phân biệt chữ trên nút với nền thì không thể đọc nhãn.

Đây không phải là các trường hợp ngoại lệ. Khoảng 15% dân số toàn cầu có một dạng khuyết tật nào đó, và các suy giảm tạm thời (chuột hỏng, ánh nắng mạnh, đang bế em bé) cuối cùng cũng ảnh hưởng đến tất cả mọi người.

Tin tốt là khả năng tiếp cận của nút phần lớn là những vấn đề đã có lời giải. Bạn không cần phát minh mẫu mới hay chờ trình duyệt hỗ trợ. Bạn chỉ cần dùng nền tảng đúng cách và kiểm thử công việc của mình.

Những điểm chính cần ghi nhớ

• Dùng phần tử <button> cho nút và phần tử <a> cho điều hướng — khác biệt ngữ nghĩa rất quan trọng với công nghệ hỗ trợ
• Đảm bảo vùng nhấn ít nhất 44×44 pixel CSS để hỗ trợ người dùng có suy giảm vận động và người dùng di động
• Cung cấp trạng thái focus nhìn thấy được, có độ tương phản cao và hoạt động nhất quán trong design system của bạn
• Viết nhãn nút có ý nghĩa khi được đọc riêng lẻ, và dùng aria-label cho các nút chỉ có biểu tượng
• Kiểm tra độ tương phản màu trong giai đoạn thiết kế, không phải sau khi ra mắt, để tránh việc sửa chữa tốn kém

FAQ

Q: Tôi có thể dùng role="button" trên một <div> nếu thêm trình xử lý bàn phím không?

A: Có thể, nhưng bạn không nên. Bạn sẽ phải tự xử lý Enter, Space, quản lý focus và trạng thái disabled — và chắc chắn bạn sẽ bỏ sót điều gì đó. Phần tử <button> làm đúng tất cả những việc này theo mặc định. Hãy dùng nó.

Q: Còn những nút chuyển đổi trạng thái, như nút phát/tạm dừng thì sao?

A: Dùng aria-pressed="true" hoặc aria-pressed="false" để cho biết trạng thái hiện tại. Nhãn nút cũng nên phản ánh hành động sẽ xảy ra khi nhấp ("Tạm dừng" khi đang phát, "Phát" khi đang tạm dừng), chứ không phải trạng thái hiện tại. Người dùng trình đọc màn hình cần biết nút sẽ làm gì, không phải hệ thống đang ở trạng thái nào.

Q: Nút disabled có cần đáp ứng yêu cầu về độ tương phản không?

A: WCAG 2.1 miễn trừ các control disabled khỏi yêu cầu về độ tương phản (1.4.3), nhưng điều này còn gây tranh luận. Nút disabled có độ tương phản kém khiến tất cả mọi người khó nhận biết. Nếu bạn định hiển thị một nút disabled, hãy làm cho nó đọc được. Tốt hơn nữa, hãy ẩn nó hoặc giải thích vì sao nó bị disabled.

Q: Làm thế nào để kiểm thử khả năng tiếp cận của nút mà không cần trình đọc màn hình?

A: Hãy dùng bàn phím. Dùng Tab để đi qua giao diện và xác minh rằng bạn có thể tới mọi nút, thấy focus đang ở đâu, và kích hoạt nút bằng Enter hoặc Space. Cách này phát hiện được hầu hết vấn đề. Để kiểm thử sâu hơn, hãy dùng accessibility inspector trong Chrome hoặc Firefox DevTools để kiểm tra role và label được tính toán.

Q: Sự khác nhau giữa aria-label và aria-labelledby là gì?

A: aria-label cung cấp trực tiếp một chuỗi văn bản. aria-labelledby tham chiếu đến ID của một phần tử khác, nơi nội dung văn bản của phần tử đó trở thành nhãn. Dùng aria-labelledby khi văn bản nhãn đã tồn tại ở nơi khác trong DOM. Dùng aria-label khi bạn cần cung cấp một nhãn không hiển thị trên màn hình.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM