用 RUP 創(chuàng)建易訪問的應用程序

級別: 初級

Dr. Gottfried Zimmermann, 奠基人, Access Technologies Group
Dr. Gregg Vanderheiden, 教授, Trace Center, University of Wisconsin

2005 年 10 月 19 日

本文來自 Rational Edge：在當今的軟件和 Web 開發(fā)項目中，易訪問性的考慮起到了非常小的作用，很少有產品對殘疾人或老年用戶是具有易訪問性的。本文的作者主張我們可以通過將易訪問性原則無縫地嵌入到所建立的開發(fā)過程中來解決該問題。他們提議一種將具有易訪問性的設計集成到 IBM Rational Unified Proces，或 RUP（許多軟件開發(fā)項目中使用的迭代過程）中的激勵人的方法。他們還解釋說需要更多研究來充分利用所提議的方法。

全世界的易訪問性倡導者說服軟件行業(yè)通過依照易訪問設計原則開發(fā)對殘疾人和老年用戶具有易訪問性的主流產品。商業(yè)理論很簡單：易訪問設計使產品對許多用戶更具有吸引力，不僅是那些殘疾人。例如，一個設計為所有人使用的應用程序，包括那些看不見的人，也會更好地適應于小屏幕的移動設備。如果所有用戶擁有一個替殘疾用戶著想而設計的產品，他們將更高效并很少出錯。換句話說，易訪問性是一個具有潛在高效益的尚未打開的市場機會。 ¹

立法者也正在推行產品的易訪問性，特別是那些對應 Web 站點的產品。在美國，Rehabilitation Act 的 508 部分命令所有聯(lián)邦機構只購買具有易訪問性的產品并在 Web 上以無障礙的方式提供信息。在其他國家類似的規(guī)則也在考慮中或實施中，包括澳大利亞和其他歐洲國家。例如，在德國，2002 年反岐視法要求到 2005 年底聯(lián)邦政府 Web 站點要具有易訪問性。

一般而言，易訪問性規(guī)則依賴于一種普通標準的，能使軟件產品或 Web 站點具有易訪問性的觀點。University of Wisconsin 的 Trace Center 和 World Wide Web Consortium（W3C）是為軟件和 Web 領域中的易訪問設計開發(fā)指導方針的先驅。 ² 現(xiàn)今，易訪問性指導方針在以下這些領域中可用：

• 一般軟件 ³
  
  
• 主要的操作系統(tǒng)和平臺
  
  
• Web
  
  
• E-learning 應用程序
  
  
• 公共終端
  
  
• 電信和其他領域

然而，盡管所有這些指導方針、標準和規(guī)則要求易訪問性 ⁴ 大多數主流產品仍舊沒有為殘疾用戶考慮而設計。為什么大多數軟件開發(fā)人員和 Web 設計人員對易訪問設計原則了解得這么少？

在開發(fā)過程中嵌入易訪問性設計

首先，目前易訪問性指導方針和標準是靜態(tài)對象。要對產品開發(fā)有真正的影響，還需要將它們嵌入到現(xiàn)今的開發(fā)環(huán)境中并具有可操作性和實踐性。軟件開發(fā)項目有嚴格的時間和預算限制，設計人員和開發(fā)人員沒有時間費勁地看完長長的易訪問性標準的列表。

我們的論點是，應該將易訪問設計實踐緊密地集成到企業(yè)的軟件工程項目過程中以便其不顯著。換句話說，團隊成員應該很容易能夠在日常中遵循這些規(guī)則，就像他們遵循任何類型的合理工程實踐一樣。實際上，這種集成會為更廣泛環(huán)境中的更廣泛人群擴展和增強產品的使用。

該集成還會代表易訪問設計的下一個發(fā)展階段。第一個階段是探究：依據易訪問性找出什么行什么不行。第二個階段是聚集：開發(fā)對具體領域，如 Web、e-learning 等等，普遍認同的易訪問性指導方針?，F(xiàn)在，有了公認的指導方針和標準的基準，我們準備將定義到軟件開發(fā)工具和環(huán)境中的原則插入。然后，開發(fā)人員可以利用這些工具自動地評估有關具體用戶組的產品易訪問性并且也能用于有關如何應用易訪問性原則的集成到過程中的指導方針。

其次，設計人員傾向于將易訪問性考慮成產品完成后應用到產品中的補丁。這是一種事后聰明的做法（或者是“不考慮”），而不是整體的計劃考慮。這樣代價很大。在開發(fā)之后向 Web 應用程序中“添加”易訪問性要比最開始建立時多花費大約十次。 ⁵ 所以，許多人認為易訪問設計是負擔不起的，因此，對產品競爭力不利。

