Hướng tới khả năng tiếp cận

Hướng tới khả năng tiếp cận

Thứ Sáu là ngày kết thúc ngày làm việc. Tin xấu luôn đến vào cuối ngày làm việc thứ Sáu.

Bạn chuẩn bị rời văn phòng thì một lá thư mới về một cuộc tái tổ chức khác vừa được gửi đến.

Cảm ơn bạn xxxx, yyy từ hôm nay bạn sẽ báo cáo zzzz
...
Và nhóm của Hugh sẽ đảm bảo sản phẩm của chúng tôi có thể tiếp cận được với người khuyết tật.

Ôi không! Tại sao tôi đáng bị như vậy? Họ có muốn tôi rời đi không? Hãy chuẩn bị tinh thần làm việc chăm chỉ và cố gắng sửa chữa lỗi lầm của người khác. Đây chắc chắn là một thất bại...

Đây là sự sẵn có một vài năm trước. Một số linh hồn tội nghiệp đã được giao công việc "dọn dẹp" giao diện người dùng để cố gắng giúp người khuyết tật có thể truy cập được.

Ý nghĩa thực sự của điều này khá mơ hồ - có lẽ nếu bạn có thể thấy chỉ báo tiêu điểm và tab qua các trường, có một số văn bản thay thế và một vài mô tả trường, thì ứng dụng của bạn có thể truy cập được ...

Nhưng đột nhiên số lượng “bọ” bắt đầu sinh sôi với tốc độ như một trận tuyết lở.

Trình đọc màn hình khác nhau (Eng. Trình đọc màn hình) và trình duyệt hoạt động hoàn toàn khác nhau.

Người dùng phàn nàn rằng ứng dụng không thể sử dụng được.

Ngay khi một lỗi được sửa ở nơi này, một lỗi khác lại xuất hiện ở nơi khác.

Và chỉ cần thay đổi và sửa lỗi giao diện người dùng cũng cần đến nỗ lực của Herculean.

Tôi đã ở đó. Tôi đã sống sót, nhưng chúng tôi đã không "thành công" - về mặt kỹ thuật, chúng tôi đã dọn dẹp rất nhiều, thêm nhiều mô tả lĩnh vực, vai trò và đạt được một số mức độ tuân thủ, nhưng không ai hài lòng. Người dùng vẫn phàn nàn rằng họ không thể điều hướng ứng dụng. Người quản lý vẫn phàn nàn về những lỗi xảy ra liên tục. Các kỹ sư phàn nàn rằng vấn đề được đặt ra không chính xác và không có giải pháp “đúng” nào được xác định rõ ràng để có thể giải quyết được trong mọi trường hợp.

Có một số khoảnh khắc mở mang tầm mắt của tôi trong suốt hành trình tìm hiểu khả năng tiếp cận của tôi.
Có lẽ điều đầu tiên là việc nhận ra rằng việc thêm chức năng trợ năng lên trên sản phẩm hoàn chỉnh là rất khó. Và việc thuyết phục các nhà quản lý rằng điều đó cực kỳ khó khăn! Không, không chỉ là "thêm một vài thẻ" và giao diện người dùng sẽ hoạt động tốt. Không, việc này không thể hoàn thành trong ba tuần; thậm chí ba tháng cũng không đủ.
Khoảnh khắc sự thật tiếp theo của tôi đến khi tôi tận mắt chứng kiến ​​người mù thực sự sử dụng ứng dụng của chúng tôi như thế nào. Điều này thật khác với việc xem thông báo lỗi.

Tôi sẽ quay lại vấn đề này nhiều lần, nhưng hầu như tất cả "giả định" của chúng tôi về cách mọi người sử dụng ứng dụng của chúng tôi đều sai.

Điều hướng giao diện người dùng phức tạp bằng tổ hợp phím Tab/Shift+Tab – điều này thật tệ! Chúng ta cần thứ gì đó tốt hơn. Phím tắt, tiêu đề.

Mất tập trung khi thay đổi giao diện người dùng không phải là vấn đề lớn phải không? Hãy suy nghĩ lại - điều này thật khó hiểu.

Tôi tiếp tục, làm việc trên các dự án khác nhau trong một thời gian và sau đó chúng tôi bắt đầu một dự án mới, với giao diện người dùng phức tạp và cài đặt rõ ràng, để cuối cùng lần này chúng tôi có được khả năng truy cập.

Vì vậy, chúng tôi đã lùi lại một bước và xem xét cách chúng tôi có thể triển khai điều này một cách khác biệt và thành công, đồng thời làm cho quá trình bớt nhàm chán hơn!

