譯文:
Web內容可訪問性指南 1.0
http://www.certifiedchinesetranslation.com/openaccess/wai-pageauth.html
原文:
Web Content Accessibility Guidelines 1.0
http://www.w3.org/TR/WAI-WEBCONTENT
注意:
翻譯
Abacus Chinese Translation Services (Samuel Chong)
時間:
初次定稿 2009-08-23

W3C

Web內容可訪問性指南 1.0

W3C推薦標準 1999年5月5日

當前版本:
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
(純文本, PostScript版本, PDF版本, HTML版tar/gzip壓縮包, HTML版zip壓縮包)
最新版本:
http://www.w3.org/TR/WAI-WEBCONTENT
上一版本:
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
編者:
Wendy Chisholm, Trace R & D Center, University of Wisconsin -- Madison
Gregg Vanderheiden, Trace R & D Center, University of Wisconsin -- Madison
Ian Jacobs, W3C

摘要

本文檔介紹了如何使Web內容對於殘疾人也具有可訪問性。適合所有網站開發人員(頁面架構和網站設計師)以及編輯器開發者閱讀。本文檔的主要目的是促進可訪問性的發展,並且,遵循這些指南可以使Web內容對所有人更加有用,無論使用什麽用戶代理(例如:桌面瀏覽器、語音瀏覽器、移動電話、車載個人電腦等等。)或者在條件限制的情況下使用(例如:嘈雜的環境、過暗或過亮的房間、或者是免提情況等等。)。遵循本指南也可以幫助人們更快的找到他們想要的資訊。這些指南並非建議開發者不使用圖片、視頻等,而是解釋如何讓多媒體內容更加具備可訪問性,並且有更多的使用者。

本文檔可以作爲可訪問性法則和設計的參考文檔,文中談到的一些策略也涉及到互聯網國際化和移動訪問。但是本文專注於可訪問性,無法完全將其他相關的W3C內容都敍述出來。請參考W3C移動訪問主頁W3C國際化主頁來獲得更多資訊。

本文檔作爲穩定版本,並沒有提供各種瀏覽器支援情況等詳細資訊,因爲它們更新地太快。不過,Web可訪問性倡議(WAI)網站上提供這些資訊(請參考[WAI-UA-SUPPORT])。

本文另附一份文檔,按主題和優先權列出了所有的檢驗點。這些檢驗點都鏈結到本文檔內部各自的定義。附錄中涉及到主題包括圖像、多媒體、表格、幀、表單以及腳本。包括一份檢驗點全表和一份檢驗點簡表

“Web內容可訪問性指南 1.0 技術部分”([TECHNIQUES])是一份單獨的文檔,用來闡明如何貫徹各個檢驗點,詳細討論了每一個檢驗點,並且提供了很多例子,運用了超文本標記語言(HTML)、層疊樣式表(CSS)、同步多媒體集成語言(SMIL)和數學標記語言(MathML)等相關技術。該文檔也包含文檔驗證和測試的技術,以及一份HTML元素和屬性的索引(技術上需要的)。該技術文檔用來追蹤技術的變化,所以更新比本文要快的多。注意,並不是所有的瀏覽器或多媒體工具都支援本文談到的一些特性,尤其是HTML 4.0或CSS 1或CSS 2裏的一些新特性。

“Web內容可訪問性指南 1.0”是可訪問性指南系列的一部分,都是由WAI發佈的。該系列還包括“用戶代理可訪問性指南”([WAI-USERAGENT])和“編輯工具可訪問性指南”([WAI-AUTOOLS]).

本文檔的狀態

本文檔已被W3C成員及其他相關方面審閱,並已被W3C理事(W3C Director)批准爲W3C推薦標準。這已經是穩定版本,可以被其他文檔引用或者作爲正式的參考材料。W3C制定推薦標準的任務是使之受到關注,並促使其被廣泛應用。這將增強Web的功能性與互操作性。

本文檔的英文版本是唯一正式版本,其他語言翻譯版本請見http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS

本文檔的一些已知錯誤請見http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA。報告錯誤請發送郵件至:wai-wcag-editor@w3.org

W3C當前推薦標準和其他技術文檔請查詢http://www.w3.org/TR

本文檔是W3CWeb可訪問性倡議的一部份。Web內容指南工作組的工作目標在工作組章程裏可以找到。

目錄

另附檢驗點全表檢驗點簡表


1. 簡介

對於那些不熟悉網頁設計可訪問性問題的人,要考慮到許多用戶可能有與自己非常不同的操作習慣:

內容開發者必須考慮到頁面設計過程中這些不同的情形。當要考慮若干種情況時,每種可訪問性設計的選擇通常使一些疾病類型的殘疾病人立刻受益並融入整個網路。例如,通過使用樣式表控制字體,廢棄FONT元素,HTML作者對頁面的控制將加強,頁面對視力障礙的人群更具可訪問性,通過共用樣式表,還將減少所有使用者的頁面下載時間。

本指南討論了可訪問性問題並提供可訪問設計解決方案。每一條都針對特定的場合、特定的殘疾(和字體樣式的例子類似)可能産生的問題來解答。例如,第一條解釋了內容開發者如何使圖像具備可訪問性。有些用戶可能無法看到圖像。有些可能使用基於文本,不支援圖像的瀏覽器,有些可能關閉了圖像支援(例如由於低速網路連接問題)。 並不是說要避免使用圖像來提高可訪問性。相反的,解釋了爲什麽替代文字將使使圖像具備可訪問性。

替代文字是如何提高圖像的可訪問性的?替代文字中每個字都是重要的:

要注意的是,除了使殘疾人用戶受益之外,同等的替代文字可以幫助所有用戶更快地找到頁面,因爲當索引頁面時搜索引擎機器人可以利用這些文字。

網路內容開發者必須提供圖片和其他多媒體內容的同等替代文字,相應的,用戶代理(比如瀏覽器和諸如螢幕閱讀器盲文顯示等的輔助功能)有責任爲用戶表達這些資訊。

文字的非文字等同替代(例如,圖示,預先錄製的語音或者將文字翻譯爲手語的視頻)能使那些訪問文字有困難的人可以訪問文檔,這些人包括許多存在認知殘疾,學習殘疾的個體和聾人。文字的非文字等同替代對於無法閱讀的人也有幫助。聽覺描述就是視覺資訊非文字等同替代的一個例子。多媒體演示的聽覺描述可以使得不能獲得視覺資訊的人從中受益。

2. 可訪問性設計的主題

本指南主要處理以下兩個主題:保證內容良好呈現,使內容易理解與可導航。

2.1 保證內容良好呈現

通過遵循這些指南,內容開發者可以製作出內容良好呈現的頁面。簡介中提到的任何情況,包括身體上的、感覺上的和認知上的殘疾,工作限制,和技術壁壘,這些頁面都具有良好的可訪問性。以下是保證頁面設計良好呈現的幾個關鍵因素:

指南第1至11條處理本主題。

2.2 使內容易理解與可導航