再次，將易訪問設計原則嵌入到流行的軟件開發(fā)過程和工具中能夠解決這些問題。如果我們把易訪問性需求作為一般的需求，那么它們將和功能與性能需求一起出現(xiàn)在開發(fā)人員的任務描述中。開發(fā)人員不需要為使產品對殘疾人可用而做任何額外的事情，他們要做的全部事情就是開發(fā)滿足特定需求的產品。

將易訪問性原則集成到 RUP 中

應用程序開發(fā)不是新規(guī)程，且采用已證明的最佳實踐可以幫助企業(yè)成功地處理應用程序開發(fā)的復雜性。我們的目標是將這些最佳實踐作為能將易訪問設計原則集成到主流應用程序開發(fā)中的媒介。

IBM Rational Unified Process，?或 RUP，?是過程框架且是對于面向團隊的軟件開發(fā)方法的最佳實踐的集合。在 2003 年，全世界大約有超過 3,000 個公司中的五十萬用戶使用它。 ⁶ RUP 被設計成對具體企業(yè)環(huán)境中的具體項目很容易配置。項目或企業(yè)也許開發(fā)自己的插件以適應他們具體的需求或者加入 RUP 團體中可用的第三方插件。

RUP 提供對概念和工作流的普通理解，并且它從模板和開發(fā)過程中各點的核對清單開始。這使得它成為合并易訪問設計原則的理想媒介，并且我們在本文中使用它來論證如何做到這點。然而，如您讀到的，記住我們所提議的概念和方法可以嵌入到任何迭代應用程序開發(fā)過程中。

收集需求

盡管有時候將易訪問性定義為對所有用戶的“可用性”，但是易訪問性的一些方面超過了這些，并考慮到擁有不同能力和個人工具的人?，F(xiàn)在，易訪問性的一個重要方面是與輔助技術的互通性，且因此，與已建立的標準一致。

當前的易訪問性規(guī)則和政策要求產品對具有廣泛功能限制并處于廣泛年齡組中的用戶是易訪問的（有一些免責條款：例如，在線銀行系統(tǒng)不必要為六歲孩子使用而設計）。

雖然我們經常認為易訪問性是固有的軟件質量，但是它不是真正的二元的屬性（例如，要么是真要么是假），而是特殊環(huán)境中產品和用戶之間的關系。因此，代替詢問“我們希望使該產品易訪問嗎？”，我們應該問“誰是該產品的目標用戶（例如預期的和必需的）？”此外，我們將希望知道：“他們的需求是什么？”及“他們在什么情形下使用該產品？”這些問題與 RUP“開發(fā)一個遠景”行為（初始階段出現(xiàn)的，在軟件開發(fā)項目的開始時）保持一致。

讓我們拿在線銀行應用程序作為實例。在我們開始設計產品之前，如果我們期望該產品能夠實現(xiàn)我們的目標（比起銀行只通過普通渠道實現(xiàn)的，而以更低的成本服務于更多的客戶）那么我們首先必須識別潛在的用戶功能和非功能需求。這里是這些需求的示例：

• 應用程序的使用必須簡單 —— 沒有人希望為進行銀行業(yè)務而閱讀手冊。
  
  
• 應用程序必須對各種各樣的人可用：男人和女人，年輕人和老年人（也許太虛弱以至于不能去銀行），說英語的和說西班牙語的，有經驗的計算機用戶和技術恐懼者。
  
  
• 應用程序必須對老年人和其他閱讀小文本時有困難的人是可用的。應用程序必須對所有年齡的手不靈巧很難使用鼠標的人是可用的。
  
  
• 應用程序必須適于在家庭環(huán)境中使用。大多數客戶會通過 Internet 連接用家庭計算機訪問應用程序。
  
  
• 用戶應該擁有當處理電匯訂單時可以斷開的能力，因為他們按分鐘支付 Internet 費用。
  
  
• 圖像要容易辨別，甚至對那些視力差的用戶。
  
  
• 對于盲人，至少要有一個屏幕閱讀器在目標執(zhí)行平臺上是可用的，并且要與應用程序配合得很好。換句話說，要將產品設計成可以提供音頻輸出的。

注意到我們初始的需求收集是基于 RUP 中倡導的迭代開發(fā)方法。我們的設想是按照技術、實踐、預算和其他驅動因素所指示的在生命周期過程中添加、修改和撤消需求。我們還將在規(guī)定的迭代中開發(fā)應用程序，每個迭代不斷增加地為應用程序的規(guī)定范圍和質量標準做出貢獻。盡管如此，在過程的早期，定義盡可能完整的初始需求（包括用例）是關鍵的。這些需求會作為進一步的迭代計劃和風險管理的基礎。在過程的任意處，需求應該反映出有關預想產品的當前的認識。

一旦我們獲取了易訪問性需求（包括法令），我們就可以像對待其他需求一樣對待它們。易訪問性應該作為一條準則，像其他功能確定產品質量的方式一樣鑒定整體的產品質量。換句話說，如果產品對目標用戶是不可行的，那么該產品是有缺陷的。

