"Ôi trời, ứng dụng của mình đã thành công mà lại không tính đến khả năng truy cập"

Nhanh chóng áp dụng a11y (khả năng truy cập) trong SwiftUI

• Đưa ra cách khắc phục nhanh khi đã bỏ qua khả năng truy cập trong ứng dụng SwiftUI.
• Khả năng truy cập là một tính năng quan trọng mà 16% người dùng cần đến, nhưng thường bị bỏ qua trong quá trình phát triển.
• Ứng dụng không tính đến khả năng truy cập có thể để lại ấn tượng tiêu cực cho người dùng.

Kiểm tra khả năng truy cập của ứng dụng

• Điều quan trọng là phải kiểm thử khả năng truy cập trên thiết bị thật.
• Thiết lập tối ưu Trung tâm điều khiển để có thể nhanh chóng bật các tính năng khả năng truy cập.

Kiểm tra kích thước văn bản

• Trên iOS có 12 mức kích thước văn bản; cần kiểm thử để xác nhận ứng dụng hiển thị tốt ở từng mức.
• Cần kiểm tra xem UI có còn hoạt động ổn định ngay cả ở mức chữ lớn nhất hay không.

Kiểm tra trình đọc màn hình

• Với người dùng sử dụng trình đọc màn hình, hãy kiểm tra khả năng truy cập bằng các công cụ như VoiceOver.
• Chỉ với những chỉnh sửa đơn giản như thêm nhãn khả năng truy cập cho hình ảnh cũng có thể mang lại cải thiện lớn.

Nhanh chóng áp dụng khả năng truy cập

• Sau khi xác định được vấn đề, hãy xử lý nhanh từng vấn đề một.

Nội dung có thể cuộn

• Khi kích thước chữ tăng lên, có thể giải quyết vấn đề bằng cách mở rộng nội dung vào ScrollView.
• Sử dụng custom view modifier a11yScrollView() để chỉ cho phép nội dung cuộn khi thực sự cần.

Mùi mã khi cố tạo khoảng trống

• Thay vì Spacer(), hãy dùng modifier frame() để tạo bố cục đáng tin cậy hơn.

Điều chỉnh kích thước hình ảnh và biểu tượng

• Dùng property wrapper @ScaledMetric để điều chỉnh động kích thước hình ảnh và biểu tượng theo cỡ chữ của người dùng.

Căn chỉnh nội dung

• Sử dụng A11yHStack để căn chỉnh nội dung theo kích thước chữ của người dùng.

Cải thiện trình đọc màn hình

• Dùng accessibilityLabel, accessibilityElement(children:), accessibilityRepresentation v.v. để tăng khả năng tương thích với trình đọc màn hình.

Sử dụng component native

• Hãy dùng các component SwiftUI native bất cứ khi nào có thể để cải thiện hiệu năng và khả năng truy cập.

Thuyết phục các bên liên quan

• Cách tạo ảnh hưởng trong tổ chức để mọi người coi trọng khả năng truy cập.
• Nhấn mạnh các yêu cầu pháp lý và lợi ích kinh doanh để làm nổi bật tầm quan trọng của khả năng truy cập.

Kết luận

• Giải thích toàn bộ quy trình xác định và xử lý các vấn đề về khả năng truy cập của ứng dụng.
• Giới thiệu nhiều công cụ và kỹ thuật mà SwiftUI cung cấp để cải thiện khả năng truy cập.

Ý kiến của GN⁺

• Bài viết này rất hữu ích cho các nhà phát triển ứng dụng vì nêu rõ vì sao khả năng truy cập lại quan trọng và đưa ra những cách cụ thể để cải thiện trong thực tế.
• Ứng dụng không tính đến khả năng truy cập có thể làm giảm trải nghiệm người dùng và dẫn đến rủi ro pháp lý, vì vậy cần cân nhắc yếu tố này ngay từ giai đoạn đầu phát triển.
• Khi sử dụng framework hiện đại như SwiftUI, nên tận dụng tối đa lợi thế của các component native để đồng thời cải thiện hiệu năng và khả năng truy cập.
• Tận dụng các thư viện và công cụ do cộng đồng cung cấp để cải thiện khả năng truy cập cũng là một cách hay, giúp đơn giản hóa quy trình phát triển và tăng hiệu quả.
• Cải thiện khả năng truy cập không chỉ là vấn đề kỹ thuật mà còn là thực hành trách nhiệm xã hội và tính bao trùm, bảo đảm mọi người dùng đều có thể sử dụng dịch vụ một cách bình đẳng.

[aer0700]

Có lẽ việc cân nhắc khả năng tiếp cận cũng là một cách để tạo ra những khách hàng trung thành với dịch vụ của mình. Nếu các dịch vụ cạnh tranh tương tự không hỗ trợ tính năng đó mà chỉ ứng dụng của chúng ta hỗ trợ, thì khách hàng sẽ sử dụng sản phẩm của chúng ta.

[godrm]

Ồ, cái này cũng nên giới thiệu trên Let’s Swift nữa haha

[GN⁺]

Ý kiến trên Hacker News

• Tóm tắt bình luận thứ nhất:

  Nhà phát triển không đồng ý với quan điểm của tác giả rằng “sẽ không dừng lại cho tới khi mọi người đều có thể sử dụng ứng dụng”. Mọi ứng dụng họ phát triển đều được xây dựng để phù hợp với nhiều người dùng nhất có thể, miễn là không phải hy sinh các yêu cầu kinh doanh hoặc những khía cạnh quan trọng/cốt lõi của ứng dụng. Nếu không thì sản phẩm sẽ trở nên không thể sử dụng được.