內容開發者應該使內容易於理解並且可導航的。這並不僅僅要求語言上的清晰與簡單,而還需提供易於理解的頁面導航機制。提供導航工具和位置資訊能夠極大的提高可訪問性和易用性。並不是所有人都能使用圖片映射(image map)、成比例的捲軸、框架頁,或者是用來引導桌面圖形瀏覽器用戶的圖片。有些人可能只能逐詞閱讀(如語音合成或盲文顯示),或者一次只能看到一部分內容(如小的顯示區域或放大顯示),他們可能很容易就失去了上下文的聯繫資訊。沒有位置資訊,用戶可能難以理解巨大的表格、列表、功能表等等。

指南第12至14條處理本主題。

3. 本指南的組織形式

本文檔包含十四條方針,或者說是可訪問性設計的基本原理。每條包括:

每條方針後的檢驗點定義解釋了在特定情況下方針的應用情況。每個檢驗點定義包括:

每個檢驗點都試圖解釋的非常清楚,這樣訪問者可以明確頁面或網站是否達到該檢驗點。

3.1 文檔約定

本文檔遵循以下約定:

4. 優先順序

W3C工作組按照檢驗點對可訪問性的重要程度,賦予每個檢驗點一個優先順序。

[優先順序 1]
Web內容開發者必須滿足該檢驗點。否則部分人或團體將無法獲取文檔中的資訊。該檢驗點是使得部分人或團體能訪問web文檔的最基本要求。
[優先順序 2]
Web內容開發者應該滿足該檢驗點。否則部分人或團體將對獲取文檔中的資訊感到困難。達到該檢驗點可以掃清相當數量訪問web文檔的障礙。
[優先順序 3]
Web內容開發者可以採納該檢驗點的要求。否則部分人或團體有可能對獲取文檔中的資訊感到困難。滿足該檢驗點可以提高web文檔的可訪問性。

一些檢驗點在某些(已指明)情況下,可能會改變優先順序。

5. 一致性

本部分定義了一致性的三個級別:

注意:一致性級別被呈現爲可讀,以便於理解。

文檔的一致性聲明必須使用以下兩種形式之一。

形式 1:指明:

例子 1:

本頁面遵循W3C的“Web Content Accessibility Guidelines 1.0”,URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, 一致性級別“AA”。

形式 2:在一致性聲明頁面上包含3個W3C圖示之一,並且鏈結到該圖示所代表的聲明頁面。關於圖示的使用請參考[WCAG-ICONS].


6. Web內容可訪問性指南

第一條. 爲視覺和聽覺的內容提供等義的替代

Next guideline: 2 Previous guideline: 14 Go to contents

一切呈現給用戶的內容,包括視覺上和聽覺上的,都需要提供功能上或目的上等義的替代。

雖然部分人無法使用諸如圖像、電影、聲音、Applets程式等技術,但是他們還是可以訪問那些提供了等義替代內容的頁面來獲取資訊。比如,一個鏈結到目錄索引的向上箭頭圖片可以添加“返回目錄”這樣的替代文字。一些情況下,替代內容還需描述視覺內容(比如複雜的圖表、布告板或示意圖)或者聽覺內容(比如用於教育的音頻樣例文件)。

本原則強調了爲非文本內容(圖片、預錄製的音頻、視頻)提供等義文本替代的重要性。利用等義文本替代的好處,就在於它可以被絕大部分技術或工具通過不同方式呈現給具有各種障礙的殘疾人。文字可以被合成語音或者被翻譯爲盲文,或者在螢幕、紙上以不同尺寸顯示。合成語音對於盲人,閱讀障礙,理解和學習障礙,以及聾人非常重要。而盲文也利於那些失去聽覺和視覺的人,以及盲人理解內容。並且文字顯示對於聾人和絕大部分web使用者都非常友好。

爲文字內容提供非文本內容的替代(比如圖片、視頻和預先錄製的音頻),同樣有益,特別是對那些沒有閱讀器或者有閱讀障礙的人來說。在視覺呈現或者視頻裏,視覺化動作(比如肢體語言、手語等)可能沒有足夠的聲音資訊來傳達同樣的內容。除非也提供口頭描述,不然那些看不到視覺內容的人將無法獲取其中的資訊。

檢驗點:

1.1 對於所有的非文本元素,提供具有相同意義的同等的替代文字(如用"alt"、"longdesc"屬性,或者在元素內容中提供)。這些非文本元素包括: 圖片,圖片形式的文字(包括符號),圖像映射(image map)區域,動畫(如GIF動畫),applet小程式和一些程式性的物件,ASCII圖案,框架,腳本,列表的指示圖片(list bullets),用來調整間距的物件(spacer),圖形按鈕,,聲音(無論是否通過使用者互動來播放),單獨的音頻文件,視頻文件的音軌以及視頻。[優先順序 1]
HTML中的例子:

請參考檢驗點 9.1檢驗點 13.10.

1.1 技術部分
1.2 對於伺服器端的圖像影射的每個有效區域,均提供額外的文字鏈結。[優先順序 1]
請參考檢驗點 1.5檢驗點 9.1.
1.2 技術部分
1.3 除非用戶代理能自動地將視頻資訊的同等替代文字朗讀出來,否則就應該提供聽覺上的描述內容,以表達視頻或多媒體呈現的重點資訊。[優先順序 1]
根據檢查點1.4聽覺描述提供同步音軌。 關於視覺資訊的文字替代請參考檢查點 1.1
1.3 技術部分
1.4 對於任何時間性的多媒體內容(如電影或動畫),都應該將等價的替代物件(例如字幕或視頻的聽覺性描述)與媒體播放同步化。 [優先順序 1]
1.4 技術部分
1.5 除非用戶代理能繪製出用戶端圖像映射鏈結的等義文字,否則就應該要爲每個用戶端圖像映射的有效區域提供額外的文字鏈結。[優先順序 3]
請參考檢驗點 1.2檢驗點 9.1
1.5 技術部分

第二條. 不要僅依靠色彩來提供資訊

Next guideline: 3 Previous guideline: 1 Go to contents

確保沒有顔色的情況下,文字和圖像都易於理解。

如果僅通過顔色來傳達資訊,那麽無法辨別顔色的人和使用單色的或非可視發的顯示裝置的用戶將無法獲取資訊。當前景色和背景色色調比較接近,使用單色顯示器用戶可能無法提供足夠的對比度來顯示它們,有顔色視覺缺陷的人也將無法獲取資訊。

檢驗點:

2.1 確保所有通過顔色傳遞的資訊在無色情況下也可用。比如通過前後文或者標示理解。[優先順序 1]
2.1 技術部分
2.2 確保前景色與背景色的搭配組合,即使在色盲患者的眼中,或在黑白螢幕裏,都具有充足的對比。[對於圖片爲優先順序 2,對於文字爲優先順序 3].
2.2 技術部分

第三條. 適當使用標記語言和樣式表

Next guideline: 4 Previous guideline: 2 Go to contents

