最好的學習是總結 - 總結 Accessibility 專案的從零到一
最近Accessibility 的專案已經做了一個release了，phase1 正式結束，phase2 準備開始，覺得自己應該總結一下Accessibility專案總體怎麼做的，以及踩過哪些坑...
專案準備
Team 總共由10名開發，四名QA，一名PM，一名支援的Scrum Master，還有一名支援的Designer 組成，第一階段開發時長為一個release，一個release 為五個Sprint，每個Sprint 為2周
開發測試工具
aXe - The demo link
WAVE
第一週：
開發任務：做Accessibility 技術研究：什麼是Accessibility？用什麼技術實現？Best Practice？如何測試？聽力障礙，視覺障礙，肢體障礙的不同需求
QA任務：通過WAVE 等工具掃描現在的頁面，列出所有有問題的地方，並分類
第二週：
開發任務：互相分享講解Accessibility 技術要點，將要點歸類，建立相關User Story， User Story 分為兩類 - 核心程式碼需要修改的Ticket以及分散在各個元件中修改的ticket
QA任務：根據開發的歸類將掃描出來的問題新增到各個分類Ticket 下，單獨出現的問題單獨分類建Ticket
共同任務：將發現的問題列在Google doc 上，並新增簡單描述
問題分類以頁面為單位列出了 路徑，問題位置，期望表現和實際表現，分配給誰，備註，PM提供的對應文字，問題狀態，QA測試狀態
第三週：
開發任務：合併重複的問題並分配開發任務，開始著手核心程式碼部分修改
QA任務：合併重複問題，同時將Google Doc上未新增到ticket 的部分新增到ticket
Note: 這裡其實JIRA Ticket 相當於按照元件功能將任務分類，Google Doc 上是按頁面內容將任務分類，這裡的工作實際上是將頁面分類的任務分對應功能分類下
第四周：
開發任務：每個開發take1-3 個User Story，著手核心部分程式碼修改
Note: Doc中問題描述應與Ticket 描述關鍵詞符合，比如 label 部分，assign 了label ticket 的同學便可以直接搜尋label 關鍵詞找到所有label 相關的部分，同時，開發在開始幹活兒的時候將doc 中該部分狀態標註為inprogress，這樣別的同學就不會重複地去看這個問題，改完了標註done，QA同學就知道這部分可以測了
QA任務：寫test case，遇到新的問題，與開發溝通並新增到Doc和ticket上
第五週：
開發任務：完成核心部分程式碼修改，已經完成的同學開始熟悉模組部分的需求
QA任務：驗證已經完成了的核心部分修改，並提bug
第六週：
開發任務：模組部分任務根據Google Doc 列出來的任務大家按需自取，取走的任務將自己名字寫在assign 一欄
Note：開發應及時更新任務的狀態，方便QA以及其他同學及時瞭解，同時看見相同型別的任務，或者改一個地方可以覆蓋相關所有型別的模組的任務，應在doc 上同樣assign 到自己名字下面，避免重複修改
QA任務：繼續驗證核心部分修改
第七週：
開發任務：繼續完成模組部分任務，修改核心部分程式碼改出來的bug，如果需要，修改核心部分元件以適應模組元件的任務
QA任務：驗證已經完成的Ticket
第八週：
開發任務：基本完成模組部分開發任務，協助QA 繼續用多種工具掃面頁面遺漏部分
QA任務：驗證已經完成的Ticket，掃描頁面遺漏部分
第九周：
開發任務：要求完成全部開發任務，修bug，將內容總結成文件
QA任務：驗證已完成的TIcket，掃描頁面遺漏部分
第十週：
開發任務：要求關掉所有ticket，所有bug，準備文件，把Accessibility 加入未來功能開發的必要規範，同時把規範內容對公司內其他相關組員進行培訓
QA任務：驗證以已完成的ticket 以及bug，反覆測試確保‘閉著眼睛也能用我們的產品’，協助開發總結文件。
Accessibility 規範
1. 儘量用語義化的tag，如 button 代表操作，a 代表連結
2. 如果無法第一條規範，需新增role且保證role 的內容語義與節點所司功能相符
3. 對手風琴摺疊的元素，加上合理的 aria 屬性，標明元素狀態。
4. 如果是html 原生 tag 就沒必要新增無謂的role或者aria- 屬性，因為原生tag已經新增好屬於自己的屬性了
Note, 這並不代表你一定不能加，相反，有的情況下你需要新增相關屬性避免衝突
5. 避免用原生態的語義化標籤如 h1 - h5 來做排版，因為閱讀器會把這些語義化標籤也讀出來，如果你一定要用，記得加上 role="presentation" 去消除閱讀內容
6. 任何支援滑鼠操作的地方都應該支援鍵盤 ‘tab’ 過去。
7. 圖片:
7-a. 對於視覺障礙的使用者，圖片是無法傳達任何資訊的，這時候螢幕閱讀器tab到圖片的時候就會讀圖片的alt 屬性的內容，所以，新增一個生動的alt屬性，是給視覺障礙的使用者展示一副多彩頁面的關鍵。如果是background image 的情況怎麼辦呢，在加background image 的 標籤加一個 role = ‘img' 然後再加上 aria-ablel 去描述這個圖片就可以了。
7-b. 如果這個圖片沒有任何意義，只是吃瓜圖片來佔位置的話，我們應該給它標出來，用 (alt="") 或者 role="presentation" 或者 role="none"
8. 關於Icon，特別是字型圖示
8-a. 如果是純裝飾性字型圖示，要手動新增 aria-hidden 去防止無意義的閱讀 (這裡插一句嘴，如果是無意義的純字元裝飾，也應該arir-hidden 起來 ，比如 user | work | about) 中間的麵包屑分割線應該包起來，hidden 掉)
8-b. 如果這個icon 是有意義的，需要新增一些東西讓icon 能被正常讀出來
i. aria-hidden 屬性
ii. 用一個不會影響頁面佈局的標籤 如 span （或者其他標籤修改css 讓它不會出現在頁面）包上文字
iii. 通常還要再加一個 title 屬性
9. 避免用 Click here 做外部連結，直接用 內容 做連結
10. Form 內容應該有合適的label，或者"aria-label"，"aria-labelledby" 屬性
11. 標籤不可濫用，不要把label 當 標題用，更不能疊用。用label 的時候 label 標籤要新增for 屬性，切它對應的標籤要新增獨立id 與for 屬性值對應。做一組標籤的標題的時候儘量用 legend，需要整理格式的時候用 Block
12. 在表單裡面以一組形式出現的表單元素必須用<fieldset> 和 <legend> 去做他們的標題，或者可以用一個 role = group 的標籤把它們包起來
13. 如果一個原生元素不支援focus，且沒有合適的HTML 標籤去替換它，用 tabindex=0 去支援focus，原則上來說"tabindex > 0" 是不允許出現的。
14. 用鍵盤導航應該有正確的業務邏輯
15. Id 屬性應該要獨特，否則會衝突。WMC 的FormGroup中，testAutomationID 最好也是獨立的，因為如果Id 如果沒定義的話，它會自動根據 testAutomationId 生成
16. Form 的 error 應該由Form 元件 自動生成，不應在元件外自己寫
17. Iframe 元素都應該由一個 title 屬性去描述iframe 裡面的內容。如果iframe 裡面含有不可讀的內容，仍然應該根據標準新增title，但記得吧這些無意義的內容用aria-hidden="true" 隱藏起來
18. 不可見但又需要被讀出來的內容，用 "sr-only" css class
19. Table 永遠要加一個header
20. 如果一個 form control 有inline 錯誤資訊，這個資訊應該能被讀出來
21. 所有新頁面應該新增以下 <meta> 來啟用zooming 功能
專案總結
專案技術上困難度不高，難點在於1. 技術分散。 2. 頁面眾多，部分修改適合以功能分類，部分修改適合以頁面分類，分類不清楚的話極易造成重複修改 3. 測試任務繁重，基本要把專案所有部分涵蓋 4. 由於專案修改涵蓋範圍廣，最終程式碼Merge的時候跟其他專案組的程式碼衝突極多。
經過phase1 的總結，在phase2 中，QA同學已列出頁面上問題已經從頁面分類轉變為型別分類，整個團隊對整體業務邏輯和元件功能的熟悉程度都上升很快