title: 無障礙設計——這看起來就是開發者倡議者該做的工作！
published: true
tags: #accessibility, #devrel, #codenewbie, #career
去年年初，我開始擔任一個以無障礙設計為重點的前端工程師新職位。科技無障礙設計（或簡稱 a11y）在疫情期間我研究這個領域，並在社群媒體上與無障礙專業人士交流之後，成了我夢想中的職涯。
特別是當我了解設計時納入 a11y 的考量，不只對身心障礙者與神經多樣性族群有幫助，實際上也常常會帶來讓每個人生活更好的技術時，a11y 就深深吸引了我。最常見的例子之一，是早期發明打字機的動機，很大一部分就是為了方便盲人與低視力者書寫，而現在我們大家都在打字了！同樣地，若在設計網頁應用程式時考慮可用鍵盤操作，除了能讓因為動作障礙而不方便使用滑鼠的人使用之外，也能幫助重度使用者與喜歡快捷鍵的玩家。
但在我開始上手工作、也開始參加 a11y 研討會之後，最大的驚喜之一是：我在無障礙領域中使用的技能，幾乎和我先前夢想中的職涯——開發者關係（Developer Relations，簡稱 devrel）——所培養的技能一模一樣。
無障礙設計和開發者關係其實是出奇相似的技術領域；幾乎任何能幫助開發者倡議者成功的技能，也都能應用在無障礙工作上！如果你想了解我的意思，接下來就來看看我最喜歡的幾個 a11y 與 devrel 的相似之處。如果你正在從事，或有興趣投入，devrel 或無障礙領域，這篇文章就是寫給你的！
社群建立
2017 年讓我想成為開發者倡議者的，不只是那種在各地會議間飛來飛去的浪漫想像（不過老實說，這也不是加分項）。更重要的是，devrel 的工作有很大一部分是圍繞著建立一個互相支持的社群。當我對無障礙設計產生興趣後，很快就發現 a11y 也是社群建立者大放異彩的地方。
一個成功的 devrel 計畫，不只是幫助人們解決你們技術上的問題，也會圍繞著這項技術建立社群。這包括舉辦工作坊、解釋幾乎每個人都很陌生的概念（在像 AI 和代理程式這種變化快速的領域尤其如此！）、撰寫維護良好的 API 文件、到用插畫讓你的程式語言活起來，替它那個可愛的卡通吉祥物畫出你自己的風格的作品。這些都同時能幫助開發者解決技術問題，也讓他們對你和你的團隊接下來要打造的東西充滿期待。
無障礙設計和 devrel 一樣，也非常重視社群。當你開始接觸無障礙相關討論時，最先聽到的事情之一，就是這個領域的跨學科程度有多高。從 UX 設計、UI 工程、產品管理、客服支援、文件撰寫，一直到高階主管，幾乎公司裡每一個角色都要為產品無障礙化盡一份力。一個成功的無障礙計畫，與其說是一個單一團隊，不如說是一個橫跨許多不同團隊與角色的社群。
在這兩個領域中，社群建立的一部分也包括鼓勵社群貢獻。最好的 devrel 專業人士會讓人感受到，像是貢獻他們的開源專案、邀請朋友加入社群，這些行為都會被珍惜。同樣地，最好的無障礙專業人士也很擅長讓不同角色的人明白，他們在自己的崗位上究竟可以做些什麼，來預防無障礙問題並打造可及的產品。
所以不管無障礙還是 devrel 才是你的菜，你已經具備或正在磨練的任何社群建立技能，都會幫助你做出有影響力的工作。
溝通
對 devrel 和 a11y 專業人士來說，社群建立的核心就是成為一個優秀的溝通者：不論是在自己團隊內，或是和那些可能擁有與你不同背景、專業知識與優先順序的人溝通；這些人可能在公司內，也可能是客戶。
開發者倡議者有時某一天會和隊友一起，用真實案例在他們的框架中做出一個示範應用程式；或是撰寫教學文章，精準說明如何解決某個問題。又或者在別的日子裡，他們可能會聽到客戶在使用那個工具時遇到的痛點，然後把這些回饋整合進正在打造的功能，或更完整的文件中。
同樣地，無障礙工作有些日子可能是在與設計師一起檢視設計稿與原型，整理出無障礙需求；另一些日子則可能是把這些需求轉譯成工程團隊能理解的程式規格。也可能是評估無障礙工具，釐清它們的優勢與限制，知道某個工具能解決或不能解決哪些問題，然後把分析整理給利害關係人。又或者，是測試網頁應用程式是否有無障礙錯誤，並把結果寫到足以讓錯誤回報具有可行性的細節程度。
幾乎任何溝通技能都可以是 devrel 或 a11y 的技能，無論是寫作、做技術演講、畫流程圖，還是和客戶交談。所以如果你對這兩個領域中的任何一個有興趣，就持續培養你的溝通能力吧。
順帶一提，雖然無障礙和開發者關係都是「跟人打交道的工作」，但你不必是外向的人才能成為「擅長與人相處的人」。這兩個領域中有很多優秀的溝通者其實都是內向者。比起你的社交風格，更重要的是知道如何從對方當下的處境出發。
從對方當下的處境出發
如果你曾經在某個社群裡寫程式，即使你是新手，也感受到被支持，且當你提問時，別人的回答不會讓你覺得自己被看扁，那就是 devrel 中「從對方當下的處境出發」所產生影響的絕佳例子。事實上，這正是我在 Go 社群中愛上 devrel 的原因！不論在 devrel 之內或之外，Gophers 都是一個沒有「新手問題」的社群。
同樣地，從對方當下的處境出發也是一項關鍵的無障礙技能，因為它對跨角色協作至關重要。不同角色的人在解決不同的問題、使用不同的術語，就算是同一個角色的人，無障礙技能組合也可能差異很大。舉例來說，有些人可能對色彩對比掌握得很好，但對螢幕閱讀器測試還很陌生。他們可能已經學過如何設計動畫來避免引發癲癇，卻還不熟悉如何設計應用程式版面，讓自閉症者在瀏覽時覺得直覺易用；而這方面的最佳實務仍在持續形成中。
而談到從對方當下的處境出發，這個「當下的處境」有時候也可能是壓力很大、很挫折的情境。能撰寫清楚且附有真實範例文件的開發者倡議者，對於在緊迫期限下導入某個框架的人來說，簡直是救星。同樣地，把產品做到無障礙所需的工作量，往往還得第一次學習新技能，這真的會讓人很沮喪。所以，如果你能主動提供建議，告訴別的角色的人可以先做什麼來解決無障礙問題，就能幫隊友建立起前進的動能與解題直覺。
這就是為什麼情緒智商在這兩個領域之間都很通用；事實上，我認為它是職涯中最重要的技能之一。雖然這通常被稱為「軟技能」，但我更喜歡 April Wensel 使用的說法：「催化型技能」。無論在 a11y 還是 devrel，如果你能以同理心，從不同角色或不同學習方式出發去教導他人，你就是在催化別人的成功！
樂趣感
最後，無障礙設計和 devrel 都是很適合發揮你「有趣感」的領域。就像我前面提到的，社群建立是成功的 a11y 計畫與成功的 devrel 計畫的核心。而其中很重要的一環，就是幫助人們認同自己是你正在協助建立的社群的一部分。讓社群變得有趣、好參與，對營造那種歡迎感很有幫助！
在 devrel 中，對於領域外的人來說，最容易被看見的例子大概就是開發者倡議者在科技活動上發送的貼紙和贈品。但更重要的，其實是讓科技社群變得有趣的那些無形方式。舉例來說，我從 #CodeNewbie 創辦人 Saron Yitbarek 的一段影片中學到的、關於技術公開演講最好的建議之一，就是要從說故事的角度來準備，而不是把它當成大學課堂演講。
順帶一提，#CodeNewbie 社群本身就是 devrel 中「有趣」與「支持性」的絕佳例子，它促成了許多和正在學習或從事各種科技領域的人之間的精彩對話，大家熱情分享想法、彼此鼓勵，當然還有大量的動畫 GIF。就像和 Gophers 混在一起讓我對 devrel 產生興趣一樣，和 #CodeNewbie 聊天中的 a11y 專業人士交流，也讓我對無障礙設計萌生了興趣！
在無障礙設計方面，樂趣感同樣會激發人們對 a11y 的整體好奇心，也會激發出帶來優秀創新的好奇心。例如，在上一屆 CSUN 輔助科技研討會上，我除了自己的工作之外，最喜歡的一場演講，是關於打造完全以聲音為基礎的電腦遊戲。那是我第一次聽到音訊遊戲這個概念，讓我既想親自試玩，也想知道這種技術還能如何被用來創造更有生命力的網頁體驗，不論你是視障者，還是有視力或低視力。最近我也一直在想，圍繞螢幕閱讀器與鍵盤導覽設計一款遊戲，或許能讓更多開發者熟悉這兩種導覽方式。
我希望這篇文章能讓你看見，無障礙設計和 devrel 就像同一個鍋裡的兩顆豆子一樣密不可分。現在我很想知道，你覺得 a11y 和 devrel 之間還有哪些相似之處？或者如果你正準備轉職進入這兩個領域中的任何一個，你覺得 a11y/devrel 和你原本的領域之間有哪些相似處？
原文出處：https://dev.to/andyhaskell/accessibility-this-looks-like-a-job-for-a-developer-advocate-2a12
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
