Ai App Mà Bạn Tạo Ra Có Thể Dùng Được Với Mọi Người Không? Hướng Dẫn Đơn Giản Về Khả Năng Tiếp Cận

Khi bạn xây một ứng dụng bằng AI, bạn thường thử nó theo cách bạn dùng: màn hình của bạn, mắt của bạn, đôi tay vững vàng cầm laptop của bạn. Vấn đề là một phần không nhỏ những người sẽ mở ứng dụng của bạn lại không dùng nó theo cách đó. Có người phóng to chữ trên điện thoại lên gấp đôi cỡ bình thường. Có người không phân biệt được thông báo lỗi màu đỏ của bạn với chữ đen xung quanh nó. Có người đang bế con và chạm màn hình bằng một ngón cái. Khả năng tiếp cận của ứng dụng đơn giản là câu hỏi liệu những người đó có còn dùng được ứng dụng hay không — và đó là câu hỏi mà phần lớn ứng dụng do AI tạo ra chưa từng được đặt ra.

Bạn không cần bằng cấp hay một đội ngũ tuân thủ quy chuẩn để xử lý chuyện này. Bạn chỉ cần biết bốn, năm chỗ mà ứng dụng thường vô tình gạt người dùng ra ngoài, và cách yêu cầu công cụ xây dựng của mình sửa chúng. Hãy để tôi chỉ cho bạn những trường hợp phổ biến qua vài câu chuyện thực tế, vì chúng sẽ dễ nhận ra hơn một khi bạn đã thấy qua.

Vì sao bố cục ứng dụng của tôi bị vỡ khi ai đó phóng to màn hình?

Vì phần lớn ứng dụng do AI tạo ra được thiết kế ở một cỡ chữ cố định, nên khi ai đó phóng to chữ trên điện thoại hoặc trình duyệt của họ — điều mà rất nhiều người làm, nhất là những ai trên sáu mươi tuổi — các nút sẽ chồng lên nhau, các cột bị dồn thành một chuỗi lộn xộn, và các điều khiển trượt đè lên nhau.

Tôi biết một người từng xây một ứng dụng đặt lịch hẹn gọn gàng cho tiệm làm tóc của mẹ mình. Trông rất đẹp. Rồi mẹ cô mở ứng dụng lên, và việc đầu tiên bà làm — giống như rất nhiều người trên sáu mươi tuổi — là chụm hai ngón tay để phóng to chữ. Bố cục sụp đổ ngay lập tức. Các nút chồng lên nhau, nút “Đặt lịch” trượt xuống dưới menu, và một cột giờ hẹn biến thành một mớ hỗn độn không thể đọc nổi.

Đây là lỗi khả năng tiếp cận phổ biến nhất trong các ứng dụng do AI tạo ra, và nó vô hình cho đến khi có ai đó phóng to màn hình. Hãy yêu cầu công cụ xây dựng của bạn: “Đảm bảo bố cục vẫn hoạt động tốt khi chữ được phóng to đến 200%. Không có gì được chồng lên nhau hoặc bị cắt mất.” Sau đó tự mình kiểm tra — trên điện thoại của bạn, tăng cỡ chữ hệ thống lên mức lớn nhất rồi mở ứng dụng lên. Nếu nó vỡ tan, đó chính là điều cần sửa đầu tiên.

Vì sao ứng dụng của tôi không nên chỉ dùng màu sắc để thể hiện trạng thái?

Vì khoảng một trong mười hai nam giới có cách nhìn màu sắc khác biệt, phổ biến nhất là không phân biệt được đỏ và xanh lá — nên một trạng thái chỉ được thể hiện bằng chấm đỏ so với chấm xanh sẽ trông giống hệt nhau đối với họ, và họ thực sự không thể phân biệt được “đã thanh toán” với “quá hạn.”

Một người làm việc tự do từng xây một công cụ theo dõi hóa đơn chỉ hiển thị trạng thái bằng màu sắc — chấm xanh, chấm đỏ. Một trong những khách hàng của anh, người vốn bị mù màu đỏ-xanh lá, cứ liên tục thanh toán những hóa đơn đã trả rồi vì hai chấm màu ấy trông y hệt nhau với anh ta. Thông tin vẫn ở đó. Chỉ là nó không tồn tại đối với anh.

Cách khắc phục là một thói quen, không phải một tính năng: đừng bao giờ chỉ dùng màu sắc làm cách duy nhất để truyền đạt điều gì đó. Hãy thêm một từ, một biểu tượng, hoặc một hình dạng đi kèm. “Quá hạn” bên cạnh màu đỏ. Dấu tích bên cạnh màu xanh. Dấu hoa thị và chữ “bắt buộc,” chứ không chỉ viền đỏ. Màu sắc vẫn có thể giữ nguyên — chỉ là nó không thể một mình gánh cả thông điệp.

Vì sao trình đọc màn hình chỉ nói “nút” thay vì gọi tên nó?