一旦我們辨別出目標用戶基礎并得到我們的易訪問性需求，向設計人員和開發(fā)人員傳達這些需求的最好方式是什么？為他們生成一個很長的列表來手工處理對大多數項目來說是不現(xiàn)實的。實際上，我們必須以對所有團隊成員都方便且具有易訪問性的形式來獲取這些需求。利用角色（嵌入到用例和情境中）是一種方式。

使用用例和情境

許多主流軟件工程項目已經成功地使用用例來指定應用程序的外部特征。用例使功能需求對所有涉及到項目中的風險承擔者是具有易訪問性的且可理解的。

Ivar Jacobson 1992 年所介紹的 ⁷ 用例被定義成系統(tǒng)執(zhí)行的動作序列，能夠生成對特殊參與者價值的引人注目的結果。 ⁸ 統(tǒng)一建模語言（Unified Modeling Language，UML）為用例定義圖形符號，針對系統(tǒng)應該做什么，而不是如何去做。用例作為客戶（如，用戶）和系統(tǒng)開發(fā)人員之間溝通的共同語言。因此，在開發(fā)項目的早期可以用它們來獲取需求。

盡管用例獲取用戶和任務的一般化觀點，但是依據具體的工作流，情境描述具體的用例實例。情境使用具體的數據，具體的事件，和可能具體的用戶界面，有時候描述情節(jié)。開發(fā)團隊為每個用例生成一些情境來說明事件流和各種錯誤條件（參見圖 1）。情境基于真實數據，這使得它們成為后來過程中測試用例的適當基礎。

圖 1：每個用例都有一組分配的情境。

RUP 使用用例將使用方法描述連接到應用程序的體系結構和代碼上。其實，用例像增加的應用程序開發(fā)和在項目生命周期中連接各種開發(fā)活動的線程一樣運行。

然而，用例和情境有局限性。它們把用戶僅視為“參與者”并且獲取他們的用戶界面需求——和他們的功能。雖然這些技術提供了杰出的方法來描述系統(tǒng)行為，但是它們不能傳達真實的用戶環(huán)境和界面需求的足夠信息。

添加角色以獲取易訪問性需求

Alan Cooper 1999 年所介紹的概念，使用角色 ⁹ 是彌補缺陷的一個恰當的方法。指定角色包括為系統(tǒng)用戶分配假想的名稱和面容（照片）并撰寫一篇工作生活中一天的大體描述。雖然假想的角色被描繪成個體，但輪廓反映出整個的用戶組。

Cooper 區(qū)分了主要角色和次要角色。主要角色代表主要的目標用戶，因此是設計應用程序用戶界面的主要推動力。次要角色有額外的需求，如果為滿足這些需要而進行變更，符合此描述的人就可以使用主要角色的界面。當然，這些變更必須不能與主要角色或者其他次要角色的界面需求沖突。

事實上，使用角色會導致有效的，以用戶為中心的設計。角色能夠使開發(fā)人員通過各種各樣有多樣化界面需求和參數選擇的潛在用戶的眼光來觀察他們的系統(tǒng)。

有代表性的是，產品設計人員不知道人們實際上如何使用產品，甚至很少知道用戶的需求和目標。除此之外，如果設計人員很年輕，技術熟練，并設計為老年人所用的產品，是特別成問題的。這對殘疾人來說也是重要的問題。如果角色被定義成帶有個人感覺并在生命中掙扎的，角色可以幫助設計人員理解老年人和殘疾人如何使用產品。

隨著開發(fā)人員與該角色的接觸 —— 他們會更加熟悉它們的需求和參數選擇 —— 甚至同情他們。這些角色所代表的殘疾用戶會切實地，普遍地出現(xiàn)在開發(fā)過程中。

角色規(guī)范含有用戶環(huán)境，包括任何使用產品時所需要的輔助技術。您可能會為一個人書寫多種描述，或者，將一個用戶組分成多個角色來表示盲人用戶的范圍（語音輸出用戶、盲點法用戶、天生的盲人、后天失明的等等）。

單獨的角色不是易訪問性需求的代替，它們是向這些需求中添加意義和上下文的裝置。它們可以使需求更加具體并更容易理解。隨著時間的推移，它們可以幫助開發(fā)人員將需求內在化，以便照例依照它們，不需要記住它們或者迷信地遵循它們。與易訪問性需求迷信地保持 ¹⁰ 一致經常導致滿足規(guī)范的設計，但不是必要地理想甚至可操作。利用角色來舉例說明設計過程中的易訪問性需求，并隨后在實現(xiàn)和測試中追溯可測試評估點是有效的。稍候我們將討論此后面的功能。