• Tóm tắt bình luận thứ hai:

  Nhà phát triển luôn cố gắng hết sức để người khiếm thị cũng có thể dùng ứng dụng của mình. Ở ứng dụng gần đây, họ tìm ra cách vừa giúp người không có khuyết tật dễ sử dụng hơn, vừa mang lại lợi ích cho người khuyết tật. Họ đã thêm tính năng “trợ giúp nhấn giữ”, trong đó nhấn giữ lâu vào bất kỳ phần tử UI nào sẽ hiện một popover giải thích phần tử đó. Tính năng này hoạt động tốt nhờ dùng nhãn và gợi ý trợ năng.

• Tóm tắt bình luận thứ ba:

  Đánh giá tích cực về một bài viết thực tế. Họ cho rằng trợ năng là quan trọng, nhưng việc gọi các nhà phát triển không mặc định làm ứng dụng có trợ năng tốt là lười biếng thì có vấn đề. Có rất nhiều khái niệm phải học, các ưu tiên thường xung đột, có những công cụ cần phải làm quen, và cũng cần xây dựng được luận điểm kinh doanh cho trợ năng. Phần lớn nhà phát triển và nhà thiết kế không hiểu rõ các quy tắc WCAG. Ngay cả việc tìm màu thương hiệu đáp ứng yêu cầu về độ tương phản cũng rất khó.

• Tóm tắt bình luận thứ tư:

  Nhà phát triển đã tạo ứng dụng bằng Flutter mà không nghĩ tới trợ năng, nhưng sau đó nhận được phàn nàn từ một người dùng khiếm thị đã dùng ứng dụng suốt 6 tháng. Flutter tự động xử lý phần lớn vấn đề trợ năng, và các tính năng tùy biến cũng hoạt động tốt cho người khiếm thị mà không cần sửa đổi lớn.

• Tóm tắt bình luận thứ năm:

  Đặt câu hỏi vì sao phải ưu tiên hiển thị các tùy chọn trợ năng về mặt thị giác và gắn chú thích lên một môi trường vốn cần độ chính xác cao và mật độ chạm dày đặc. Có lẽ sẽ tốt hơn nếu cung cấp các phiên bản ứng dụng được tùy chỉnh cho người cần trợ năng, như phiên bản “thị lực kém” hoặc “độ chính xác chạm thấp”.

• Tóm tắt bình luận thứ sáu:

  Đặt câu hỏi về trách nhiệm pháp lý hoặc thời gian ân hạn khi một ứng dụng mới hay startup thành công nhanh hơn nhiều so với dự kiến. Khi chưa chắc ý tưởng có hiệu quả hay không, trợ năng có thể không phải là mối lo lớn; và ngoài California, họ cho rằng nhìn chung sẽ không gặp rắc rối pháp lý nghiêm trọng nếu phân bổ nguồn lực để xử lý vấn đề trợ năng sau một thành công ngoài mong đợi.

• Tóm tắt bình luận thứ bảy:

  Chia sẻ trải nghiệm của cha nhà phát triển phải dùng xe lăn điện sau khi bị đột quỵ. Điều đó khiến họ nhận ra tầm quan trọng của việc tuân thủ ADA, đồng thời nhấn mạnh rằng với tư cách là nhà phát triển, chúng ta có thể đóng vai trò rất lớn trong việc làm cho thế giới dễ tiếp cận hơn. Họ kêu gọi các nhà phát triển nỗ lực để công việc của mình có thể được tiếp cận bởi mọi người trong khả năng có thể.

• Tóm tắt bình luận thứ tám:

  Chia sẻ trải nghiệm của một người dùng đã bật các tùy chọn “Văn bản lớn hơn” và “Thu phóng màn hình” trên iPhone. Đây không chỉ là chuyện dành cho người khuyết tật, mà còn là về sự linh hoạt và khả năng kiểm soát để mọi người dùng có thể điều chỉnh giao diện theo cách sử dụng của mình. Đôi khi họ không muốn nhìn vào màn hình mà muốn máy đọc nội dung trên màn hình, hoặc chỉ đọc một phần cụ thể.

• Tóm tắt bình luận thứ chín:

  Cộng đồng cần trợ năng nhìn chung có xu hướng yêu cầu trước rồi mới kiện sau. ADA là một bộ luật mạnh, nhưng nếu có nỗ lực thì thường sẽ không thành vấn đề. Khoảng năm 2000, họ từng viết hướng dẫn về trợ năng dưới sự giám sát của luật sư, và sau đó tiếp tục làm việc với người dùng khiếm thị để bổ sung trợ năng cho ứng dụng. Nếu ai đó yêu cầu, hãy giúp họ; làm vậy bạn có thể có được một người ủng hộ rất mạnh cho những gì mình đang làm.

• Tóm tắt bình luận thứ mười:

  Lý do ứng dụng thành công là vì đã không lãng phí thời gian vào những thứ không cần thiết như accessibility (a11y) hay internationalization (i18n). Trong lịch sử, không có sản phẩm thành công nào tập trung vào trợ năng hay quốc tế hóa ngay từ đầu. Giờ ứng dụng đã thành công, nên có thể nghĩ tới trợ năng và đầu tư nguồn lực cho nó.