- 參與無障礙專案的經驗帶來了哪些學習與啟發？
- 在前公司打造針對身障者產品的經驗，有什麼不同的面向？
- 在公司內部推動 accessibility 的經驗，遇到哪些挑戰?
- 前端工程師對 accessibility 的了解可以帶來哪些優勢？
- 前端工程師可以如何學習 accessibility 的資源和建議？
今天與我們對談的是 Jamie ，一位擁有豐富前端經驗的工程師。他從踏入前端領域初期就加入 Coseeing (附註) 雲端千眼專案的開發，過去也曾經任職於關心身障族群的社會企業。作為一名前端工程師，Jamie 在參與 Coseeing 的 side project 過程中積累了哪些寶貴的知識和經驗？在日常工作中做了哪些推動無障礙的努力？以及這些經驗對他的前端工程師的職涯帶來哪些影響？讓我們來看看 Jamie 的這些經歷如何影響他的職涯與對無障礙開發的見解吧！
NOTE
Coseeing 是一個以科技人所組成的志工社群，透過開發工具讓視障者看見更多資訊和可能；透過推廣活動讓大眾看見障礙者的實際情況和需求。希望以不同的形式與持續的行動，讓所有人都能共同看見這精采的世界以及獨特的彼此。
其實我一開始純粹是想找個 Side Project 來多方磨練自己的實力跟經驗，以及期待跟其他有熱誠的工程師互相交流，剛好在網路上的一個學習看板看到團隊在招募對 accessibility 有興趣的工程師一起來做專案。
當時我對 accessibility 的認識可以說是一片白紙，因為當年相關的討論與文章也不像現在這麼多，所以就對這個專案的內容感到蠻好奇的，覺得會是一個很棒的學習機會，此外覺得能用程式開發來幫助有需要的人事件很棒的事，也想讓自己貢獻一份心力，因此就這樣加入了。
在加入之後，我和 Product Owner 一起開發雲端千眼（讓視障使用者借書與閱讀的平台）這個專案，他主要負責後端，我則負責前端的部分，一邊開發一邊討論如何在開發與設計的過程中更注重 accessibility。
我覺得主要是對 HTML 語意的注重還有螢幕閱讀器 NVDA 的使用吧。剛加入的時候還沒什麼概念，所以程式碼寫完之後，夥伴常常提醒說這一段的語意其實很不清晰。其他像是如何使用 ARIA 屬性去做元素之間的關聯，或是 focus 要不要去鎖定等等，這些細節都是平常在開發的時候不會去注意到的事情。
「學會使用螢幕閱讀器之後，我才意識到自己寫的程式碼想要表達的原意，與透過輔助科技上所『看到』的內容之間存在著相當大的落差。」
除此之外也認識了 NVDA 這個軟體與螢幕閱讀器 (附註) 的概念，那時候我才知道原來有這種工具可以協助視障者去得知螢幕上的資訊，跟我們明眼人平常所見即所得的操作方式很不一樣，學會使用螢幕閱讀器之後，我才意識到自己寫的程式碼想要表達的原意與透過輔助科技上所「看到」的內容之間是存在著相當大的落差，也才驚覺到平時開發頁面時有很多語意細節都沒注意到。因此，現在日常開發時，會很習慣使用 devtools 中的 accessibility tree (附註) 來查看 ARIA 屬性與角色的作用情形。
NOTE
- Accessibility Tree: 瀏覽器為了輔助科技所設計，用來描述頁面語意的資料結構。參考 Accessibility Tree：細心的栽種打造無障礙頁面
- 親自使用螢幕閱讀器來感受使用者的體驗，可以讓無障礙開發更全面。參考： 螢幕閱讀器檢測無障礙，自己來！(一)
我認為視角上蠻不同的，accessibility tree 只是幫助你查看瀏覽器有沒有呈現對應的資訊給輔助科技，但使用 NVDA 去走過整個網站比較像是做 end to end 測試 ，會讓你更貼近使用者的真實體驗。就算在開發的時候有加上語意，在 accessibility tree 上也有顯示出來，但不保證最後在螢幕閱讀器上的體驗是好的，因為有很多面向其實單看 accessibility tree 也很難去察覺，例如焦點控制和 live region 的實作。
除了前面提到學習了很多 accessibility 知識之外，專案所使用的技術其實都蠻新的，夥伴也很鼓勵導入與嘗試新的技術。在公司，你可能會因為技術債或是各種風險的考量，而只能使用較舊的技術來開發，因此參與 Coseeing 的專案就提供了一個嘗試新技術的好機會。
此外，在與設計師合作的方面我也覺得很不錯，在平時工作中公司內可能會有很多個設計師，每個都有自己的風格喜好，有時候不見得會有一致性。但參與 Coseeing 專案的設計師們會比較講究一致性這件事，例如什麼情境之下要使用哪一類型的提醒，或是操作的流程要怎麼跑，都會盡量保持統一的做法。此外，因為在設計的過程中會從無障礙的角度去思考元件的設計和行為，就比較不會發生某些明明是相同的情境但是用不同的元件去做，這樣同時也提升了整個網站設計的一致性。
最後就是之前參與開發的雲端千眼平台其實有蠻多使用者的，會覺得自己做的專案真的有幫助到一些人，是對社會有一點正面影響的，而不只是單純的 side project 而已。
仔細回想了一下，發現參與了 Coseeing 專案對我的職涯選擇其實有不小的影響，加入當下我其實前後端都有在學習，但因為當時這個專案比較欠缺前端人力，我也不排斥就逐漸往前端領域發展了。或許當時如果專案缺少的是後端人力的話，我說不定現在就是後端工程師了(笑)。
參與這個專案除了讓我更確定在前端工程師這條路上發展之外，後來換下一份新工作的時候，就應徵了一家專注服務身障族群的社會企業。在面試的過程中，公司看到我有無障礙專案的實作經驗，覺得我跟他們的文化很契合，最終也順利地拿到了這份工作。
我前公司的產品是一個 AI 圖片標註平台，例如他會給你一張圖，然後要求你去把圖片中的狗全部標出來，所以受眾其實比較偏向肢體障礙而不是視覺障礙的使用者。
而該平台需要比較精細的操作，這邊遇到的挑戰就是不同的伙伴有可能只能使用左手或右手操作，但我們希望每個人都能夠順利執行標註的任務。因此，我們需要開發可客製化快捷鍵的功能，甚至讓每個專案都能自行設定快捷鍵，讓使用者更有效率地去執行任務。
此外我們也要去考量到有些人只能用鍵盤，或是只能用滑鼠的情況。不過相較之下，因為使用者客群的關係，在 HTML 語意方面就沒那麼注重。我覺得這算是蠻特殊的案例，公司確實是注重無障礙的，但跟一般文章常提到的無障礙面向又不太一樣。
我之前在公司內部的技術交流會中分享了幾次有關無障礙的主題，還記得第一次分享的主題是介紹 Chrome 的 ChromeVox 工具，這是一個類似 NVDA 的螢幕閱讀器，雖然功能比較沒有那麼完整，但相對入門比較容易，只要有 chrome 就可以很快的安裝起來開始體驗。
當時我示範如何用這個工具來測試公司的網站，同事就很驚訝地發現，網站裡有一個導覽功能的地方在螢幕閱讀器底下竟然完全看不到。這是因為當時開發的人沒有考慮到有這樣操作的使用者。如果我是螢幕閱讀器使用者的話，應該會搞不懂怎麼使用這個網站，然後直接離開吧。
除了分享會，我也把像是 aria 屬性、HTML 原生元素等無障礙相關的重要知識點寫成文件給團隊參考。在 code review 時，我也會提醒一些基本的無障礙原則，像是該 focus 的地方要 focus、圖片 image 要加上 alt 替代文字，或者沒有必要的時候不要亂加 aria 屬性之類的。雖然離完美體驗還有一段距離，但這樣做的話，至少能夠達到七八成的無障礙了，不會讓輔助工具的使用者完全無法使用的程度。
「讓管理階層的人去理解無障礙的重要性是一個蠻大的挑戰，能夠讓他們理解後進而站在同一陣線，要去推動無障礙會比較容易。」
我覺得是如何衡量做無障礙這件是會帶來什麼效益吧。之前有跟主管提過加強無障礙這一塊的可行性，主管也是支持做網頁無障礙化的想法，只是希望能更具體地看到這件事真的有幫助到一些人的。例如你做這個功能會有多少人去用、或是會提升多少的轉換率這樣，也就是主管希望我提出可以觀測的指標來看做了無障礙會帶來什麼好處。但這方面我也覺得是比較不容易去呈現的，因為我們並沒有很好的工具去確認最終使用者用的是什麼輔助工具來瀏覽我們的頁面。
另外就是讓管理階層的人去理解無障礙的重要性也是一個蠻大的挑戰，能夠讓他們理解後進而站在同一陣線，要去推動無障礙開發會比較容易。如果只是我單方面提出一個建議，希望所有人都認同、遵循，好像也比較難有說服力。此外，單靠工程端去推動也沒辦法做的很完整，會同時需要設計端、PM 端去合作，甚至更進階的話，連 QA 部門也要參與，這些都是做好無障礙的關鍵拼圖。
我覺得了解無障礙的知識對前端工程師來說可以帶來不小的優勢，因為了解這一塊知識領域的人真的比較少。如果你對無障礙有一些理解，甚至有實務經驗的話，這可以變成你職涯上面的記憶點。例如你去面試的時候，會 HTML、JS、CSS 等等大家都只會覺得這些是前端的基本功，但如果你還了解無障礙的話，就會讓人眼睛一亮。
「前端有很多專業領域可以深耕，有些人打包特別強、或是做動畫很強，如果你在無障礙這方面有深入研究，這就是你這個前端工程師跟其他人不一樣的地方。」
尤其前端跟使用者體驗息息相關，而無障礙又是使用者體驗的一部分，如果你對這一塊很有熱情，表示你是注重使用者體驗的工程師，那在面試的時候就肯定是一個加分的項目。前端有很多專業領域可以深耕，有些人打包特別強、或是做動畫很強，如果你在無障礙這方面有深入研究，這就是你這個前端工程師跟其他人不一樣的地方。
我覺得比較困難的部分應該是資訊比較不完整。假設你對上語意的方式有一些疑問，或是想要知道某些無障礙問題的解法，這方面的文件雖然有，但數量不算多。就算你查到了官方文件，但官方文件的描述通常比較抽象，需要一些實際例子來理解，這時候你就還要去查 stackoverflow 或從相關社群找資料。但社群的討論度其實也沒那麼高，這就讓學習的過程變得比較困難。如果有一個專門討論無障礙相關話題的地方或社群，應該會對學習有蠻大的幫助。
我初學時是有看 W3C 的一份常用設計模式的文件 (APG patterns)，我覺得這份文件提到的每一個元件都蠻值得進去看一下的，它會為你開啟一個新的角度去看事情。例如網頁常見的圖片牆，下面可能會有一排點點點按鈕，分別對應每一張圖片，但是如果我們沒有針對這些點去加上適當的語意的話，那對螢幕閱讀器使用者來說他們就只是無意義的 DOM 元素，不知道它在幹嘛。這份文件很棒的是，他會很詳細去介紹要加哪些語意、要怎麼加。
另外 Google 他們每一年的 Google I/O 發表會上都會介紹與無障礙相關的優化，例如 2022 年的這個影片就介紹了如何用 Chrome devtools 去 debug accessibility。Google 對無障礙這塊蠻重視的，每一年都有一些新的話題，你可以去追蹤他們每年做了哪些優化，或是透過他們了解有哪些新的技術工具可以使用。
最後，可以追蹤像 A11y 新手村這類發表無障礙內容的部落格，透過不同的管道來了解無障礙新知也是很推薦的方式。此外，我自己覺得比較好的方式還是要自己親手去實作。讀文章的時候雖然會覺得蠻有收穫的，可是缺乏實務經驗還是會比較可惜。像我就是因為加入了 Coseeing 專案，所以才累積了一些實務的經驗，透過這些實務經驗就更能深刻地理解無障礙的各種知識。
我覺得雖然無障礙的推動很不容易，但就像是我們蓋大樓的時候都要蓋無障礙坡道一樣，如果有法規去規範，那大家就會很自然地去遵守。雖然數位世界的無障礙不像實體的無障礙坡道那麼容易被看見，但作為前端工程師，若能在個人能力範圍內實踐無障礙，也可以從個人的角度對社會產生一些正面的影響。