您應該為每個人類參與者提供一組相關的角色（參見圖 2）。對每個組，您必須指派一個主要角色，其他的都是次要的。主要角色應該為每個涉及相關人類參與者的用例推進用戶界面設計。然后，對每個用例，您應該用所有次要角色來“代替”主要角色，修改用戶界面設計，并確保用戶界面滿足每個次要角色的需要。您可以依照與情境類似的程序。很少情況下，主要角色是兩個，因為他們有沖突的用戶界面需求。在這種情況下，您可以復制用例，為一個主要角色分配每個用例，并為每個用例創(chuàng)建分開的界面。

用例、情境和角色共同組成了支持用戶為中心的分析和設計的強大技術。用例獲取產品的整體功能行為，角色為用例指定（不同的）目標用戶集，并因此可以表達易訪問性需求，并且連接到具體用例的情境為真實用戶描述現(xiàn)實的事件順序。

圖 2：每個用例有一組相關的角色。

您需要多少角色？要表示一組完全的用戶，包括多種殘疾的用戶（一般在老年人中），我們的研究表明您也許需要三十個角色（假設該組中極大的可變性和許多殘疾的方面）。用更小的數字獲得完全的覆蓋面會更有利，對這方面的研究在 University of Wisconsin 的 Trace Center 中正在進行。然而，目前，對不能表示局限性不同排列的一組角色的使用、開始的年齡、技能，和殘疾人之間等的內容能夠導致嚴重的誤解和浪費了的工作。甚至對易訪問性很熱心的設計人員還經常不注意地忽略重要用戶組的需求 —— 包括那些上了年紀的用戶。需要做更多的研究來識別應用程序開發(fā)中使用的標準角色組。此外，啟發(fā)式的和對于易訪問性的設計指導方針對創(chuàng)建伴有角色的易管理的設計過程是關鍵的。

確保為用戶提供對易訪問性的支持

當您完成了產品的開發(fā)時，進行部署的用戶會需要支持。這是角色的另一個有用之處，它們可以為這些用戶推動支持機制。您可以利用角色來開發(fā)產品文檔（例如，用戶的指導、安裝指導、課程和培訓材料）。如果您計劃以印刷形式散發(fā)文檔，您也需要做電子形式的。您需要檢查這些文檔，以及其他在線材料（例如，在線幫助，版本注釋，用于下載的 Web 頁面）是否對目標用戶組有易訪問性。如果要將產品以物理包的形式售出，您也需要檢查包裝的易訪問性。如果您在舉行輔導活動，那么房間應該是具有易訪問性的。

如果您決定為直接的用戶支持提供熱線，那么您還應該為此檢查易訪問性。您需要為文本電話用戶安裝單獨的熱線，并在文檔中包含其號碼。

測試易訪問性

RUP 將測試描述為一種在軟件開發(fā)生命周期中不斷地確保質量的方法。 ¹⁰ 及早測試可以減少完成和維護軟件的成本。測試最初源于需求，但它們也源于其他來源。例如，在您發(fā)現(xiàn)并糾正具體錯誤情況之后進行測試。對于當今的復雜軟件應用程序，自動化工具對生成測試數據并運行和分析測試是必要的。

如果您已經利用整合到用例和情境中的具體角色來獲取易訪問性需求，如我們上面描述的，那么您可以使易訪問性測試成為您繼續(xù)的生命周期測試活動中的完整部分。IBM Rational 的 Jim Heumann 描述了一個方法，由用例和情境生成測試用例。 ¹¹ 如我們早期注意到的，每個用例都有一組分別表示主要的和次要的事件流的情境。測試人員可以為每個情境獲得一個或多個測試用例并將數據值附上。

對于根據功能需求評價產品來說，這些測試用例是有用的。它們還為用例提供具體的用戶界面，這使得您對照易訪問性需求來評估產品，您可以讓您的測試基于源自一組角色的易訪問性評估點。

如我們所見，您可以為每個用例和其人類參與者指派一組角色，來為易訪問設計生成整合的方法。不論您在測試用例中使用的角色是什么，測試數據都將是一樣的，因為對于主要和次要角色來說事件流是一樣的。然而，此要角色擴展并增強了情境的可用性需求，且這些額外的需求要得到檢查。

要運行測試用例，構建基于主要角色的測試數據，然后根據次要角色檢查附加的易訪問性就足夠了。例如，如果您的主要用戶使用鼠標和鍵盤進行可視化交互，使用屏幕閱讀器和鍵盤導航的次要角色會添加以下需求：

• 通過平臺的易訪問性 API，要顯露出所有單元。
  
  
• 圖像要有文本的等價物。
  
  
• 通過鍵盤要能訪問所有單元。

對于聽力損傷的次要角色，您會確保為聲音輸出提供音量調節(jié)功能，為視頻剪輯提供字幕，等等。對于無語言或學習能力的次要角色（也許看不見），您要對產品的易用性、在線幫助文本的閱讀級別等等特別關注。

利用自動和手動測試來驗證易訪問性

