雜談網頁親和力（六）其他與語言相關的網頁親和力實務

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

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


i18n


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

TGIF

而其中的爭議點是，有些人認為頭文字一定要是一個「可以唸的新字」，例如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;
}

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


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


中研院


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


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


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



若且唯若
(
if and only if
)



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


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


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

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

You may be interested in the following articles:

• 雜談網頁親和力（七）語意與尺寸的親和力兩難 - 2007-07-26
• 雜談網頁親和力（五）多語環境中的網頁親和力 - 2007-06-10
• 雜談網頁親和力（四）自然語言的親和力原則 - 2007-05-16
• 雜談網頁親和力（三）親和力的非技術性層次 - 2007-04-16
• 雜談網頁親和力（二）網頁內容親和力與無障礙 - 2007-03-11
• 雜談網頁親和力（一）淺談網頁親和力方針 - 2007-02-10