使用結構化元素來標記整個文檔。使用樣式表來控制表現,而非表現層元素和屬性。

使用標記不合理——沒有按照規範——阻礙了可訪問性。濫用表現層的標記(如使用表格來佈局或者用標題h1-h6來增大字型大小等)會給用特定軟體訪問的用戶造成理解和導航上的困難。此外,使用表現層的標記的文檔結構也會使得其他設備理解困難。(參考內容、結構與表現之間的區別)。

內容開發者可能會爲了適應某些舊的瀏覽器,而使用(或濫用)一些標記來達到某種想要的設計格式或特效。但是這樣做可能會造成可訪問性方面的問題,要考慮清楚這樣子的頁面設計是否比保證所有人獲取文檔資訊還重要。

另一方面,內容開發者也不要因爲有一部分瀏覽器和輔助技術無法正確處理,而把這些標簽給供奉起來。比如說,在HTML裏,對於表格狀資訊應該使用TABLE元素來標記,即使還有一些舊的螢幕閱讀器無法正確處理那些相鄰的文本。(參考檢驗點 10.3)。正確並且合適的使用TABLE來創建表格,使一些軟體能夠正確呈現這些表格而不僅僅是二維格子。(參考第五條

檢驗點:

3.1 如果有合適的標記語言,就應該用標記來傳遞資訊,而不是用圖片。[優先順序 2]
比如使用MathML來標記數學公式,用樣式表來格式化文字和佈局。同樣還要避免用圖片來替代文字,儘量使用文字和樣式表。參考第六條第十一條.
3.1 技術部分
3.2 使用已發佈發佈的正式語法來創建文檔。[優先順序 2]
比如,在一個文檔開始部分常包含一個已發佈的文檔類型聲明DTD(如strict HTML 4.0 DTD)。
3.2 技術部分
3.3 使用樣式表來控制佈局和表現。[優先順序 2]
比如用CSS的font來替代HTML中的FONT元素來控制字體、字型大小等。
3.3 技術部分
3.4 在標記語言的屬性值和樣式表的屬性值中,儘量使用相對的單位[優先順序 2]
比如,在CSS中,儘量使用'em'或者百分比單位,而不是'pt'或'cm'這樣的絕對單位。如果已使用絕對單位,驗證並確保呈現的內容正常有效。(請參考驗證一節)。
3.4 技術部分
3.5 根據規範使用標題(headings)來呈現文檔結構。[優先順序 2]
比如在HTML中,使用H2來表示以下內容爲H1的子內容。不要使用標題來控制字型大小等效果。
3.5 技術部分
3.6 適當的標記列表及列表專案。[優先順序 2]
比如在HTML中,可以合適的嵌套OL/UL/DL。
3.6 技術部分
3.7 標記引用語,不得利用引用語標記來製造縮排等排版效果。[優先順序 2]
比如在HTML中,使用Q和BLOCKQUOTE元素來分別標記短的和大段的引用。
3.7 技術部分

第四條. 闡明自然語言的使用

Next guideline: 5 Previous guideline: 3 Go to contents

Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.

當內容開發者爲文檔中的自然語言變換作了標記,語音合成器和盲文設備會自動切換至新的語言,使文檔對於多語言使用者具有可訪問性。內容開發者應該將文檔內容的主要自然語言標記在HTTP頭中,也需要爲縮寫和簡稱提供解釋說明。

除了有利於輔助技術,自然語言標記也使得搜索引擎可以更好的獲取指定語言的關鍵字。自然語言標記同樣爲所有人促進了可讀性,包括有學習障礙和認知障礙的人群,和聾人。

當縮寫或者自然語言的更改沒有被指名,閱讀機器或者盲文顯示可能無法辨認內容。

檢驗點:

4.1 文檔中任何文字或等義文字(如表格標題說明)所使用的自然語言更換時,予以明確地識別。[優先順序 1]
比如在HTML裏使用"lang"屬性,在XML裏,使用"xml:lang"。
4.1 技術部分
4.2 文檔中縮寫詞或簡稱第一次出現時,應當注明其全稱。[優先順序 3]
比如在HTML中,爲ABBR和ACRONYM使用"title"屬性。在正文中提供這樣的解釋有利於提高文檔的可用性。
4.2 技術部分
4.3 指名文檔所使用的主要自然語言。[優先順序 3]
比如在HTML中,在HTML元素上標明"lang"屬性,在XML中使用"xml:lang"。系統操作人員應當合理配置伺服器以利用內容判斷(content negotiation)機制([RFC2068], section 14.13),這樣用戶端可以自動找到首選語言版本的文檔。
4.3 技術部分

第五條. 創建編排良好的表格

Next guideline: 6 Previous guideline: 4 Go to contents

確保表格具備良好的結構標簽使瀏覽器和其他用戶代理可以良好呈現。

表格應該用來組織表格狀資訊(“資料表格”)。內容開發者應當避免使用表格來佈局(“佈局表格”)。不管怎樣,表格在螢幕閱讀器裏總是呈現很多問題(參考檢驗點 10.3),尤其是佈局表格。

除非是在表格的標簽與結構正確的情況下,一些用戶代理才呈現良好。(參考第三條

以下的檢驗點直接關係到用戶通過聽覺訪問表格(比如螢幕閱讀器或車載設備),或者用戶一次隻瀏覽一步分頁面情況下(比如盲人或者有視覺障礙的用戶通過語音輸出或盲文顯示,或其他小螢幕設備等等)的情況:

檢驗點:

5.1 對於資料表格,指名行和列標題。[優先順序 1]
比如在HTML中,使用TD來表示資料單格,用TH來表明標題。
5.1 技術部分
5.2 對於具有兩層或多層行列邏輯關係的表格,合理使用標簽聯繫單格與標題的關係。[優先順序 1]
比如在HTML中,使用THEAD,TFOOT,和TBODY來爲行分組,使用COL和COLGROUP來爲列分組,使用"axis","scope",和"headers"屬性來描述資料間的複雜關係。
5.2 技術部分
5.3 不要使用表格來佈局,除非該表格線性化後仍有意義。如果表格並不具有意義的話,就該提供等義的替代物件(這可能是線性化後的版本)。[優先順序 2]
【注】 只要用戶代理支援使用樣式表定位,就不應該用表格來佈局。參考檢驗點 3.3.
5.3 技術部分
5.4 如果已經使用表格來佈局,就不該再使用其他的結構性標記來處理視覺格式效果。[優先順序 2]
比如在HTML中,不要使用TH元素來使文字(非表格標題)居中和加粗。
5.4 技術部分
5.5 提供表格的摘要資訊。[優先順序 3]
比如在HTML中,使用"summary"爲TABLE添加摘要資訊。
5.5 技術部分
5.6 提供表格標題提供縮寫。[優先順序 3]
比如在HTML中,使用"abbr"爲TH添加縮寫資訊。
5.6 技術部分

請參考檢驗點 10.3

第六條. 確保頁面能夠在新技術下良好呈現

Next guideline: 7 Previous guideline: 5 Go to contents

保證頁面可訪問,即使不支援新技術或者效果被關閉。

雖然鼓勵內容開發者使用新技術來解決問題,但應當保證運用新技術的頁面在舊瀏覽器和被關閉效果的瀏覽器中同樣有效。

檢驗點:

6.1 組織文檔,使其在沒有樣式表的情況下也能加以閱讀。舉例來說,當一個HTML文件沒有按照關聯的樣式表來呈現時,一定要還是能閱讀其內容。[優先順序 1]
當內容是按照邏輯組織的,即使樣式表被關閉或不支援 ,這些內容也會按照邏輯顯示。
6.1 技術部分
6.2 確保動態內容的等義替代文字在動態內容更新時也能一併更新。[優先順序 1]
6.2 技術部分
6.3 確保在腳本,小應用程式或其他程式型物件在被關閉或不支援的情況下,網頁仍可使用。如果實在不可能辦到的話,應該提供等義的替代資訊或其他具可訪問性的網頁。[優先順序 1]
比如,保證觸發腳本的鏈結在校本被關閉或不支援的情況下也可用(即不要使用"javascript:"作爲鏈結目標),如果這不能辦到,則在NOSCRIPT元素中提供等義的文字替代,或者使用伺服器端腳本來實現功能,或者提供替代的可訪問頁面,如檢驗點 11.4所述。同樣參考第一條
6.3 技術部分
6.4 對於腳本及小應用程式來說, 都應確保事件處理程式應與輸入介面及設備無關。[優先順序 2]
參考設備無關的定義。
6.4 技術部分
6.5 確保動態內容也具可訪問性,否則就該提供等義的替代內容或網頁。[優先順序 2]
比如在HTML中,在框架頁的最後使用NOFRAMES。在一些應用中,伺服器端腳本比用戶端腳本更具可用性。
6.5 技術部分

請參考檢驗點 11.4.

第七條. 確保使用者能處理時間敏感內容的改變

Next guideline: 8 Previous guideline: 6 Go to contents

保證用戶可以暫停或者停止移動的、閃爍的、自動更新的物件或者頁面。

認知障礙和視覺障礙患者可能不能閱讀移動的文字。移動同樣會造成對其他內容閱讀和理解的分心。螢幕閱讀器並不能閱讀移動的文字。肢體殘疾的用戶也無法快速跟蹤移動的物件,從而産生理解上的困難。

【注】 以下檢驗點包括一些內容開發者需要承擔的義務,直到用戶代理提供足夠的控制機制。

檢驗點:

7.1 除非用戶代理 支援用戶控制閃爍的物件,否則應儘量避免螢幕閃爍。[優先順序 1]
【注】 當螢幕閃爍在4至59每秒及峰值靈敏度20Hz的情況下(如從暗變亮,類似於閃光燈),感光性癲癇症患者可能會發作。
7.1 技術部分
7.2 除非用戶代理支援用戶控制閃光,否則應儘量避免內容閃爍(比如從有到無,或類似於消失後馬上出現的情形)。[優先順序 2]
7.2 技術部分
7.3 除非用戶代理支援用戶停止移動內容,否則應儘量避免頁面內出現移動內容。[優先順序 2]
當頁面包含移動內容時,應當提供腳本或小程式讓用戶關閉移動或者更新。使用腳本和樣式表來讓用戶可以自由關閉一些特效。參考第八條.
Techniques for checkpoint 7.3
7.4 除非用戶代理支援用戶停止頁面刷新,否則應儘量不要創建周期性自動刷新的頁面。[優先順序 2]
比如在HTML中,不要使用"HTTP-EQUIV=refresh",除非用戶代理支援用戶關閉此功能。
7.4 技術部分
7.5 除非用戶代理 支援用戶停止自動重定向,否則應儘量避免頁面自動重定向。而通過伺服器來實現重定向。[優先順序 2]
7.5 技術部分

【注】BLINK和MARQUEE元素在W3C HTML標準中從來沒有定義過,並不推薦使用。參考第十一條

第八條. 確保嵌入式用戶介面具有直接的可訪問性

Next guideline: 9 Previous guideline: 7 Go to contents

確保用戶介面遵循可訪問性設計原則:對功能操作設備無關,可以鍵盤操作及自動發音等。

當一個嵌入式物件具備“自己的介面”,和瀏覽器的介面類似,那對於用戶來說比較易用。如果嵌入式的這個介面不能達到此要求,那麽最好有一個可替代的無障礙方案。

【注】 更多關於用戶介面易用性的,請參考用戶代理可訪問性指南([WAI-USERAGENT])以及編輯工具可訪問性指南([WAI-AUTOOL])。

檢驗點:

8.1 讓程式型元素如腳本和小應用程式等,能夠直接被一些輔助技術使用,或者與之相容[如果功能很重要而且不在其他地方出現的話,優先順序爲1,否則優先順序爲 2。]。
參考第六條
8.1 技術部分

第九條. 設備無關的設計

Next guideline: 10 Previous guideline: 8 Go to contents

確保通過多種不同的輸入設備都可以啟動或觸發頁面上的元素。

設備無關性意味著用戶可以使用一些喜好的輸入(或輸出)設備——如滑鼠、鍵盤、語音、肢體棒等——來和用戶代理或者文檔交互,如果,舉個例子,表單控制只能通過滑鼠或者其他指示設備來觸發,那麽當一些具有視力障礙或者使用語音輸入和鍵盤的人就無法使用。

【注】 爲圖像映射或圖像鏈結提供等義替代文字,可以使沒有指點設備的用戶正常交互。參考第一條.

通常來說,支援鍵盤交互的頁面同時也支援語音和命令行操作。

檢驗點:

9.1 除非無法用有效的多邊型形狀來定義,否則應該提供使用者端的圖像映射,而非伺服器端。[優先順序 1]
請參考檢驗點 1.1, 檢驗點 1.2, 和檢驗點 1.5
9.1 技術部分
9.2 確保任何具有自身操作介面的元素,其操作方式都與使用者的設備無關。[優先順序 2]
請參考設備無關性的定義。
同樣請參考第八條
9.2 技術部分
9.3 對於腳本來說,應指定邏輯上的事件處理,而不應該指定特定裝置的事件處理。[優先順序 2]
9.3 技術部分
9.4 在鏈結、表單控制及物件間,提供合乎邏輯的Tab條約順序。[優先順序 3]
比如在HTML裏,可以通過"tabindex"屬性來制定tab順序,確保頁面設計的邏輯性。
9.4 程式部分
9.5 爲重要鏈結提供鍵盤快捷鍵(包括用戶端圖像映射、表單控制、表單控制群組)。[優先順序 3]
比如在HTML裏,可以使用"accesskey"來指明鍵盤快捷鍵。
9.5 技術部分

第十條. 使用過渡的解決方案

Next guideline: 11 Previous guideline: 9 Go to contents

使用過渡的可訪問性解決方案可以使輔助技術以及舊的瀏覽器很好的支援。

比如,舊的瀏覽器不允許用戶操縱空的編輯框;舊的螢幕閱讀器把連續的鏈結列表理解爲一個鏈結;這些活動元素訪問起來就比較困難或者難以訪問。改變當前視窗內容或者彈出新視窗則會使一些用戶感到迷惑。

【注】 以下檢驗點僅在用戶代理支援時有效(包括輔助技術)。這些檢驗點都被標爲“過渡”的,這意味著Web內容指南工作小組認爲它們在本文檔發佈時是有效和需要的。但並不保證在將來,Web技術也可能會加入一些預期的功能和特色。

檢驗點:

10.1 除非用戶代理支援用戶關閉新開的視窗,否則應儘量避免使用彈出式窗口或其他類似視窗,也不該在未通知用戶的情況下就變更當前視窗。[優先順序 2]
比如在HTML中應避免在某個框架頁上使用鏈結目標爲新視窗。
10.1 技術部分
10.2 除非用戶代理支援處理label和表單控制元素間的關聯,否則對於所有的表單控制元素和不明確的lable來說,都應當確保這些label位於合適的位置。[優先順序 2]
label必須出現在它所聯繫的控制元素之前(包括一行內具有多個的情況),或者是上一行。請參考檢驗點 12.4.
10.2 技術部分
10.3 除非用戶代理 (包括輔助技術)能夠正確地繪製出平行的文字, 否則就應該爲所有使用平行文字或折行表列的表格(在同一頁或其他頁面中)提供線性的等義替代文字。 [優先順序 3]
【注】 請參考線性化表格的定義。 本檢驗點主要考慮那些使用不支援平行文字塊的用戶代理(比如一些螢幕閱讀器)的用戶;本檢驗點並非阻止開發者使用表格表現表格狀資料。
10.3 技術部分
10.4 除非用戶代理能夠正確處理空白的控制元素,否則就應該要在編輯框及文字區域中,預先放置占位元字元。[優先順序 3]
比如在HTML中,TEXTAREA和INPUT元素應當如此。
10.4 技術部分
10.5 除非用戶代理(包括輔助技術)能夠清楚地顯示緊靠的兩個鏈結,否則應當在兩個鏈結間插入不屬於鏈結又可被列印的字元(並以空格隔開)。[優先順序 3]
10.5 技術部分

第十一條. 使用W3C推薦的技術和規範

Next guideline: 12 Previous guideline: 10 Go to contents

使用W3C技術(根據規範)並且遵循可訪問性指南。如果使用W3C技術有困難,或者可能會造成內容呈現上的問題,那麽可以提供一個現有內容的可訪問性替代版本。

本指南推薦W3C技術(如HTML和CSS等)有以下原因:

很多非W3C格式(如PDF,Shockwave,等)必須安裝插件或者獨立的應用程式來瀏覽。通常情況下這些格式不能被標準的用戶代理(包括相關輔助技術)閱讀和導航。避免使用非W3C推薦和非標準的功能(私有的元素、屬性和擴展),這樣可以使更多的人使用多種軟硬體訪問。當一些頁面必須使用有訪問障礙的技術時,必須提供等價的替代頁面。

使用W3C技術也必須遵循可訪問性指南,當使用了新的技術,確保它們能夠良好的呈現出來。(參考第六條。)。

【注】 從PDF、PostScript、RTF等形式轉換成W3C標簽語言(如HTML、XML)所得的文檔可能不具有良好的可訪問性。所以轉換完成後須檢驗每個頁面的可訪問性和可用性(參考驗證一節)。如果轉換比較困難,那麽可以通過修訂原文檔來確保良好呈現,或者提供一個HTML或純文本版本。

檢驗點:

11.1 盡可能並且合理的使用W3C技術,盡可能使用被支援的最新的W3C技術。[優先順序 2]
最新W3C標準和規範請查閱參考文獻部分,最新的關於用戶代理(UA)支援方面的W3C技術資訊請參考[WAI-UA-SUPPORT]
11.1 技術部分
11.2 避免使用W3C不贊成的廢棄的功能。[優先順序 2]
如在HTML中,請勿使用不推薦的FONT元素;而使用樣式表(如CSS裏的font屬性)。
11.2 技術部分
11.3 提供相關的資訊,讓使用者能夠按照其偏好 (語言, 內容類型等)來獲取文檔。[優先順序 3]
【注】 盡可能的使用內容判斷(content negotiation)機制。
11.3 技術部分
11.4 如果竭盡所能仍無法建立具可訪問性的網頁, 那麽應另外提供網頁,該網頁應使用W3C推薦的技術,具備可訪問性,並且提供等義的替代資訊 (或功能),並且與那個不具可訪問性(原來的)網頁保持同步更新。[優先順序 1]
11.4 技術部分

【注】 當其他措施都無效的時候,內容開發者才應該提供可訪問性替代版本,因爲這些替代版本可能更新比“主”頁面慢。這樣如果用戶訪問主頁資訊有障礙,而替代版本又是過期的,可能會造成挫折。自動生成替代版本也許是好主意,但是要確保這些頁面正確並且可以通過鏈結導航。在採取替代頁面方案前,再考慮一遍原頁面的設計,畢竟提高原頁面的可訪問性對於所有用戶都有好處。

第十二條. 提供內容引導資訊

Next guideline: 13 Previous guideline: 11 Go to contents

提供上下文和位置資訊以幫助用戶理解複雜的頁面或元素。

提供相關頁面間和相關元素間聯繫資訊,可以幫助所有的用戶理解。一些頁面間複雜的聯繫可能會造成認知障礙人士和視覺障礙人士訪問上的不便。

檢驗點:

12.1 爲每一個框架添加標題,以促進框架的辨認與導航。[優先順序 1]
比如在HTML裏在FRAME元素上使用"title"屬性。
12.1 技術部分
12.2 如果框架標題不夠明確,就應該描述每一個框架的目的,以及當前框架與其他框架間的聯繫。[優先順序 2]
比如說在HTML裏面,使用"longdesc"屬性或者是描述鏈結
12.2 技術部分
12.3 自然適當的將大塊的資訊分隔爲易於管理的小部分。[優先順序 2]
例如在HTML裏;使用OPTGROUP來群組SELECT裏相關的OPTION元素;用FIELDSET和LEGEND來分隔表單控制;適當的使用嵌套的列表;使用標題(headings)來結構化文檔,等等。請參考第三條
12.3 技術部分
12.4 明確地將LABEL與其所關聯的表單元素聯繫在一起。[優先順序 2]
例如在HTML裏使用LABEL元素和"for"屬性。
12.4 技術部分

第十三條. 提供清晰的內容導航機制

Next guideline: 14 Previous guideline: 12 Go to contents

提供清晰並且一致的導航機制——位置資訊、導航條、網站地圖,等等——如此可使使用者在網站上快速而精確地找到特定資訊。

清晰並且一致的導航機制對於具有認知障礙、視力障礙的人非常重要,並且對於所有人都有益。

檢驗點:

13.1 能夠明確的知道每個鏈結的目標。[優先順序 2]
鏈結文字應該意義清楚,無論是單獨理解或者是放入上下文。鏈結文字也必須是扼要的。
比如,在HTML裏,寫“4.3版本資訊”而不是“點擊這裏”。爲了使鏈結文字清楚,內容開發者必須利用資訊提示(在HTML裏,即"title"屬性)指明鏈結的目標。
13.1 技術部分
13.2 利用原資料(metadata)爲頁面和網站加入語義化資訊。[優先順序 2]
比如,使用資源描述框架(RDF)([RDF])來表明文檔的作者、內容的類型等等。
注意:一些HTML用戶代理 可以通過HTML的LINK元素和"rel"或"rev"屬性來創建導航。(如:rel="next",rel="previous",rel="index",等等。) 參照檢驗點 13.5.
13.2 技術部分
13.3 提供網站結構規劃方面的資訊(如網站地圖或者目錄索引)。[優先順序 2]
在描述網站結構的時候,涉及到可訪問性的內容可以高亮顯示並加以解釋說明。
13.3 技術部分
13.4 提供一致的導航機制。[優先順序 2]
13.4 技術部分
13.5 提供導航條,強調並讓使用者導航機制。[優先順序 3]
13.5 技術部分
13.6 將相關的鏈結聚集一起,並且(爲用戶代理)指明,除非用戶代理可以處理,否則還應該提供跳過該鏈結群的方法。[優先順序 3]
13.6 技術部分
13.7 如果提供了搜索功能,可以設計不同的網頁內容搜索方式,以提供不同經驗與喜好者搜尋選用。[優先順序 3]
13.7 技術部分
13.8 在網頁標題、段落、列表等的開始部分放置區分資訊。[優先順序 3]
注意: 這通常被稱作“預載入”並且非常有利於利用串列設備(如合成語音)的人獲取資訊。
13.8 技術部分
13.9 爲文檔輯(包含衆多頁面)提供資訊。[優先順序 3]
例如,利用HTML的LINK元素和"rel"和"rev"屬性可以幫助建立文檔輯。另外一種方法就是製作存檔(如利用zip,tar和gzip,stuffit等等。)。
注意:離線瀏覽可以爲一些動作不便、緩慢的人節省下不少費用。
13.9 技術部分
13.10 提供一個跳過多行ASCII圖形的方法。[優先順序 3]
參考檢驗點 1.1術語表中ASCII圖形的例子
13.10 技術部分

第十四條. 確保文檔內容的清晰與簡單

Next guideline: 1 Previous guideline: 13 Go to contents

確保文檔內容的清晰與簡單,以便於人們理解。

一致的頁面佈局,可辨認的圖片以及易於理解的文字可以讓所有人受益。特別是可以幫助具有認知障礙和閱讀障礙的人訪問。(爲盲人、視力障礙者或關閉圖片顯示的用戶提供圖片的替代文字,請參照第一條。)

使用清晰簡單的文字可以提高資訊的傳達效率。較書面的文字會給認知障礙和學習障礙者造成理解上的困難。使用清晰和簡單的問題同樣可以使那些母語並非網頁語言的訪問者易於理解,還包括那些主要使用手語的人。

檢驗點:

14.1 使用最清晰最簡單的文字表達網站的內容。[優先順序 1]
14.1 技術部分
14.2 提供圖片、音頻表達的文字補充說明,便於增強頁面內容的易理解性。[優先順序 3]
參照第一條
14.2 技術部分
14.3 統一頁面之間的表現樣式。[優先順序 3]
14.3 技術部分

附錄 A. -- 驗證

可以通過自動工具或者人工驗證可訪問性。自動的驗證工具可以非常便捷的得出結果,但是並不能覆蓋所有的可訪問性問題。人工驗證可以保證語言文字和導航資訊的清晰與易用。

儘量在開發初期就重視驗證可訪問性問題,發現的越早則越容易解決和避免。

以下是一些重要的驗證方法,在技術文檔 - 驗證部分中有詳細的介紹。

  1. 使用自動化的工具和瀏覽器驗證工具,請注意使用軟體工具並不會提示所有的可訪問性問題,比如鏈結文字的意義、替代文字是否合適等等。
  2. 語法檢驗(如:HTML,XML等)。
  3. 樣式表檢驗(如:CSS)。
  4. 使用純文本瀏覽器或模擬器。
  5. 使用多媒體圖形瀏覽器,並且:
  6. 使用多個瀏覽器,舊的和新的。
  7. 使用能自我發音的瀏覽器、螢幕閱讀器、放大軟體或小面積顯示等等。
  8. 使用拼寫和語法檢查器。拼寫錯誤可能導致使用語音合成器的瀏覽者誤解詞語的意思。減少語法上的問題可以提高可理解度。
  9. 檢查文檔的清晰度和簡潔性。通過一些文字處理軟體統計閱讀資訊,對於文檔的清晰度和簡潔性有指示作用。最好的辦法就是邀請有經驗的作家來協助撰寫內容。通過編輯人員的,也可以提高文檔的可用性。
  10. 邀請一些殘疾人來評論,他們都會認真地提供關於可訪問性或使用性的有價值的反饋資訊。

附錄 B. -- 術語表

Accessible 可訪問的,無障礙的
當內容對於殘疾人來說可以正常使用與理解,即具備可訪問性。
Applet Java應用小程式
某種嵌入Web頁面的程式。
Assistive technology 輔助技術
特別設計用來輔助殘疾人完成日常活動的軟硬體。輔助技術包括輪椅,閱讀機器,抓握裝置等。在web可訪問性領域,常用的基於軟體的輔助技術包括螢幕閱讀器,螢幕放大器,語音合成器,語音輸入軟體,通常與桌面圖形瀏覽器(以及其他用戶代理)聯合操作。硬體輔助技術包括特製鍵盤和定點設備。
ASCII art ASCII圖案
ASCII圖案使用文本字元來組合創造圖像。例如, ";-)"是表示微笑。下面是一個ascii圖案,表現了閃動頻率與病人睜眼、眨眼的光敏反映。[跳過ascii圖案或參考本圖案描述]:
 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Flash frequency (Hertz)
Authoring tool 創作工具
HTML編輯器,文檔轉化工具,以及由資料庫産生web內容的工具都是創作工具。查閱“創作工具可操作性指南”([WAI-AUTOOLS])關於開發這些工具的相關資訊。
Backward compatible 向後相容
即設計在早期版本的語言、程式中都相容。
Braille 布萊葉盲文
布萊葉盲文用六個不同式樣的突起點來表達字母和數位,供盲人用指尖來閱讀。布萊葉盲文中“Accessible”(可訪問性)一詞表示如下:
Accessible
盲文顯示器,通常也叫做“動態盲文顯示器”,由一個電子裝置——通常是電腦——發出命令,提升或降低點的樣式。結果是出現一行可以迅速改變的盲文。當前通用的動態盲文顯示器在尺寸上從一單元(六至八點)延伸至八十單元行,大多數每行有十二至二十單元。
Content developer 內容開發者
創建Web頁面或是設計、規劃網站的人。
Deprecated 不贊成、棄用的
棄用元素或屬性是已經由更新的所替代,已經過時的元素或屬性。棄用元素在將來HTML的版本中變的陳舊。技術文檔中HTML元素和屬性的索引顯示了在HTML 4.0中不主張使用的元素和屬性。
開發者應當避免使用棄用元素和屬性。但由於向後相容的原因,用戶代理應繼續支援。
Device independent 設備無關的
用戶必須使用由他們選擇的、被支援的輸入輸出設備,依照他們的需求,與用戶代理(以及它呈現的文檔)交互。輸入設備可以包括定點設備、鍵盤、盲文設備、肢體棒,麥克風和其他設備。輸出設備可以包括顯示器、語音合成器和盲文設備。
請注意,“與設備無關的支援”不是說用戶代理必須支援每一種輸入或輸出設備。用戶代理應當爲支援的設備提供衆多輸入和輸出機制。舉個例子,如果一個用戶代理支援鍵盤和滑鼠輸入,用戶應當可以僅使用鍵盤、僅使用滑鼠或兩者完成所有交互。
Content,Structure, and Presentation 文檔內容、結構與表現
文檔的內容即文檔通過自然語言,圖像,聲音,電影,動畫等呈現給用戶的東西。文檔的結構就是指文檔在邏輯上是如何組織的(例如,通過章節,引言,目錄等等)。詳細表明文檔結構的元素 (例如HTML中的P, STRONG, BLOCKQUOTE)稱作結構元素。文檔的表現是指文檔是怎樣呈現的(例如,列印,二維圖像表示,純文本表示,合成語音,盲文等)。詳細表明文檔表現的元素(例如B, FONT, CENTER)稱作表現元素
例如一個文檔標題,標題的內容就是標題所說的(例如“帆船”);在HTML中,標題就是被標出的結構元素,例如,H2。最後,標題的表現形式可能是粗印刷體文字並具外補丁,佔據一行並居中的文字,標題由某種聲音(例如一種聽覺字體)說出,等等。
Dynamic HTML (DHTML)
DHTML是一個營銷術語,應用於包括HTML,樣式表,文檔物件模型[DOM1],腳本在內的各種標準的混合。然而並沒有正式定義DHTML的W3C標準。大多數指南適用于DHTML的應用,但本文檔下列原則集中討論同腳本和樣式表相關的問題:第一條, 第三條, 第六條, 第七條, 和第九條
Element 元素
本文檔用“元素”這一術語既表示嚴格的SGML含義(元素是一個語法組成部分),也通常用來表示內容的類型(例如視頻或語音)或邏輯結構(例如標題或列表)。後一種含義強調,一個HTML格式的指南可以毫不費力的應用於另一種標記語言。
注意一些(SGML)元素有其顯示的內容(例如P, LI, 或TABLE),一些爲外部內容所取代(例如IMG),一些影響處理過程(例如STYLE和SCRIPT使資訊被樣式表或腳本引擎處理)。使文字字元成爲文檔內容的元素稱爲文字元素
Equivalent 等價的、同等的、可替代的
當一部分內容與其他內容一樣都能基本實現對用戶的表達相同功能或目的時,可稱其爲等價。在本文檔中,就像基本內容爲健全人士所提供的功能一樣,等價必須爲殘疾人基本實現同樣的功能(至少是在考慮到殘疾人的本性與技術狀態下的可行範圍內)。例如,文字“滿月”在表示給用戶時,可以傳遞與滿月圖像同樣的資訊。注意,等價資訊是用來完成同樣的功能。如果圖像是鏈結的一部分,且理解圖像對猜測鏈結目標有至關重要的作用時,等價也必須給予用戶鏈結目標的概念。爲可訪問性內容提供等價資訊是開發人員使殘疾人訪問文檔的一種主要的途徑。
作爲完成內容相同功能的一部分,等價可以包括對內容的描述(也就是內容的外表特徵和語音特徵)。例如,爲使用戶瞭解一個複雜圖表所傳達的資訊,作者應當描述圖表中的視覺資訊。
由於文本內容可以以合成語音,盲文和視覺化播放文字的形式呈現給用戶,因此本文檔也要求圖像和音頻資訊的等義文字替代。必須編寫同等的替代文字以便傳達所有基本內容。非文字替代(例如一個視覺表示的聽覺描述;一個用手語講故事的視頻,作爲一個書面故事的等價;等等)同樣提高了那些不能訪問視覺資訊與書面文字的人的可訪問性,這類人包括盲人,有認知障礙的人,有學習障礙的人和聾人。
等價資訊可以以許多種方式提供,包括:通過屬性(例如一個在HTML和SMIL中”alt“屬性”的屬性值);作爲元素內容的一部分(例如HTML中的OBJECT);作爲文檔內容的一部分;通過一個鏈結的文檔(例如在HTML中指定爲"longdesc"屬性或描述鏈結(d-link))。由於同等可替代內容的複雜性,需要結合技術(例如對較複雜的資訊使用"longdesc",益於第一次使用的用戶;除此之外,較簡短的則使用"alt",對回訪的用戶有益)。至於如何提供及何時提供等價資訊,技術文檔中有詳細資料。
文字副本(text transcript) 是音頻資訊的等義替代,音頻資訊包括語音和非語音,例如音響效果。字幕(caption)就是一種文字副本,它與音頻視頻同步。字幕通常在疊加在視頻上表示,以利於那些聾人,有聽覺困難和聽不到聲音的人(例如在一個嘈雜的房間內)。按序文字副本(collated text transcript )將(按序)字幕同視覺資訊的文字表達(動作表達,身體語言,圖像和視覺追蹤的情景變化)相結合。這些等義的替代文字使聾人、盲人以及不能播放電影、動畫的人等都可以訪問。同時,也使資訊可用於搜索引擎。
非文字等同的一個例子就是一些關鍵視覺元素的聽覺描述(auditory description )。這個描述既可以是一個預先錄製的人聲也可以是一段合成的聲音。聽覺描述與是視頻同步的,通常在自然停頓的時候播放。聽覺描述包括動作,肢體語言,圖像和情景變化等資訊。
Image 圖像
一種圖形化呈現。
Image map 圖像映射
圖像映射是指圖像上被劃分的與鏈結相關聯的作用區。點擊任一作用區可以觸發操作。
當一個用戶點擊一個用戶端圖像映射的作用區時,用戶代理計算點擊在哪個區發生並進行與那個區相關的鏈結。點擊一個伺服器端的圖像映射的作用區,會使點擊的相應指令被傳送到伺服器,隨即執行一些操作。
內容開發者可以使用用戶端圖像映射來創建與設備無關的訪問。用戶端圖像映射允許用戶代理提供用戶直接反饋,以便得知用戶指示(如滑鼠)是否移動至一個作用區上。
Important 重要
對理解文檔有至關重要作用的那部分資訊。
Linearized table 線形表格
是指按照段落顯示的方式顯示表格單格的一種呈現方式。這些段落將以單元被在原始檔案中被定義的同樣順序顯示。當按順序閱讀時單格應當有意義並包含結構化元素(創建段落,標題,列表等)以便頁面線性化後有意義。
Link text 鏈結文字
一個鏈結內部呈現的文字內容。
Natural Language 自然語言
口語,書面語或有符號的人們所使用語言,如法語,日語,美式手語,盲文等。自然語言的內容可以利用HTML([HTML40],第8.1節)中“lang”屬性,和XML([XML],第2.12節)中"xml:lang"屬性指明。
Navigation Mechanism 導航機制
導航機制是用戶進行頁面或站點導航使用的任何手段。一些典型的導航機制包括:
navigation bars 導航欄
導航欄是一份文檔或整個站點大多數重要部分的鏈結的集合。
site maps 站點地圖
站點地圖是整個頁面或站點結構的全局視圖。
tables of contents 目錄
目錄通常是一份文檔大多數重要部分的列表(及相應鏈結)。
Personal Digital Assistant (PDA) 個人數位助理,PDA
PDA是一種小型可攜帶的電腦設備。大多數PDA用於記錄個人資料,比如日曆,聯繫和電子郵件。PDA通常是一個有小螢幕的手持設備,可以通過多種資源輸入。
Screen magnifier 螢幕放大器
是一種放大螢幕比例以便更方便觀看的軟體程式。螢幕放大器主要爲弱視個體所使用。
Screen reader 螢幕閱讀器
一種將螢幕內容大聲朗讀給用戶聽的軟體程式。螢幕閱讀器主要爲盲人所使用。螢幕閱讀器通常僅能閱讀螢幕的印刷體文字而不能閱讀圖片文字。
Style sheets 樣式表
樣式表是文檔表現的詳細描述。樣式表可以有三種不同的來源:可由內容提供者編寫,可由用戶創建,或由用戶代理商立。在CSS ([CSS2])中,內容提供者,用戶和用戶代理樣式表的交互稱爲層疊
Presentation markup 表現層標記是用來完成格式上(而非結構上)效果的標記,例如HTML中的B或I元素。注意STRONG和EM元素不作爲表現層標記是因爲它們傳達與特定字體樣式無關的資訊。
Tabular information 表格式資訊
當表格用於表達資料文字,數位,圖像等中的邏輯關係時,資訊被稱作“表格式資訊”,表格被稱爲“資料表格”。由表格表示的關係可以在視覺上表示出來(通常在一個二維的格子上),在聽覺上表示(通常是最前面的有標題資訊單元),或以其他形式表示。
Until user agents ... 直至用戶代理...
在大多數檢驗點中,要求內容開發者保證他們的頁面和站點具有可訪問性。然而,還有很多可訪問性需求需要用戶代理(包括輔助技術)支援。至本文發表時,不是所有的用戶代理或輔助技術提供訪問控制用戶要求(例如,一些用戶代理不允許用戶關閉閃爍內容,或一些螢幕閱讀器不能較好的處理表格)。包含“直到用戶代理商……”的檢驗點要求內容開發者爲可訪問性提供額外支援,直到大多數用戶代理可被其用戶容易地利用,包括必需的可訪問性功能。 However, there are accessibility needs that would be more appropriately met by user agents (including assistive technologies).
注意,W3C無障礙網路倡議網站(參見[WAI-UA-SUPPORT])提供了關於用戶代理支援可訪問性功能的資訊。建議內容開發者適當地參考這個頁面的最新資訊。
User agent 用戶代理
訪問web內容的軟體,包括桌面圖像瀏覽器,文字瀏覽器,語音瀏覽器,移動電話,多媒體播放器,插件程式,以及一些用來與瀏覽器聯結的軟體輔助技術,比如螢幕閱讀器,螢幕放大器,語音識別軟體等。

鳴謝

Web內容可訪問性工作組聯合主席:
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
W3C小組聯繫人:
Judy Brewer and Daniel Dardailler
感謝以下所有曾經幫助修正本文檔的朋友:
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White

本文檔的原始草案基於由Trace R & D Center at the University of Wisconsin編譯的“網站可訪問性指南統一標準(The Unified Web Site Accessibility Guidelines)”([UWSAG]),該文檔包含另外的貢獻者名單。

參考文獻

任何最新版本W3C標準及規範,請查閱W3C技術報告

[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. The CSS1 Recommendation is: http://www.w3.org/TR/1999/REC-CSS1-19990111.
The latest version of CSS1 is available at: http://www.w3.org/TR/REC-CSS1.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. The CSS2 Recommendation is: http://www.w3.org/TR/1998/REC-CSS2-19980512.
The latest version of CSS2 is available at: http://www.w3.org/TR/REC-CSS2.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. The DOM Level 1 Recommendation is: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
The latest version of DOM Level 1 is available at: http://www.w3.org/TR/REC-DOM-Level-1
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. The HTML 4.0 Recommendation is: http://www.w3.org/TR/1998/REC-html40-19980424.
The latest version of HTML 4.0 is available at: http://www.w3.org/TR/REC-html40.
[HTML32]
"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. The latest version of HTML 3.2 is available at: http://www.w3.org/TR/REC-html32.
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. The MathML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-MathML-19980407.
The latest version of MathML 1.0 is available at: http://www.w3.org/TRREC-MathML.
[PNG]
"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. The latest version of PNG 1.0 is: http://www.w3.org/TR/REC-png.
[RDF]
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. The RDF Recommendation is: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
The latest version of RDF 1.0 is available at: http://www.w3.org/TR/REC-rdf-syntax
[RFC2068]
"HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. The SMIL 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-smil-19980615
The latest version of SMIL 1.0 is available at: http://www.w3.org/TR/REC-smil
[TECHNIQUES]
"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. This document explains how to implement the checkpoints defined in "Web Content Accessibility Guidelines 1.0". The latest draft of the techniques is available at: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working Draft of these guidelines for designing accessible authoring tools is available at: http://www.w3.org/TR/WAI-AUTOOLS/
[WAI-UA-SUPPORT]
This page documents known support by user agents (including assistive technologies) of some accessibility features listed in this document. The page is available at: http://www.w3.org/WAI/Resources/WAI-UA-Support
[WAI-USERAGENT]
"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest Working Draft of these guidelines for designing accessible user agents is available at: http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONS]
Information about conformance icons for this document and how to use them is available at http://www.w3.org/WAI/WCAG1-Conformance.html
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of Education. This document is available at: http://www.tracecenter.org/docs/html_guidelines/version8.htm
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. The XML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-xml-19980210.
The latest version of XML 1.0 is available at: http://www.w3.org/TR/REC-xml

Level
Triple-A conformance icon, W3C-WAI Web Content Accessibility
Guidelines 1.0