2007/10/25

再談親和力部門──從執行長說起

前一期當中,筆者談到了親和力部門成立之前,得要有個重視親和力的執行長,並且要由對親和力有足夠瞭解的人來擔任親和力部門主管,然後還得對公司現況進行評估,再計畫親和力部門的任務里程碑,接著從其他各部門中,挑選出合適的人選來參與親和力部門的運作。從本期開始,就讓我們來看看,這些事又該如何進行呢。
2000 年的時候,奧多比 (Adobe)、美國線上 (American Online, AOL)、AT&T、康柏電腦 (Compaq)、eBay、HP、Macromedia、微軟 (Microsoft)、Qualcomm、Sun Microsystems、3Com、Red Hat、歐萊禮 (O'Reilley) 等多間大型企業的執行長和主席們,聯名寫了一封公開信給當時的美國總統柯林頓,表達對美國親和力政策的支持與配合。

在這封公開信中,對白宮推行的親和力政策,總共提出了兩項支持理由,與八項配合施行要點,很值得開發網路服務的各家公司主管參考。首先,親和力對於新興的資訊社會來說,會是個十分強大的工具,能夠大幅拓展各種可能性與機會,讓人們能更便利地接觸不斷成長中的各種電子資訊及服務;如果各公司都不做親和力的設計,則會有不少人將被摒除在這樣的主流社會與經濟活動之外。第二個理由是,注重親和力的設計,對於這些公司來說,有著良好的經濟及商業誘因,因為這樣子的設計,能夠嘉惠所有的使用者;因此不但那些在生理能力上有所限制的人可以運用這些產品或服務,其他對於輸入、輸出介面有著特別需求的專業人士,也將樂於選用有親和力設計的產品或服務。

這兩點理由,對於一路閱讀這個專欄的朋友們來說,一定不會感到陌生,因為這正是我所再三強調的理念。但是對於仲裁整間公司營運方向的人來說,這卻也是最基本、最重要的觀念,說明了親和力對於公司的道義與義務、利益與前景的重要性。執行長先要體認這兩點,然後公司纔有可能組成親和力部門。

這封公開信中接著提出了八項配合施行要點:

  • 在公司內部提高對親和力議題的體認,並提供員工們設計具親和力的產品或服務所需的相關訓練。
  • 為公司所提供的產品或服務,發展親和力方針,並在技術上及經濟上可行的前提下,交由產品開發部門來負責實現這些方針。
  • 在發展上述方針時,或者在產品或服務的設計及測試部門中,帶進實際有生理功能限制的人參與。
  • 在未來的產品開發及升級過程中,投注充分的產品開發及工程資源,以迅速地辨識並處理各種已知的親和力問題。
  • 藉由提供訓練、方針及技術解決方案等方法,讓開發社群能更輕易地建立具有親和力的產品或服務。
  • 針對產品及公開提供的服務,撰寫文件說明各項具親和力的設計。
  • 針對與產品或服務有關的親和力科技,支持贊助內部與外部(例如大學等學術單位)的研究發展,藉此提升最新的科技進展。
  • 支持邁向親和力的標準實做,例如像全球資訊網協會針對瀏覽器、網頁內容和編輯撰寫工具,所發展的一系列指導原則。

這八個施行要點當然不會是執行長親自下海操作的,但是執行長卻必須要公開地對公司員工頒佈相關的規定或備忘錄,明確表達支持與決心,並實際讓這些事項發生。事實上,這八個施行要點,也正是任何想要著重親和力設計的公司,所能遵循的大方向。

在這八個施行要點中,除了由執行長宣示對親和力的重視與分配資源外,我們還可以看出幾個重點:親和力方針、教育訓練、技術解決方案、科技研發、社群參與。這五個重點大致上都是要有親和力部門纔能順利執行的。其中首要的任務就是由親和力部門發展出整個公司應上行下效的親和力方針,並由執行長發佈;然後親和力部門藉由規劃舉辦教育訓練、維護並提供技術解決方案,來讓實際的產品能做出注重親和力的設計;並且要投注資源在科技研發跟社群參與上,來面對此刻還沒有辦法處理、或還沒有辦法預期到的親和力議題。

由這五個重點中,正可以看出親和力部門主管的遴選依據。這個主管必須要是瞭解公司文化的人,對親和力的重視不亞於(甚至應該要更高於)執行長,要對教育訓練以及內部資源處理有經驗,還要對外部相關學術界、產業界、社群均有接觸或認知,這纔有辦法領導親和力部門,執行上述的八個施行要點。

親和力部門又要如何執行這樣的任務呢?且待下回分解。

2007/10/09

初談親和力部門

講了那麼多關於親和力的議題,相信有不少讀者急著想要知道,究竟應該要怎麼把「親和力」放進開發團隊之中呢?

在回答這個問題之前,各位讀者不妨回憶一下先前所提過的幾個重要觀念。首先,「親和力」是一種對「內容」的錙銖必較,任何內容的每一個面向、每一種表現手法、每一處細節都會跟親和力息息相關,唯有充分利用各種內容標記的科技,纔能夠確保數位內容在各種環境中,都能盡可能地被完整取用。

不僅如此,「親和力」還是一種永無止盡的追求──不管此刻做得有多好,總還是會有更理想的解決方案;這些解決方案必須是合乎現實、真正滿足使用者情境的,所以「親和力」也不會放過對使用者經驗的研究。

由於親和力的本質如此,要想建造一個「親和力加工站」,把所有不做親和力設計的產品丟進去,就吐出具親和力的版本來,實在是不可能的。有許多專做網頁的公司,並沒有把親和力納入設計的一環,而是把親和力設計當成「未來的目標」或「有空閒的時候再做的功能」,再不然就是完全不理會,直到有使用者抗議使用不便時纔來做些甚麼;這種回頭再來處理的心態,乍看之下很能因時制宜,表面上是把資源優先放在重要的地方,但是其實很快地就會付出龐大的代價──設計之初沒有顧及親和力,導致日後的維護成為要命的苦工。過去幾年來,抱持著這種心態的機關團體,包括美國許多的政府部門,紛紛喫足了苦頭,現在反而回過頭來,開始呼籲同業們應該要正視親和力設計了。

所以到底要怎麼正視親和力設計呢?最好的方法,就是讓每個人或多或少都對親和力有所體認。畢竟親和力是種必須注重一切細節的事,因此任何經手網頁的人,都必須在自己的業務範圍內,採取重視親和力的設計,最終的產品纔能成為更具親和力的版本。為了達到這個目的,必須要滿足兩個條件:

第一個條件是,一個「親和力部門」必須要跟整個公司/機關組織內的各個部門,有良好的聯繫;其中最理想的實踐方法,是讓各個部門都有若干員工在親和力部門兼任工作,因為這麼一來,親和力部門的作為就不會悖離其他部門的現實太遙遠,而且這些員工也將能在各自原本的部門中,協助推行各種親和力方針。

在這種規劃下,「親和力部門」中其實不需要太多全職的員工,除了部門主管跟若干助理外,其餘的成員平常應該花較多時間在他們各自原本的崗位上,每週僅需要排出半天左右的時間,參與親和力部門的業務及會議即可;當然,既然有這樣的規劃,表示每一個部門(尤其是主管)都必須要能理解並同意這樣的工作時間安排,這一點在習慣壓榨員工的單位很難辦到,但是別忘了,好的設計本來就不容易在終日緊張疲憊的環境中誕生。

如果整個公司長期處於那種緊張與壓力之中,對於員工沒有足夠的重視,那麼這樣的工作環境本身就很沒有親和力了,自然不會做出具備親和力的設計。在這種情況下,真的想開始重視親和力,就得從改變公司風氣開始做起;而唯一有效的改變方式,就是從主管的心態開始改變起。

所以,第二個條件是,「親和力部門」必須要獲得來自執行長(或校長、院長、主管等最高位決策者)的直接授權與背書,並且掌握可以自由運用的充足經費──甚至要能夠提出獎勵或做出懲罰。換句話說,這麼樣的一個部門,必須有實質的執行力跟影響力,尤其在初期就必須很有魄力地訂出決策方向並執行,否則很容易就會形同虛設,流於形式而沒有實質的意義。

這樣子的一個部門,首要的任務就是要提攜所有員工對親和力的認知。通常這可以經由教育訓練來達成──但是親和力部門不見得要親自帶領所有的教育訓練,部分的訓練可以使用線上的教材,或者是委外來完成,祇要能夠控制好這些訓練的內容、時程與品質即可。不管施行教育訓練的方法為何,這些訓練的內容通常又可以分成兩個不同的層次:跟法律、社會議題、使用者經驗有關的概念層次,以及跟技術細節有關的實做層次;各部門的經理人或主管至少都應該要接受過概念層次的教育訓練,而實際執行業務的人則可能要視情況接受相對應的實做層次教育訓練。

教育訓練是培養員工們對於親和力認知的開始,但不是唯一的步驟;除了教育訓練外,親和力部門還需要鼓勵同仁們針對「親和力」這樣的哲學提出想法、互相交流,不管是實際執行業務時遭遇的問題,或者是可行的解法,都會是很有價值的資產──這些交流應當要被記錄下來,並加以整理,形成公司內部的知識庫。一旦有了知識庫後,就要讓知識庫便於被查詢、檢索,並且要常常更新。當然啦,經營這樣的知識庫乃是親和力部門的職責所在,當有人遭遇了實際的問題,而沒有其他人有充足資源來回答或討論時,親和力部門理所當然地也得扮演技術協力的角色,而不是瞪著難題就此卡住。至於如何鼓勵員工多利用知識庫、貢獻內容到知識庫,也得仰賴親和力部門的執行力──適當地獎賞,並且讓各級主管明白這件事的重要性,都是不錯的手段。

一旦所有的員工普遍對親和力都有了足夠的認知,而且日常遭遇的親和力難題也都有了明確的解決之道時,就是擬定內部親和力方針的時候了。

所謂的內部親和力方針,指的是公司內部對於親和力取捨的共識與目標。因為親和力博大精深,一心想要在各方面都盡善盡美,未免有些不切實際,因此親和力部門必須針對公司實際的處境與考量,決定出必須格外注重的部分,以及不得不捨棄的部分──還記得先前提過的負面列表消去法嗎?先明確地規劃出不得不捨棄的環節,剩下來的部分就會比較容易掌握了。

除了訂出範圍外,同時也應該訂出品質確認的規範,包括了執行的預計里程碑、技術性的監控、評估的方式等,這些也都是內部親和力方針的內容。一旦這個方針擬定完成後,就可由執行長發佈為內部正式。接下來應以每季或每半年為單位,檢視這個方針實際執行的情況如達成率、遭遇的困難等,然後做出適當的調整──可能會要調整員工,也有可能是要調整這個方針本身。切記:唯有一份能真正被施行的方針,纔能稱得上是方針。為了確保親和力實務真的能被力行,而不是唱高調而已,所以親和力部門纔會需要有來自各部門的員工參與。

親和力部門除了對內制訂方針、協助全體員工貫徹方針外,還有一個很重要的任務:擔任對外的公關單位,讓一般的客戶,以及各種有特殊需求的客戶團體,都能夠明白公司在親和力設計上的用心;並且也藉由主動參與相關的社群及客戶團體,來增進公司的親和力實務技術,並改善親和力方針。

萬事起頭難,講了這麼多可以做的事情,一開始還是得要有個重視親和力的執行長,以及對親和力有足夠瞭解的人來擔任親和力部門主管,然後還得對公司現況進行評估,再計畫親和力部門的任務里程碑,並且從其他各部門中,挑選出合適的人選來參與親和力部門的運作。這些事又該如何進行呢?且聽下回分解。

2007/09/09

封面圖案

(這件事來不及放進提案中,不過反正之後還可以再說不遲)書的封面應該要怎麼做?其實我有想了好一陣子。目前的想法是,色系宜暖,「溫柔」、「舒適」的感覺為佳;圖片的挑選主旨則為「Touch」這樣的意念。

我從 Flickr 上找了一些可能還不錯的、授權上也沒問題的圖片:


Thailand
Originally uploaded by babasteve



MS SC_Collab Photo App
Originally uploaded by lucamascaro



Touched by an alcoholic
Originally uploaded by the Comic Shop



Touching Rosetta
Originally uploaded by Namlhots



touching spring 2
Originally uploaded by michale

2007/09/05

所以提案寫完了

接下來就是丟給幾家出版社,看有沒有人有興趣出版……

提案摘要

《網頁親和力》是一系列以「親和力 (Accessibility)」為主題的叢書,涵蓋但不侷限於「無障礙網頁」的範疇,內容並不僅針對網頁設計師,同時也會針對決策者以及相關的人員來撰寫。有別於這類書籍通常都是厚厚一大本,不僅書價昂貴且難以日常翻閱使用,《網頁親和力》一開始就決定拆成數冊,各冊有各自的發展重點。

第一冊是從較高的層次來探討網頁親和力的哲學、概念與理論,然後逐一說明各種規範的細則,以及如何安置合宜的人力資源來執行相關的任務;第一冊後半段則接著以實務的角度,說明實際執行時所需要考量的面向,及可行的步驟,然後再從「設計」的角度出發,分析有哪些設計的花樣 (Pattern) 與親和力息息相關,以及要如何施行這些設計花樣。第一冊的最後則以親和力檢測、報告的規範及工具作為結束。預計包括網頁設計人員、負責維護或發包網頁專案的人員,以及決策的人員,都能從書中獲得相當有用的知識。

第二冊從較低階的層次來探討網頁親和力的技術細節。首先會先帶過目前在國內相關的輔具資訊及資源,讓讀者感受各種不同的運用網頁的方式;接著再分別針對網頁內容、導覽、表單、CSS、JavaScript、Flash、PDF、多媒體檔案說明親和力技術。這一冊的最後則以嶄新的 Web 2.0 開發框架的親和力作為結尾。預計包括網頁的視覺設計人員,以及網頁應用程式的開發人員,都會對這一冊感興趣。

目前規劃的這兩冊書籍,總篇幅將少於八百頁(各冊均少於四百頁),全部採單色(灰階)印刷,估計實際的撰寫時間大約落在七至十個工作月之間;主要的內容均由 Jedi 撰寫,第二冊約有一至兩章的篇幅會請和多工作室的朋友合力撰寫。預計將自 2007 年 10 月份起開始撰寫。

內容

《網頁親和力:法規與實務》

第一章:弄懂網頁親和力
  • 親和力與可用性
  • 親和力與無障礙
  • 親和力的非技術層次
  • 自然語言與多語環境
  • 親和力的取捨

第二章:網頁親和力規範

  • 法律基礎
  • 各國法規
  • W3C 推薦標準/指導原則
  • 研考會規範

第三章:WCAG

  • WCAG 1.0
  • WCAG 2.0

第四章:研考會「無障礙網頁開發規範」

  • 規範內容
  • 檢測程序
  • 瑕疵與建議

第五章:ATAG、UAAG、WAI-ARIA

  • ATAG
  • UAAG
  • WAI-ARIA

第六章:親和力團隊

  • 背景
  • 設立
  • 規模、功能與目的
  • 施行方法

第七章:導入網頁親和力

  • 過渡時期
  • 分析與評估
  • 重新設計
  • 檢視設計
  • 殘留的問題
  • 實行

第八章:設計花樣

  • 甚麼是設計花樣
  • 導覽框架
  • 有力的首頁
  • 撰寫及維護內容
  • 建立信任及信譽
  • 設計有效率的頁面佈局
  • 導覽容易度
  • 網站加速
  • 行動網頁

第九章:親和力評估與 EARL

  • 評估
  • 工具
  • 報告

第十章:止於至善

  • 親和力哲學
  • 親和力的極限
  • 結語

《網頁親和力:技術與實做》

第一章:輔助科技

  • 輸入輔具
  • 輸出輔具
  • 作業系統的親和力科技
  • 網頁技術

第二章:網頁內容

  • 原則
  • 文字描述
  • 語言資訊
  • 微格 (Microformats)
  • 色彩
  • 表格
  • 圖片、多媒體內容
  • 創用 CC 授權

第三章:導覽設計

  • 原則
  • 結構與順序
  • 導覽功能
  • 頁框
  • 影像地圖
  • 鏈結
  • 表單

第四章:資料輸入

  • 原則
  • 表單
  • PDF 表單
  • 計時

第五章:CSS

  • 原則
  • 色彩與背景
  • 字型與字體
  • 圖片代換技巧
  • 佈局與定位
  • 多重樣式表
  • 聽覺樣式表
  • 列印樣式表

第六章:JavaScript

  • 原則
  • 刻板(壞)印象
  • AJAX 與不亂入的 JavaScript
  • JavaScript 與導覽
  • JavaScript 與表單

第七章:Flash

  • 原則
  • 技術
  • 實做

第八章:PDF

  • 原則
  • 技術
  • 標記 PDF
  • 親和力修補
  • PDF 表單

第九章:多媒體

  • 原則
  • SMIL
  • QuickTime
  • Windows Media
  • RealPlayer

第十章:Web 2.0 Framework

  • 原則
  • Jifty (Perl)
  • RoR (Ruby-on-Rails)
  • Air (Flex)
  • 結語

2007/09/04

本書

「網頁親和力」在國內仍然是個很新興的領域,至少到目前為止都還沒有任何一本書是在探討這個主題;行政院研考會自 2003 年起開始制訂、執行「無障礙網頁開發規範」,此規範亦屬於「網頁親和力」的範圍內,但是除了研考會本身提供的微量文件外,並沒有任何書籍面市。另一方面,研考會所制訂的規範有許多扭曲親和力原意的細則,其所提供的文件及教育訓練講習等,也都有若干缺失,所以需要一本較為端正視聽的書籍,從比較高層次的觀點來講述整個「網頁親和力」背後的哲學,與實做的技術細節。

「網頁親和力」所要講述的主題,並不是只有「無障礙」的部分。亦即,並不是只有要說明「如何設計出一個殘障人士也能夠使用的網頁」,而是要去說明「如何設計出一個更多人能夠使用的網頁」,因此包括使用 PDA、手機、電視遊樂器(例如 Wii)、iPhone 等設備使用網頁的客戶,都能夠從重視「網頁親和力」的設計中獲益,使公司或組織的經營更為成功。

除了網頁瀏覽器以外,還有許多的「使用者代理」也會從網頁親和力的設計中獲利。包括像 QuickTime、Acrobat Reader 等,也都是「網頁親和力」所要探討的內容。許多過於專注於「網頁」的書籍或文件,往往疏忽了這些多媒體內容的處置,而這些卻是現今網頁所不可或缺的,因此本書也會來討論這方面的技術現實。

由於上述這些內容涵蓋甚廣,如果擠在一本書內出版,勢必會變成七百頁以上的磚塊書,而不會成為實用的書籍。為了實用性及銷售的考量,拆成兩本會是比較好的選擇;以兩本的架構來說,第一本會偏理論,第二本會偏技術。第二本因為有許多技術細節,因此在銷售上比較沒有疑慮,可是第一本卻有可能流於空泛,而成為人們僅在書店閱讀而不買回家的書。為了解決這個問題,所以第一本的內容將包含一些實務的章節,包括如何應對研考會所制訂的規範、過渡時期的導入方針、成立親和力團隊的方法、評估與檢測的方式等。在這樣的安排下,可以預期不管是實務人員或者是決策人員,都會對第一冊也感興趣纔是。第二冊同時也加入了一些提到流行術語的章節,例如 Web 2.0 等,以增加讀者購買及閱讀的意願。

封面及封底文案可以包含這些內容:
  • 超越「無障礙規範」的網頁開發流程/技術
  • 台灣部落格之父 Jedi 又一力作
  • StudyArea 團隊推薦
  • 符合 W3C 標準的跨平台網頁設計
  • 設計 Wii 及 iPhone 也便於瀏覽的網頁
  • 開發超友善的 Web 2.0 網頁
  • 讓你的 QuickTime、RealMedia、Windows Media、Flash、PDF 更平易近人

附件:可以有 PDF 版,可以用另外分售的方式,或者是開放已購書的讀者索取。網站上可以提供讀者特區,並提供上述的 PDF;至於 CD 則不需要。另外也可以設計一些檢核表或可以單獨使用的單頁文件,以厚紙印製,附在書後,讓讀者可以輕易裁下使用。

新書提案的寫法

隨便找了一些資料:

2007/09/03

作者資歷

Jedi 自 2002 年起即開始關注網頁親和力議題,曾與和多有限公司(當時尚未成立)的 hlb 共同翻譯《深入親和力》一書,該譯本雖未出版印行,僅以網頁及 PDF 格式散播,但至今仍為國內各相關研習、文件所相繼引用的資料。Jedi 於聽語障礙科學領域取得碩士學位,論文內容即與聽障族群之網路使用相關,實際接觸過殘障團體,並自 2001 年起就負責過網頁設計的專案,因此對於網頁親和力有著更為深入的體會。

Jedi 著有《BLOG 架站實務:使用 Movable Type》一書,由旗標出版社出版;該書已全數銷售完畢,沒有任何庫存殘留。此外 Jedi 亦曾參與過《Perl 學習手冊第三版》、《Perl 網路程式設計》、《架設 Slash 社群網站》、《FreeBSD 完全探索》、《深入親和力》、《超越式 CSS》等書的翻譯,獲得 2003 年由台灣軟體自由協會所頒發的自由軟體社群「傑出軟體中文化獎」以及「傑出文件翻譯撰寫獎」,並因推廣帶動台灣部落格發展而被稱做「台灣部落格之父」。

行銷

《網頁親和力》一書已設立了部落格 (http://blog.accessibility.tw/),作者是網頁設計師社群 HappyDesigner 的核心成員之一,計畫將舉辦以網頁親和力為主題的定期聚會;同時作者亦任教於臺北市公務人員訓練中心,因此可提案開設網頁親和力相關訓練研習。上述這些活動都可直接使用此書作為教材,或者作為重要的參考資料,因此可帶動書籍銷售。另外在南部活躍的 StudyArea 社群也願意推薦這本書。

篇幅

兩冊各十章,預計都會控制在少於四百頁的篇幅長度內,平均每章少於四十頁;如果以全部都是文字來計算的話,每章預計都不會超過三萬字。第一冊預計會花三到四個月左右的時間來撰寫,而第二冊則要花四到六個月左右。

第一冊完全由 Jedi 來撰寫,但是第二冊因為要涵蓋了許多技術細節,所以會再找兩、三位伙伴來一同撰寫。原則上第二冊需要仰賴外力的篇幅是兩章,也就是全書的 1/5,一旦確定合約等事宜後,就會馬上請合作對象開始撰寫,以免耽誤到時程。

第一冊當中會有若干流程圖及其他圖表,第二冊第一章則會有一些照片等,除此之外各章都會有螢幕擷取畫面。這些圖表及圖片都不需要彩色印刷,因此兩冊都出版單色(灰階)印刷版即可;原始碼範例中重要的部分則以粗體表達。

相關書籍

此刻市面上完全沒有任何一本直接與「網頁親和力」這個領域相關的中文書籍。即便是英文書籍也是屈指可數,其中比較重要的有:

  1. Building Accessible Websites. Joe Clark. 2002. New Riders Press. ISBN: 073571150X.
  2. Maximum Accessibility: Making Your Web Site More Usable for Everyone. John M. Slatin, Sharron Rush. 2003. Addison-Wesley Professional. ISBN: 0201774224.
  3. Web Accessibility: Web Standards and Regulatory Compliance. Jim Thatcher, Michael R. Burks, Christian Heilmann, Shawn Lawton Henry, Andrew Kirkpatrick, Patrick H. Lauke, Bruce Lawson, Bob Regan, Richard Rutter, Mark Urban, Cynthia D. Waddell. 2006. friends of ED. ISBN: 1590596382.

上列的書籍當中,第一本大概是同類書籍當中被引用最多次的一本,由親和力專家 Joe Clark 獨力完成,內容涵蓋甚廣,也討論了許多會實際發生的現實狀況;但是很不幸地,這卻是一本流於抱怨的書籍,讀者很難從這一本書當中看到甚麼光明的希望。

第二本書由兩位作者合力撰寫,內容涵蓋甚廣,很適合一般人也來閱讀,內容的編排上以實際的「情境」與「經驗」為主,讓人讀了之後很能夠心領神會,每一章一開始也列出該章所會涵蓋的 WCAG / Section 508 / XHTML Tags,因此用於技術人員的參考也很好用。對於親和力議題的態度則採正向積極,告訴讀者們如何「讓他更好」,這一點也是值得肯定的。這本書字很大,閱讀起來很舒服,這也是值得效法的一點。

第三本是由十一位作者合力撰寫而成的,是三本書當中內容最為廣泛的一本,同時也是資料最新的。除了帶進 AJAX、Flex 以及新工具的介紹外,還有大量的圖表,在概念的表達上相當清楚,並講述了 WCAG 2.0、JavaScript 的親和力、Flash 的親和力等,還有一個完整的實際案例研究──從事前規劃、每一個實際步驟、事後再檢討等等,鉅細靡遺。在技術性的章節中,除了概念的闡述外,思考的邏輯、運用的核心技術,實做的步驟,以及實際的程式碼──JavaScript, Action Script (for Flash), PHP 等,也都交代得很詳細。

《網頁親和力》大致上是參考第三本書的結構來規劃的,在內容及規模上會介於第二本跟第三本之間;所有跟我國無直接關係的部分(如 Section 508)都不會去提,而我國的法規及研考會的規定則會花更多篇幅來深入。技術實務的部分,會特別著眼在多媒體及新科技上,包括前述三本書都沒有提到的 Web 2.0 框架如 Jifty、RoR 等;另外也會提到微格 (Microformats) 跟創用 CC (Creative Commons)。

另外,有鑑於前三本書中,比較值得參考的後兩本書都相當厚,一方面售價不易壓低,另一方面難以帶著到處跑、到處用,所以《網頁親和力》一開始就打算分冊撰寫。目前的規劃是分成兩冊,第一冊談論的是法律、規範、策略與施行的實務,第二冊則要專注在各項技術的細節。因此針對不同的讀者,將更有誘因:用比較少的錢,把自己感興趣的那一部分買回去。如果看出興致來了,再買另外一冊不遲。理論上在決策位置的人,獲許會想買第一冊就好,而實務執行的人則可能會想要兩冊都買。

由於書中的內容會有些瑣碎的資料、圖表,並且每章都會規劃可以「帶著使用」的檢核表等,所以就算有人站在書店把書翻完,也還是會把書買一份回家纔是。

如果銷售情況理想,反應熱烈,則將《網頁親和力》主題繼續延伸出第三冊亦無不可。

讀者

根據教育部統計處的各級學校概況表指出,九十五學年度全國公、私立國小、國中、高中、高職、大專院校、大學、學院、專科學校、特教學校、空中大學共計 4213 所;全國公、私立大專院校、大學、學院的研究所數及學系數共計 7498 個。每個校、系、所至少都會有一名人員必須負責網站維護,因此光在學校系統中,總共就至少有 11711 名目標讀者。如果將各校校長或決策首長一併納入,則總共會有 19209 名。在這些校、系當中,九十五學年度網頁設計相關科系的學生總數為 49573 人,這些人也都有可能是本書系的目標讀者。

又根據 E 政府所提供的全國機關名錄,全國共有 4507 個公家機關,每個機關若至少有一人(不論是自己做或者是外包)實際負責網站維護,則這部分就至少會有 4507 名目標讀者。再加上各機關的決策首長,至少就會有 9014 名。

總括上述數據,本書系可能之讀者群約有 77796 名。當然不可能每一個人都會掏出錢來把書買回家,保守地估計,假設各級學校及公家機關當中,實際負責維護網站的人員有 1/10 會買本書,而各決策首長及學生當中有 1/100 會買本書,則預計的銷售量將會是 1171+75+496+450+45=2237,因此一刷兩千本應該是可以銷售完畢的。

市場

網頁設計師會對這套書有興趣。因為第一冊說明了許多的網頁標準及規範,包括其應用實例及分析,會是網頁設計師們接案(尤其是承接公家單位的案子)時的重要參考;第二冊針對每一項網頁技術進一步的詳細說明其親和力做法,更是網頁設計師會拿來參考的重要資料。

各級學校的資訊教師、網管會對這套書有興趣。雖然以臺北市來說,預計要達成全面符合研考會「無障礙網頁開發規範」的日期是 2007 年年底,但是實際上來說並不大可能在今年年底就真的全面達成;而且研考會還會在半年後,也就是 2008 年年中左右,對前述各級學校的網頁復檢抽查,因此這套書仍然能對各級學校負責網頁的人員有所幫助。

提供網頁/網路服務的中、大型公司/組織/公家單位主管會對這套書有興趣。因為這套書一開始就會挑明了說,為什麼網頁親和力能對營運有幫助;尤其在第一冊當中,更會說明相關的法律議題,以及如何部屬親和力團隊,正確地分配資源,省下不必要的重工成本。

學習網頁、決定以網頁作為出路的人,也會對這套書感興趣。因為這個主題還沒有任何中文書出現在市面上,因此除非直接閱讀英文書,否則這套書將成為目前唯一的一套教科書。

2007/09/02

關於書名

因為這套書預計要賣的對象,很大一部分會是那些面臨研考會壓力的人,所以雖然我不喜歡,但是恐怕還是得將「網頁無障礙」或「無障礙網頁」納入書名,否則大概會有很多人直接錯過吧。唉。

研考會的東西叫「無障礙網頁開發規範」,所以書名就一律改為《網頁親和力與無障礙網頁開發規範》吧。如果這書名太長了,那就縮短為《網頁親和力與無障礙》、《網頁親和力與無障礙網頁》或《網頁親和力與無障礙網頁開發》吧。

Blogger 有個投票功能啊……那來辦個投票好了,為期一週,請大家給意見吧!如果有人覺得有更好的書名,也可以直接回應這一篇。

內容規劃

之前本來想分成三冊,不過在訪談之後決定把一、三冊合併成一冊,然後再加以調整其內容,讓書的內容更豐富多元、賣相(?)更好。所以目前的規劃是這樣的:書分兩冊,上冊叫《網頁親和力:法規與實務》,下冊叫《網頁親和力:技術與實做》,預定篇幅都在四百頁以內,內容分別如下:

《網頁親和力:法規與實務》
  • 第一章:弄懂網頁親和力
  • 第二章:網頁親和力規範
  • 第三章:WCAG
  • 第四章:研考會「無障礙網頁開發規範」
  • 第五章:ATAG、UAAG、WAI-ARIA
  • 第六章:親和力團隊
  • 第七章:導入網頁親和力
  • 第八章:設計花樣
  • 第九章:親和力評估與 EARL
  • 第十章:止於至善
《網頁親和力:技術與實做》
  • 第一章:輔助科技
  • 第二章:網頁內容
  • 第三章:導覽設計
  • 第四章:資料輸入
  • 第五章:CSS
  • 第六章:JavaScript
  • 第七章:Flash
  • 第八章:PDF
  • 第九章:多媒體
  • 第十章:Web 2.0 Framework

MIT 徵網頁親和力工程師

MIT 的計算機科學暨人工智慧實驗室 (Computer Science and Artifical Intelligence Laboratory, CSAIL) 現在在徵全職的網頁親和力工程師 (Web Accessibility Engineer),工作內容就是要直接參與 W3C WAI 的運作,協助制訂 WCAG、ATAG、UAAG、EARL 等指導原則。

詳細的說明請見 http://www.csail.mit.edu/contact/jobs/00003003.html,或者直接到 http://sh.webhire.com/servlet/av/jd?ai=631&ji=1794224&sn=I 投遞履歷。

我覺得這是個相當好的機會啦,幾乎就是站在第一線貢獻了。不過我自己實在不大有自信,而且此刻也不大適合去做離開台灣的全職工作,所以這一次大概祇能眼睜睜地錯過了。

2007/08/26

訪談心得

讓我試著整理一下。(不過一定會有些雜亂)

以臺北市的教師來說,可能會參加過的研討會有:

其中研考會的場次主要是介紹,並播放了一支宣導影片;臺北市教師研習中心的場次則專注在 XOOPS 的使用上──但是另外還教了一些「鑽漏洞」的規避手法。這兩場研討會的因果關係大約是這樣的:研考會舉辦了研討會,要求各公家單位負責網頁的管理師必須參加;其中臺北市並定下了一個目標,希望今年 (2007) 年底的時候,能夠達到 100% 的「網頁無障礙 (A+)」符合率;屆時如果能符合這樣的要求,則負責的人員可以獲得嘉獎,至於不能符合的,至少今年也還不會懲處。其中學校單位的管理師或資訊教師參與了研考會的研討會後,開始反應說沒有足夠的能力或資源,因此北市教研中心也開始辦理研習活動。

至於各學校實際面對這個目標時,採取的策略有四:

  • 自己寫一套內容管理系統,包括像是西門國小、新生國小都是這樣做
  • 使用 XOOPS 作為內容管理系統;前面提到的陳怡杰經營了一個工作室叫「多媒體e學園」,就接了許多這樣的案子
  • 跟廠商購買內容管理系統,例如 SchoolPAD
  • 與廠商合作撰寫內容管理系統

這一點其實很有趣,因為好端端的一個網頁無障礙或網頁親和力的推廣,瞬間變成了各家廠商販售內容管理系統 (CMS) 的商機──而且糟糕的是,其實這些 CMS 未必真的能把事情做好啊(尤其像是,還有人在研討會上說,為了要能用 XOOPS,所以 MySQL 的內容必須塞 BIG5?天啊!)。

而參與過上述研討會的資訊教師,其實還是不能體會,投注這些資源到底目的是甚麼──做這些事情只是為了要滿足政策呢?還是真的能夠幫助到誰甚麼?為什麼這樣的代價是值得的?這些都不是上述研討會所能夠回答的,因此這大概就會是我新書內容所必須涵蓋的部分:更加活生生的案例及說明等。

除此之外,由於各項研討會都變成了 CMS 販售推銷大會,參與這些活動的資訊教師祇能學到各種 CMS 的用法,對於「親手撰寫出有親和力的網頁」這回事,反而缺少資訊。例如要如何用 Dreamweaver 或 Expression Web 來寫出有親和力的網頁,這樣的內容也是值得放進書中的。

在發現這件事的同時,還有一件令人驚惶的事:研考會的部分規範,像是 alt 的寫法、表格寬度的設定等,似乎是誤解了 WCAG 1.0 的內容,因此會造成弊多於利的結果。我想這件事也應該要放進書中,拿個一整章來討論,看能怎麼辦。

最後我還問了關於其他人──主管、其他行政人員對這件事的態度。原則上當事人會很希望其他人能夠明白這一切到底是怎麼一回事、要怎麼分配資源進來,以及應該要如何配合等。不然即使是一開始達成了,日後要繼續維護也只會是更多苦痛。所以,如果有一份文字,是能夠讓,不直接處理、但是有相關的其他人,也能夠明白這些事的話,對於執行業務的人來說會很方便。

我在訪談結束後,稍微描述了一下目前對三冊書的規劃──結果似乎第一冊跟第三冊的吸引力較弱,也許應該要把它們重組成一冊,變成總共兩冊的架構。我得再想一想。

2007/08/25

訪談要點

明天要為這本書,進行第一次的(半正式)訪談。願意接受我訪談的是一位臺北市的教師,負責學校的網站等業務,並且參加過一些臺北市的「網頁無障礙研習」活動。

明天訪談的重點,大致上如下:
  • 這些研習活動的規劃
  • 這些研習活動的內容
  • 實際執行網頁業務的人員的需求(以及目前仍然遇到的困難等)
  • 跟此業務有關的其他人(主管、部屬、同仁)的需求

之所以會想做這次的訪談,是因為我覺得如果書要賣得好,那麼全國執行網頁業務的教師或人員,必然就會是不可放棄的市場。同時我也希望在這麼訪問之後,能夠進一步確立書(尤其是第一冊)的內容規劃。

如果我明天有振作起來的話,希望是可以馬上把訪談心得寫下來或整理出來啦。

2007/08/20

可以拜訪的單位或廠商

除了之前提過的幾間公司外,因為書中應該會有一章是在介紹各種跟網頁相關的輔具科技,所以國內有一些相關的單位,或許可以去拜訪一下:
另外還有一些公司、廠商,是實際在代理或開發這些輔具的,大概也可以去拜訪一下:
目前有記到的就這些,如果沒辦法實際拜訪、拍照,至少也該拿拿型錄之類的。

2007/08/16

可以訪談的對象

書的第一部分中,有至少一個章節是要講做網站的公司應該要怎麼面對/規劃親和力團隊的。

就我之前打聽到的消息,國內好像沒有甚麼公司真的有這樣的團隊;就連雅虎台灣,也就只有 User Experience 部門而已,而沒有獨立的 Accessibility 部門。這其實是個很有趣的議題,我的意思是說,去瞭解國內的公司、企業對這件事的看法,本身就是很有趣的一件事,然後再去想想在這樣的環境中,要怎樣才能再更進一步,也是有價值的方向。

所以,我一開始就有想到,可以來拜訪一下雅虎台灣的 User Experience 部門。另外就我所知,他們與趨勢科技似乎也有某種地下的、非正式的、非官方的關係,到時後也可以再來循線拜訪。

除了雅虎台灣之外,從行政院研考會辦的網頁無障礙研習當中,可以看到有幾間公司:凌網科技大理資訊網韻資訊,他們都「宣稱」了自己有能力做著重於親和力的案子,所以我想之後也可以來安排拜訪一下。

至於拜會的重點,大概有二:首先是瞭解一下他們的作業流程中,如何安置親和力這一環;接下來並瞭解一下,他們是否有專責的部門,如果有的話又是如何與其他部門合作或互動。

語意與尺寸的親和力兩難

截至目前為止,我們已經連續討論了六期親和力相關議題,並且實際說明了許多用來增進親和力的網頁標記。現在,該是讓我們來面對另一個兩難的時候了。

循序思考過親和力的讀者,不難發現親和力的重點之一,在於表達網頁內容的語意;因此我們採用了恰當的方式,運用各種符合網頁標準的標記,來加強網頁內容的意涵──藉由這樣的做法,就算使用者代理程式(例如瀏覽器)祇能剖析部分的網頁內容,還是能拼湊出完整的語意。

這其實跟磁碟陣列(RAID)的哲學是相同的:放置冗贅(redundant)的內容,犧牲空間來換取強猛有力(robust)的資訊傳播。磁碟陣列的做法是把同樣的數位內容放置在多個磁碟空間,而網頁親和力則是把同樣的意義表達成多種型態;同一份媒體內容,可能還會有同步、對應的字幕、聲音描述、其他語言的配音、替代文字、描述網頁等。

但是這種做法所要付出的代價就是,同樣的「意義」將佔據更多的空間──在網際網路的世界中,不僅是儲存的成本提高了,下載所需的成本也提高了。傳輸內容會耗用更多的頻寬,使用者下載頁面也得花上更多時間。

等一下,當我們思考網頁親和力時,其中一個常被提倡的優勢,不就是讓網頁能更快被下載嗎?有的讀者此時可能會問,為什麼現在又要說,增進網頁親和力的同時,會讓網頁變得更肥大呢?這樣豈不是自相矛盾了?

事實上親和力在追求的,並不是一味地減少網頁尺寸,而是要把資源花在刀口上;同時,如果還能夠把成本降低,那再去做。舉例來說,如果某個網頁中,不具語意的標記如 <strike>、<font> 等佔據了 20%,那麼單純把這些不具語意的標記清掉,可以把網頁尺寸降為原來的 80%。另一方面,如果把這些內容以具語意的標記重新處理過,也許會使得整體的尺寸變成原來的 120%,看起來好像反而增加了 20%,可是由於語意的冗贅,使得網頁祇要下載完 40%就能夠表達充分的意義──因此使用者實際上祇要下載原網頁尺寸的 48%(120%×40%=48%)就夠了,這比從 100%降到 80%的降幅還要大。

親和力並不是要剝奪使用者的使用經驗,反而是要讓使用經驗更為紮實且豐富;這一點也是許多誤解親和力的人所不明白的。許多製作網頁的人,常常會以為「祇要另外製作一個純文字版的網頁,就可以符合網頁無障礙的規範了」;但是從前面的說明中,我們可以明白,像這種做法僅是把網頁檔案尺寸從 100%降到 80%──然後再繼續把網頁的語意一併刪減,讓網頁的尺寸降到 40%,結果網頁尺寸的確變小了,可是網頁的意涵也祇剩下 50%,親和力則剩下不到 10%。

那樣子單純祇是想減少網頁尺寸、祇提供平坦而無深度的內容的做法,實在是邪門歪道,帶來的只有更多的歧視與偏見;因為那種網頁設計在向使用者說:「我(網頁設計者)不管你的情況如何,也不管你還有哪些優勢,對我(網頁設計者)來說你們就是低等公民,我(網頁設計者)就是要無差別地剝奪你的使用經驗與樂趣。」

要讓網頁更有親和力,就應該要讓使用者能運用他們各自所擁有的任何優勢與能力,盡可能地傳達網頁意義,並讓使用者能享受到最多的使用經驗。

具備親和力的設計,之所以能辦到這件事,是因為設計師能夠以「意義」為核心,然後就跟洋蔥一樣,一層一層地把額外的意義附加到核心外。這種分明的層次,讓網頁的不同部分──結構、樣式、功能、協定等──各自獨立,而且都能重視「意義」,因此接下來就可以針對網頁的不同部分,運用各式各樣的技術來改善。

舉例來說,雖然用 CSS 來處理樣式,乍看之下會比直接在 HTML 內使用視覺性的標記要來得麻煩,但是我們可以用一條 CSS 規則來處理所有共同的樣式,讓不同的網頁部件能在語意上相連,並讓實際的檔案總尺寸減少;同時,我們可以針對不同的使用者代理媒體類型,分別提供不同的 CSS,讓使用者實際需要下載的 CSS 檔案尺寸也變小。這麼一來,我們在大幅增加靈活性與適用性的同時,仍能將下載網頁所要耗費的 HTTP 請求數量控制在一定的範圍內。

同樣地,藉由調整網頁的結構部分,雖然使用者要完整地看到網頁的每個細節仍然要花同樣的時間,但是在網頁還沒整個載入前,使用者就能夠獲得整個頁面中最重要的資訊;甚至那些比較岔題、較旁枝末節的部分,也能夠在此分離到另一個單獨的網頁去,等使用者有需求時再載入。藉由重視親和力的設計,就能夠分別針對這些不同部分逐一處理,而不用擔心他們會互相牽制。
不祇是網頁的檔案尺寸而已,為了達成具有親和力的網頁設計,所要投入的人力及資源成本、所該規劃的組織規模等,也都會增加。但是這種投資,都可以減少不必要的浪費,並且獲得更多的優勢。

下一期,就讓我們來探討,該如何來投入這樣的人力成本吧。

2007/08/15

其他與語言相關的網頁親和力實務

接連幾期我都在講述跟語言有關的親和力議題,從自然語言的處理到多語環境,本期仍然要來探討這方面的議題。

在某些語言當中,會有一些進階的語言用法,像是英文(及泛英語系)中就會有「縮寫」跟「頭文字」。網頁規格主要是英語使用者所制訂的,所以這種語言上的特色也就被保留進來。例如我們會把「versus」縮寫成「v.」或「vs.」,把「internationalization」縮寫成「i18n」;當我們在網頁上使用這些縮寫時,其實可以用 <abbr> 標籤來標記,再用 title 屬性來指出原本的文字。例如:

<abbr title="internationalization">i18n</abbr>

這麼一來,不瞭解這些縮寫,或者是認知能力遭遇困擾的讀者,就有額外的機會可以明白這些文字到底是甚麼意思;螢幕朗讀軟體也能有機會把縮寫唸成正確的字詞,而不僅是逐字唸出。「縮寫」的概念並不難理解,但接下來的「頭文字」就有些討論空間了。原則上頭文字乃是一種縮寫的形式,由整個字串中各個字詞的開頭字母所組成,例如把「Thanks God It's Friday」寫成「TGIF」就是一種頭文字,應該要這樣標記:
<acronym title="Thanks God It's Friday">TGIF</acronym>

而其中的爭議點是,有些人認為頭文字一定要是一個「可以唸的新字」,例如 NASA (National Aeronautics and Space Administration) 可以唸成「那撒」(音),所以纔能算是頭文字,而上述的 TGIF 唸成「T-G-I-F」則不能算。我個人對這個爭論的態度是,傾向於不去考慮它能不能唸──因為人們總是有辦法把不能唸出來的字詞唸出來;舉例來說,前述的 TGIF 也有人會唸成「踢鋸撫」(音),所以用這種方式來判別,其實是有待商榷的。不過呢,如果你覺得要用能不能唸出來作為這兩者的分別的話,或許還可以獲得額外的好處──你可以輕易地透過 CSS 來指定用不同的方式,把這些內容「唸」出來:

abbr[xml:lang=en] { speak: spell-out; }
acronym[xml:lang=en] { speak: normal; }

這種縮寫及頭文字的用法,拿到我們日常使用的中文環境中,就會激盪出許多想法及想像。由於我們歷經了文言文那種極為壓縮的語言用法,導致許多常用字詞,其實也都是「縮寫」──「判別」可以擴寫回「判斷分別」,「爭論」可以擴寫回「爭執議論」,如果把所有的常用詞都按縮寫標記的話,顯然是搞錯了。

任何設計都是這樣,用過頭了就會有反效果;但是我們還是可以適當加以運用,強調網頁內容的關鍵語意。舉例來說,當某個網頁第一次出現「中研院」的時候,也許這麼標記:

<abbr title="中央研究院">中研院</abbr>

就能夠讓與此背景較不熟的人,不至於對奇怪的詞彙感到迷惘──不過標記一次就好,接下來再標記則會畫蛇添足。這裡還有個可以討論的議題:「中研院」這樣到底算縮寫還是頭文字?如果覺得「中央」「研究」「院」是三個詞,每個詞的開頭組成「中研院」的話,應該要是頭文字纔對。但是或許頭文字更適合保留給(目前還沒有辦法在電腦上輕易輸入的)「招財進寶」那種字的用法。不過,不管「中研院」算不算頭文字,橫豎頭文字都是一種縮寫的形式,所以用 <abbr> 來標記總是錯不了的。

前面我剛提過文言文,有些讀者或許馬上會想到,如果要標記文言文的內容,加註白話翻譯,是不是也該用 <abbr> 標籤呢?日文中有種叫「振假名」的用法,就是在漢字上面用假名來標記讀音──這個用法在近代也有了不少演變,包括不限於漢字,就連英文字母或其他字符都可以有「振假名」;而且也不見得要標記讀音,也可以標記「真正要指稱的意義」。W3C 的日本分會基於這種需求,在 XHTML 1.1 中提議了一個叫 Ruby 的模組,稍後並成為 XHTML 1.1 規格之一。

XHTML 的 Ruby 可不是 Ruby-on-Rails 的 Ruby,而是個印刷術語,意思是「字旁註」,不但適合日文中的振假名,同時也適合標註國音一式/二式等注音,以及文言文的白話翻譯等。有的讀者可能會感到疑惑,「字旁註」這種印刷表現,怎麼看都很像是基於排版及視覺效果所設計出來的組件,跟當代的網頁設計哲學有所衝突。事實上這個組件有其語意,讓我們來看看這個範例:

<ruby>
<rb>若且唯若</rb>
<rp> (</rp>
<rt>if and only if</rt>
<rp>) </rp>
</ruby>

對於支援 Ruby 的瀏覽器,上述的範例會顯示出「若且唯若」四個字,並在這四個字上方用較小的字型標示出「if and only if」;對於根本不支援 Ruby、或者是無法表達出字旁註視覺效果的瀏覽器(例如點字瀏覽器、螢幕朗讀軟體或其他瀏覽環境),上述的範例則會忽略所有的標記,而逐字繪製出「若且唯若 (if and only if) 」,而這完全符合我們對中文的使用習慣,語意上可以說是一點瑕疵、一點累贅也沒有。

在知道了這麼多細節之後,我們還要回頭看看現實的環境:並不是所有的瀏覽器,都能理想地支援上述各種實務做法;像是許多瀏覽器對 <abbr> 及 <ruby> 的支援都不理想,會讓設計師在撰寫網頁時退卻不前。這時候我們該怎麼辦?放棄這些理想,向現實屈服嗎?

正好相反,我們該做的事情是要擁抱現實,持續以正當的標籤表達網頁語意,並向瀏覽器廠商──Opera、Mozilla、Microsoft 等表達出對此的急迫需求,因為網頁瀏覽器──以及其他眾多的使用者代理──也是親和力中極為重要的一環,祇不過自從上一次瀏覽器大戰結束後,就一直未受到足夠的重視。當政府及許多方開始關注網頁內容的親和力後,其實也該把資源投注到瀏覽器上,不過那又是另一個漫長的故事了,日後有機會再來討論吧。

在那之前,下一期,我們將來回過頭看看親和力實務上另一個受到忽略的基本議題──網頁大小。

2007/08/14

多語環境中的網頁親和力

上一期我們談論了自然語言的親和力議題,但是這個議題還沒有結束;對於網頁這種媒體來說,經常會出現許多語言同時呈現在同一個網頁上的情況,這時如果能夠多花點心思來處理,就有機會幫助讀者掌握這些語言或語境間的切換。

網路幾乎是沒有國界的,任何一個網頁的內容,都有可能是由任意的語言所撰寫。當隨機的某個網頁出現在我們眼前,我們也許能夠立即做簡單的判別,判斷出網頁的內容是否是我們自己所熟知的語言,例如中文、日文、韓文、英文等;但是如果撰寫網頁內容的語言,並不是我們所熟悉的,例如德文、法文、義大利文、波蘭文等,那麼我們除了能判斷出「這不是中文」、「這似乎不是英文」之外,所能獲得的資訊就很少了。

有人也許會覺得,「知道這不是我所能理解的語言」就好了,何必非得認出一個自己不理解的語言呢?因為即使我們認不得網頁的內容,但祇要我們可以知道那是用甚麼語言寫成的,那麼就可以利用各種翻譯軟體或線上翻譯服務,把網頁翻譯成我們所能理解的語言。更進一步地,如果我們有辦法讓翻譯軟體或線上翻譯服務直接知道網頁內容所使用的語言,那麼就可以更方便地將網頁以我們所能看懂的語言呈現,網頁也將更具親和力。

要實現這個夢想一點兒也不難,祇消在網頁的根組件 <html> 標籤加上一個屬性即可。如果網頁是以 HTML 撰寫的,就用 lang 屬性;如果是以 XHTML 撰寫網頁的話,則可以用 xml:lang 屬性,標記出網頁內容主要使用的語言。日後,不論是搜尋引擎、線上服務,或者是使用者本機端的應用程式,就都能夠根據這個屬性,更便利地取用網頁內容。

這小小的一個屬性,作用卻很大;除了能讓你辨識陌生的語言外,還可以協助讀者分別相似但不同的語言。舉例來說,台灣、香港、大陸所使用的文字看起來很像,重疊率也不低,但是畢竟語法有出入、措辭有差異、語音語調有相別,各有不同的語感;光是要在這幾種不同的語言間翻譯就不是輕鬆的事,如果還要進一步從中擷取出語意,或者更進一步地加以處理其資訊,就會是更困難的事。如果再加進日文或韓文的漢字,這種分歧就會更顯著。

就算是美式英文跟英式英文這樣的差別,也應該要標示出來。想像一下,如果有讀者習慣(或必須)用螢幕朗讀軟體,把網頁內容朗讀出來,那麼美式英文跟英式英文就該有不同的腔調,纔有那個味道,網頁內容也纔會更具親和力。

不同網頁可能用不同語言來撰寫,而同一個網頁內也常常會有多種不同語言並存。舉例來說,以目前崇尚英文的情況來說,中英夾雜是非常常見的;或者在介紹遊戲、動畫、漫畫的網頁中,中日夾雜也很常見。如果我們用前述的方法指定了網頁主要使用的語言,卻沒辦法處理交雜在其中的其他語言,那麼將會帶來困擾──任何處理網頁內容的科技或軟體,都有可能被迫用不正確的方式來處理這些內容,例如硬把日文漢字當作中文字來朗讀或翻譯成英文等。所幸在 XHTML 中,任何組件都可以使用 xml:lang 屬性,因此我們可以把任何需要特別標示的其他語言內容,都這麼標示出來。例如:


<html xml:lang="zh-tw">
……
<p>……你這<span xml:lang="ja">馬鹿</span>!……</p>
……
</html>

在上述的例子當中,由於我們已經指定了整份 XHTML 網頁主要使用的是繁體中文,所以其中任何以繁體中文撰寫的內容都不需要特別標記;當要混入日文漢字(馬鹿)時,就將其組件──沒有的話就多包一層 <span> 標籤,這對語意不會有損傷──加上 xml:lang="ja" 屬性,這麼一來螢幕朗讀軟體就知道這個詞應該唸成「巴嘎」而不是「馬路」,翻譯軟體也能知道這邊要切換成日文辭典而不能繼續沿用中文辭典。

除了這種自然語言夾雜的情況,有時候我們也會把自然語言跟不是那麼自然的語言混在一起,例如電腦資訊的相關教學文件,或者是撰寫程式或網頁的文件等,裡面除了會有自然語言外,還會有許多不自然的字詞──鍵盤按鍵、程式碼或原始碼、應該根據情況修改的參數、螢幕輸出的範例等,也應該要用 <kbd>、<code>、<var>、<samp> 等標籤,特別標記出來,這麼一來其他程式才能知道要用合適的方式來處理這些內容,用更符合情境的方式加上視覺裝飾(例如按鍵就加上立體外框,顯示成按鍵的樣子),而且不要硬把它們當成英文翻譯成其他語言。

各位可以發現,像這種做法,與其說是為了網頁親和力,倒不如說是添加網頁內容的語意。的確,因為親和力的核心就是要盡可能地表達語意,所以把網頁的語意顧好了,親和力自然就完成一半了。

讓我們回到自然語言本身。當我們想要把網頁唸出來──不管是要自己朗誦,或者是藉由螢幕朗讀軟體來將文字轉語音 (TTS,Text-To-Speech) 時,又有哪些細節,是可以讓網頁更具親和力呢?由於篇幅的關係,讓我先賣個關子,且待下回分解。

2007/08/13

自然語言的親和力原則

「自然語言」這個說法,是相對於「人造語言」(例如電腦程式語言)的稱呼,簡單來說也就是一般人日常溝通所會使用的語言。人造語言通常有著(由少數人)自創的詞彙,以及嚴格、絲毫不通融的文法,再加上受限的表意範圍,所以對普羅大眾來說,往往會是不容易上手、但也不難完全掌握的語言類別。

另一方面,自然語言跟整個社會文化無法分離,隨著時間而不斷演變;人類在成長過程中很容易就能養成對這種第一語言的語感,再加上自然語言在句法、表意上的彈性,使得這類語言對人類來說猶如天性一般。然而,也因為永無止盡的例外、變動和暗示,自然語言同時也成為最難完全掌握的語言類別。(所以「文學」纔變成了一門學問,而且永遠沒有發展的止境。)

在我們將親和力的設計付諸實現時,最困難的部分並不是關於標籤、標記等「人造語言」的部分,而是在於「自然語言」的使用。不管是在設計網站,或者是在評估網站的親和力程度,自然語言都會是個費解的議題;我在此挑選了這個部分來當作親和力實務的第一步,希望能多少抒解各位心中的困惑。

自然語言,或者說任何用於網站內容的文字、語音,是要給讀者看、聽的;這就是第一個原則:使用(目標)讀者易於理解的語言。

當然啦,真正的問題我們之前有提過,在於「誰纔是目標讀者」。這件事是在設計任何網站之前就要先搞清楚的;但是一般在設定目標讀者時,尤其在採用了樣本個案或使用情境範例時,很容易造成盲點──有一些人其實應該是你的目標讀者,但卻因「一時沒想到」而被摒除在外。

舉例來說,設計一個「以公眾為服務對象、內容多翻譯自英文」的網站時,很有可能為了提供大眾最精確的內容,而使用許多外來語以及英語式文法,甚至常常用括號夾註原文。這樣的書寫似乎很符合網站的定位;然而,因為對英文熟悉的人,根本會直接去看原始的英文網站,所以這種網站真正的目標讀者,其實是對英文及英文式文法不熟悉的人,結果這網站內容所用的語言,恰好是對目標讀者最沒有幫助的──這些讀者被網站的內容摒除在外。這樣的網站就算花了再多心思去撰寫、維護,最後卻會被嫌「難以閱讀」(網頁內容不夠具有親和力)而未敬其功。

為了避免重蹈此種覆轍,我建議在列出樣本個案或使用情境範例時,同時併用「負向列表」:試著列出「哪些人不是我們要服務的對象」,其餘的都是需要顧及之處。

以相同的例子來說,我們除了把目標讀者設定成「受過(或正在受)國民義務教育的普羅大眾」外,如果再把「熟悉英文及歐美文化的人」排除掉,就能夠避開前述的慘劇。各位可能注意到了,「負向列表」並非祇訂出「可以不處理」的範圍,而是成為增強目標讀者特質的陳述。當然啦,在這個例子中,你也可以直接把目標讀者設定成「不熟悉英文及歐美文化的普羅大眾」,但是這種用精細的正向列表累積出來的目標設計,不但容易有所疏漏,而且可能會造成若干矛盾,甚至混淆了各項細節的輕重緩急;所以尤其在專案的一開始,同時併用正向列表及負向列表,將讓事情更簡單、更清楚。

第二個原則是:使用的文字要在情境中具有意義。也就是說,任何文字,都必須考慮到前後文──句子是不是能像個句子、段落是不是能像個段落。

跟這個原則最直接相關的常見錯誤,出現在非文字組件(如圖片、影片、音訊、Flash 動畫等)的替代文字(alt)屬性。許多撰寫網頁的人,對親和力沒有正確的認知,祇因為被教導說「所有的 <img> 標籤都要有 alt 屬性」,就畫蛇添足地撰寫了過量的替代文字。

其中一個最常見的情況,是在裝飾性(而不具語意)的圖片上,撰寫了多此一舉的替代文字。想像一下,有一個網頁,在標題「新生活運動」的前後,用了若干裝飾用的雲朵圖片;這些雲朵圖片通通都加上了 alt="雲" 的屬性,因此使用研考會網頁無障礙的檢測軟體,或者用 W3C 的親和力檢測軟體檢測時,都能順利地通過。然而,當使用者把瀏覽器的圖片顯示功能關閉,或者使用純文字網頁瀏覽器,或者把網頁內容直接複製─貼上到 BBS 上或其他純文字編輯器時,卻會變成這樣子:

雲 雲 雲 新生活運動 雲 雲 雲

如果網頁的讀者使用了螢幕朗讀軟體,還可能因此發出更多噪音:

「圖,雲,圖,雲,圖,雲,新生活運動,圖,雲,圖,雲,圖,雲」

因為這些圖片放在前後脈絡中,沒有任何語意,所以最適合它們的替代文字屬性應該要是個空字串,寫成 alt="" 。如此一來,不論是純文字模式中,或者是螢幕朗讀的時候,讀者都祇會看或聽到真正具有意義的「新生活運動」而已,不會有多餘而無意義的東西。

另一個也很常見的狀況,則出現在附有解說的圖片上。如果圖片之後緊跟著圖說,或者是馬上出現了代表該圖片意義的文字,那麼這種圖片也應該用 alt="" 的空字串替代文字屬性,否則讀者就有可能會連續看或聽到兩次相同的內容。如果有人跟你說話時,每一句話都要講兩次,你一定會精神崩潰;所以千萬不要用同樣的方式虐待你的讀者或聽眾。

除了不要畫蛇添足外,對於安插在文句當中的(非文字內容的)替代文字,以及網頁中的任何文字,也都應該要秉持著相同的原則,讓應該要是句子的字串,能有句子該有的正確語法,表達出恰到好處的語意。

接下來的第三個原則,跟第二個原則可以說是一體的兩面:使用的文字要在情境外具有意義。或者說,每一段文字在單獨出現的時候,也要能有足夠的意義。

這聽起來很奇怪,畢竟我先前一再地強調情境、脈絡、上下文的重要性,現在卻又叫你要能從中抽離。這個原則是因應網頁媒體的特性而生的:網頁媒體的特性在於,任何讀者都能夠決定,內容要如何呈現在他們面前,好讓他們能夠更便利地使用。所以,網頁中任何一段文字,都有可能被擷取出來,抽離其原本所處的脈絡,被重新整理呈現。

舉例來說,許多網頁瀏覽器或螢幕朗讀軟體,都能夠把網頁中所有的圖片或超連結抽取成一份清單,在這份清單中會列出圖片的標題(title 屬性)及替代文字(alt 屬性),或者是超連結的標題(title 屬性,沒有的話則通常會用超連結文字)及網址。所以尤其當你替語意不全的文字──例如「說得好」、「很」「多」「人」、「以前」等──加上超連結時,別忘了務必要用 title 屬性,為它們撰寫一段「單獨閱讀也能懂」的標題文字。

這個原則並非侷限於圖片或超連結而已,任何的文字段落及網頁內容也都該如此。除了因為讀者可能把這些片段抽出運用外,他們也有可能因為某些原因(例如運用了定位錨)跳過網頁開頭,而從中間開始閱聽;或者是受到注意力、記憶力、視力或其他感官的限制,而沒有辦法追溯太多前後文。不管他們所遇到的困難為何,保持網頁中每一個小單元的自給自足,總是能有所幫助,也能讓你的網頁更有親和力。

第四個原則,也是本文所要講解的最後一點:小心處理表情符號跟非正式書寫模式。有一些文字其實不是真的文字,而是圖案;例如:

XD
:)
:-p
^_^

orz

這些被稱做「表情符號」(或「顏文字」)的東西,其實是借用 ASCII 字符的形狀,所拼湊出來的圖案。另外在網路書寫中,也常常會看到用來表達情緒、動作或內心狀況的註記,例如:

*心*
*茶*
(笑)

這些都不是符合正式語境中的自然語言用法;要判定這件事相當地容易:把這些內容大聲地朗讀出來,然後你就應該會知道了。當然,如果哪一天,我們使用的語言演變成,日常對話中充斥著:

「我哪有這麼呆,笑」
「那時我真的很大於底線小於」

那麼這大概就不是個問題了(例如日文在這方面就演變得比較快……)。不過在那一天到來前,除非你所設定的網站目標讀者明確能接受這樣的對話出現,否則你都該小心處理這樣的內容。
最簡單的處理方法,就是避免使用。真的要用表情符號或表態註記時,它們其實可以被當作是某種縮寫,所以你應該用 <abbr> 標籤來標記,並使用 title 屬性來替它們撰寫較正式的用語──別忘了,這段用語應該要在情境中及情境外都有足夠且合宜的意義。例如在前面的兩個範例中,分別用「<abbr title="說著說著,我就笑了出來">」跟「<abbr title="難堪">」標籤來標記縮寫,那麼讀者不論是讀到或聽到這些內容,就都能夠理解其意義,並感受到撰寫者所要表達的情緒:

「我哪有這麼呆。說著說著,我就笑了出來」
「那時我真的很難堪」

各位閱讀至此,可能會發現本文所涵蓋的親和力怎麼很像是作文技巧?因為,的確,作文技巧會影響到文章的親和力,影響到網頁內容的親和力。對於許多撰寫程式或視覺設計起家的網頁設計師來說,這恐怕會是艱辛的一步;但是請務必理解,這些原則卻也是讓你的努力免於浪費的關鍵,所以絕對值得各位花時間下功夫。畢竟,網頁是要給人來使用的,自然該從人的角度,仔細看待網頁內容的細節。

同時,當各位能掌握到這些網頁內容細節時,這些掌握也將回饋到你原本的工作中,讓你能夠更精巧、纖細地處理網頁內容,而做出更細緻動人的設計。

2007/08/12

書的大綱初想

到目前為止,在我所讀過所有跟網頁親和力沾得上邊的書當中,我覺得最值得推薦的乃是 FriendsofED 出版的《Web Accessibility》。雖然好像比較多人覺得 Joe Clark 比較大牌,而推薦他寫的那本《Building Accessible Websites》,但是在那本書當中,實在是充滿著他個人的碎碎念跟不滿的情緒,其實沒辦法改變甚麼現實。

我覺得一本好的書,不但要具備豐富的內容,精確的細節,更重要的還得有正面的態度,並鼓勵讀者做些甚麼,試圖展開良好的正向循環。而《Web Accessibility》正是一本這樣的書。也因此,當我在思考《網頁親和力》的大綱時,最想參考的便是這本書。

《Web Accessibility》其實已經是經過試煉與實驗的結果──這本書的前一版是由 Apress(其實這就是 FriendsofED 的母公司吧)所出版的《Constructing Accessible Web Sites》;在這次的改版中,除了內容的增添與翻新外,章節的順序也經過調整。換句話說,《Web Accessibility》的順序是更為妥善安排、更適合閱讀及使用的順序。

《Web Accessibility》全書共十七章,分成三個部分:第一部分是描述網頁親和力所帶來的衝擊,包含了前三章,講述了網頁親和力的基本概念、相關法令及指導原則的概述、以及該如何在企業中實踐網頁親和力;第二部分是全書的重頭戲,用十二章的篇幅來講解各種實踐網頁親和力的技術細節,囊括了親和力科技的概述、輔助科技如螢幕朗讀軟體等、內容的親和力、導覽的親和力、資料輸入的親和力、與親和力相關的 CSS、JavaScript 的親和力、Flash 的親和力、PDF 的親和力、親和力檢測與評估、WCAG 2.0 的介紹,還有一個將網站重製成更具親和力的實際個案研究;最後一個部分則是說明關於親和力的法令及政策,用兩章的篇幅分別說明了美國及全球各國的親和力相關法規。

根據這樣的編排,我所設想的內容大綱也是這樣的三個部分:第一部分是概觀與現狀分析,一樣要說明網頁親和力的基本概念、相關法令及指導原則的概述、以及該如何在企業中實踐網頁親和力;在這邊我想要在國內做一些訪談,多著墨在國內的現狀以及為什麼沒有人這麼做的分析。當然還要去試著估量所需的人力、資源,以及其所可能帶來的利益等。

第二部分自然也是要講解各種技術細節。我想要帶入一些國內有在做的事情或產品,包括淡江大學的視障中心、科技輔具基金會在做的東西、花師(現在改名了?)特教系那邊在做的事、陽明復健科技輔具所的研究等,這些主要是輔助科技的現況與發展,帶進 UAAG。接下來就是跟常見網頁技術有關的親和力章節,這包括了 (X)HTML(包含 Microformats)、CSS、JavaScript、以及 Flash;這邊大概還會扯到 ATAG。然後我想要再花一個章節來講述一些常用的 AJAX 網頁開發框架──例如 Perl 的 Jifty、Ruby on Rails 等的親和力現況等,並帶入跟 AJAX 有關的 WAI-ARIA。再來是其他的網頁媒體,除了 PDF 外,還有各種多媒體檔案或格式(例如 QuickTime、RealMedia、Windows Media Audio/Video、SMIL 等)的說明及比較。最後則是跟各種設計花樣如導覽、資料輸入等有關的親和力章節。

第二部分由於篇幅最多,所以也許會再視情況拆分成若干部分。

最後的第三部分要來說明親和力的評估,我想這邊會帶入目前還是工作草案的 EARL,然後會去剖析研考會現行的無障礙規範,包括其流程、優劣得失、與 WCAG 1.0 之異同、滿足其規範的竅門等。嗯,這兩段內容也許順序會對調。接下來還可以說明 WCAG 1.0 到 2.0 的改變或進展,另外也還可以說明國內還有些甚麼相關法規,然後如果還有力氣的話,再去說明世界各國又是怎麼一回事。

如上述這樣的規劃,其實三個部分是可以拆成三本書的。每一本書(每一個部分)大抵來說都會有概念、策略、技術等部分,應該是足以讓會買的人整套買走纔對。

目前的想法大概是這樣。

親和力的非技術性層次

我們在前幾期中,一次又一次地試著釐清「網頁親和力」究竟為何;每一次我們除了對親和力添增一份瞭解外,也連帶地對周遭有關的事情多一份掌握。也因此,我們將逐步邁入更讓人容易忽略、卻更為關鍵之地。因此在這一期當中,所要探討的是更為抽象的非技術性因素。

之所以非技術性因素會更為抽象,乃是由於非技術性因素往往不在網頁設計師或開發者的思考脈絡之中。網際網路是由各種科技所創造出來的場域;在這樣的場域中,決定一切運行基本準則的,不是自然定律,而是這個世界的特有法則──原始碼。設計師也好、開發者也好,都藉由原始碼來參與這個世界,讓網際網路持續發展。很自然地,這些原始碼──它們所使用的理論、實踐他們所需的技術──成為這一行所專注的範疇,甚至要成為這一行的全部。

然而,網路作為人類的工具,目的在於滿足人類的需求,它所能面臨的最大挑戰也同樣地來自人類本身。當多數人還無憂無慮地在網路上自由往返的同時,有些人對於這樣的自由感到不安,對於無法掌控的自由感到焦慮,於是他們把能限制住真實世界的人的那套手腕,渲染到網路世界中──更精確來說,是把人類對權利的操控,加諸數不清的原始碼上。

這樣的產物大家並不陌生,正是 DRM。然而一般人所不易發現的,是 DRM 對於親和力所會造成的潛在影響。讀者諸君必須瞭解,DRM 是建立在不信任之上的產物,藉由過度限制合理使用的範圍,來根絕未被預期的內容運用方式。

也因此,現在的網路上出現越來越多:不能被定址的資源、不能被標記的網頁、不能被朗讀的句子、不能被看清楚的文字、不能被指認的內容、不能訴諸其他表現形式的媒體。這些內容都受到了程式的限制,使得它們難以被取用──喪失了親和力;它們並非沒得用,也不真的能抵擋有心人士胡作非為,而是讓這一切必須付上龐大的代價:額外的人力成本。

這個代價龐大到足以抵銷一切由網路、由資訊科技所帶來的便利。不是電腦辦不到,而是來自非技術的力量,阻止電腦去辦到。這實在很弔詭。

最近如 EMI、Apple、微軟等大廠,都開始逐漸接受不使用 DRM 的營業模式,這是好事。然而 DRM 只是一種危害親和力的手段而已;類似這樣,會影響親和力的因素還有千千萬萬,包括真實世界中的法律、契約、威脅恫嚇以及其他心靈/情感力量。

當人們連「權利」都當作商品在買賣,原本自然單純的消費被分解成無限多片段,就不再能直接碰觸到內容。播放一次的權利、播放十次的權利、播放給其他人視聽的權利、播放給不特定許多其他人視聽的權利、傳輸的權利、公開傳輸的權利、贈送給其他人的權利、轉賣給其他人的權利、大聲唸出來的權利、抄寫下來的權利、按滑鼠右鍵的權利、複製進線上字典查詢的權利、保存使之不易損毀的權利、列入遺產的權利、讓別人知道有這項內容的權利、讓別人知道你知道有這項內容的權利、決定其他人能夠有哪些權利的權利、能不能決定其他人能夠有哪些權利的權利……每一項都要分別談,實際的內容被包裝在無窮多層的盒子裡,親和力蕩然無存。

當然不是所有的地方都這麼糟,但是善於此道的既得利益者努力想要調教人們,想要讓人們接受「本來就該把權利分成這麼細,一樣一樣處理」的模式,並運用殺一儆百的手法營造出寒蟬效應。久而久之,人們會變得畏懼做任何不保守的事,而那是非常、非常可惜的。

很久之前我在介紹創用 CC 授權時曾提過所謂的 DRE,試圖用淺顯易懂的方式,表達預先釋出的權利。這大概是近期比較顯著的一項逆轉嘗試,在如履薄冰的環境中圈出一塊受保障的安逸公園,鼓勵人們從事創新應用。然而我們不能祇安於此,覺得這樣就足夠了。設計師必須要明白自己存在的目的、服務的對象,用盡一切手段,做出讓所有人都受益的設計。沒錯,DRE、創用 CC 乃至於這麼抽象層次的考量,也都是親和力的一環。

介紹到此,有些讀者可能又會興起疑惑:對所有的人都會造成影響的,不是可用性嗎?親和力不是祇應該對部分的人造成影響嗎?其中的道理是這樣的,可用性會對所有的人「在同樣的方面」造成影響,親和力卻會對不同的人在不同的方面造成影響……我們在此所談論的親和力議題正是如此:每個人都會在某個不同的方面受到影響,而所有的人加起來恰好是全部的人;於是明明看起來祇會影響到局部人的親和力考量,就影響了所有人。

這也就是,為什麼親和力該是設計的一環的原因。也是網頁設計師必須能凌駕原始碼,真正去思考「內容」與「意義」的原因。

身為設計師,不能一味追求視覺呈現;身為開發者,不能祇著重在程式的行為。所有做網頁的,都必須要理解到,內容纔是真正的核心;而如何讓人們能更容易取用內容、如何讓內容更有親和力,這些纔是真正的網頁設計,也是設計師該捍衛的領域。

2007/08/11

目標讀者

要寫一本書,第一個工作就是要先決定書的目標讀者──也就是,這本書要賣給誰看、誰會把這本書攤在桌上或塞在書架上。

網頁親和力是個很大很大的題目,必須要仰賴在各個方面一起努力配合才能成功,所以目標讀者的選擇,就成了一個不容易的題目。有一些事,例如組織的安排、政策的奠定等,是要賣給決策高層的:經理、總經理、執行長、官員、標案發包者等等。另外有一些事情,像是各種技術細節,則是要賣給底下實際執行、製作網頁的人:網頁設計師、網頁程式開發者、還有實際生產各種多媒體(影片、聲音、圖片等)的人。

以國內的情況來說,這幾年由於研考會的關係,至少「網頁無障礙規範」成了許多餬口飯的人的當務之急;雖然「網頁無障礙規範」距離「網頁親和力」還十分遙遠,但是這確實也是必須考量、面對的實際情況。

因此,我覺得這麼一本講網頁親和力的書,主要就要針對所有跟「網頁無障礙規範」有關的人來撰寫。根據前述的那個脈絡,這本書應該要能讓推動網頁無障礙規範的人能有一窺全貌的機會,讓未來的相關法規更健全、方向更正確;然後這本書也要讓各網站標案的發包方及承包方瞭解,為什麼網頁親和力的要求會是重要的;實際製作網頁及內容的人,則應該要能從這本書當中,學到每一個技術環節應該要怎麼處理,纔能符合這種無障礙的規範,並預先滿足對親和力的考量。然後,最重要的,這本書還有一個任務,就是要讓網頁開發的公司或單位,能夠重視網頁親和力的重要性,而能夠投入充足的資源及人力,做出具親和力的設計。

從這樣的目標讀者設想中,就可以發現這本書必須要兼備理論與實務──這會讓這本書變得很厚,就跟所有這個主題的英文書一樣。然而太厚的書,大概就會變成很難用的書;可能會有人買回家,努力地把整本書讀完,然後就束之高閣,三個月後也就差不多忘光光了。

發現這件事後,我想這本書大概得要拆成好幾本──至少是三本吧,分別是《新希望》、《帝國大反擊》、《絕地大反攻》……呃,我開玩笑的,三個部分其實分別是要涵蓋「綜觀」、「技術」、「政策」;其中關於「技術」的部分,恐怕還得針對篇幅或者是領域,再拆成若干小冊。

關於這部分的想法,我下次再來試著整理出來吧。

網頁內容親和力與無障礙

前一期我們談到了網頁內容親和力方針,並且簡要說明了親和力與可用性的異同,接下來就讓我們來談談更容易被混淆的性質:網頁無障礙與網頁內容親和力間的關係。

非常非常多的人會把網頁內容親和力當作「無障礙」來思考,包括很多這個領域的學者專家也很容易陷入這個窠臼之中,認為親和力的目的就祇是要讓身心障礙的人也能夠順利地瀏覽網頁、從網頁上取得內容。也因此,當行政院研考會移植了 W3C 的 WCAG 1.0 後,就改稱之為「無障礙網頁開發規範」。

的確,讓有身心障礙的人能夠順利地使用網頁、取得網頁內容,乃是網頁內容親和力所要處理的議題之一,但是「親和力」所涵蓋的卻遠多於「無障礙」。「無障礙」通常是在法律條文或行政命令的脈絡下所出現措辭,往往是為了要確保憲法中對平等權的規定所制訂的規範;因此在網頁設計及開發流程中,「無障礙」會被當成是一種功能或特色,或者是被當作一項稽核的項目來看待。也因此,多數人心中的「無障礙」就變成一種門檻,認為一旦能跨越了這道門檻,那麼網頁就足以應付身心障礙人士的需求。

另一方面,「親和力」卻是沒有止盡的;不管再怎麼努力,網頁的內容總是可以再更有親和力一點。或者說,親和力其實是網頁設計的一個環節,其重點在於要如何適切地表達實際的內容,盡可能地讓最多的人、程式、裝置都能夠取得並運用這些內容。當「無障礙」派的人還在為即將結案的網站專案一筆一筆地加上 alt 屬性時,「親和力」派的設計師已經把內容放在整個設計流程的核心,並且發展出許多理念與實做如:結構─呈現─行為抽離、XHTML 混成、從內容向外法、微格 (Microformats)、安分的 (Unobstructive) JavaScript 以及超越 CSS 法等。
包括穀歌及雅虎在內的大型企業,都已經將親和力視為設計網頁服務的一環,從設計的初期階段就開始確保內容能被完整表達。在這種設計理念之下,任何的使用者代理設備──不祇是一般的網頁瀏覽器,還包括了像是純文字瀏覽器、媒體播放程式、螢幕朗讀程式、觸覺輸出裝置、投影簡報設備、印表機、行動通訊設備如手機或 PDA、(可上網的)電視機等,通通都可以取得基本、一致但可接受的內容,以及簡單但能運作的互動經驗。然後,隨著使用者所使用的代理設備功能越強大,例如更大的顯示範圍、更高的解析度、更完整的支援網頁標準等,就能夠獲得更豐富的使用經驗。

有別於無障礙通常被視為額外的功能,因此總是在設計完成之後,纔根據所謂的規範,以急就章的方式填補,甚至由於重構工程過於浩大、所費不貲,而被整個放棄或往後順延;親和力需要在設計或開發初期就開始參與流程──因為親和力會跟實際的內容息息相關,包括像內容的表達手法、多媒體的同步呈現、用字遣詞、使用的語言、視覺對比,乃至於(技術上或非技術上的)取用限制等,一概都是親和力需要面對的。所以從內容籌備、資訊架構、介面設計、版面規劃乃至於技術開發,每一個環節都與親和力息息相關,而且隨著科技進步,總是還有更多進步的空間。
「無障礙」比較像是要求設計師向真實世界妥協──因為真實世界中的協助科技祇能做到哪個地步,所以就要把整個網頁的設計跟規劃也限制在那個程度,以確保使用協助科技的那些人能夠順利地取用內容。至於「親和力」則是鼓勵設計師藉由設計,來帶動整個網頁技術持續進步,為那些尚未發明、達成的協助科技及使用者代理設備做準備。

讓我們來看看些當紅炸子雞,例如 AJAX 技術。前一期當中提到了 W3C WAI 為了 AJAX 或 Flash 這類的互動技術特別推出了 WAI-ARIA 套件;事實上各位祇要對 AJAX 或 Flash 稍有瞭解,就會明白他們很難放進所謂無障礙的規範中。或者說,如果祇是為了滿足無障礙的規範,許多技術開發者會急就章地假設使用者代理設備對其技術的支援是「全有或全無」──使用最現代的瀏覽器的使用者,可以獲得完整的使用經驗;但是使用略有限制的設備的使用者,則會被迫降級到跟用純文字瀏覽器的使用者相同的待遇。

不祇是 AJAX 或 Flash,有多種不同媒體及網頁技術如頁框或互動腳本等,都正如此被自暴自棄地對待──儘管這樣還是能夠符合無障礙規範,而你也沒辦法說領錢做這件事的人們有錯。這麼一來,原本立意良好的無障礙規範,卻是讓更多使用者被迫綁手綁腳。如果我們祇知道無障礙、祇推行無障礙,那麼再過十年恐怕多數的網頁上仍是搪塞,而我們原本想弭平的不平等對待仍然鮮明地存在,受到歧視的人們仍然祇能獲得貧乏的使用經驗。

這就是為什麼我要說親和力,而不說無障礙的原因。親和力的諸多實做面向中,有不少用到了稱做「進展式強化」的技術,這樣的技術很像是有教無類的同時又因材施教,意思是說雖然支援所有的瀏覽器及使用者代理設備,但是「支援」並不意味著所有的訪客都能獲得一模一樣的使用經驗;反之則是根據每一種設備及瀏覽器的能力差異,分級給予最適合的功能及協助,使其都能盡量存取並利用網頁的內容。因此,即便在使用 AJAX 或 Flash 等技術,仍然能夠盡可能地加進親和力的設計,讓他們能在該派上用場的時候加以發揮。

如果要借用社會制度的術語來說明可用性、親和力與無障礙這三個概念,大概可以這麼說:可用性強調的是齊頭式的平等,做得好則大家共享,做得差則大家共同承擔;無障礙是 M 型社會,雖然大家都活得下去,但是貧富兩極化懸殊;親和力則是立足點的平等,所有人都受到同等的重視,但同時每個人的能力各有不同,所以就會獲得不同的好處。

有了這一層認知之後,在下一期我要來介紹一個更少人意識到的環節:非技術性的親和力因素。

淺談網頁親和力方針

從本期開始,我們將用幾期的篇幅來研究跟網頁親和力有關的一些事情;本期首先就要來談談有哪些指導方針與網頁親和力有關,以及他們各自著重於網頁親和力的那個部分。

網頁親和力的重點在於網頁的實際內容,而親和力則是這些內容是否容易被接觸、被取用。這聽起來跟網頁可用性很像──網頁的介面是否便於操作,讓使用者順利獲得其所需的資訊,或者是完成其所欲進行的目的;雖然親和力與可用性都是在設法讓使用者能更容易取得內容,但是兩者的切入角度卻是不同的。簡單說來,可用性會影響到所有的人,不論其主觀、客觀狀態為何;而親和力祇會影響到特定的部分使用者,或者是處於特定環境中的使用者。

當然啦,怎麼樣纔叫做「特定的部分使用者」其實是個很弔詭的問題,而且沒有任何永遠有效的判定方法,祇能夠根據情境來推論及決定。舉例來說:使用中文撰寫的網頁內容,顯然祇有懂中文的人纔能看得懂,但若要因此主張「不懂中文的人就無法獲得任何此網站上的資訊」,而說所有用中文撰寫的網站都不夠具有親和力,顯然是不對的。但是如果覺得「既然可以把網頁的閱讀情境限定在使用中文的環境,那麼也可以把網頁的閱讀情境限定在用眼睛看的環境」,而把視力不佳的讀者排除在外,這顯然也是不對的。

到底應當如何判定某個元素的影響是全域或局部性的,以及要如何合理合宜地設定網頁的使用情境,其實都是門大學問;尤其對於一般的網站至作者或主事者來說,最困難之處恐怕在於──根本不知道的世界,就設想不到。本地論述人機介面、使用流程、網頁可用性的書籍已經不多了,深入去探討網頁親和力的的則連一本都沒有,即便在研考會開始推行「網頁無障礙規範」(註:我們下一次就會談到網頁親和力與網頁無障礙間的關係)之後仍舊如此,足見這個問題尚未激起充分的重視及意識。

這講下去會沒完沒了,所以先讓我們回到這次的主題:網頁親和力的相關指導方針。就網頁的使用週期來說,至少有三個環節會跟親和力有關:網頁的製作、網頁內容本身、處理網頁內容,因此 W3C WAI 就為這三個環節分別制訂了三套方針:編撰工具親和力方針 (ATAG)、網頁內容親和力方針 (WCAG)、用戶代理者親和力方針 (UAAG)。在這三套方針當中,最為核心的部分是 WCAG, WCAG 規範著網頁內容的表達應當要兼顧哪些細節、要如何建構語意,接著以此為基礎, ATAG 規範著編撰網頁的工具必須協助網頁作者能容易地製作出符合 WCAG 規範的網頁,並且這個工具本身也要具備親和力;另一方面, UAAG 則是要規範各種用戶代理者如瀏覽器、媒體播放裝置、螢幕閱讀器、列印及顯示器等,要如何正確表達出符合 WCAG 規範的網頁內容、如何讓閱聽人能夠掌握網頁中的脈絡及語意。

除了上述的三套方針之外,為了讓網頁親和力的評估結果有個標準、可互通、可延展的格式, W3C WAI 也發表了一份「評估及報告語言」 (EARL)。 EARL 跟 ATAG 都會涉入網頁的編撰作業,也都奠基於 WCAG 的實做。

在這樣的架構下,其實我們也可以看出,網頁親和力其實是個很大的領域,包括網頁編輯器廠商、網頁瀏覽器廠商、各種多媒體製作及播放軟體的廠商等,通通都在其涵蓋之下;換而言之,此刻我們必須面對現實:網頁親和力還沒辦法徹底落實,這個領域之中還有太多等待眾人努力之處;而且網頁親和力的努力是永無止盡的──永遠都還可以更好、永遠都還有改進的空間。及早明白並認清這一點,將對網頁親和力的早期規劃有所幫助,將資源做更好的分配。

隨著全球資訊網日益發展,許多事情又變得跟以前很不同。例如 Web 2.0 的重要精神「網頁即服務」 (Web as Service) 就打破了以往網頁僅單向地提供資訊的目的,搖身變成如應用程式般的互動介面,在 DHTML、 AJAX 等技術的加持下,網頁的更新、呈現等早已不適用 WCAG。為了反映這樣的科技演變, W3C WAI 也推出了一個「親和富饒的網際網路應用程式」 (WAI-ARIA) 套件,協助開發者使用這些花俏技術的同時,也能夠保有網頁的親和力,讓資訊真正能傳達到讀者心中。

這些指導方針很多都還在草案階段,還沒有拍案定論,但是我們對親和力的認識及努力卻已是片刻不容緩。這也是我開始撰寫這一系列文章的原因。下一期,我們將來談談跟親和力最有關的人們,以及一些更不容易釐清的偏見。

Blogger 與親和力

這個部落格是用 G 社的 Blogger.com 服務來維護的──以「親和力」的考量來說,這顯然不是最好的選擇。我對此必須道歉,我需要把心力集中在即將撰寫的內容,以及協調、研究、調查等事務上,而沒辦法自己來慢慢處理這整個系統。

人家說啊,「投降輸一半」,請各位讀者務必瞭解,這個部落格,以及掛在這個網域名稱下的其他東西,大概都有非常多的親和力增進空間。這裡,並不是為了「展示」或「示範」而存在的;而是為了,捕捉我所能設想到的、該被寫出來的事情。

這件工程相當浩大,我已經下了「就算接下來一整年都沒辦法工作賺錢也要完成」的決心;所以如果各位哪一天看到這裡多出了廣告,也請多多包涵了。希望各位朋友能先別挑著這個部落格本身的不圓滿,也請因此處親和力不足而無法順利取用內容的朋友們再忍耐一陣子。親和力需要投入人力,而我目前就祇能孤軍奮鬥,有太多不得不退讓的地方。

接下來,我將先開始貼上,之前刊登在 OSSF 自由軟體電子報上的文章。

2007/08/10

舊議題‧新觀點‧新書‧新部落格

籌畫很久的新書終於要開始動起來了。「網頁親和力」,這大概是我對網頁的終極關懷;有鑑於國內完全沒有任何一本專書在講述這方面的事,而相關的事也沒甚麼人重視(甚至沒有任何一家網路公司有親和力團隊),所以還是得要自己跳進來做。

作為起步,我開始在自己的專欄中撰寫一連串網頁親和力的文章,同時也要來弄一本書。而這個部落格也是在這樣的機緣下誕生的。

在此,我將記下「寫這本書」的歷程,也會先把之前撰寫過的相關文章貼一份過來。之後若還有想到甚麼可以做的,自然也會一併在此寫下。

為了讓這事能夠長久經營,這一次決定不再自己弄系統了,來用 G 社的吧。