軟體檢測邏輯範例、自我評量暨稽核步驟範例

繼續承上一篇，我最近這一週在寫二版規範的軟體檢測邏輯範例，以及自我評量暨稽核的步驟範例，因為第一次座談會時的進度還很初期，我覺得多數的與會者其實對於「第二版到底會怎麼實踐」很難有具體的想像，當然，更關鍵的是研考會相關人員對此也沒有具體的認知，所以我在座談會後的第一次會議當中就提出：期末座談會的時候應該要以實際的範例，展示一下第二版到底會怎麼進行。

目前研考會的 FreeGo 檢測軟體其實稍微把玩就會發現裡面的邏輯還蠻不嚴謹的，導致很容易就會有漏洞，或者是遭遇無法處理甚至無法加以判斷該不該處理的情況，這也是我在撰寫這個範例的時候，想要順便釐清的環節。以下就以「XH1010101 提供影像地圖區域的替代文字」這個檢測碼為例，其軟體檢測邏輯應該會像這樣：

1. 根據 DTD 判斷內容為 HTML 4.01、XHTML 1.0、XHTML 1.1
2. 所有的 <area> 標籤一定要有 alt 屬性，且其值不得為無內容或空白
3. 選擇性檢測：所有的 <area> 標籤的 alt 屬性的值不得為無意義的網頁編輯軟體預設值（例如「未命名」、「預設」、「Untitled」、「Default」等值），否則應提出警告，確認是否為真的要使用這些值的情境
   

軟體檢測在第二版規範當中，主要的用途是第一線篩檢工具，也就是揪出顯而易見的錯誤，而不是要精確地指出所有不符合規範細則的地方。為了要確認網頁符合規範意圖，通過所有的軟體檢測之後，緊接著要由網站主自己進行「自我評量」（取得認證的網站日後也會由第三方執行稽核，稽核跟自我評量祇有執行者的差異，執行步驟倒是相同）。

在目前的第一版作業程序當中，「人工檢測」幾乎都是直接閱讀網頁原始碼，或者是丟給 Lynx（不支援 UTF-8！）看結果，比較像是在針對盲人使用的情境處理，而不是真的在確認網頁親和力，而且做起來很辛苦，執行門檻高。我覺得這種自我評量應該要採用比較務實的方式來執行，搭配各種工具，用便於觀察及記錄的方式來處理；例如以「EV1010102 提供影像地圖區域的替代文字」來說，可以這樣做：

1. 使用 Firefox 搭配「Firefox Accessibility Extension」顯示替代文字（Accessibility → Text Equivalents → Show Text Equivalents）
2. 檢查所有的替代文字是否與其圖片區域原本要表達的功能及意義吻合，必要的時候並參考區域的鏈結目的地來驗證
   

像是這樣的範例，我大概已經寫了五組左右，本週的會議上應該會討論這些範例是否合宜、要採用哪一組、是否還需要修改等等。