同大多數測試一樣，將您對易訪問性需求的測試自動化是有利的。用自動測試工具，您可以在開發(fā)生命周期中重復運行回歸測試，以確保在您進行變更之后，系統(tǒng)體系結構和用戶界面仍然健全并且易訪問特性仍然完好無缺。理論上，您甚至可以生成能夠自動實現(xiàn)測試用例（或一部分）的腳本。然而，易訪問性不是所有方面都支持自動測試。很重要的是不要嚴重依賴那些適合此種測試的方面。

RUP 的測試建議由單元測試、整合測試、系統(tǒng)測試和試點測試組成。對易訪問性需求的測試技術在這些領域大概是一樣的（除了試點測試，其涉及了真人用戶的測試）。盡可能早地開始測試是合適的。由開發(fā)人員所執(zhí)行的單元測試使您在早期辨別并修改問題，這樣做既降低了成本又降低了項目風險。改正您通過隨后的測試所發(fā)現(xiàn)的問題要涉及不只一個人 —— 因此，更多間接營業(yè)成本。

在許多項目中，開發(fā)人員在書寫代碼的同時書寫單元測試 —— 或者有時甚至提前（如在測試驅動開發(fā)中）。如果單元測試相當小并且只覆蓋必要的功能需求的話，這種方法是可行的。如果開發(fā)人員不得不為每個測試用例中的易訪問性評估點書寫代碼，那樣會添加許多工作。幸運的是，易訪問性需求對運行在同一平臺上的測試用例和功能單元是公共的。大多數易訪問性需求與用戶界面設計有關，并且對擁有類似用戶界面的用例是一樣的。因此，開發(fā)人員可以在項目測試用例和用例上復用評估點，利用當前的測試工具來自動地生成代碼并根據易訪問性評估點驗證產品。

此外，用于易訪問性檢查的專門的商業(yè)和免費工具可以幫助簡化并自動化測試過程。大多數工具以指導方針和規(guī)則為基礎評估 Web 頁面。 ¹² 一些工具允許您配置評估點集合來應用到應用程序中。

易訪問性評估點是具體到特殊平臺的檢查點的最小單位，不幸的是，不是所有的點都可以由計算機進行測試。例如，計算機可以測試文本等價物對圖像是否可用，但不能測試文本的質量或者甚至確定文本是否是無意義補白。

然而，一旦人類做出了決策，計算機就會接管，執(zhí)行統(tǒng)一的，重復的任務。例如，如果一個測試人員手工地驗證具體圖像所對應的具體文本，那么他可以安排計算機來驗證應用程序中對應圖像副本的同樣的文本。然后，在后繼的測試運行中，測試人員將不需要再觀察文本等價物了，除非從最近一次測試運行開始圖像或文本改變了。

不幸的是，很少有工具關注圖形用戶界面，并且大多數沒有我們提到的成熟。然而，該情況應該隨著對生產力工具的需求而改進，以支持易訪問設計的增加。

從角色中得到易訪問性評估點

確定易訪問性評估點不是微不足道的事。這些點應該基于用例所涉及的角色和使用的上下文（參見圖 3）。如果您向一些或所有用例中添加角色，那么您也應該向相關的測試用例中添加檢查點，以確保系統(tǒng)對新角色是具有易訪問性的。

圖 3：測試用例源于用例情境，評估點源于角色并包含于測試用例中。

理論上說，您可以使用自動化工具取得基于角色和使用的上下文的易訪問性評估點。要使其可行，您需要角色和易訪問性測試工具之間的無逢連接。該方法也會提出關于評估點所出自的標準和指導方針的具體需求。出于討論的目的，我們將假設指導方針和標準由一組開發(fā)人員用于產品檢查的評估點組成。當然，真正的標準和指導方針實際上包含了需要由開發(fā)人員轉化為具體平臺上的評估點的一般易訪問性原則。

讓我們再假設指導方針和標準闡述了每個評估點如何影響不同類型用戶（角色）的可用性，并將用戶利益分為：基本的、重要的，或者有益的。如果系統(tǒng)沒有滿足基本的評估點，角色根本不能夠使用該系統(tǒng)。如果沒有滿足重要評估點，角色可以使用產品，但只能付出很大努力，而以效率低下的方式。如果系統(tǒng)實現(xiàn)了有益的評估點，產品對角色會更有用，盡管產品在不滿足標準的情況下仍舊具有功能。

在某些情況下，評估點實際上會使特殊的角色更難使用產品。我們還可以定義三個程度的劣勢：排除、阻礙，和不便。排除意味著如果滿足了評估點，角色根本不能使用產品。阻礙意味著角色可以使用產品，但只有付出相當大的努力。不便意味著產品對角色的可用性較小，但角色可以在沒有重大困難的情況下使用產品。

總之，評估點和角色之間的關系可以被描述成七個值：

1. 基本的
   
   
2. 重要的
   
   
3. 有益的
   
   
4. 中立的
   
   
5. 不便
   
   
6. 阻礙
   
   
7. 排除

