March 07, 2003

[敲打鍵盤] 網路無障礙與網頁親和力Alt-E

我昨天到師大參加了由師大資訊教育學系中華民國輔助科技促進職業重建協會所主辦的「無障礙網路空間研討會」。

我初步的想法是,國內官方至少有人開始注意到這個課題了;但是在這個關鍵的時刻,如果沒有朝向正確的方向走下去,日後恐怕會很危險。怎麼說呢?且聽我細細道來……

先來看看這一場研討會裡,到底說了些甚麼吧;妳可以先從研考會取得一些文件(對,很糟,居然是中文檔名的 PDF 文件;而且還祇是把紙本文件掃瞄成圖檔而已),然後如果妳剛巧讀過 W3C WAIWCAG 1.0 (有人做了中文化的教學頁面)的話,妳應該也能發現,在這份「無障礙網頁開發規範草案」裡,其實沒有對 WCAG 1.0 裡的十四條指導原則及三個不同優先權的設計做了任何的更動;另一方面,如果妳也有出席這場研討會的話,妳該有聽到這段話:

……使用機器來檢測可以說是我們自己的創見;
因為這是連國外都沒有做到的……
聽到這句話,其實我不禁皺起了眉頭。怎麼說呢?在「深入親和力」這本書裡有提到, WCAG 1.0 的這十四條指導原則被刻意寫得不明確,這是因為它們本來就祇是概念上的東西,而不該以任何確切的作法限制住。另一方面也因為很多指導方針的內容,都是針對語意或語境來制訂的;那麼這些語意或語境的適當與否,除非人工智慧蓬勃發展,否則實在難以祇透過甚麼程式來加以判斷。

固然即使是在國外,也有 Bobby 這樣的服務機制,來幫助人們檢測網頁內容是否符合 WCAG 1.0 或 Section 508 的規範;但是這些都祇能拿來當作參考、祇能作為最低限度的技術缺失的檢查。換而言之,「通過這種檢查」頂多祇能當作必要條件,卻萬萬不能當作充分條件。(岔題: Bobby 的服務不真的是完全免費的;然而國內有人做了類似免費服務,其實好像也算好事……)

讓我們來開刀吧。以這個無障礙網路空間服務網的頁面來說,左方鏈結區用了一個箭頭圖示來當作項目符號;可是偏偏在標記語意上就是沒有使用 <ul> 這類的清單標記,這將造成語意的混淆。想像一下,假設妳因為各種原因而無法看見頁面上的圖形,那麼按照這一頁的情況,妳會看到一個寫著「小圖示會員權益說明」的鏈結;而這顯然是不對的。從這個例子裡我們可以看到,就算所有的圖片都加上了替代 (alt) 文字,也不見得就真的能被輕易讀懂(關於這部分的技術細節,請參考「深入親和力:使用真正的清單」的說明)。

接下來是同一個標籤的另一個技巧。妳可以看到在無障礙網路空間服務網的首頁裡,用了許多的 <img border="0" src="webacc/pic/cloud.jpg" alt="小雲圖示" width="29" height="29"> 標籤來為祇有美觀功能而不具語意的圖案加上替代 (alt) 文字;可是這些圖示既然不具有任何語意功能,那麼加上了替代 (alt) 文字反而是畫蛇添足。試想,如果妳是盲人,那麼妳瀏覽到這一個頁面的時候,就會聽/摸到這些字串:

小雲圖示 小雲圖示 連結 中文版 小雲圖示 小雲圖示
這樣真的更能讓妳釐清現在發生了甚麼事嗎?恐怕不會。

對於這類祇作為視覺效果的圖片來說,應該使用空字串作為替代 (alt) 文字。例如像這樣: <img border="0" src="webacc/pic/cloud.jpg" alt="" width="29" height="29"> 。要特別注意的是這裡仍然必須保有替代 (alt) 文字,因為如果妳把整個 alt 屬性拿掉的話,某些螢幕朗讀軟體或純文字瀏覽器就會自動地把圖片的檔名拿來當作替代 (alt) 文字,而這顯然是錯的(關於這部分的技術細節,請參考「深入親和力:忽略卡位圖片」的說明)。

前述的頁面裡還有別的問題,在於上方的導覽列(包括那個「網站導覽」的鏈結)通通都是用 JavaScript 寫成的。那麼在任何不支援 JavaScript 的瀏覽器上,將完全失去了導覽功能。如果妳夠仔細的話,還會發現這些頁面也同樣地沒有用 <link rel="prev" title="前一頁的標題" href="http://前一頁/的/網址" /> 提供額外的導覽協助(關於這部分的技術細節,請參考「深入親和力:提供額外的導覽協助」的說明)。對,現在妳完全無計可施了(註:妳還可以參考一下 hlb 寫的『障礙重重的「無障礙網路空間服務網」』)。

諸如此類的問題其實不勝枚舉,足以看出實際執行跟建設這樣服務的人縱使有想要做甚麼事的好想法,但終究還是缺乏足夠的意識 (sense) 。然後這批人從今天 (2003/03/07) 開始,就要在全省展開巡迴研討會了;妳說,怎能不令人憂心?