Rất nhanh chóng chúng tôi đã đi đến một số kết luận:

  1. Chúng tôi không muốn những người phát triển giao diện người dùng gặp rắc rối với các nhãn/vai trò aria và tất nhiên là cả cấu trúc HTML của các thành phần. Chúng tôi cần cung cấp cho họ những thành phần phù hợp để xây dựng khả năng truy cập ngay lập tức.
  2. Khả năng tiếp cận == Dễ sử dụng – tức là. Đây không chỉ là một thách thức kỹ thuật. Chúng tôi cần thay đổi toàn bộ quy trình thiết kế và đảm bảo rằng khả năng tiếp cận đã được tính đến và thảo luận trước khi bắt đầu thiết kế giao diện người dùng. Bạn cần suy nghĩ sớm về cách người dùng sẽ khám phá bất kỳ chức năng nào, cách họ sẽ điều hướng và cách nhấp chuột phải từ bàn phím sẽ hoạt động. Khả năng truy cập phải là một phần không thể thiếu trong quá trình thiết kế - đối với một số người dùng, khả năng truy cập không chỉ là vẻ ngoài của ứng dụng.
  3. Ngay từ đầu, chúng tôi muốn nhận được phản hồi từ người dùng mù và người khuyết tật khác về tính dễ sử dụng của ứng dụng.
  4. Chúng tôi cần những cách thực sự tốt để nắm bắt các hồi quy về khả năng tiếp cận.

Chà, từ quan điểm kỹ thuật, phần đầu tiên nghe có vẻ khá thú vị - phát triển kiến ​​trúc và triển khai thư viện các thành phần. Và quả thực nó đã như vậy.

Lùi lại một bước, nhìn Ví dụ về ARIA và bằng cách coi đây là một vấn đề thiết kế chứ không phải là một vấn đề "phù hợp", chúng tôi đã đưa ra một số khái niệm trừu tượng. Một thành phần có 'Cấu trúc' (bao gồm các phần tử HTML) và 'Hành vi' (cách nó tương tác với người dùng). Ví dụ: trong đoạn trích bên dưới, chúng ta có một danh sách không có thứ tự đơn giản. Bằng cách thêm "hành vi", các vai trò tương ứng sẽ được thêm vào danh sách để làm cho nó hoạt động giống như một danh sách. Chúng tôi làm tương tự cho menu.

Hướng tới khả năng tiếp cận

Trên thực tế, không chỉ các vai trò được thêm vào đây mà còn cả các trình xử lý sự kiện để điều hướng bằng bàn phím.

Điều này trông gọn gàng hơn. Nếu chúng ta có thể có được sự tách biệt rõ ràng giữa chúng, thì cấu trúc được tạo ra như thế nào cũng không thành vấn đề, chúng ta có thể áp dụng Hành vi cho nó và có được khả năng truy cập phù hợp.

Bạn có thể thấy điều này trong thực tế tại https://stardust-ui.github.io/react/ – Thư viện UX Phản ứng, được thiết kế và triển khai có tính đến khả năng tiếp cận ngay từ đầu.

Phần thứ hai - việc thay đổi cách tiếp cận và quy trình thiết kế ban đầu khiến tôi sợ hãi: các kỹ sư cấp thấp đang cố gắng thực hiện thay đổi tổ chức không phải lúc nào cũng kết thúc tốt đẹp, nhưng hóa ra đó lại là một trong những lĩnh vực thú vị nhất mà chúng tôi đã có những đóng góp đáng kể cho quy trình này. . Tóm lại, quy trình của chúng tôi như sau: chức năng mới sẽ được phát triển bởi một nhóm, sau đó nhóm lãnh đạo của chúng tôi sẽ xem xét/lặp lại đề xuất và sau đó, sau khi được phê duyệt, thiết kế thường sẽ được chuyển giao cho nhóm kỹ thuật. Trong trường hợp này, nhóm kỹ thuật đã “sở hữu” chức năng trợ năng một cách hiệu quả vì họ có trách nhiệm khắc phục mọi sự cố liên quan đến chức năng đó.

Ban đầu, việc giải thích rằng khả năng tiếp cận và khả năng sử dụng có mối liên hệ chặt chẽ với nhau là một công việc khá khó khăn và điều này phải được thực hiện ở giai đoạn thiết kế, nếu không sẽ dẫn đến những thay đổi lớn và xác định lại một số vai trò. Tuy nhiên, với sự hỗ trợ của ban quản lý và những người đóng vai trò chủ chốt, chúng tôi đã lên ý tưởng và thực hiện nó để các thiết kế được kiểm tra khả năng tiếp cận và khả năng sử dụng trước khi chúng được trình bày cho ban quản lý.

Và phản hồi này cực kỳ có giá trị đối với mọi người - thật tuyệt vời như một bài tập chia sẻ/giao tiếp kiến ​​thức về cách người dùng tương tác với các ứng dụng web, chúng tôi đã xác định nhiều vấn đề về giao diện người dùng trước khi chúng được xây dựng, các nhóm phát triển hiện có thông số kỹ thuật tốt hơn nhiều về không chỉ các khía cạnh trực quan mà còn cả hành vi của thiết kế. Các cuộc thảo luận thực sự là những cuộc thảo luận vui vẻ, sôi nổi, sôi nổi về các khía cạnh kỹ thuật và tương tác.

