九月下旬預計會有一場座談會，要說明目前研考會版《無障礙網頁開發規範》第二版的研修進度，以及相關的一些事項。在這次的座談會當中，有個重頭戲是要展示目前規劃中的檢測流程，其中也包括了新版檢測軟體的暫定介面。
我前幾天花了些時間，構想了一個介面設計的草圖，有興趣的朋友可以下載回去看看（PDF 檔案）；不過，由於這只是個草圖，所以我可以擔保：最後做出來的東西，一定不是長這個樣子啦！
（註：草圖當中的程式標題寫著「FreeGo v4」，但是根據最新的信件來看，新版的程式很有可能會叫「FreeGo II v1.0」）
幾個月前，我在找據說已消失一陣子了的 IBM Home Page Reader，雖然後來千方百計地終於取得了，但是對於史上第一個螢幕朗讀軟體／語音瀏覽器就這樣消失，不免感到有些遺憾；後起之秀如 JAWS 或 Window-Eyes 雖然功能強大，但是售價也是 IBM Home Page Reader 的十倍以上（IBM Home Page Reader 當初售價大約一百美元出頭，JAWS 專業版要將近一千一百美元，Window-Eyes 要將近九百美元──就連 60 天評估版的 Window-Eyes 也要約四十美元纔能取得），不論是對於有需要的使用者，或者是對於想弄一套來測試的網頁設計師來說，都是相當大的負擔，讓人不由得心灰意冷。
我在 IBM 的網站東翻西翻，想要蒐集幾年間遺落的碎片，結果有了意外的發現，那就是 aDesigner、aiBrowser 以及他們背後的偉大推手──
到了 2004 年至 2005 年間，她發現 IBM Home Page Reader 已經無法應付多變的網頁媒體，以及接下來三年即將迎向她的各種 Web 2.0 網站和 RIA (Rich Internet Application)，這也是 IBM Home Page Reader 功成身退的時候。
但是她跟 IBM 東京研究室並沒有停下腳步。在 2004 年，她做出了 aDesigner，這是一套給設計師的工具，跟其他既有的分析工具最不同之處，在於它能夠用非常視覺化的方式分析網頁並產生報表──這麼直觀有效率的分析工具，竟然是出自盲人之手！
事實上 aDesigner 並不止於網頁，它還能拿來分析開放文件格式 (OpenDocument Format) 的檔案，包括 ODT (OpenDocument Text)、ODS (OpenDocument Spreadsheet) 和 ODP (OpenDocument Presentation) 等，也能夠拿來分析 Flash 檔案，還有一般的圖形化介面 (GUI) 應用程式。換句話說，除了網頁設計師外，互動式多媒體設計師、一般的文件撰寫者，還有應用程式的開發者，通通都可以用 aDesigner 來評估文件或程式的親和力，評估的基準除了全球資訊網協會 (W3C) WCAG (Web Content Accessibility Guideline)、美國 508 公法 (Section 508 of the U.S. Rehabilitation Act)、日本工業標準 (Japan Industrial Standard, JIS) 與 IBM 親和力檢核清單外，還包括了分析 IA2 (IAccessibility2) 與微軟 MSAA (Microsoft Active Accessibility) 資訊的功能。
在 aDesigner 之後，她又做了 aiBrowser──IBM Accessibility Internet Browser for Multimedia，這可以算是 IBM Home Page Reader 的加強版，加強的重點在於讓使用者可以控制隨著網頁載入的各種多媒體物件，而不會受到干擾而失去焦點。更棒的是，aDesigner 和 aiBrowser 都是使用者可以免費下載使用的。
2007 年 12 月 4 日，她代表 IBM 把 aDesigner、aiBrowser 等程式的源碼帶到開放源碼社群，ACTF (Accessibility Tools Framework) 計畫於是誕生了，不論是對親和力的領域，或對開放源碼社群來說，都具有相當重要的意義。
看一看
原本我祇是想搜刮一些工具而已，但是除了 aDesigner 和 aiBrowser 這兩大收穫外，又發現了這些工具背後居然是這麼了不起的一個人，不禁讓我內心也感到熱血沸騰、慷慨激昂。
最後僅以
We can make the impossible possible by never giving up.
「親和力」的專題一連介紹了一整年，或許有些讀者會覺得，「這些跟自由軟體有甚麼關係啊？」這關係可大了。本期讓我們先撇開還沒講完的設計花樣，先來看看一個叫 aDesigner 的軟體，回答上述的疑惑，並做為「親和力」專題第一階段的結尾。
在自由軟體及開放源碼軟體發展的歷史上，向來最為人詬病的就是軟體的介面設計。如果單以技術面來審視自由軟體，確實有許多非常傑出的作品──程式碼漂亮、功能強大的軟體，但是這些軟體卻往往不是一般人在挑選軟體時的首選；它們固然穩健敏捷，效能卓越，並且便於延伸擴充，但是介面設計卻不討喜，使得軟體人們不具親和力，甚至有的完全缺乏設計。
讓我們直視問題的癥結，介面設計在軟體開發流程當中，原本就是相當奢侈的一環，有言「好設計是不折不扣的」，因為要做出好的介面設計，不但要仰賴藝術天分，而且一定會需要許多的測試者參與協助，並且花費昂貴的代價來建置測試用的空間與設備，這些都不是靠著年輕熱血，窩在鍵盤前就有辦法完成的。
君不見今日的圖形設計師仍一面倒地使用 Adobe Photoshop，少有依賴 GIMP 為生的？當然還是有一些較成功的專案，以 Firefox 為例，其實很大部分是靠著 Mozilla Foundation 把資金投入行銷、使用者經驗研究這些光靠技客們無法處理的領域，纔有今日的成就。
就算撇開主流市場不談，有些悲天憫人的軟體開發者，認為自由軟體或開放源碼軟體存在的必要，在於提供社會上的弱勢族群，也能享受到資訊技術的進步。套用古老笑話中的說法，「這群人在路邊幫人們拼裝了時速可達兩百公里的超級坦克車，而且還免費贈送。」但是這樣的善意並不見得有辦法傳遞到弱勢族群手中──因為弱勢族群不見得有手、有眼睛、有耳朵，能夠用來操控這樣的軟體。
雖然在筆者過去一年來談論親和力的時候，總是強調讀者們不應把「親和力」跟「殘障人士」劃上等號，但是此刻讓我們先以殘障人士的角度來審視這樣的議題，畢竟這群人對親和力不佳的設計，會感受到最大的不便。
對於肢體動作、視力、聽力等能力有所不便的使用者來說，有一些輔助科技可以協助操作電腦軟硬體；這些輔助科技包括了硬體與軟體的組合，像是把螢幕畫面轉為語音甚至點字輸出的設備、利用語音做為標準輸入輸出的設備，或者是即時以視覺方式來呈現聲音線索、即時將多媒體內容的語音上字幕的軟體等。
問題來了，這些輔助科技如何能夠得知，作業系統或其他應用程式到底繪製了甚麼畫面、發出了甚麼聲音、輸出了甚麼內容呢？
以這些輔助科技支援最廣的作業系統──微軟 Windows 為例，從 Windows98 以及 Windows 2000 開始，包括這兩個版本，所有後續的 Windows 作業系統都支援了微軟在 1995 年起制訂的 Microsoft Active Accessibility (MSAA) API，至於更早一點的 Windows95 則可以安裝一個 RDK（Re-Distributable Kit，可再散佈的套件）來支援 MSAA，而 WindowsNT 4.0 則是從 SP4（Service Pack 4）也支援 MSAA；MSAA 的核心是一個叫 IAccessible 介面的東西，因此當軟體元件支援 IAccessible 介面時，就能夠享受到由 MSAA 所提供的環境，與其他支援 MSAA 的輔助科技互通。舉例來說：各種應用程式能使用便捷鍵（跟組合快速鍵不一樣，不過這個說來話長，日後有機會再詳述），螢幕朗讀軟體可以唸出選單、對話窗、按鈕上的文字，字幕程式可以替程式輸出的語音顯示字幕，或者使用替代滑鼠的其他指標裝置等。
到了 1998 年，原有的 MSAA API 已不敷使用，IBM 與 Sun Microsystems 於是合作提出了新一代的介面，叫 IAccessible2，並以此實做出 Java Accessibility API；這個 API 稍後又繼續發展成許多不同的 API，包括 OpenOffice.org 做的 UNO Accessibility API，GNOME 社群所做的 UNIX Accessibility Toolkit（ATK）及其伙伴 Assistive Technology Service Provider Interface（AT-SPI）等。
這些新一代的 API 都是奠基於 IAccessible2 介面而來的，而 IAccessible2 則是個免費的開放標準，IBM 已將其規格捐給自由標準組織（Free Standards Group，FSG，現在是 Linux Foundation 的一部分），並逐步將相關的程式碼捐贈給自由軟體／開放源碼軟體組織；藉由投入自由軟體／開放源碼軟體界，讓社群能夠享受到親和力科技的努力成果，讓社群也樂於採用這樣的 API，打造更具親和力的軟體，並且能進一步地回饋，持續改良 API。包括像是 IBM Workplace Productivity Editors、Firefox、Eclipse 等軟體，都是採用 IAccessible2 介面的實例；現今所流行的 Web 2.0 網頁應用程式（AJAX、DHTML 等）也受到 IAccessible2 的支援。因此可以說，IAccessible2 介面乃是目前為止實做資訊系統親和力功能時，最重要的核心之一。
瞭解了這些背景後，讓我們回過頭來看軟體介面設計。
雖然已經有許多不同的 API 支援 IAccessible2，能讓程式設計師以較低的成本在多種平台上實做具親和力的應用軟體，但是我們都知道，有 API 不代表就能做出好東西，有沒有甚麼工具或辦法，能夠協助自由軟體／開放源碼軟體社群，來評估軟體的親和力呢？
在 MSAA 時代，有一些工具例如 Inspect32 及 AccEvent 等，可以用來測試軟體的介面親和力，但是他們都祇能支援 IAccessible 而已，沒辦法用於 IAccessible2 的測試。一直到了 2004 年，IBM 東京實驗室推出了一個叫 aDesigner 的工具，解除了這樣的困境。2007 年年底，IBM 傑出工程師淺川智惠子（Chieko Asakawa）代表 IBM，將包含 aDesigner 在內的許多程式碼，捐給了 Eclipse Foundation，展開了一個叫 ACTF（Accessibility Tools Framework）的開放源碼計畫，期待對自由軟體／開放源碼軟體社群有所幫助的同時，也能讓自由軟體／開放源碼軟體的介面設計更具親和力。
ACTF 還是個很新的計畫，國內更是沒多少人知道 aDesigner 這套工具。aDesigner 其實不是一套專為軟體開發人員所設計的工具，而是適用於各種設計人員──除了軟體設計師外，網頁設計師、Flash 多媒體設計師也同樣是這套工具的對象，甚至連拿著投影片要去做簡報的人，也可以使用 aDesigner。
aDesigner 的使用上，大致可以分成四個不同的模式：網頁（HTML）、文件（OpenDocument）、Flash，以及應用程式圖形介面（GUI）的親和力分析模式。既然我們這次主要要介紹設計軟體介面時的親和力檢查，就讓我們從圖形介面的親和力分析模式介紹回來吧。
在 GUI Accessibility 檢視的模式下，設計師可以針對任何執行中的應用程式予以分析；這個檢視模式會有五個子視窗，分別是 GUI Summary、GUI Outline、GUI Properties、GUI Event 以及 GUI List（包括 GUI Report 與 GUI Siblings）。在 GUI Summary 子視窗中，會將選定的應用程式「線性化」，把各個物件以純文字的方式依序顯示出來；如果使用者透過螢幕朗讀軟體來操作應用程式的話，螢幕朗讀軟體唸出來的內容，就會跟 GUI Summary 的輸出結果差不多，因此若介面元件安置的順序不良，在此就能夠看出結果。
GUI Outline 子視窗會把選定應用程式的 MSAA 物件結構以樹狀方式顯示出來，如果在這個樹狀結構中加以點選，除了會以閃爍的黃色外框實際在應用程式周圍標示該物件外，GUI Summary 子視窗中相對應的部分也會反白標出，GUI Properties 子視窗的內容亦會隨之更新；至於 GUI Properties 除了會顯示出 GUI Outline 子視窗中所選物件的 IAccessible 介面資訊，還會顯示出 IAccessible2 介面資訊的細節，可供軟體開發者進一步分析親和力問題。
當然，aDesigner 也有自動分析的能力，因此在 GUI List 子視窗的 GUI Report 分頁中，將會自動地尋找所選程式中，各個 MSAA 物件是否提供了替代文字，並將有問題的部分列出；GUI Siblings 分頁則是會根據 GUI Outline 子視窗中所選的物件，列出其毗鄰物件，讓軟體設計師不會迷失在物件樹之中。
除了靜態的分析之外，aDesigner 的 GUI Event 子視窗也會動態地顯示出各個應用程式所觸發的 MSAA/IAccessible2 事件，並且會記錄大於一秒鐘的時間間隔，當要分析應用程式的操作效率時，這項資訊就會非常有用。
除了一般的應用程式會用到 MSAA/IAccessile2 之外，現在也流行運用 Flash 或 AJAX 技術來開發網頁應用程式，這些網頁應用程式其實也會透過 MSAA 介面輸出，所以 aDesigner 能夠與 Internet Explorer 或 Firefox 搭配使用，讓開發者分析瀏覽器中的網頁應用程式 GUI 親和力。
除了以 GUI 為導向的分析方式外，aDesigner 也可以用 Flash 模式來分析 Flash 媒體的親和力，這時候 aDesigner 將同時擔任代理伺服器的任務，除了 GUI Summary、GUI Outline、GUI Properties、GUI Report、GUI Siblings、GUI Event 之外，還會多出 Flash Outline 以及 Flash Proxy Log，前者會直接剖析 Flash 媒體內容的執行期結構，後者則會紀錄存取 Flash 內容的 HTTP 歷程，對於以 Flash 為主的開發者來說，會是很好的除錯工具。
aDesigner 的網頁（HTML）分析模式也跟歷來的各種網頁親和力分析工具有所不同。最大的差別在於 aDesigner 會將盲人使用者所感受到的瀏覽經驗，以視覺化的方式呈現給設計者：網頁的不同部分，會用深淺不同的底色，來表示使用者瀏覽至該位置所耗費的時間，並且會提供此估算的秒數，讓網頁設計師能夠「看」到有沒有哪些內容，對使用者來說將難以取得；另外也會用雷達圖的方式，綜合評論網站是否（在技術上）符合相關規範、是否易讀、是否便於導覽，雖然這離真正完整的親和力評估仍有距離，但是卻比之前任何檢測工具要來得全面性了。
網頁分析模式除了盲人模式外，還有一個弱視模式，不但會同步模擬網站在弱視使用者眼中的樣子，並且會有一個「Problem Map」來標示出哪些部分的對比可能不足。這些用視覺化的方式，來分析並呈現網頁整體的親和力概況的做法，實在可以說是一項創舉，也是 IBM 東京實驗室的驕傲。值得注意的是，促成 aDesigner 誕生、推動 ACTF 計畫最用力的 IBM 傑出工程師淺川智惠子（Chieko Asakawa）本身是一位盲人，卻能夠帶領這項計畫走向視覺化，也明白親和力跟自由軟體／開放原始碼軟體的結合，將能促成雙贏局面，這樣的用心實在是值得我們效法。
最後，aDesigner 還有個文件分析模式，除了能以 XML 技術分析 ODT（OpenDocument Text）、ODS（OpenDocument Spreadsheet）和 ODP（OpenDocument Presentation）等開放文件格式檔案的親和力，並以盲人模式跟弱視模式模擬外，還特別做了一個「簡報模式」，讓使用者可以模擬在不同的簡報環境（小型會議室、大型會議室、大禮堂）中，自己的文件或簡報投影在螢幕上時，台下的觀眾看到的樣子究竟如何。這項功能也是個創舉，任何要上台做簡報的讀者都應該要試著用用看，畢竟場地的干擾將可能讓任何耳聰目明的聽眾變得視茫茫，而沒有任何簡報軟體能提醒你這一點。
上述這些祇是 aDesigner 的簡短介紹，每一種模式又都可以再深入探討。之所以應用程式的 GUI、網頁、文件的親和力檢查可以放進同一個工具程式之中，其實是因為親和力的本質是相同的，當今資訊技術所建構出來的解決方案也是相似的。同樣地，筆者在這個專題一年來所說明的，也適用於應用程式的 GUI、網頁、文件等不同設計領域。
從親和力的概念、釋疑，到最近所介紹的設計花樣，除了用於網頁外，亦可用於文件或應用程式 GUI 設計。希望藉由介紹 aDesigner 的背景及功用，能對於設計軟體 GUI 的讀者有所幫助，並且讓讀者們看到，親和力與自由軟體／開放源碼軟體社群結合的趨勢所在，也希望這些議題在未來都能有更多人關注、發展出更多更好的解決方案，讓自由軟體／開放源碼軟體更具親和力、更多人樂於使用。
配色是一門大學問，在網頁設計的世界中又比其他藝術創作更是如此；因為不當的對比，可能會讓妳的網頁一塌糊塗。
今年年初，我把新版的色彩對比分析程式帶進台灣（Windows 版跟 Mac 版都有），這可以稍微解決這個問題──妳可以用這個程式，挑選妳中意的配色，看看其對比是否理想。但是，萬一怎麼配都不理想，要怎麼辦？一個個慢慢試嗎？
Joe Dolson 用 PHP 做了一個線上服務，叫「色彩對比檢測程式」，能一口氣檢測上千種不同的色彩搭配，這樣就能更快找出恰當的色彩了吧。這個線上服務一樣由我中文化了，所以請盡情使用吧！
接下來有空的時候，還會再把 Opera 版的網頁親和力工具列也處理一下。
網頁親和力工具列 2.0 版跟色彩對比分析程式 2.0 版都已經釋出好一段時間了，一直到最近終於抽出空來，做了繁體中文版。
有需要的朋友可以到（同樣是我翻譯的）中文網頁下載這兩個好用的小工具：網頁親和力工具列 2.0 繁體中文版（內含色彩對比分析程式 2.0 繁體中文版，但是這個也可以單獨下載免安裝的版本）。
這項資訊亦已刊登於 The Paciello Group Blog 以及 Web Accessibility Toolbar Blog 上。
色彩對比分析程式其實還有 Mac 版，我已經把相關的翻譯送回去了，但是開發者的 Mac 爛掉送修中，得要等一段時間纔會有辦法編譯含繁體中文的版本出來，屆時我也會放到中文網頁上。另外網頁親和力工具列也還有 Opera 版，這個我有空也會做中文化。
中文化的網頁中，除了上述工具的下載及說明頁面外，還有一些比較詳盡的文件，我也一樣會抽空來翻譯，敬請期待。
