一個小程式，幫助撰文者製作符合無障礙網頁規範的文章
以 TinyMCE 為例，建立小工具檢測文章內容是否符合無障礙規範
情境
一間企業幫助政府單位架設內容管理系統網站，文章編輯需要使用所見即所得編輯器的高度自由，又要全網站符合無障礙網頁規範。
痛點
即使有無障礙網頁知識，但只要碰到所見即所得(WYSIWYG)編輯器，網站建立後的文章內容便不再受控。
企業：
1. 每當網站被抽測時，就需要花費大量時間幫助業主修復。
2. 程式需要特別限制必填欄位，但是有點填鴨式，例如 <a> 在某些情況下，不需要有 title 屬性。
3. 額外提供寫作的教育訓練。
撰文者：
1. 如果企業的編輯器有特別限制必填，則一定要填寫欄位，否則無法儲存。
2. 不暸解該欄位意義，於是可能流於表象的填寫，對無障礙網頁沒有真正意義上的幫助，例如圖片 alt 的描述可能會比較模糊。
3. 被抽測時，文章沒通過無障礙的機率非常高，就只能等待企業修復。
解決方案
打造一個編輯器內工具
- 撰寫文章時可以即時檢測無障礙網頁規則。
- 提供該無障礙網頁錯誤的撰寫提示，每次錯誤時，撰文者可以學習一些無障礙網頁規範。
- 錯誤提示提供視覺化顯示，例如圖片錯誤的話，應顯示該圖片，並且點擊後可以將滑鼠鼠標移動到錯誤的位置。
- 使用者點擊檢測按鈕時觸發，或是自動即時檢測，但是不能直接跳出錯誤一直干擾撰文者編寫流程，只需要在按鈕文字後加上錯誤數量和改變顏色。例如，當錯誤在 5 個以下，按鈕文字顯示黃色，10 個以上就變成紅色，以提醒撰文者不要累積太多錯誤再更改，但也不打擾寫作。
- 建立指標，例如通過是 100 分，沒通過就按比例顯示分數。
可利用遊戲化方式，鼓勵撰文者學習。 - 即使有錯誤，但仍然讓使用者可以儲存，儲存後在列表和檢測按鈕裡，有警告 icon 提示該文章尚未完成無障礙檢測。
實作：以 TinyMCE 為例
思路
- 制定格式、寫一次規則後，此格式的程式碼，可以輕易的在不同所見即所得編輯器中製作成外掛，才會更能推廣。
- 無障礙網頁規則通常只會新增的比較多，修正比較少，所以當規則第一次寫好後，維護不至於太困難，所以開發者負擔應該不會太多。
- 先以常見錯誤開發，先解決常見問題，再制定更細部規則。
- 要注意編輯器先天限制，假設編輯器本身圖片沒有給 alt 欄位，這時候即便您有檢查到沒寫 alt，也無濟於事。
近期未來發展
進階檢查
編輯器先天不足與客製化工具的搭配，成為獨家功能，進而開啟獲利模式。
LLM 自動修復
若成本足夠低了，而且 AI 也能根據上下文給予圖片有意義的 alt 屬性或其他遵循規則，正確率也很高，就可加入自動修復。
在檢測分數後，有一顆按鈕點擊後，串 LLM 自動修復該欄位，並且給予適當的值。例如圖片的 alt，LLM OCR 後，自動判斷怎樣的描述會比較好。
但不要直接對內文馬上改，而是先提供預覽或是更動的地方，待點擊「同意變更」之類的按鈕後，再異動內文。
LLM 自動檢測
或者，乾脆也不用自己寫規則了。
如果未來 AI 夠強，只要編輯器工具列放一顆「一鍵自動檢測修復無障礙」就搞定了。
額外要注意的地方
通常，網頁頁面的標題和副標題，不會在所見即所得的編輯器裡，這很大一部分是因為網頁排版問題。
所以，工程師最好在所見即所得的外層，包一層 <article>，重置標籤 h 系列的順序(<article>表示此內容足夠當作獨立一個頁面的內容)。這樣就不需要特別動到編輯器工具，否則，可能要根據網頁的排版，限制編輯器內建的標題從哪個開始。
另外，如果編輯器背景是透明，編輯器內的無障礙網頁檢查，可能沒辦法檢測到編輯器內外的問題。例如，編輯器內文字是白色，但編輯器外的背景也是白色，此狀況下，編輯器內的檢測工具，就沒辦法檢測顏色對比。
結論
這樣的工具最主要是降低有關於達成無障礙網頁的成本，對開發商、撰文者、最終讀者都有利，並且技術難度不高，剩下的就是體驗問題和自動化成本問題。