目標是在不為其他產品生成排除或阻礙因素的情況下為一個產品滿足所有基本標準及對所有角色盡可能多的重要標準。

在標準和指導方針的理想集合中，每個指導方針會有多種評估點集，每個集合與具體的平臺有關。按照那種方式，您可以在項目中間轉向運行時平臺并簡單地將您原來的評估點集換成適應新平臺的集合。您的需求 —— 基于角色集 —— 仍舊穩(wěn)定，并且仍舊推動評估點對新平臺的選擇。

減輕與易訪問性相關的風險

在任何應用程序開發(fā)項目中，項目經理必須確保按照需求、準時，且在預算之內開發(fā)產品。 當使用 RUP 中具體化的迭代開發(fā)方法時，項目經理保留著一個按照出現(xiàn)和影響可能性排列的風險列表。每次連續(xù)的迭代處理最可能在那時出現(xiàn)并對產品有嚴重的負面影響的風險。團隊通過觀察產品沒有滿足的需求來得到這些風險。如果他們將易訪問性需求加入他們的初始集中，那么他們可以在早期減少易訪問性風險，就像他們對其他可用性問題做的一樣。

例如，在 RUP 的構建階段，開發(fā)人員也許會確定產品不能由利用屏幕閱讀器的角色進行訪問。要減少該風險，團隊可以在目標運行時環(huán)境中建立原型，并用屏幕閱讀器測試。

當變更請求到來時，要對變更進行考察，看其是否與現(xiàn)有的需求有潛在的沖突。這種變更可以破壞應用程序對一些用戶的易訪問性，根據項目的角色集分析每個變更。例如，如果您決定將幫助信息作為工具提示，而不是在由用戶請求打開的單獨的窗口中，工具提示可能對屏幕閱讀器用戶是不具有易訪問性的。如果您的角色集隱含地包含了對與屏幕閱讀器互通性的需求，您可以在變更、之前通過檢查需求來預料該問題。

專家審查和用戶測試

我們已經討論過的角色驅動方法將為創(chuàng)建易訪問產品提供基礎指導，但是由于角色是唯一接近實際用戶的，用專家審查和真實用戶測試來補充該方法是重要的。當然，對于設計人員來說擁有關于潛在用戶的完整信息并完全理解角色特性也是重要的。如果設計人員對角色所做的事情有不完善的設想，那么他們可能會設計出那種人不能實際使用的產品。由于大多數設計人員不熟悉殘疾人或他們的能力，所以這種類型的錯誤很普遍。

避免創(chuàng)建在開發(fā)的后期仍舊是不具有易訪問性的產品的最佳方法是在每個迭代中實施用戶測試 —— 但是預算和時間的限制通常使這項工作不切實際。對于許多項目，另一種最好的方法是實施審查，利用了解殘疾人特征的專家和他們對各種產品設計的結論。通過這些審查，您可以發(fā)現(xiàn)許多與您通過用戶測試而識別的同樣的設計問題，并獲得如何改正問題的指導方針。

最佳的策略是在項目生命周期中讓這些專家參與測試。在最開始，他們可以幫助識別產品的目標用戶以及有關易訪問性和可用性的管理需求。另外，他們應該根據所識別的用戶基礎指導創(chuàng)建角色的關鍵工作。在開發(fā)生命周期中這將花掉許多次。

在每次迭代中，這些專家根據直接推斷和自己的專家經驗實施易訪問性審查以發(fā)現(xiàn)設計問題。這對早期的迭代特別重要，那個時候更容易糾正設計問題。 根據這些專家審查，隨著迭代的進展，為設計人員修改角色集或澄清特征也許是必要的。

然而，雖然這種專家審查實施起來更簡單并且比用戶測試更便宜，但是一些設計問題只有通過用戶測試才能發(fā)現(xiàn)。我們推薦至少在項目的早期進行一些對原型的用戶測試以減少主要的易訪問性風險。您的易訪問性專家可以幫助計劃、實施并評估這些測試。這些行為將為擴展到超過當前項目的企業(yè)帶來利益。隨著您調整角色以適應測試結果并向設計人員提供更有意義的描述，您將開發(fā)出在所有軟件開發(fā)項目中存儲并復用的有效資產。

對于用 RUP 進行的通用設計的路標

如我之前所說的，RUP 可以成為進行易訪問設計的集成開發(fā)框架。本部分將提供有關這樣做的大體概述（路標）。

如前面所說的，您可以修整 RUP 工作流、工作流細節(jié)、模板、報告和檢驗表以包含與易訪問性相關的任務。

例如，一個應用我們所描述的方法的焦點是 RUP 工件用戶界面原型。通過以更加正式的方式經由角色的應用得到用戶界面設計，并通過使用根據已生成的評估點檢查用戶界面的高級工具，您可以減少開發(fā)過程早期的基礎的易訪問性風險。這與減少 RUP 中描述的詳細描述階段中的體系結構風險類似。

