Web 2.0應用程序最佳實踐
隨著Web 2.0的日漸普及，Web 2.0應用程序的可訪問性對開發者提出了越來越高的要求，應用程序可訪問性是指為殘障人士掃除使用障礙。在使用電腦時，有些用戶也許無法看見或無法移動鼠標，或者會面臨很多其他困難。
IBM在產品的可訪問性方面有著悠久的歷史；讓應用程序能夠被最廣泛的客戶群使用具有良好的商業意義。因此，IBM承諾將支持世界級規范和標準的技術帶給殘障人士。
附加測試，也稱為可訪問性驗證測試（AccessibilityVerificationTesting，下文簡稱為AVT），被用于確保產品符合這些可訪問性標準。AVTChecklist是一個檢查點列表，支持可訪問性的產品需要遵守這個列表。該列表是根據世界級可訪問性標準生成的，如USsection508和W3CWebContentAccessibilityGuidelines（下文簡稱WCAG）。在本文中，我們將通過一些簡單的例子來解釋檢查列表中一些基本的、重要的項目。我們將分享如何對一個Web 2.0產品規劃和執行AVT的最佳實踐。
背景
WAI-ARIA（下文簡稱ARIA），即AccessibleRichInternetApplicationsSuite，開發出一種方式使網絡內容更易于殘障人士訪問。它讓AsynchronousJavaScript+XML(Ajax)、JavaScript或其它技術開發出的動態內容尤其易于使用。特別是，WAI-ARIA提供了一個框架用于添加屬性來識別用戶交互的特點、它們互相如何關聯以及它們的當前狀態。在以下的例子中，您將看到，大多數屬性是特定于WAI-ARIA的。
關于AVT的例子及信息都基于我們對Web 2.0應用程序的測試，支持Firefox3瀏覽器和JAWS10，因為有些屬性，例如WAI-ARIA標記，只有使用特定的組件組合才能看到。
可訪問性檢查列表的關鍵要素
那么，究竟哪些技術被認為是與可訪問性相關的技術？可訪問性檢查列表有幾條關鍵原則：
◆輸入方式可選擇：鍵盤、鼠標、語音，以及用于殘障人士的設備；
◆輸出方式可選擇：顯示、聲音、打印，以及將圖像提示轉換成聲音的用戶界面元素；
◆一致性和靈活性：與顏色、字體等用戶設置保持一致。
這些原則是可訪問性檢查列表的基礎。在本文中，我們將重點放在Web 2.0應用程序的可訪問性，因此我們討論Web應用程序檢查列表。Web應用程序應該符合檢查列表以便殘障人士能夠使用。這些例子將包含一些基本的要點以及經常出現問題的方面。
1.替換文本：所有非文本內容均應有對應的文本內容
有些瀏覽器不支持圖片，因此一些視力受損的用戶看不到圖片。因而為所有的圖片提供替代文本就尤為重要，這能使所有用戶都了解其信息。有了替代文本后，屏幕閱讀器之類的輔助技術就可以以另一種方式傳達圖片的內容，根據WCAGSC1.1.1指南描述，所有非文本內容都應有alt文本屬性。冗余的圖片可將alt值設置為空，但有意義的圖片應用有意義的語句設置。替代文本應當準確、簡明。如下所示：
圖1.非功能圖片
1.1 非功能圖片的alt內容為空
圖1顯示的是優先級設置。在詞語“高優先級”和“中等優先級”前的紅色和綠色標志圖標，其實與詞語意思相同，因此這些圖標就是非功能性的或者說是冗余的。如檢查列表1.1指出的，您應當將圖標的alt屬性設為空值。清單1顯示了相應的HTML代碼。
清單1.非功能圖片的代碼
- <imgclassimgclass="lconnSpritelconnSprite-iconPriorityMedium16"
- alt=""src="/activities/javascript/dojo-ibm/dojo/resources/blank.gif"/>
1.2 功能性/重要圖片的alt包含有意義的內容
圖2顯示的是用戶的信息卡。卡上的照片是重要的圖片，因此其alt屬性應包含有意義的描述。清單2顯示的是HTML代碼。
圖2.重要的圖片
清單2.功能圖片的代碼示例
- <imgheightimgheight="35"width="35"alt="Profilephoto" src="http://lc40.cn.ibm.com:9082/profiles/photo.do?userid=
- CFDFB8C1-7082-428F-97EF-9E274BDE3F68"/>
圖3是另一個關于功能圖片的例子。“myactivity”前面的閃電圖標代表活動的優先級，它旁邊沒有文字描述，因此alt屬性應被設為有意義的文字以告訴用戶該圖片的作用。
圖3.功能圖片
清單3.另一個功能圖片的代碼示例
- <imgclassimgclass="lconnSpritelconnSprite-iconActivities16"dojoattachpoint="icon_AP"
- src="/activities/javascript/dojo-ibm/dojo/resources/blank.gif"
- alt="NormalPriority(Default)"/>
1.3 對于多媒體應使用文字記錄描述其內容
圖4是視頻文字記錄的例子。Web 2.0應用程序通常都會提供多媒體內容，有些甚至可以與用戶交互。視力受損的用戶感覺不到這些信息，因此，應該有代替的方法能使殘障用戶了解其內容。在圖4中，內容下方有文字記錄鏈接，用戶可以通過閱讀文字記錄了解視頻信息。
圖4.多媒體的文字記錄 #p#
2.適應性
通過UI呈現給用戶的網站結構應該有一套替代方法來滿足盲人用戶的需求，通過UI展現給用戶的信息、結構和元素關系應該能由程序控制或有替代文本。以下兩個例子描述了確認UI上的表單之間的關系的方法。
2.1 如果一個表單旁邊有標簽，可以使用“for”來確定標簽和表單間的關系
本例子可用于大多數典型的表單結構，即每個條目字段旁都有標簽。使用與相關數據條目元素的id屬性相匹配的值為標簽添加for屬性。如果for屬性未設置，僅當焦點位于輸入表單時，用戶才會聽到“編輯器”。然而，如果為標簽設置了for屬性，用戶將會聽到“用戶名列編輯器”。這能幫助用戶明確表單的用處和應該輸入什么。清單4是這些標簽的代碼。
圖5.表單旁邊有一個標簽
清單4.表單中“for”參數的用法
- <div>
- <labelforlabelfor="user">Username:</label>
- <inputidinputid="user"class="lotusText"type="text"name="j_username"/>
- </rdiv><div>
- <labelforlabelfor="password">Password:</label><inputidinputid="password"
- class="lotusText"type="password"name="j_password"/>
- </div>
2.2 如果一個表單沒有標簽，則為“title”、“aria_title”或“aria_labelledby”設置參數。
圖6.表單的數據輸入字段旁沒有標簽
圖6顯示了一個表單，稱為“AddRelatedActivity”。數據輸入字段旁沒有標簽，但有一段長描述，因此應當為此表單設置title屬性。
清單5.使用“title”屬性
- <selecttitleselecttitle="AddRelatedActivity"style="width:530px;"size="5"
- name="target"dojoattachpoint="targetSelect_AP"/>
此外，設置另外兩個屬性也可以達到同樣效果：aria_title和aria_labelledby。可以通過WAI-ARIA技術來使用這兩個屬性，我們將在本文中稍后討論。
3.顏色
顏色是用戶界面中一個重要的元素。有時，你寧愿使用顏色而不是意思相同的文字來表示某些功能性含義。這就違反了WCAGSC1.4.1，它指出顏色只能用于裝飾；功能性含義不能只用顏色標記。以下兩個例子就指出并解決了違反顏色相關規定的情況。
圖7和8顯示了一個此類違背的例子并提供了一個可行的解決方案。如果用顏色來表示特定的含義，視力受損的用戶或使用高對比模式系統的用戶就無法了解只通過顏色傳達的信息。圖7中的第一個例子顯示了一個高對比屏幕，所有條目的顏色都消失了。因此用戶無法看到條目間的區別。圖8顯示了一個解決方案，只需添加一些簡單的有意義的文字，如[RequiringApproval]或[Draft]，就可以區分不同類型的條目。
圖7.顏色的不合理使用
圖8.顏色的合理使用
圖9顯示的是另一個顏色可用性的問題。普通模式下，選項卡活動時會高亮顯示，但如果系統設置為高對比模式，則無法確定哪個選項卡頁是活動的。解決方法是在每個選項卡頁上加上選項卡名稱。這樣，當用戶進入某頁時，就能知道該頁是活動的。
圖9.高對比模式下的顏色問題 #p#
4.鍵盤
鍵盤也是處理可訪問性問題時應關注的另一領域。
4.1 所有功能都能用鍵盤訪問
WCAGSC2.1.1指出用戶應當能用鍵盤導航到所有內容和功能，圖10顯示了一個關于鍵盤問題的例子。如果鼠標移動到用戶名處，下方將會彈出一張卡片。用戶單擊彈出信息將打開整個名片。這整個操作過程都應當有為鍵盤用戶設計的替代方法。這種情況下，快捷鍵就是一個不錯的選擇。例如，按下Ctrl+Enter將打開用戶的名片。
圖10.打開彈出信息時的鍵盤問題
圖11顯示了另一項復雜的操作，即拖放功能，這是Web 2.0應用程序中的常見特性，允許用戶在UI上動態拖拽小部件。這項功能很難用鍵盤模擬，因此應該用其他方法實現。UI中的另一個明顯的功能是向用戶展示向哪里移動小部件。
圖11.關于拖放功能的鍵盤問題
4.2不應有鍵盤陷阱：焦點可以進入和退出當前的UI
當用戶在當前窗口之上再打開一個新窗口時，可能會對焦點變化感到疑惑。WCAGSC2.1.1指出不應有鍵盤陷阱。如果打開一個新窗口，焦點應當移到新打開窗口的第一個可編輯元素中，并且應該能通過關閉或按下鍵盤ESC鍵的方法來退出新打開的窗口。
圖12顯示的是UI中彈出新窗口的例子。當用戶展開MoreActions按鈕并單擊ImportBookmarks時，屏幕顯示焦點仍在MoreActions按鈕上而不是移到新窗口中。這就是一個鍵盤陷阱，因為用戶無法只用鍵盤就將焦點移到新窗口中。鍵盤導航仍停留在原窗口中。這種情況下，應當添加一些代碼來專門將光標移到新打開窗口的第一個可編輯對象上。
圖12.焦點的鍵盤問題
圖13顯示的是另一個鍵盤陷阱問題。單擊Prioritize按鈕后，彈出一個下拉列表。如果用戶不想選擇任何項，只是退出列表，那么他們不管按下什么鍵都無法做到。這是一個鍵盤陷阱。應該有退出的方法，如按ESC鍵。
圖13.下拉列表的鍵盤陷阱
5.高對比模式
高對比（下文簡稱HC）模式是一種特別的顯示模式。在HC模式下，所有背景設置無效，包括圖片和顏色。因此，應用程序中應有專門的代碼處理HC模式。
圖14顯示的是關于該檢查點的例子。每條用戶記錄都有一個按鈕來讀出名字。但圖片是背景圖，在HC模式下不會顯示在UI中。在圖14中，我們用替代文字來表示圖標。清單6顯示了如何通過第7行中的<span>指令來用span設置替代文字。
圖14.高對比模式下的背景圖
清單6.為HC用戶生成替代文字
- <atitleatitle="Playanaudiofilewiththepronunciationoftheperson'sname"
- id="pronunciation"
- href="/profiles/audio.do?key=4815d70b-680d-4bfb-ba05-f32ccedbbcb5
- &lastMod=1248147056328">
- <imgsrcimgsrc="/profiles/nav/common/styles/images/blank.gif"class="lconnSprite
- lconnSprite-iconAudio16"/>
- <spanclassspanclass="lotusAltText">Pronunciation</span>
- </a>
6.其它問題
還有其他一些影響使用性的情形，它們不包含在以上類別中。本節將介紹這些情形。
6.1定時調整
WCAGSC2.2.1指出應用程序中不應有無法禁用或調整的時間限制。圖15顯示的是該檢查點的例子。錯誤消息將在約5秒鐘后消失，而用戶無法禁用這個有關時間限制的配置。這對于殘障人士是無法接受的，尤其是視力受損用戶。解決方法是禁用時間限制或僅彈出一個錯誤消息即可。
圖15.具有定時調整的消息
6.2導航特性
WCAGSC2.4.1指出所有UI都應有導航特性以幫助用戶將焦點移到合適的位置，例如在包含空白圖片的UI頂部使用“Skiptomaincontent”標記。當然，一個產品的所有用戶界面都應有導航特性。清單7顯示了該檢查點。有三個標識供用戶跳過他們不想聽到的內容。
清單7.提供方法使用戶跳過不希望聽到的內容
- <!--ThefollowinglinesarerequiredforAccessibilityandareusedbyscreenreaders.
- Pleasedonotremove-->
- <ahrefahref="#mainContent"id="lotusAccessLinkMainContent"accesskey="S"
- class="lotusAccess">
- <imgsrcimgsrc="/activities/nav/common/styles/images/blank.gif"
- alt="Skiptomaincontentlink.AccesskeyS"/>
- </a>
- <ahrefahref="#tabNavigation"id="lotusAccessLinkTabNavigation"accesskey="1"
- class="lotusAccess">
- <imgsrcimgsrc="/activities/nav/common/styles/images/blank.gif"
- alt="Skiptotabnavigationlink.Accesskey1"/>
- </a>
- <ahrefahref="#subNavigation"id="lotusAccessLinkSubNavigation"accesskey="2"
- class="lotusAccess">
- <imgsrcimgsrc="/activities/nav/common/styles/images/blank.gif"alt="Skipto
- subnavigation.Accesskey2"/>
#p#
可訪問性認證測試
現在您已經了解到Web應用程序開發過程中會遇到的各種問題，那么現在來看一下如何對這些問題進行測試，在可訪問性驗證測試中使用的工具，按照以下步驟測試Web內容的可訪問性，將會事半功倍：
步驟1：語法分析：WebKing
步驟2：鍵盤導航和可視焦點
步驟3：可視內容的格式化和定時
步驟4：音頻和視頻
步驟5：高對比和大字體
步驟6：禁用樣式表
步驟7：屏幕閱讀器
每一步都有相關的輔助工具，本文描述的官方工具有：語法檢查器和屏幕閱讀器。
Web語法檢查器—WebKing
我們在第一步就提到了Web語法檢查器。這其實主要供開發人員而不是測試人員使用。它一般在開發結束、正式AVT開始之前使用。WebKing是常用的Web語法檢查工具，它可以直接檢查HTML代碼并幫助您在使用其他輔助技術之前修復可訪問性問題。
動態內容生成是Web 2.0應用程序的一項特性。使用Ajax在Web上動態生成對象使頁面在每次加載時都產生不同的HTML代碼。WebKing支持兩種不同的代碼掃描方法：靜態掃描和動態掃描。靜態掃描可用于開發人員在開發環境中直接掃描源代碼。動態掃描可用于測試人員在與程序交互并加載不同內容時操作。WebKing掃描結果報告可用于分析不同違背現象的原因和解決方案，以下列舉了幾種常見的違背現象。
重復ID
HTML代碼中的所有元素都應有一個ID。對于用來識別HTML頁面上的元素的輔助技術來說，ID應該是惟一的，否則就會產生混亂，無法確定哪一個才是正確的元素。對于HTML之類的靜態代碼來說，很容易遵守這一點。但對用JavaScript生成的動態代碼來說，則會很困難。在這種情況下，必須用某種方法保證每次都產生不同的ID。圖16顯示了一種關于重復ID的解決方案。每次頁面加載時，JavaScript都會生成“hidedetails”按鈕。每個按鈕都加個數字作后綴來實現惟一的ID。
圖16.重復ID示例
清單8.為動態生成的代碼設置惟一ID的代碼
- <aidaid="showMore_1"class="lotusActionlotusNowrap"href="#"
- onclick="showDetails('1');returnfalse;"
- style="display:none;">showdetails</a>
- <aidaid="hideMore_1"class="lotusActionlotusNowrap"style=""
- href="#"onclick="hideDetails('1');returnfalse;">
- hidedetails</a>
ALT文字和標簽—表單關系設置
這些問題經常會發生，這就是第一步要執行WebKing的原因。在這個階段，要檢查所有圖片的alt屬性是否設置、對象間的關系是否設置。如果還沒設置的話，您將收到警告，并且您應該在進入下一階段前修復這些問題。
并不是所有違背現象都會成為真正的問題。以重復ID為例，有些隱藏對象不會顯示給用戶，只是供分析腳本使用。這種類型的問題可在WebKing中設置為禁止報告或看作報告中的例外。
屏幕閱讀器—JAWS
屏幕閱讀器主要針對視力受損的用戶。它能幫助用戶使用耳朵而不是眼睛來導航整個頁面。它還能幫助識別用戶界面中的所有元素及其關系。當使用JAWS聽取UI內容時，有一些快捷鍵可用來打開“Linklist”、“headlinelist”等內容。另外，還可以對JAWS設置閱讀配置，如是否讀出鏈接的上下文、標題或alt內容等。如果要進行設置，打開JAWS主面板，選擇Utilities>ConfigurationManager>SetOptions>HTMLOptions。圖17顯示的是設置面板。
圖17.JAWS設置
JAWS10可用于FirefoxVersion3或Microsft®InternetExplorer8來讀取UI內容，因為二者都支持WAI-ARIA技術。用戶能聽到UI上的更多內容，如頁面結構或對象關系，JAWS有兩種模式可供用戶聽取UI內容。一種是VirtualPC光標模式，另一種是Forms模式。有時候這兩種模式被簡稱為打開VirtualPC光標模式或關閉VirtualPC光標模式。當運行JAWS聽取內容時，這兩種模式的效果截然不同。VirtualPC光標模式為用戶逐行讀取文檔或使用快捷方式讀取。Forms模式讓用戶與控件交互并在可編輯控件中輸入信息。這兩種模式可用Insert+Z組合鍵切換。在VirtualPC光標模式下，用戶無法在可編輯字段中輸入任何信息，必須切換到另一模式才可以。
測試方法
對Web 2.0應用程序的AVT測試并不經常進行。但對于使程序符合W3CWeb檢查列表卻十分重要。以下是AVT方法的最佳實踐。
◆AVT應當在所有的主要UI更改完成后進行，因為大的UI變更會引入新的元素或更新已有元素的屬性。
◆AVT應當在UI凍結（freeze）前完成。在該階段發現的問題會導致UI更改，這將造成元素屬性改變，應當確保在不出意外的情況下修復問題。如果項目對UI更改的簽入有最后期限，應該在最后期限之前完成AVT。
◆Webking被更多地作為單元測試工具使用，而不是在AVT階段使用的工具，特別是用于靜態掃描。應當在完成WebKing靜態掃描并修復問題后再進行其他測試。
◆JAWS是個靈敏的工具。不同版本的JAWS對UI元素會讀出不同的內容。這不僅出現在主要版本變更中，例如JAWS9和JAWS10，也出現在小的補丁包變化中，如JAWS10.0.512和JAWS10.0.1142。早期版本可能在讀取ARIA屬性方面存在bug，后期版本則沒有。因此，識別JAWS版本也是一項重要工作。
◆ARIA是用于Web 2.0應用程序的一項很好的技術。該技術定義了很多屬性幫助用戶識別UI中元素的結構和含義。該工具還可為您節省大量工作，例如，在aria-sort屬性中，您可以使用很長的一句話來設置排序鏈接的標題，告訴用戶是降序還是升序排列。使用aria-sort屬性，用戶可以用一個常用單詞來設置標題，或添加aria-sort=ascending/descending來確定排序的模式。
◆有時測試人員很難確定alt文本是否需要或能否設置為空。原則是如果有一種替代方法能讓用戶知道圖片傳達的信息，alt就可以設置為空。否則，應填入有意義的文字。
結束語
AVT是產品生命周期中一個重要階段。每個產品都有其不同的實現方法并且都應符合WCAG檢查列表。本文描述了一些基本而重要的檢查點以及測試工具。請現在就學會這些技巧并運用到您的測試過程中吧。
【編輯推薦】