Vì một nút biểu tượng không có nhãn — thùng rác, cây bút chì, kính lúp mà không kèm chữ nào — không có văn bản để trình đọc màn hình (phần mềm mà người khiếm thị và thị lực yếu dùng để nghe đọc màn hình) đọc lên, nên nó sẽ đọc, đúng nghĩa đen, là “nút.” Không phải “xóa.” Không phải “sửa.” Chỉ là “nút.”

Các công cụ xây dựng AI rất thích các nút biểu tượng gọn gàng vì trông hiện đại. Nhưng hãy tưởng tượng bạn dùng một ứng dụng mà mọi điều khiển đều được gọi là “nút” và bạn phải tự đoán. Bạn không cần thêm chữ hiển thị vào mọi biểu tượng — bạn cần đảm bảo mỗi điều khiển có một cái tên ẩn bên dưới, dù là vô hình, mà trình đọc màn hình có thể đọc lên. Hãy yêu cầu công cụ xây dựng của bạn: “Gắn nhãn có thể tiếp cận cho mọi nút biểu tượng — biểu tượng thùng rác nên được đọc là ‘Xóa,’ biểu tượng bút chì là ‘Sửa.’” Đó là một thay đổi nhỏ, nhưng là sự khác biệt giữa một ứng dụng mà người khiếm thị có thể điều hướng được và một ứng dụng chỉ toàn những nút vô danh.

Các vùng chạm trên ứng dụng di động nên lớn cỡ nào?

Quy tắc chung mà các nhà thiết kế thường dùng là bất cứ thứ gì có thể chạm vào nên có kích thước khoảng 44 pixel — xấp xỉ đầu ngón tay — cùng với khoảng cách thực sự để hai thứ có thể chạm không bị dồn sát cạnh nhau.

Hãy quan sát ai đó dùng ứng dụng của bạn bằng một tay trên xe buýt. Ngón tay cái to và không chính xác, xe buýt đang di chuyển, còn nút “X” để đóng của bạn chỉ là một chấm 16 pixel ở góc màn hình. Họ chạm trượt hai lần, đụng phải thứ phía sau một lần, rồi bỏ cuộc. Vùng chạm nhỏ và chen chúc không chỉ là điều gây phiền, mà còn là vấn đề khả năng tiếp cận — nó ảnh hưởng nặng nhất đến những người bị run tay, ngón tay to hơn, hoặc đang ở trong môi trường di chuyển. Hãy yêu cầu công cụ xây dựng của bạn: “Làm cho vùng chạm ít nhất là 44 pixel và thêm khoảng cách giữa chúng để người dùng không chạm nhầm.” Sau đó tự kiểm tra: mở ứng dụng trên điện thoại và thử thao tác chính bằng một tay, vừa đi vừa làm. Nếu bạn cứ chạm nhầm, thì mọi người khác cũng vậy.

Làm sao để kiểm tra khả năng tiếp cận của ứng dụng trong năm phút?

Bạn có thể tự mình phát hiện phần lớn những vấn đề này mà không cần công cụ nào, chỉ với ba kiểm tra nhanh trên màn hình mà mọi người dùng nhiều nhất:

Phóng to nó. Tăng cỡ chữ trên điện thoại hoặc trình duyệt lên mức lớn nhất rồi mở màn hình chính. Có gì bị chồng lên nhau, biến mất, hoặc bị cắt mất không?
Rút hết màu sắc. Nhìn vào mọi chỗ ứng dụng của bạn dùng màu sắc để thể hiện điều gì đó — trạng thái, lỗi, trường bắt buộc. Nếu bạn hình dung tất cả chỉ toàn màu xám, bạn vẫn có thể hiểu được chuyện gì đang diễn ra không? Nếu không, hãy thêm một từ hoặc biểu tượng.
Bật trình đọc màn hình trong hai phút. Cả iPhone (VoiceOver) lẫn Android (TalkBack) đều có sẵn tính năng này. Bật nó lên, nhắm mắt lại, và thử làm việc chính mà ứng dụng của bạn hướng tới. Bạn sẽ ngay lập tức nghe ra những nút nào không có tên.

Không cái nào trong số này đòi hỏi bạn phải là lập trình viên. Nó chỉ đòi hỏi bạn ngừng thử nghiệm như chính mình trong năm phút, và thử như một người có đôi tay, đôi mắt, hoặc màn hình khác với bạn.

Bạn không cần sửa mọi thứ cùng một lúc. Hãy chọn màn hình mà mọi người dùng nhiều nhất — biểu mẫu đặt lịch, trang đăng ký, danh sách chính — và làm cho riêng màn hình đó hoạt động tốt khi được phóng to, rút hết màu sắc, và đọc lên thành tiếng. Chỉ một màn hình đó, làm đúng, đã bao phủ được nhiều người hơn cả một cuộc kiểm toán khả năng tiếp cận toàn diện cho những góc khuất chẳng ai ghé qua. Hãy bắt đầu từ đó, và người tiếp theo mở ứng dụng của bạn bằng một ngón cái và một màn hình đã phóng to sẽ được là một người dùng thực thụ, thay vì rời đi ngay lập tức.