除了簡單的修整，我們建議用三點補充來展開 RUP：

• 作為新的工件類型的角色
  
  
• 用于易訪問性測試的評估點
  
  
• 新的易訪問性經理角色
  
  

添加角色

如我們早先描述的，角色代表用戶組，在工件中，他們可以由人口統(tǒng)計和其他數據支持。應用程序設計人員可以根據目標用戶基礎設計角色并將它們與產品用例聯(lián)系起來。一旦您描述了它們，您就可以復用角色，用細微的修改來適應不同應用程序的環(huán)境。最終，RUP 插件可以提供覆蓋許多用戶的可適應的角色集，包括有各種各樣殘疾的人。設計人員可以使這些適合他們具體的項目環(huán)境。

添加易訪問性評估點

我們的推薦是包含 RUP 中的基于普通易訪問性標準和指導方針的易訪問性評估點，并對各種運行時平臺可用。每個評估點會提供與插件集中每個角色相關的具體平臺信息，并且根據我們早先概括的種類進行分類：基本的、重要的、有益的、中立的、不便的、阻礙或排除。應用程序設計人員會根據他們所選的角色來選擇一組相關的易訪問性評估點。理論上，角色和相應的評估點會由工具支持基于 RUP 的半自動測試過程的商家所提供。

添加易訪問性經理角色

我們建議添加新的 RUP 易訪問性經理角色，該角色會檢查過程調整以反映與易訪問性相關的由企業(yè)和項目使用的標準和指導方針。一個（或一些）設想此角色的人會實施專家審查并且作為項目易訪問性問題的顧問。然而，為目標用戶設計易訪問產品的實際工作仍舊是項目團隊設計人員、開發(fā)人員、測試人員，和其他內行角色的責任。企業(yè)的目標是必須總是將易訪問設計原則集成并根植于現(xiàn)有開發(fā)團隊過程的和實踐中。

要支持這三個對 RUP 的主要補充，企業(yè)也會擴增加一些現(xiàn)有的過程要素來反映易訪問設計原則。例如：

• 添加描述原則的“Accessible design”概念頁面，用于增強并擴充軟件開發(fā)中的可用性，列出與易訪問性相關的 RUP 活動，并提供對重要文獻和標準的參考。
  
  
• 用與易訪問性相關的活動擴充 RUP 工作流，修改現(xiàn)有工作流細節(jié)，而不添加新的內容。
  
  
• 更新工件，如檢查點、模板和報告，來提供易訪問設計原則。例如，Software Architecture Document 會有一個關于易訪問性的附加部分。

結束語

本文簡要地概括了一種通過推動產品開發(fā)并為迭代測試指示評估點的用例和角色來開發(fā)易訪問軟件應用程序的集成方法。將該方法嵌入到公認的過程框架中，如 RUP，是將其引入到開發(fā)企業(yè)中的理想方法。最后，開發(fā) RUP 插件以將此方法的要素集成到標準的 RUP 框架中。 ¹³

除了我們已經介紹的概念，開發(fā)團隊可以應用體系結構模式和用戶界面模式來生成滿足目標角色需求的代碼。在 RUP 中，這些模式可以作為增加代碼質量并增大開發(fā)生產率的設計機制而使用。

總之，我們希望本文將刺激應用程序開發(fā)企業(yè)的“內心的思考”，鼓勵他們實踐以用戶為中心的計劃并從開始就將易訪問特性建立到軟件產品中 —— 而不是在開發(fā)生命周期晚期把它們作為事后產生的想法。我們還希望工具廠商和 RUP 及其他開發(fā)框架的第三方供應商將開始把對易訪問性的集成方法嵌入到他們的產品中。

對所有軟件開發(fā)企業(yè)，我們相信本文中所介紹的方法最終將提高生產力和應用程序的質量。在制造對所有潛在用戶易訪問并實用的產品時，進步的企業(yè)能夠利用新的市場機遇并獲得強大的競爭優(yōu)勢。

致謝

此項工作是在 Grant H133E030012 下的，由美國教育部，National Institute on Disability and Rehabilitation Research 提供部分資助。在 Universal Interface 和Information Technology Access Rehabilitation Engineering Research Center of the University of Wisconsin, Trace Center 進行實施。此處的意見是作者的，不代表資助機構的。

注釋

¹參見“The Wide Range of Abilities and Its Impact on Computer Technology?！?003 年由 Forrester Research 實施的 Research Study by Microsoft。由 http://www.microsoft.com/enable 獲得。

² 參見 Application Software Design Guidelines，Version 1.1，1-June-1994。Trace Center，University of Wisconsin（在 http://trace./docs/software_guidelines/software.htm 可訪問）和 Web Content Accessibility Guidelines 1.0，W3C Recommendation 5-May-1999（在 http://www./TR/1999/WAI-WEBCONTENT-19990505/ 可訪問）。

