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 社的吧。