Buổi 6 — Khả năng tiếp cận và người dùng thật
Accessibility thường bị coi là việc phải làm vì quy định. Thực tế nó là thiết kế tốt cho một nhóm người dùng lớn hơn bạn nghĩ nhiều.
Vì sao PM nên quan tâm
Không chỉ vì người khiếm thị. Tương phản màu đủ mạnh giúp cả người dùng đang cầm điện thoại ngoài nắng. Vùng bấm đủ lớn giúp cả người đang đi trên xe. Phụ đề giúp cả người xem video ở nơi công cộng.
Thiết kế cho trường hợp khó làm sản phẩm tốt hơn cho tất cả mọi người. Đây là lập luận thực dụng, không phải lập luận đạo đức — dù cả hai đều đúng.
Bốn thứ kiểm tra được không cần chuyên môn
Tương phản màu. Chữ xám nhạt trên nền trắng trông tinh tế trên màn hình designer và không đọc được trên điện thoại ngoài trời. Có công cụ kiểm tra miễn phí, mất 30 giây.
Kích thước vùng bấm. Nút quá nhỏ hoặc quá sát nhau gây bấm nhầm. Kiểm tra bằng cách dùng sản phẩm bằng một tay khi đang đi bộ.
Điều hướng bằng bàn phím. Bấm Tab qua toàn bộ trang. Có đi được tới mọi chức năng không? Có thấy rõ đang ở đâu không? Nhiều người dùng nâng cao dùng bàn phím vì nhanh hơn.
Không dùng màu làm tín hiệu duy nhất. "Ô đỏ là bắt buộc" vô nghĩa với người mù màu — khoảng 8% nam giới. Luôn kèm biểu tượng hoặc chữ.
Ngôn ngữ và văn bản tiếng Việt
Tiếng Việt có dấu chồng lên nhau, nên chiều cao dòng phải rộng hơn so với tiếng Anh — chữ hoa có dấu như "Ổ" hay "Ự" bị cắt ngọn khi line-height quá chặt.
Ngoài ra, một câu tiếng Việt thường dài hơn câu tiếng Anh tương đương khoảng 20-30%. Giao diện thiết kế vừa khít cho bản tiếng Anh sẽ vỡ khi dịch.
Người dùng thật không giống bạn
Đội ngũ sản phẩm dùng máy tính mạnh, mạng nhanh, màn hình lớn, và biết sản phẩm rõ hơn bất kỳ ai. Đó là điều kiện xa nhất so với người dùng trung bình.
Thử định kỳ: dùng sản phẩm trên điện thoại đời cũ, với mạng 3G bị giới hạn, ngoài trời nắng. Bạn sẽ phát hiện những vấn đề không bao giờ xuất hiện trong văn phòng.
Đưa vào quy trình thế nào
Đừng để accessibility thành một đợt rà soát cuối. Thêm bốn mục kiểm tra ở trên vào định nghĩa "xong" của team. Chi phí gần bằng 0 nếu làm ngay từ đầu, và rất đắt nếu sửa sau.
Bài tập
Chạy bốn kiểm tra ở trên trên màn hình chính của sản phẩm. Ghi lại số vấn đề tìm được — con số này thường đủ để thuyết phục team đưa nó vào quy trình.
<!--les-append-->
Bốn kiểm tra làm được trong 15 phút
Không cần công cụ chuyên dụng, không cần biết code:
1. Phóng to 200%. Trên trình duyệt, nhấn Ctrl/Cmd + nhiều lần. Bố cục có vỡ không? Chữ có bị cắt không? Nhiều người dùng chạy ở mức phóng to mặc định lớn hơn bạn.
2. Chỉ dùng bàn phím. Bỏ chuột, nhấn Tab đi qua màn hình. Có tới được mọi nút không? Có nhìn thấy đang ở đâu không? Nếu viền chỉ báo tiêu điểm bị tắt đi vì "trông xấu", màn hình đó không dùng được bằng bàn phím.
3. Tắt màu. Chụp màn hình, chuyển sang trắng đen. Còn phân biệt được trạng thái không? Nếu "hợp lệ" và "lỗi" chỉ khác nhau ở màu xanh/đỏ, khoảng 8% nam giới không phân biệt được.
4. Đọc ngoài nắng. Ra ngoài trời với điện thoại. Chữ xám nhạt trên nền trắng trông tinh tế trong văn phòng và biến mất hoàn toàn ngoài nắng.
Vì sao đây là lập luận thực dụng
| Thiết kế cho | Cũng giúp |
|---|---|
| Người khiếm thị | Người dùng bằng giọng nói khi đang lái xe |
| Người khiếm thính | Người xem video ở nơi công cộng |
| Người yếu vận động | Người đang bế con, đang đi trên xe |
| Người mù màu | Bất kỳ ai xem trên màn hình kém |
| Người cao tuổi | Bất kỳ ai đang vội hoặc mệt |
Ba thứ đắt nếu sửa muộn
Một số quyết định rất rẻ lúc đầu và rất đắt về sau:
- Tương phản màu trong hệ thống thiết kế. Sửa token thì toàn bộ sản phẩm đổi. Sửa sau khi đã có 200 màn hình thì không ai làm.
- Cấu trúc tiêu đề trang. Ảnh hưởng cả người dùng trình đọc màn hình lẫn công cụ tìm kiếm.
- Nhãn cho ô nhập. Ô không có nhãn thì trình đọc màn hình đọc ra "ô nhập văn bản" và người dùng không biết điền gì.
Làm ngay
Chạy bốn kiểm tra trên một màn hình quan trọng nhất của sản phẩm. Ghi lại cái nào trượt. Bốn kiểm tra này mất 15 phút và thường tìm ra ít nhất một vấn đề thật. <!--/les-append-->