³參見 1) American National Standards Institute (ANSI) Draft Standard for Trial Use (DSTU) 2003: "Human Factors Engineering of Software User Interfaces." Human Factors and Ergonomics Society, Santa Monica, California 和 2) ISO TS 16071:2003: "Ergonomics of Human-System Interaction: Guidance on Accessibility for Human-computer Interfaces

⁴ 要得到易訪問性標準和指導方針的列表，參看 Access Technologies Group Web 站點：http://www./Resources

⁵ 參見“Design Accessible Sites Now，”Forrester Report，2001 年 12 月。http://www./ER/Research/Report/Summary/0,1338,11431,00.html

⁶ Philippe Kruchten，The Rational Unified Process: An Introduction。Addison-Wesley，2004 年。

⁷ 參見 Ivar Jacobson，Object-Oriented Software Engineering: A Use-Case Driven Approach。Addison-Wesley，1992 年。

⁸ Philippe Kruchten，The Rational Unified Process: An Introduction。Addison-Wesley，2004 年。

⁹參見 Alan Cooper，The Inmates Are Running the Asylum。SAMS/Macmillan，1999 年。

¹⁰通過迷信的行為，我們的意思是一個人繼續(xù)以不與必要相聯(lián)系的特定方式做事情 —— 只是因為以前那樣做。例如，電話用戶可能總是在通話最后關掉電話，因為他原來的電話需要他去關掉電話來掛斷。或者，某些計算機用戶可能總是完全刪除并將信息重新輸入到新的記錄中，而不要僅僅編輯舊記錄 —— 一種與老技術相聯(lián)系的殘留行為?；蛘?，一些進行頁面規(guī)劃的人可能總是使用特定的格式，因為另一個設計人員給她的印象 —— 而不是因為她理解了那個設計人員決策的基礎。換句話說，當人們繼續(xù)做他們曾經做的事而不質疑或理解為什么 —— 甚至如果在當前環(huán)境中該行為不再必要或者充分 —— 時，人們就在從事迷信行為。

¹¹參見 Paul Szymkowiak and Philippe Kruchten，“Testing: The RUP Philosophy?！?The Rational Edge，2003 年 2 月。

¹²參見 Jim Heumann，“Generating Test Cases from Use Cases。” The Rational Edge，2001 年 6 月。

¹³參見 Web Content Accessibility Guidelines 1.0，W3C Recommendation，1999 年 5 月 5 日（在http://www./TR/1999/WAI-WEBCONTENT-19990505/ 可得到）。

¹⁴ 雖然使 RUP 本身對有殘疾的開發(fā)團隊成員具有易訪問性的問題超出了本文的范圍，但是我們目前有一個特殊的想法，就是關于視覺上減弱的人可能如何通過各種方法從事“可視化建模軟件”的最佳實踐。

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文。

作者簡介   

		Gottfried Zimmermann 是軟件工程、質量管理，和 IT 易訪問性方面的專家，他是一名博士，Access Technologies Group（是 ICT 易訪問性方面的顧問公司及 IBM 的業(yè)務伙伴）的創(chuàng)立者。原來，他工作于 Wisconsin-Madison大學的跟蹤中心，致力于有關信息和通信技術的通用設計方面的研究和開發(fā)。在那之前，他是一個 debis（現(xiàn)在叫 T-Systems）方面的軟件架構師和顧問。Zimmermann 博士是 Rational Unified Process 的認證顧問，他曾經作為有關協(xié)議和格式的 W3C 工作組方面的特邀專家，German Chapter of the Usability Professionals Association（GC UPA）的一名成員，且是 Association for Computing Machinery（ACM）中的一名成員。擁有德國斯圖加特大學的計算機科學博士學位。

		Gregg C. Vanderheiden 博士，是行業(yè)工程（Human Factors Program）和生物醫(yī)學工程系的教授，且是 University of Wisconsin-Madison 的 Trace Research 和Development Center 的主任。他在技術易訪問性方面的工作超過三十年了，他撰寫過關于訪問和輔助技術方面的許多文章，締造了得到廣泛接受的術語，如增大性的通信（augmentative communication）、計算機控制（computer curbcuts）、鍵盤仿真（keyboard emulation）、通用遠程控制臺（ universal remote consoles），和伙伴技術（companion technologies）。他的研究團隊還開發(fā)了一組廣泛使用的計算機易訪問特性，包括粘滯鍵（StickyKey）和 MouseKey。Vanderheiden 博士為大量科學顧問和計劃委員會工作過，這些委員會是為導致對許多特殊且大量銷售的產品和技術（包括 Web 技術、ATM，和投票系統(tǒng)）的易訪問性及互聯(lián)標準（如 INCITS V2 URC）的專業(yè)組織、政府，和行業(yè)服務的。