Chúng tôi có thể làm điều này thậm chí còn tốt hơn nếu chúng tôi có người dùng mù và khuyết tật tại các cuộc họp này (hoặc các cuộc họp tiếp theo) - việc tổ chức này rất khó nhưng hiện tại chúng tôi đang làm việc với cả các tổ chức và công ty dành cho người mù ở địa phương, những nơi cung cấp thử nghiệm bên ngoài để xác minh sớm quy trình thực hiện trong phát triển—cả ở cấp độ thành phần và cấp độ thực thi.

Các kỹ sư hiện có các thông số kỹ thuật khá chi tiết, các thành phần có sẵn mà họ có thể sử dụng để triển khai và cách xác thực quy trình thực thi. Một phần của những gì kinh nghiệm đã dạy chúng ta là điều mà chúng ta đã bỏ lỡ bấy lâu nay – làm thế nào chúng ta có thể ngăn chặn sự hồi quy. Tương tự như vậy, mọi người có thể sử dụng thử nghiệm tích hợp hoặc thử nghiệm toàn diện để kiểm tra chức năng mà chúng tôi cần để phát hiện những thay đổi trong tương tác và luồng thực thi—cả trực quan và hành vi.

Xác định hồi quy trực quan là một nhiệm vụ được xác định rõ ràng, có rất ít thứ có thể được thêm vào quy trình ngoài việc kiểm tra xem tiêu điểm có hiển thị khi điều hướng bằng bàn phím hay không. Thú vị hơn là hai công nghệ tương đối mới để làm việc với khả năng tiếp cận.

  1. Thông tin chi tiết là một bộ công cụ có thể chạy cả trong trình duyệt và như một phần của chu trình xây dựng/kiểm tra để xác định sự cố.
  2. Việc xác minh rằng trình đọc màn hình hoạt động chính xác là một nhiệm vụ đặc biệt khó khăn. Với việc giới thiệu quyền truy cập vào DOM khả năng truy cập, cuối cùng chúng tôi cũng có thể chụp ảnh nhanh khả năng truy cập của ứng dụng, giống như cách chúng tôi thực hiện kiểm tra trực quan và kiểm tra khả năng hồi quy của chúng.

Vì vậy, trong phần thứ hai của câu chuyện, chúng tôi đã chuyển từ chỉnh sửa mã HTML sang làm việc ở mức độ trừu tượng cao hơn, thay đổi quy trình phát triển thiết kế và giới thiệu thử nghiệm kỹ lưỡng. Các quy trình mới, công nghệ mới và mức độ trừu tượng mới đã thay đổi hoàn toàn bối cảnh về khả năng tiếp cận và ý nghĩa của việc làm việc trong không gian này.
Nhưng điều này chỉ là khởi đầu.

“Hiểu biết” tiếp theo là người dùng mù đang sử dụng công nghệ tiên tiến - họ là những người được hưởng lợi nhiều nhất không chỉ từ những thay đổi mà chúng tôi đã mô tả trước đó mà còn từ những cách tiếp cận và ý tưởng mới nhờ ML/AI. Ví dụ: công nghệ Immersive Reader cho phép người dùng trình bày văn bản dễ dàng và rõ ràng hơn. Nó có thể được đọc to, cấu trúc câu được chia nhỏ theo ngữ pháp và thậm chí ý nghĩa của từ cũng được hiển thị bằng đồ họa. Điều này hoàn toàn không phù hợp với tâm lý "làm cho nó có thể truy cập được" cũ - đó là một tính năng hữu dụng sẽ giúp ích cho tất cả mọi người.

ML/AI đang tạo ra những cách tương tác và làm việc hoàn toàn mới và chúng tôi rất vui mừng được trở thành một phần trong các giai đoạn tiếp theo của hành trình tiên tiến này. Sự đổi mới được thúc đẩy bởi sự thay đổi trong suy nghĩ - nhân loại đã tồn tại hàng thiên niên kỷ, máy móc hàng trăm năm, trang web trong vài thập kỷ và điện thoại thông minh thậm chí còn ít hơn, công nghệ phải thích ứng với con người chứ không phải ngược lại.

PS Bài viết đã được dịch có sai lệch nhỏ so với bản gốc. Với tư cách là đồng tác giả của bài viết này, tôi đồng ý với Hugh về những điều lạc đề này.

Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. Đăng nhập, xin vui lòng.

Bạn có chú ý đến khả năng tiếp cận các ứng dụng của mình không?

  • vâng

  • Không

  • Đây là lần đầu tiên tôi nghe nói về khả năng truy cập ứng dụng.

17 người dùng bình chọn. 5 người dùng bỏ phiếu trắng.

Nguồn: www.habr.com

Thêm một lời nhận xét