九月下旬預計會有一場座談會，要說明目前研考會版《無障礙網頁開發規範》第二版的研修進度，以及相關的一些事項。在這次的座談會當中，有個重頭戲是要展示目前規劃中的檢測流程，其中也包括了新版檢測軟體的暫定介面。
我前幾天花了些時間，構想了一個介面設計的草圖，有興趣的朋友可以下載回去看看（PDF 檔案）；不過，由於這只是個草圖，所以我可以擔保：最後做出來的東西，一定不是長這個樣子啦！
（註：草圖當中的程式標題寫著「FreeGo v4」，但是根據最新的信件來看，新版的程式很有可能會叫「FreeGo II v1.0」）
繼續承上一篇，我最近這一週在寫二版規範的軟體檢測邏輯範例，以及自我評量暨稽核的步驟範例，因為第一次座談會時的進度還很初期，我覺得多數的與會者其實對於「第二版到底會怎麼實踐」很難有具體的想像，當然，更關鍵的是研考會相關人員對此也沒有具體的認知，所以我在座談會後的第一次會議當中就提出：期末座談會的時候應該要以實際的範例，展示一下第二版到底會怎麼進行。
目前研考會的 FreeGo 檢測軟體其實稍微把玩就會發現裡面的邏輯還蠻不嚴謹的，導致很容易就會有漏洞，或者是遭遇無法處理甚至無法加以判斷該不該處理的情況，這也是我在撰寫這個範例的時候，想要順便釐清的環節。以下就以「XH1010101 提供影像地圖區域的替代文字」這個檢測碼為例，其軟體檢測邏輯應該會像這樣：
軟體檢測在第二版規範當中，主要的用途是第一線篩檢工具，也就是揪出顯而易見的錯誤，而不是要精確地指出所有不符合規範細則的地方。為了要確認網頁符合規範意圖，通過所有的軟體檢測之後，緊接著要由網站主自己進行「自我評量」（取得認證的網站日後也會由第三方執行稽核，稽核跟自我評量祇有執行者的差異，執行步驟倒是相同）。
在目前的第一版作業程序當中，「人工檢測」幾乎都是直接閱讀網頁原始碼，或者是丟給 Lynx（不支援 UTF-8！）看結果，比較像是在針對盲人使用的情境處理，而不是真的在確認網頁親和力，而且做起來很辛苦，執行門檻高。我覺得這種自我評量應該要採用比較務實的方式來執行，搭配各種工具，用便於觀察及記錄的方式來處理；例如以「EV1010102 提供影像地圖區域的替代文字」來說，可以這樣做：
像是這樣的範例，我大概已經寫了五組左右，本週的會議上應該會討論這些範例是否合宜、要採用哪一組、是否還需要修改等等。
承接上一篇文章，另一個最近處理的問題是關於《無障礙網頁開發規範》第一版執行期間冒出來的那個「A+ 等級」。
這個「A+ 等級」在第一版規範當中，大致上是以「A 等級」為基礎，然後額外加上「三項功能」，以及 6.5、9.2、9.3、9.5、13.6 這五個檢測碼──實際上那個「三項功能」的用意或精神都已經涵蓋於那五個檢測碼當中了，唯一完全跳脫整個規範設計的祇剩下那個古怪的「導盲磚」。
於是乎，在處理《無障礙網頁開發規範》第二版時，關鍵就會在於那五個檢測碼會發生什麼事。非常幸運地，那五個檢測碼在 W3C WCAG 2.0 當中，多半屬於「現在的使用者代理已經夠成熟了，不再需要這種過渡性設計」，白話一點，就是已經不復存在了；唯一一個殘存下來的，是第二版規範中的「8.5 除非網頁是一段程序的結果或某個步驟，否則就要有多於一種方法，來在一組網頁當中定出特定的一個來」，這一個成功準則原本在 W3C WCAG 2.0 的設計中，是 AA 檢測等級，由於研考會強烈要求要把 A+ 對應到第二版的 A，所以唯一可行的作法就是把這一條從 AA 改列為 A。以下是我目前在規範當中針對這項變化所撰寫的註腳：
規範 8.5 於 W3C 協會網頁內容可及性規範之檢測等級為 AA，然因多重導覽之設計，對我國網頁使用者至關重要，故於本規範中，將此條規範之檢測等級設為 A；比對本規範與 W3C 協會之網頁內容可及性規範時，需注意符合本規範檢測等級 A 之網站可符合 W3C 協會網頁內容可及性規範檢測等級 A，但符合 W3C 協會網頁內容可及性規範檢測等級A之網站，亦需通過規範 8.5 之檢測，方可符合本規範之檢測等級 A。
最近幾個星期以來，我都在處理檢測碼與自我評量碼的編列，這基本上是個很大的工程，我覺得很難在九月底前（這是研考會這項委外案的結案期限）完善處理好，但是研考會方面不管怎麼溝通，都還是很堅持要生出可供結案的清單，所以目前僅有還不是很理想的進度……
為了讓各位能夠了解目前發生了什麼事，我把一封我寫給專家會議成員的內部信件稍微整理後張貼如下（很長，請做好心理準備）：
現行之 Techniques for WCAG 2.0 當中，General 共計 144 項，HTML 共計 57 項，CSS 共計 22 項，然而各項技術與 WCAG 2.0 規範成功準則之間為多對多的關係，而 WCAG 2.0 當中的檢測等級係按照成功準則來訂定，所以同一項技術在不同條件下施展，會對應到不同的檢測等級。
另一方面，Techniques for WCAG 2.0 當中的各項技術乃是非強制性的正向列表，對於能對應到多項技術的某條成功準則來說，符合規範並不需要實踐所有的技術；然而目前檢測作業方式必需使用「若且唯若」形式的列表，所以不可能直接採用 Techniques for WCAG 2.0 當中的各項技術。舉例來說，C12、C13、C14 分別指定使用不同的尺寸單位，如果要全部分列檢測碼，就會發生只能通過其中一個，無法同時通過三個的情況。
考慮到上述兩個情況，所以將 Techniques for WCAG 2.0 的各項技術移植為檢測碼與自我評量碼時，部分技術需要合併，部分技術需要分解，部分技術則需要合併後再分解；技術分解的前提是同時對應到多個檢測等級不同的成功準則，如果有多個相同檢測等級的成功準則均採用了同樣的技術，則斟酌各成功準則的目的，以及該技術的主要用意，將該技術僅編列於最吻合的成功準則。
除了前述可合併的情況外，另有部分技術彼此互相矛盾，舉例來說，H46 技術的使用前提已經與 H88 及 G134 違背，而且其對應的成功準則均為A檢測等級，因此這類技術就予以刪除，不予納用。
註：此例 H46 技術並非任何成功準則的充分技術，而是技術忠告而已，描述的是在未能達成 H88 及 G134 技術的情況下，仍可試圖增添親和力的作法；然而就檢測作業來說，加入這類技術忠告並沒有實質的作用，徒增作業複雜度及承辦人員困擾，故不採用。
至於與現行一版檢測碼相關的部分，也盡量予以合併或調整。
在編修過程當中，產生了若干情況：
經過一番重新整理、編修之後，做出了幾項變動：
最後初步整理出來的有：XH 檢測碼共計 36 項，CS 檢測碼共計 13 項，ME 共計 1 項，自我評量碼共計 171 項，不過目前這樣的編修結果可能仍過於嚴苛，或者在實務上 不見得可行，或者與我國國情無關（但是可能與國際接軌有關），均需進一步確認及商討。
