Accessibility, hay khả năng tiếp cận, trong thiết kế giao diện là làm cho website và ứng dụng dùng được với càng nhiều người càng tốt, kể cả người nhìn kém, khó phân biệt màu, run tay, dùng trình đọc màn hình hay chỉ dùng bàn phím. Tiêu chuẩn được dẫn nhiều nhất là bộ hướng dẫn WCAG của tổ chức W3C, với các yêu cầu cụ thể về tương phản, kích thước vùng chạm, nhãn, khả năng dùng bằng bàn phím.
Phần lớn những việc này nằm trong tay người thiết kế, không phải lập trình viên: chọn màu chữ và nền, quyết định cỡ nút, viết thông báo lỗi, quyết định có dùng màu làm tín hiệu duy nhất hay không. Bài này dành cho người làm đồ hoạ lần đầu làm giao diện: bảng các điểm kiểm chính, những nguyên tắc ít được nhắc nhưng hay vi phạm, chỗ AI giúp được và giới hạn của nó, cùng một bài kiểm tay ba mươi phút làm được trên chính điện thoại của bạn. Phần chọn bảng màu và cặp font thương hiệu có bài riêng ở danh mục chữ và màu của trang.
Ai được lợi khi giao diện dễ tiếp cận
Khi nghe tới khả năng tiếp cận, nhiều người nghĩ đó là việc dành cho một nhóm nhỏ người khuyết tật nặng. Thực ra nhóm được lợi rộng hơn nhiều. Người lớn tuổi mắt kém dần, ngón tay kém chính xác; người cận thị quên kính; người khó phân biệt đỏ và xanh lá; người đang bế con chỉ còn một tay rảnh; người đứng ngoài nắng nhìn màn hình độ sáng thấp; người bị gãy tay tạm thời. Mỗi người trong chúng ta đều có lúc rơi vào một trong những hoàn cảnh đó.
Ở Việt Nam, nhóm người dùng lớn tuổi dùng điện thoại để chuyển khoản, đặt khám, xem tin tức, gọi xe ngày càng đông. Họ thường là những người bỏ cuộc sớm nhất khi chữ quá nhỏ, nút quá sát hay thông báo lỗi khó hiểu, và cũng là những người ít phàn nàn nhất — họ chỉ lặng lẽ nhờ con cháu hoặc không dùng nữa.
Với khách hàng của bạn, lý lẽ thực tế nhất là: giao diện dễ tiếp cận thường cũng là giao diện dễ dùng cho mọi người. Chữ đủ lớn, tương phản rõ, nút đủ to, nhãn rõ ràng giúp cả người trẻ thao tác nhanh hơn, ít bấm nhầm hơn. Ở một số thị trường và lĩnh vực, đáp ứng tiêu chuẩn tiếp cận còn là yêu cầu pháp lý; nếu khách làm sản phẩm cho thị trường nước ngoài hay cho cơ quan nhà nước, nên hỏi họ về quy định hiện hành áp dụng.
Các điểm kiểm chính và ngưỡng thường dùng
Bảng dưới tóm tắt những yêu cầu người thiết kế giao diện cần nắm, lấy theo WCAG 2.2 ở mức AA là mức thường được đặt làm mục tiêu. Số liệu là ngưỡng tối thiểu; bản đầy đủ và cách diễn giải chính thức nằm trong tài liệu của W3C, nên kiểm bản hiện hành khi làm dự án có yêu cầu tuân thủ.
| Điểm kiểm | Ngưỡng hoặc yêu cầu | Người thiết kế cần làm gì |
|---|---|---|
| Tương phản chữ thường | Tối thiểu 4,5:1 giữa chữ và nền | Kiểm mọi cặp màu chữ và nền, kể cả chữ phụ màu xám nhạt |
| Tương phản chữ lớn | Tối thiểu 3:1 cho chữ cỡ lớn hoặc đậm | Không lấy ngưỡng này áp cho chữ thân bài |
| Tương phản thành phần | Tối thiểu 3:1 cho viền ô nhập, icon chức năng, trạng thái chọn | Viền ô nhập xám rất nhạt trên nền trắng thường không đạt |
| Kích thước vùng chạm | Tối thiểu 24×24 điểm theo WCAG 2.2 mức AA; các hướng dẫn nền tảng di động khuyên khoảng 44 đến 48 điểm | Dùng cỡ khuyên dùng của nền tảng làm mặc định, không chỉ đạt mức tối thiểu |
| Không chỉ dựa vào màu | Thông tin truyền bằng màu phải có thêm tín hiệu khác | Lỗi có chữ và icon, liên kết có gạch dưới hoặc độ đậm |
| Thấy được vị trí bàn phím | Thành phần đang được chọn bằng bàn phím phải có dấu hiệu nhìn thấy được | Thiết kế trạng thái chọn bằng bàn phím cho mọi thành phần bấm được |
| Phóng to chữ | Nội dung vẫn đọc và dùng được khi người dùng phóng to chữ tới 200% | Không thiết kế khối có chiều cao cố định chứa chữ |
Ghi chú: ở đây dùng "điểm" như đơn vị trong phần mềm thiết kế, tương ứng với đơn vị độc lập độ phân giải mà lập trình viên dùng. Khi bàn giao, thống nhất đơn vị với lập trình viên để không lệch.
Không để màu làm tín hiệu duy nhất
Báo lỗi bằng viền đỏ là chưa đủ. Người khó phân biệt đỏ và xanh lá không thấy viền ô nhập đổi màu. Thêm dòng chữ báo lỗi ngay dưới ô và một icon cảnh báo, để thông tin đi qua ba kênh thay vì một.
Biểu đồ và chú thích cần thêm hình dạng. Đường biểu đồ hai màu gần độ sáng nhau sẽ thành hai đường xám với một số người. Thêm kiểu nét (liền, đứt), điểm đánh dấu khác hình, hoặc ghi nhãn trực tiếp cạnh đường.
Trạng thái đang chọn cần nhiều hơn đổi màu. Mục đang chọn trên thanh điều hướng nên đổi cả độ đậm chữ, kiểu icon hoặc có gạch chân, không chỉ đổi từ xám sang màu thương hiệu.
Liên kết trong đoạn văn cần dễ nhận. Liên kết chỉ khác màu chữ thường, không gạch dưới, dễ bị bỏ qua. Gạch dưới là cách quen thuộc và đáng tin nhất.
Kiểm bằng cách chuyển sang thang xám. Xem màn hình ở chế độ đen trắng là phép thử nhanh: thông tin nào biến mất thì thông tin đó đang dựa hoàn toàn vào màu. Nhiều phần mềm thiết kế và hệ điều hành có chế độ mô phỏng các dạng khó phân biệt màu; kiểm tên tính năng trong phiên bản bạn dùng.
Nhãn, thông báo lỗi và trình đọc màn hình
Người khiếm thị dùng điện thoại và máy tính nhờ trình đọc màn hình, phần mềm đọc to nội dung và tên của từng thành phần. Trình đọc chỉ đọc được những gì có trong mã, nên nếu bản thiết kế không chỉ định nhãn thì lập trình viên thường không tự thêm. Một nút chỉ có icon trái tim sẽ được đọc là "nút" trơn trụi thay vì "thêm vào yêu thích".
Vì vậy bản thiết kế cần ghi rõ: tên đọc của mọi nút chỉ có icon, mô tả thay thế cho ảnh mang thông tin (ảnh trang trí thì ghi là bỏ qua), thứ tự đọc khi bố cục phức tạp, và tiêu đề của từng vùng trên trang. Đây là phần bàn giao ít người làm nhưng chi phí thấp, chủ yếu là viết thêm vài dòng ghi chú.
Ô nhập cần nhãn hiện thường trực phía trên hoặc bên cạnh, không chỉ dùng chữ gợi ý mờ bên trong ô. Chữ gợi ý biến mất khi người dùng bắt đầu gõ, nên người dùng có trí nhớ ngắn hạn kém hay bị gián đoạn sẽ quên mình đang điền gì. Thông báo lỗi nên nói lỗi gì và sửa thế nào, ví dụ "Số điện thoại cần 10 chữ số, bạn mới nhập 9" thay vì "Dữ liệu không hợp lệ".
Dùng AI rà khả năng tiếp cận: giúp được gì, không giúp được gì
AI là trợ lý tốt cho vòng soát đầu, miễn là bạn biết giới hạn của nó.
- Giúp được: đọc ảnh chụp màn hình và chỉ ra chữ có vẻ quá nhỏ, nút có vẻ sát nhau, icon không có nhãn, chỗ dùng màu làm tín hiệu duy nhất. Câu lệnh mẫu: "Đây là ảnh chụp màn hình đăng ký tài khoản trên điện thoại. Rà theo các tiêu chí khả năng tiếp cận phổ biến: cỡ chữ, tương phản, vùng chạm, nhãn ô nhập, cách báo lỗi. Liệt kê vấn đề theo mức nghiêm trọng, mỗi vấn đề kèm cách sửa."
- Giúp được: viết nháp nhãn đọc cho các nút chỉ có icon, mô tả thay thế cho ảnh, thông báo lỗi rõ ràng hơn từ danh sách lỗi bạn đưa.
- Giúp được: giải thích một tiêu chí WCAG bằng tiếng Việt dễ hiểu để bạn trình bày với khách. Đối chiếu lại với văn bản gốc của W3C trước khi dùng làm căn cứ.
- Không thay được: phép đo tương phản chính xác. AI đọc màu từ ảnh nén có thể sai; dùng công cụ đo tương phản với mã màu thật lấy từ tệp thiết kế.
- Không thay được: trải nghiệm thật với trình đọc màn hình và bàn phím, vì thứ tự đọc và vị trí bàn phím phụ thuộc vào cách dựng trong mã.
- Không thay được: ý kiến của người dùng có khó khăn thật. Nếu dự án có điều kiện, mời vài người dùng lớn tuổi hoặc người dùng trình đọc màn hình thử là cách đáng tin nhất.
Trước khi chụp màn hình gửi AI, thay dữ liệu thật như tên, số điện thoại, số tài khoản của khách bằng dữ liệu mẫu.
Bài kiểm tay ba mươi phút trên điện thoại của bạn
Không cần phần mềm chuyên dụng, bạn có thể tự kiểm một bản mẫu hay một trang đã dựng theo các bước sau:
- Bật chế độ chữ lớn của điện thoại lên mức cao, mở lại giao diện. Ghi lại chỗ chữ bị cắt, chồng lên nhau hoặc nút bị đẩy ra ngoài màn hình.
- Chuyển màn hình sang chế độ thang xám trong cài đặt trợ năng. Kiểm xem còn phân biệt được lỗi, trạng thái chọn, liên kết không.
- Giảm độ sáng màn hình xuống thấp và ra chỗ có nắng. Đọc chữ phụ, chữ trên nút, chữ trên nền ảnh.
- Thử thao tác bằng một tay, ngón cái, với điện thoại cầm thấp. Đếm số lần bấm nhầm.
- Bật trình đọc màn hình có sẵn của hệ điều hành, lướt qua các thành phần chính, nghe xem nút nào được đọc vô nghĩa.
- Trên máy tính, chỉ dùng phím Tab và Enter để đi hết một luồng chính như đăng ký hoặc đặt hàng. Ghi lại chỗ không thấy mình đang ở đâu.
- Gom các vấn đề, xếp theo mức chặn việc (không làm được), gây khó (làm được nhưng vất vả), khó chịu nhẹ. Sửa nhóm đầu trước.
Bước năm và sáu phụ thuộc vào bản đã dựng bằng mã; với bản mẫu trong phần mềm thiết kế, bạn chỉ kiểm được các bước đầu. Dù vậy, chỉ ba bước đầu đã bắt được phần lớn vấn đề hay gặp trong các giao diện nhỏ.
Đưa khả năng tiếp cận vào quy trình ngay từ đầu
Sửa khả năng tiếp cận ở cuối dự án tốn kém vì thường phải đổi màu thương hiệu, tăng cỡ chữ làm vỡ bố cục, nới vùng chạm làm thay đổi lưới. Đưa nó vào từ đầu thì gần như không tốn thêm: chọn bảng màu đã kiểm tương phản, đặt cỡ chữ thân đủ lớn trong token, đặt kích thước tối thiểu cho mọi thành phần bấm được trong thư viện.
Một cách làm thực tế là thêm vài dòng kiểm vào danh sách soát của mỗi màn hình: tương phản đã kiểm, vùng chạm đủ, mọi icon có nhãn, lỗi không chỉ bằng màu, ô nhập có nhãn hiện. Năm dòng này không thay được kiểm thử đầy đủ, nhưng giúp bạn không quên.
Khi trình khách, đừng trình khả năng tiếp cận như một khoản chi thêm mà như một phần của chất lượng. Ví dụ giả định: bạn cho khách xem cùng một màn hình ở chế độ chữ lớn trước và sau khi chỉnh, trên chính điện thoại của bố mẹ họ. Phép thử đó thường thuyết phục hơn mọi con số tiêu chuẩn.
Câu hỏi thường gặp
WCAG là gì và có bắt buộc ở Việt Nam không?
WCAG là bộ hướng dẫn về khả năng tiếp cận nội dung web của tổ chức W3C, được nhiều nước dùng làm căn cứ cho quy định. Việc áp dụng bắt buộc phụ thuộc vào quy định từng nước và từng lĩnh vực; với dự án cụ thể, nên hỏi khách và kiểm quy định hiện hành mà họ phải tuân theo.
Chữ thân bài trên điện thoại nên cỡ bao nhiêu?
Không có con số duy nhất bắt buộc, nhưng nhiều hệ thiết kế dùng khoảng 16 điểm trở lên cho chữ thân trên di động, và các nền tảng đều hỗ trợ người dùng tự phóng to. Quan trọng hơn con số là giao diện không vỡ khi người dùng tăng cỡ chữ.
Màu thương hiệu không đạt tương phản thì làm sao?
Giữ màu thương hiệu cho mảng lớn, hình khối, minh hoạ, và dùng phiên bản đậm hơn hoặc nhạt hơn của nó cho chữ và nút cần đọc. Hầu hết bộ nhận diện chịu được thêm một hai sắc độ phụ. Ghi rõ trong tài liệu sắc độ nào dùng cho việc gì.
Có cần thiết kế riêng một phiên bản cho người khuyết tật không?
Thường không nên. Cách được khuyên dùng là thiết kế một giao diện chung đủ tốt cho mọi người, hỗ trợ các công cụ trợ năng có sẵn của hệ điều hành. Phiên bản riêng dễ bị bỏ quên khi cập nhật và tạo cảm giác bị tách biệt.
Giao diện tối có tốt hơn cho người mắt kém không?
Tuỳ người. Một số người thấy dễ chịu hơn, một số người bị loá chữ trên nền tối. Nếu làm giao diện tối, vẫn phải kiểm tương phản cho từng cặp màu và nên để người dùng tự chọn hoặc theo cài đặt của hệ điều hành.
AI có tự sửa giao diện cho đạt chuẩn tiếp cận không?
AI có thể đề xuất sửa từng điểm như tăng tương phản hay viết nhãn, nhưng quyết định cuối cùng liên quan tới thương hiệu, bố cục và cách dựng trong mã. Kết quả cần được người thiết kế duyệt và kiểm lại bằng công cụ đo và thử trên thiết bị thật.