(對了,我有沒有提過,她們還想做 SVGXML 甚至是 JavaScript 的 Accessibility 標準?)

下一個我想提出來講的議題是關於名詞的翻譯。妳可以發現這群人把 User Agent 翻譯成「使用者代理人」,把 Accessibility 翻譯成「可及性」;前者顯然不夠正確,因為這裡的 Agent 往往指的是某支協助使用者的程式,而不是真的「人」;至於後者就更可以加以討論了。

我跟幾位朋友(像是 hlbautrijusSchee 等人)曾經在 IRC 上討論過這個字的翻譯,最早 autrijus 是順著國內政府機關的慣稱,譯成「無障礙」,像是「網頁無障礙」這樣的說法。但是我們後來斟酌之後,發現「無障礙」這個說法其實跟 Accessibility 這個字眼所要表達的意思不同;這個字眼真正的解釋其實是在說「可親近的」。事實上許多 WCAG 裡的指導原則,都是為了要讓頁面「更容易被閱讀」而設立的,這些措施不僅對於那些日常生活有所不便的人有幫助,同時更能讓所有其他人,也從中獲得更好的操作介面。

有鑑於此,我們後來決定把 Accessibility 翻譯成「親和力」。另外 hanteng 曾經提過:在新聞界,似乎習慣把 Accessibility 譯成「可及性」(這也就是這一次研討會裡出現的譯詞);對於這一點,我們祇花了 5 秒鐘就推翻了:

因為「可及性」這個詞彙實在很難懂,
本身一點 Accessibility 也沒有。

有不少玩工程的人很容易忽略掉這些語意或者詮釋的重要性,而祇專注在技術問題上。然而翻譯就是詮釋,而詮釋就是在行使權力。這些主事者未必會意識到的小細節,往往卻會大幅度地改變事情發展的方向,以及群眾接受的角度(關於這部分,請一併參考 Schee 寫的「要無障礙還是要親和力?」)。

國內開始注意到這種事情固然不壞,但是我卻隱隱地擔心著,「網頁親和力」的美意,會不會跟教改一樣被糟蹋了呢?

題外話,妳也許注意到了,我把原本首頁的 WAI-AAA WCAG 1.0 貼紙給拿掉了。這是因為我後來想到,有太多事情我沒有做;單單像是「所有混在中文字裡的英文,都該另外用 xml:lang="en" 屬性加以標記」這一點,我就從來沒有做到。

關於網頁親和力就是這樣:妳懂得越多,就會發現越多自己沒做到的細節。我們怎能不細心再細心、謙遜再謙遜呢?

又是拉哩拉雜地扯了一大堆,希望能再藉此引出其他人的寶貴文字。(對, ilya ,我就是在說你…)

Posted by Jedi at March 7, 2003 05:41 AM | TrackBack (8)
CommentsAlt-C
[1]

什麼?竟然被點名了!!我的一點想法是:「親和力」這個詞唯一可惜的地方就是太 soft 了。不過,access 是一個很硬的詞,把這個詞抽象化之後本來就不太有力,所以軟一點也沒有什麼不好啦。如果能夠讓更多的人有機會思考這些問題,就像 blog.elixus.org 的火車時刻表,拋磚引玉創造更多的可能,就會有更多有意思的語言/行動出現在周圍。

研考會與作這個計畫的主辦單位,恐怕還沒有想到有這麼多的人在關心他們的業務/計畫吧。我關心的是,這樣創造出來的衝突,接下來能夠為整個社會帶來什麼樣的,結構性的,改變呢?今天在參加 SLAT 大會之後,我其實有點在反省這一陣子的生活。也許我會好好的寫一篇 blog 來把這些思考想清楚吧。

Posted by ilya at March 8, 2003 07:44 PM
[2]

W3C的三個工作群組 WAI、Device Independence與 Internationalization 想要達成任何人於任何時間、任何地點、任何情況下使用網路。
但目前一項沒未完成,所以路還很長

況且目前的網頁都是以 HTML 要不以 XHTML 為主。
Flash 佔向量繪圖 98% 市場。
網路的資訊都未分級,以 RDF表示 PICS。
網路的隱私也沒保障。

Web Service 與 Semsntic Web 尚未整合。
…等等等。

不過,總有個開始是好的。

Posted by 彭建翔 at April 27, 2003 01:04 PM
[3]

類似的翻譯問題很多,我覺得如果要讓中文的網路進展的更快,也許可以建立一個討論專有名詞翻譯的地方。
類似judi的Movable Type 新手手冊:名詞解釋。
另外,希望網站具有親和力,好的資料安排也可以幫上一些忙。我在1999年5月買了一本Information Architecture for World Wide Web[http://www.oreilly.com/catalog/infotecture2/],最近﹙2002/08﹚改版,而且中譯本也出來了,可以參考看看!

Posted by chientai at May 20, 2003 01:33 AM
Post your comment: