星期五是工作日的結束時間。 壞消息總是在周五工作日結束時傳來。
您即將離開辦公室，一封關於另一次重組的新信剛剛寄到。
謝謝xxxx，yyy從今天起你檢舉zzzz
...
休的團隊將確保身心障礙者也能使用我們的產品。
不好了！ 為什麼這是我應得的？ 他們要我離開嗎？ 讓自己做好吃力不討好的努力，並努力糾正別人的錯誤。 這絕對是失敗的...
這是幾年前的可用性。 一些可憐的人被賦予了「清理」使用者介面的工作，試圖讓殘疾人可以使用它。
這實際上意味著什麼是相當模糊的- 大概如果您可以通過字段看到焦點指示器和選項卡，有一些替代文本和幾個字段描述，那麼就會認為您的應用程序是可訪問的.. ....
但突然之間，「蟲子」開始以雪崩的速度繁殖。
各種螢幕閱讀器（英語 螢幕閱讀器）和瀏覽器的行為完全不同。
用戶抱怨該應用程式無法使用。
一旦一個地方的錯誤被糾正，另一個地方就會出現另一個錯誤。
僅僅改變和糾正使用者介面錯誤就需要付出巨大的努力。
我在那裡。 我活了下來，但我們並沒有「成功」——技術上我們清理了很多，添加了很多字段描述、角色，並實現了一定程度的合規性，但沒有人高興。 用戶仍然抱怨他們無法導航該應用程式。 經理仍然抱怨不斷出現錯誤。 工程師抱怨說，問題的提出不正確，沒有明確定義的適用於所有情況的「正確」解決方案。
在我了解可訪問性的過程中，有一些絕對令人大開眼界的時刻。
也許第一個是要認識到在成品上添加輔助功能是很困難的。 更難讓經理們相信這是極為困難的！ 不，這不僅僅是“添加一些標籤”，用戶介面就能正常工作。 不，這不可能在三週內完成，甚至三個月也不夠。
當我親眼目睹盲人用戶如何實際使用我們的應用程式時，我的下一個關鍵時刻到來了。 這與查看錯誤訊息非常不同。
我會一次又一次地回顧這一點，但幾乎所有關於人們如何使用我們的應用程式的「假設」都是錯誤的。
使用按鍵導航複雜的使用者介面 Tab/Shift+Tab – 這太糟糕了！ 我們需要更好的東西。 鍵盤快速鍵、標題。
更改 UI 時失去焦點並不是一個大問題，不是嗎？ 讓我們再想想——這太令人困惑了。
我繼續，在不同的項目上工作了一段時間，然後我們開始了一個新項目，具有複雜的用戶界面和清晰的安裝，這次終於獲得了可訪問性。
因此，我們退後一步，研究如何以不同的方式實施這一點並取得成功，並使過程不再那麼無聊！
很快我們就得出了一些結論：
- 我們不希望開發使用者介面的人來弄亂 aria 標籤/角色，當然還有組件的 HTML 結構。 我們需要為他們提供正確的元件，以實現開箱即用的可訪問性。
- 可訪問性==易於使用—即這不僅僅是一個技術挑戰。 我們需要改變整個設計流程，並確保在 UI 設計開始之前考慮並討論可訪問性。 您需要儘早考慮用戶將如何發現任何功能、他們將如何導航以及如何透過鍵盤右鍵單擊。 可訪問性應該是設計過程中不可或缺的一部分 - 對於某些用戶來說，它不僅僅是應用程式的外觀。
- 從一開始，我們就希望獲得盲人和其他殘疾人用戶對應用程式易用性的回饋。
- 我們需要非常好的方法來捕捉可訪問性回歸。
嗯，從工程的角度來看，第一部分聽起來很有趣——開發一個架構並實作一個元件庫。 確實如此。
退一步看 透過將其視為設計問題而不是「適應」問題，我們引入了一些抽象。 元件具有“結構”（由 HTML 元素組成）和“行為”（它如何與使用者互動）。 例如，在下面的程式碼片段中，我們有一個簡單的無序列表。 透過添加“行為”，相應的角色將被添加到列表中，使其像列表一樣工作。 我們對菜單也做同樣的事情。
事實上，這裡不僅新增了角色，還新增了鍵盤導航的事件處理程序。
這看起來更整潔。 如果我們能夠在它們之間得到清晰的分離，那麼結構是如何創建的並不重要，我們可以對其應用行為並獲得正確的可訪問性。
您可以在以下位置查看此操作的實際效果： – 使用者體驗庫 ，其設計和實施從一開始就考慮到了可訪問性。
第二部分——改變設計的方法和流程最初讓我感到害怕：試圖推動組織變革的低階工程師並不總是有好結果，但事實證明這是我們為流程做出重大貢獻的最有趣的領域之一。 簡而言之，我們的流程如下：新功能將由一個團隊開發，然後我們的領導團隊將審查/迭代提案，然後，一旦獲得批准，設計通常會移交給工程團隊。 在這種情況下，工程團隊實際上「擁有」可訪問性功能，因為他們有責任解決與之相關的任何問題。
一開始，要解釋可訪問性和可用性是密不可分的，並且必須在設計階段完成，這是一項相當困難的工作，否則會導致一些角色的重大變化和重新定義。 然而，在管理層和關鍵參與者的支持下，我們採納了這個想法並將其付諸實施，以便在將設計提交給管理層之前對其可訪問性和可用性進行測試。
這個回饋對每個人來說都非常有價值 - 作為關於用戶如何與 Web 應用程式互動的知識共享/交流的練習，我們在構建之前識別了許多 UI 問題領域，現在的開發團隊有了更好的規範不僅是視覺方面，還包括設計的行為方面。 真正的討論是關於技術面和互動的有趣、充滿活力、熱情的討論。
如果我們在這些（或後續）會議上有盲人和殘疾用戶，我們可以做得更好 - 這很難組織，但我們現在確實與當地盲人組織和公司合作，他們提供外部測試以在早期驗證執行流程開發——元件層級和執行流程層級。
工程師現在擁有相當詳細的規範、可用於實施的可用元件以及驗證執行流程的方法。 經驗告訴我們的部分內容是我們一直以來缺少的——如何阻止倒退。 同樣，人們可以使用整合或端到端測試來測試功能，我們需要檢測互動和執行流程（視覺和行為）的變化。
確定視覺回歸是一項明確定義的任務，除了檢查使用鍵盤導航時焦點是否可見之外，幾乎沒有任何東西可以添加到該過程中。 更有趣的是兩種相對較新的可訪問性技術。
- 是一組工具，可以在瀏覽器中運行，也可以作為建置/測試週期的一部分來識別問題。
- 驗證螢幕閱讀器是否正常運作是一項特別具有挑戰性的任務。 隨著訪問權限的引入 可訪問性 DOM，我們終於能夠拍攝應用程式的可訪問性快照，就像我們在視覺測試中所做的那樣，並測試它們的回歸。
因此，在故事的第二部分中，我們從編輯 HTML 程式碼轉向更高抽象層級的工作，改變了設計開發流程並引入了徹底的測試。 新流程、新技術和新的抽象層次徹底改變了可訪問性的格局以及在這個領域工作的意義。
但這只是開始。
下一個「理解」是盲人使用者正在推動尖端技術——他們不僅是我們前面描述的變化的最大受益者，而且是機器學習/人工智慧帶來的新方法和想法的受益者。 例如，沉浸式閱讀器技術可以讓使用者更輕鬆、清晰地呈現文字。 它可以大聲朗讀，句子結構可以按語法分解，甚至單字含義也可以以圖形方式顯示。 這根本不符合舊的“使其易於訪問”的心態 - 這是一個可以幫助每個人的可用性功能。
機器學習/人工智慧正在實現全新的互動和工作方式，我們很高興能夠成為這趟前沿旅程的下一階段的一部分。 創新是由思維的變化所驅動的——人類已經存在了幾千年，機器已經存在了幾百年，網站已經存在了幾十年，而智慧型手機更不用說，技術必須適應人，而不是相反。
PS本文經過翻譯，與原文略有偏差。 身為本文的合著者，我同意休的這些離題觀點。
只有註冊用戶才能參與調查。 ， 請。
您是否關注應用程式的可訪問性？
-
Да
-
沒有
-
這是我第一次聽說應用程式可訪問性。
17 位用戶投票。 5 名用戶棄權。
來源： www.habr.com