登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
自由專欄 COSCUP 當中的親和力討論

COSCUP 當中的親和力討論

今年的 COSCUP 跟 GNOME.Asia 2010 聯合舉辦,不但在參與人數上破了記錄,議程安排的廣度也是歷年之冠。在今年的議程當中,GNOME.Asia 在第二天下午安排了親和力(Accessibility)的部份──這其實是一件很有意思的事,因為一般來說,作業系統必須要符合美國復健法案 508 公法(類似於我國的《身心障礙者權益保障法》)的規定,才能在美國販售;微軟的 Windows 與蘋果的 Mac OSX 均因此而內建許多親和力功能,然而各種開放源碼的 Linux 發行套件如 Ubuntu 等也不例外。但是 Ubuntu 並不是自己處理親和力功能,而是仰賴其採用的 GNOME 桌面環境來實現。

這一次的 GNOME.Asia 2010 當中,提到了 GNOME 對親和力的重視;北斗國小特教組葉志偉組長花了整整一小時分享 GNOME 桌面的各種親和力功能,所有的操作與選項都製作了完整的示範影片,包括螢幕畫面與操作設備(例如鍵盤)的錄影,一應俱全,十分了不起。雖然葉組長在這場簡報當中也安插了一些實際個案的功能使用的壯況,但是很可惜地,並沒有完的呈現出個別化方案,聽眾不見得能夠想像出各項功能該如何搭配運用,有可能因此改變一個人的學習甚至是生活,有種見樹不見林的缺憾。

這一個小時可說是 COSCUP 當中的「U」(使用者)和「P」(推廣者)議程,接下來的一個小時則是「C」(開發者)議程,介紹 GNOME 如何開發親和力功能,以及如何進行各種自動化測試。

具體一點來說,GNOME 的親和力功能開發議程所介紹的重點在於, GNOME 變更了親和力基礎框架架構。原本採用的是 CORBA(Common Object Request Broker Architecture)架構,在這個架構當中,GTK+、Mozilla、OOo 應用程式分別透過 GAIL(GNOME Accessbility Implementation Library)、nsAccessible、UNO 與 ATK-bridge 橋接,再與 at-spi-registryd 溝通;而Java 應用程式則有所不同,是透過 JAAPI(Java Accessibility API)與 JABG(Java Access Bridge)橋接,再與 at-spi-registryd 溝通。然而 GNOME 打算把訊息匯流排改用 D-Bus 基礎架構來實作,這麼一來就必須在 Java 裡面另外實作 D-Bus,無法跟其他應用程式一樣直接透過 ATK(Accessibility Toolkit)來傳遞應用程式訊息。解決方案是:利用 Java 當中的 JNI(Java Native Interface)技術做出 JAW(Java API Wrapper),讓 Java 直接與 C 溝通,這樣子 Java 應用程式也可以使用 GTK跟 at-spi-registryd 溝通了。這個解決方案是運用 Java 的技術來處理 Java 應用程式的需求,不令人意外地,這段議程的主講人王珂,便是在昇陽中國工作。

除了 GNOME 相關的議程排進了親和力外,第一天 Charles McCathieNevile 開場的「HTML5──More Web for More people」其實也帶到了一些網頁親和力的內容。HTML5 的發展原則上是以「基於現實情況的實務」為導向,例如 <nav>、<header>、<footer> 等標籤,就是實際統計現有網頁的撰寫模式(<div> 標籤最常用的 class 屬性值)後所提出來的;此外 HTML5 也對「萬一沒有完全按照規範來撰寫」的情況,認真構思對應行為──以往「瀏覽器自己看著辦」變成有一套比較廣闊的規則,就實際效果來說,就不再是「萬一沒有完全按照規範」的問題,而是規範變得更為寬鬆(而聰明)了。這是個很重要的轉機,但是也很有可能是個危機,因為有些立意良好但各家瀏覽器多年來都沒有認真實作的規格(例如 <img> 標籤內的 longdesc 屬性,目前主流網頁瀏覽器當中,僅有 Opera 內建支援)也在 HTML5 的討論當中,面臨了被廢除的可能。

到底是這類規格的設計原本就不切實際,導致少有人實作,還是其實癥結在於製作瀏覽器的開發者、撰寫網頁的設計師兩方對這些規格不求甚解?HTML5 的發展,會不會反而變成瀏覽器廠商便宜行事逼和的契機?制定標準的時候,應該要肩負「發展方向之標竿」的責任,還是要以「務求既有技術之可行」為最高原則?這些問題可能沒有簡潔的答案,也不會有「最佳解」,只會有「眾人所能承受的答案」。於是,在與會嘉賓 Charles McCathieNevile、Michael(tm) Smith、謝子斌、Kenny 的努力之下,於 COSCUP 第一天晚上的 BoF 掀起 W3C Chinese HTML Interest Group 成立契機。緊接著在星期二,Charles McCathieNevile 與謝子斌在 Opera 台灣辦公室與 TOSSUG 合辦的 HTML5 讀書會後,雖然 W3C Chinese HTML Interest Group 還尚未正式成立,但對應的 public-html-ig-zh 郵遞論壇已經提早破格建立。

目前在 public-html-ig-zh 郵遞論壇當中,廣泛討論了一些跟中文網頁有關的議題,從天南地北的閒聊,到對 HTML、CSS 等標準的認真思考與具體建議,Unicode 規格及平面出版的排版照例也在這一連串的討論之中。有趣的是,有一些 HTML (不論是 HTML4 的推薦標準,或者是 HTML5 的草案)當中語焉不詳的語意細節,反倒是在 WCAG 相關文件當中有較精確的描述,因此在目前的討論當中,常常就會出現 WCAG 的內容。例如 <abbr>、<track> 等標籤到底該涵蓋哪些情境等等,以及像是對 caption 的討論;又或者 CSS 文字排版中的 justify 設定,其實也都跟網頁親和力有關,都談到了 WCAG 相關文件中的內容。

從 COSCUP 開場到結束之後的現在,親和力議題不斷湧出;親和力議題的核心是在處理內容的真正意義、用來表達這些意義的事物狀態變化,以及處理這些事物的載體(例如應用程式)是否能夠透過恰當的媒介(例如應用程式介面及訊息匯流排)把意義以及狀態變化傳達出來。親和力議題其實就在我們周遭,不但是人人可以研究的領域,更是人人都應該要研究的領域;從桌面軟體到網頁,從手持裝置到線上服務,只要有人的地方就要注意親和力,因為有親和力的地方就能讓人獲益。



自由軟體鑄造場電子報 : 第 157 期 無須使用資料庫的內容管理系統 - gpEasy CMS

分類: 自由專欄