這幾年，無障礙不再是少數專家的話題，以前談到網站無障礙，是法規、稽核、檢測報告，或是某個專案最後才會被打開的 checklist，但現在不一樣了：
- 設計師開始在 Figma 裡檢查文字和背景的對比
- 前端工程師開始知道要跑 Lighthouse、axe、看 DevTools 裡的 Accessibility panel
- QA 開始在測試案例裡加入鍵盤操作
- 產品經理也開始意識到，操作困難不只是「體驗不好」，也代表一群使用者被排除在外。
這些都是很重要的進步，大家也開始重視無障礙，所以我認為是時候要從「推廣無障礙」，變成「無障礙能隨時、隨地、容易的檢測」。
現在的工具和流程，仍然很容易讓無障礙被切成不同職能的責任，例如：
- 設計師使用 Figma 負責看對比
- 工程師使用 Devtool 負責看程式碼
- QA 負責走測試鍵盤操作
這樣的分工看似合理，但可能會造成每個職能只注重自己的範圍，將某些測試只交給該職業測試，我認為現況是不理想的，無障礙測試應該是團隊成員可以隨時、隨地、容易且跨職能地檢查，無障礙測試不應該被工具與職業綁住。
舉個小例子，PM 如果要檢查顏色對比，要不就是學會 Figma，要不就是學會 Devtool，如果遇到沒辦法測試對比的情況，還要另外自己使用線上工具輸入色碼對比前後色，要檢查的門檻還是太高。
不同職能也應該要了解其他職能測試的項目，因為最基本的工夫就是大家都要擁有「無障礙意識」，在任何階段都要遵循此原則。
但我不是要模糊專業，也不是要每個人都取代專家，完整的無障礙稽核仍然需要專業，輔助科技測試、人工判斷、規範理解、複雜互動模式，這些都不是一鍵工具可以完全處理的，但初步檢查不應該困難到只有少數人能開始。
很多問題其實不用等到正式稽核才看得見，有些問題，只要有人願意多按一下，就能提早發現：
- 按一下，跑一次掃描
- 按一下，切換一種視覺情境
- 按一下，看看 PDF 有沒有基本結構訊號
- 按一下，確認目前頁面是不是有明顯的無障礙風險。
這些動作看起來很小，但能提早發現問題的時間點。
不需要每個人都背熟 WCAG，也不需要每個人都變成無障礙顧問，而是當有人覺得「這裡可能有問題」的時候，不會因為自己不是那個職業而停下來。
他可以先看一下、測一下、確認一下，把問題變得具體，這樣就夠重要了！
這也是我看待 Accesserty DevCheck連結 的方式，雖然目前可以檢查的東西還很粗淺，但所有職能都可以使用 Chrome 擴充程式檢查跨職能的測試，例如：
- 你可以做設計師要做的色盲測試
- 你可以做 UX 設計師要做的易用性與情境觀察
- 你可以做工程師會做的頁面結構與無障礙規則掃描
- 你可以檢查 PDF 結構
- 我希望未來的無障礙工具，能讓更多人跨過專業界線，不是把責任丟給所有人，而是讓所有人都有能力，在自己發現問題的那一刻，動手確認。
無障礙測試如果只能被少數人執行，它就很容易積累壓力，最後就會慢慢被消磨殆盡，但如果可以在日常中啟動，它就有機會成為一種文化，不等到使用者受阻，才開始在意的文化，這通常也代表使用者已經在某個流程裡受挫、放棄，或被排除在外。
無障礙意識正在擴散，接下來，我們需要讓檢查能力也一起擴散，而且應該足夠簡單，簡單到任何人，在任何時間點，只要動動手指，就能測試。