最近讀了三本書，全部關(guān)于Form設(shè)計。如果你覺得Form設(shè)計怎么可能寫成書，而且沒有一行代碼，我很理解。兩年前當(dāng)我在Amazon上看到那本W(wǎng)eb-Form-Design時，也是同樣的驚訝。學(xué)過HCI再回頭看終于也能理解了，不過他人的研究還是“刺激”了我，往往在看到他們對細(xì)節(jié)的關(guān)注程度，才會深刻的感到自己做事的粗淺與浮躁。

• SitePoint出版的Fancy Form Design
• Caroline的Forms that Work
• Luke的Web Form Design

對于這三本書，我個人的建議是：無論你是否設(shè)計Form，從UCD實踐來說，Luke的這本書都是值得一讀的（而且現(xiàn)在也有中文版上 市）；如果你偏重代碼實現(xiàn)，無論是HTML，CSS 還是JavaScript（特別是jQuery），SitePoint出版的這本書能給你很多幫助，對Accessibility的討論也相當(dāng)實用；如果 你需要設(shè)計非常復(fù)雜的Form，例如政府機構(gòu)、企業(yè)報表等，無論其是否基于Web，Caroline的書都提供了方法步驟幫助你整理思路，更好地處理大型 Form的設(shè)計。

允許我在這篇文章粗略的結(jié)合這三本書討論一點Form設(shè)計，一方面是對自己所讀內(nèi)容的小結(jié)沉淀，一方面也是希望能分享出來提供思考與討論；做出這篇 文章內(nèi)容的延伸，在下一篇文章里，將把這幾天對105個網(wǎng)站注冊Form的一點小小的調(diào)查和分析的結(jié)果呈現(xiàn)出來，并討論一些細(xì)節(jié)。

Wikipedia對Form（廣義）的定義是：一份文檔，其擁有空間（域），可以針對一系列有相似內(nèi)容的文檔進行填寫、選擇。

Form的歷史有多久？Wikipedia從法律歷史的角度追溯到18世紀(jì)早期，由Charles Babagge構(gòu)想出來。出于我國教育里對所有事物都必須有中國人身影出現(xiàn)的深刻影響，在全力挖掘自己腦海里自從高中畢業(yè)后就開始退化的歷史殘渣，終于想到我國古代的“畫押”儀式：一系列文本，加上可以按壓“指紋”的輸入空間，看似完全符合Wikipedia對Form的定義。

Caroline將Form抽象出三項屬性。這里以宋代的林沖同學(xué)被發(fā)配到滄州的畫押過程為例：

• 關(guān)系（relationship）：提出問題的組織（北宋王國中央政府）與回答問題的用戶（朝廷欽犯宋江）之間的關(guān)系；
• 對話（conversation）：提出的問題（畫押人宋江同學(xué)的指紋），相關(guān)的指導(dǎo)內(nèi)容（犯罪“事實”，罪名，罪刑，壓印處等），以及不同話題的組成方式（不詳）；
• 外觀（appearance）：文本的組織方式（猜測是標(biāo)題居中、正文左對齊？），輸入域（按壓指紋處）和圖形圖案的使用（政府官??？）以及色彩的使用（我估計是白紙墨字，質(zhì)量差點）等。

當(dāng)然，這三本書以及這篇文章談到的是Web Form，還不至于需要一位考古學(xué)家或者博物學(xué)家來探究它的歷史。當(dāng)Tim Berners-Lee在1992年提出首批HTML Tag時Form還不見蹤影，直到1995年HTML 2.0時才進入開發(fā)者的視野，如果從這一年算，它的年齡可能比我們大多數(shù)人都要小很多。

Web Form與生活中的紙制Form對比是件很有趣的事情，因為這個過程可以幫助抽象出共同的特征元素。綜合這幾天的閱讀擅自改編為以下“版本”：

在我國轟轟烈烈的偉大拆遷運動中，花了大把銀子向政府買地的房地產(chǎn)企業(yè)甲方要與無知善良的草民乙方建立某種聯(lián)系，F(xiàn)orm此時做為一種媒介，同時也成為一個建立聯(lián)系的過程。作為媒介，有組成它的元素：

• 標(biāo)題（Title），說明Form的目的，拆！
• 介紹（introduction），說明甲方的“情況”和想要建立聯(lián)系的性質(zhì)，我要拆你房，你不許找我要合理賠償；
• 問題（questions），甲方需要對乙方的哪些“情況”進行了解，姓氏名誰，家在何方，同意補償條款，等等；
• 輸入域（input field），乙方對自己情況的回應(yīng)區(qū)域（錢不夠而無其它，不同意；錢不夠但有黑社會時常光顧，同意）
• 注釋（notes），例如對問題的說明，法律層面的權(quán)責(zé)；
• 行動（action），F(xiàn)orm被提交的方法。

說它也是一種建立聯(lián)系的過程，因為雙方需要完成一系列交互：

如果是紙制Form，例如一份街頭的市場調(diào)查，可能是一位調(diào)查人員（甲方）拿著一份調(diào)查表與路人（乙方）交談并記錄。調(diào)查人員與路人握手，問候，自 我介紹（introduction），告知調(diào)查目的（Title），路人根據(jù)與對方所屬組織選擇同意（或拒絕），調(diào)查人員提問（questions），路 人回應(yīng)，調(diào)查人員記錄回答（input field），告知相關(guān)數(shù)據(jù)的用途和隱私保護政策（notes），將調(diào)查表收起整理歸類（action），感謝路人，贈予兩張優(yōu)惠券（也許吧），等等。這 個過程中，眼神、表情、語氣、肢體語言等等都是交互過程的一部分。

Web Form呢？企業(yè)利用互聯(lián)網(wǎng)向訪問者呈現(xiàn)Form，用戶掃描（標(biāo)題、介紹、問題），輸入（回答）…鼠標(biāo)點擊（行動），HOORAY！搞定！缺少了什么呢？眼神、表情、語氣、肢體語言嗎？或許…

語氣可以對應(yīng)Web Form的標(biāo)題、介紹、問題的用語與組織；

眼神、表情、肢體語言可以對應(yīng)Web Form的初始視覺呈現(xiàn)，以及交互過程中幫助、錯誤提示信息的呈現(xiàn)方式。

舉個例子，一個在Layout和分組（grouping）上混亂的Web Form就好像一個衣冠不整，無精打采，邏輯混亂調(diào)查人員出現(xiàn)在眼前，要么他手里銬著一黑色手提箱，內(nèi)有百萬美鈔，鑰匙已經(jīng)交給你，就等著你回答完他的問題；要么，還是用一句“我很忙”搪塞過去吧。

這樣或許算我牽強的將Web Form與紙制Form都統(tǒng)一對應(yīng)起來。

至此大概闡述完畢我對Form的定義、性質(zhì)和組成。談?wù)刉eb Form的設(shè)計吧。

Luke列出這樣的四條原則：

• 痛苦最小化（Minimize the pain）：沒人喜歡Form，他們想要的是完成Form后得到的服務(wù)，所以越簡潔容易的完成越好；
• 闡明完成路徑（Illustrate a path to completion）：既然目標(biāo)就是完成填寫，那么就盡可能清晰的表明要如何完成這一任務(wù)；
• 考慮情境（Consider the context）：Form不可能獨立存在，總有它所處的應(yīng)用、商業(yè)等考慮，它是產(chǎn)品或服務(wù)的一部分，就需要融入其中；
• 確保交流一致（Ensure consistent communication）：雖然Form的發(fā)起可能包含各個不同部門自身的考量和需要，但Form必須以一種聲音呈現(xiàn)。

Caroline將Form設(shè)計建立在Social Exchange Theory上：

規(guī)則1：建立信任（Establish trust）:

• 表明Form是由一個真實存在的組織發(fā)布；
• 簡化與該組織的聯(lián)系方式；
• 確保Form有明確的目的；
• 確保Form的設(shè)計看起來由專業(yè)人員完成；
• 遠(yuǎn)離廣告；
• 檢查Form能正確工作，杜絕任何缺陷。

規(guī)則2：減少社會成本（Reduce social cost）

• 請求得到用戶的回應(yīng)，而不是要求他們回應(yīng)；
• 保持Form的簡短容易；
• 給用戶進度提示或標(biāo)題列表讓用戶感覺Form在他們的控制之下；
• 將對用戶敏感、私人信息的請求數(shù)量最小化；
• 設(shè)計用戶確實“能夠”回答的問題；
• 錯誤提示信息要尊重用戶已付出的努力了；
• 如果用戶確實出現(xiàn)錯誤，盡量保留用戶已完成工作。使重新輸入的工作量降到最低。

規(guī)則3：增加獎勵（Increase rewards）

• 及時、小額的獎勵，比延遲、更大的獎勵更有效。

Luke和Caroline的思路很大程度上一致而在一些細(xì)節(jié)上互補。實際上，如果將Form換成交互產(chǎn)品的任何一種，這些原則基本上同樣成立。這 里我不打算糾結(jié)在這些原則上，你可以把這些作為設(shè)計時的guideline，盡量使每個細(xì)節(jié)都能與之對應(yīng)，然而，真正決定你的設(shè)計優(yōu)劣的，總是最終用戶， 所以，更重要的，還是了解目標(biāo)用戶，將他們作為核心融入到設(shè)計過程中去。

這篇文章不是三本書的筆記匯總，不會把所有要點都列在這里，否則出版社要和我急了。下面就幾個重點方面做一些小結(jié)，一來敦促自己審視對內(nèi)容的理解，二來提供給讀者以思考與討論。

設(shè)計Form和設(shè)計任何交互產(chǎn)品一樣，需要數(shù)據(jù)的支持，Luke列出了典型的用戶數(shù)據(jù)來源渠道：產(chǎn)品可用性測試；現(xiàn)場調(diào)查；客服資源；網(wǎng)站跟蹤數(shù)據(jù)；Eye Tracking；Web慣例，如果你熟悉UCD，對此應(yīng)該是耳熟能詳了。

對于不同類型的測試用戶的可信度、測試時的提問等細(xì)節(jié)，Caroline給出了更詳細(xì)的闡述，內(nèi)容較多，而我對其中的一部分內(nèi)容有所質(zhì)疑，這里不列舉出來，如果你有興趣，可以參考原書。

Form問題的選擇、安排和用語

問題的選擇：Luke提出的一個四字原則是Keep（保），Cut（砍），Postpone（延），Explain（釋）。簡單的說，保留核心問題，砍掉現(xiàn)時非核心問題，延遲問題到合適情境，解釋隱私敏感問題。

以注冊Form為例，多數(shù)網(wǎng)站，特別是Web應(yīng) 用會保留到最簡：用戶名、密碼、郵件，是為用戶提供服務(wù)的核心數(shù)據(jù)來源，有些應(yīng)用會選擇繼續(xù)詢問姓名、出生日期等作為可選，但更多的應(yīng)用會選擇延遲到用戶 自己想要設(shè)置個人信息時給出選擇。如果你要說哪個更合適？這恐怕就取決于設(shè)計師對產(chǎn)品功能、性質(zhì)的判斷，對公司在公眾心中信任程度的信心，當(dāng)然也是和其它 各部門交流后，得以決定問題的“合適情境”了。社交類網(wǎng)站從其功能性質(zhì)來說在注冊時詢問姓名、出生日期或許可以接受，但例如簡單的todo list、在線筆記這種個人應(yīng)用，可能就沒有必要在注冊時詢問姓名、出生日期之類信息了。

問題的安排：Form的交互過程如前面對其性質(zhì)的討論，如同一場對話，需要好的邏輯性，否則，有句成語大概可以形容：語無倫次，所以 問題在安排上需要有邏輯性。對于篇幅長的Form，適當(dāng)?shù)姆纸M、分頁有助于邏輯連貫性的表達(dá)，就好像對話從一個話題轉(zhuǎn)移到相關(guān)聯(lián)的下一個話題。雖然做交互 設(shè)計說明你很可能是一個邏輯思維很強的人，但利用用戶測試、以及與小組其它成員、同行的交流以理解各個問題之間的聯(lián)系來輔助自己的設(shè)計或許是更好的保證。

問題的用語（wording）：特別是如果設(shè)計網(wǎng)上問卷調(diào)查之類，問題的提問方式與用語很可能極大的影響數(shù)據(jù)收集的可信度。設(shè)計者與有心理學(xué)、社會學(xué)背景的小組成員交流合作會是一個好的選擇。

Caroline對問題的答案類型有一個分類，我認(rèn)為值得借鑒：

• Slot-in：指的是例如姓名、性別、出生地等大腦里固有的信息；
• Gathered：用戶需要自己搜集的信息，例如錢包里某張名片上的名字、電郵，電腦上某篇文章的段落等；
• Third-party：第三方信息來源，是用戶需要從其他人那里得到的信息，例如給對方匯錢時先詢問對方的帳號；
• Created：用戶在看到問題時才“創(chuàng)造”出的答案。

這里沒有嚴(yán)格的區(qū)分，問題是因人、因情況而異。例如密碼、昵稱，很可能用戶有自己固有的選擇，但如果因為安全性、重復(fù)等原因被要求提供不一樣的選擇，那么用戶可能就只好走“創(chuàng)作型”道路了。（我再險惡一些，如果用戶不幸遭遇嚴(yán)重腦損傷，忘了自己姓甚名誰…）

問題是，這樣的區(qū)分意義何在？我的答案是，幫助我們在構(gòu)建Form時更有邏輯性、有根據(jù)的思考：

綜合起來：

1. 不要把自己想出的問題當(dāng)作理所當(dāng)然，一股腦的全放到Form上拋給用戶；
2. 無論是問題本身還是相互間的關(guān)系都需要有邏輯性；
3. 什么樣的問題如何去問？需要為用戶提供怎樣的支持？我們需要認(rèn)真思考，也需要用戶的反饋。

Form Layout對用戶掃描的影響

Luke的書里有很多Eye Tracking實驗的結(jié)果。關(guān)于Label的上對齊、左對齊、右對齊，提交按鈕的位置等都有相應(yīng)的“最佳實踐”（Best Practices），我不在這里一一列出，否則出版社又該和我急了。這里把Luke和Caroline的結(jié)論結(jié)合在一起，做一個簡單的小結(jié)，“劇透”無 罪！

稍微偏題一點，對于Eye Tracking能在多大程度上幫助我們理解用戶，這個很難說，至少我還不敢下任何結(jié)論。一位HCI教授曾經(jīng)跟我說的是：what they look at, may not be what they think of。這是一位常年用Eye Tracking分析玩家玩視頻游戲的教授（對，沒錯，研究玩游戲的教授…好吧，我在誤導(dǎo)你，實際是通過游戲研究人對事物的“沉浸”現(xiàn)象），所以，在能有機會證實Eye Tracking的作用前，我的觀點依然還是Usability Testing,，field observation等來衡量用戶的使用，Eye Tracking作為輔助。

好了，拋開Eye Tracking，小結(jié)一下Form Layout的作用（下一篇文章或許能更好的闡釋這一部分的內(nèi)容）

上對齊：掃描軌跡標(biāo)準(zhǔn)的垂直向下，所以理論上最快，但垂直占用空間大，不適合問題較多的Form，但對問題長度變化的適應(yīng)性好。

右對齊：掃描軌跡也是基本垂直向下，所以理論上也很快，垂直占用空間小，對問題長度變化的適應(yīng)性較差。但如果出現(xiàn)用戶需要瀏覽所有問題時，速度下降。

左對齊：掃描軌跡水平上更多更長，所以較慢，垂直占用空間小，對問題長度變化的適應(yīng)性較差。但如果出現(xiàn)用戶瀏覽所有問題，速度不會受到影響。

何時用何種對齊方式？

• 上對齊：問題較少，問題長度可能發(fā)生較大變化（如多語言），希望用戶迅速完成。如果你的問題全部屬于slot-in類型，且數(shù)量少，我認(rèn)為這種方式基本是首選；
• 右對齊：類似上對齊，但適合問題較多的Form；
• 左對齊：出現(xiàn)大量用戶不熟悉的問題，希望用戶花時間思考這些問題；
• 其它：也有將問題內(nèi)置于輸入框內(nèi)，以節(jié)省水平空間需要，但隨著輸入框成為焦點，問題會消失。用戶可能出現(xiàn)走神或有認(rèn)知能力上的障礙而遺忘問題的情 況，此時問題的消失對用戶來說就是災(zāi)難。我的建議還是盡量避免這種設(shè)計（好吧，CSSKarma給了一個非常奇怪的解決方法，有興趣的話，你可以看看這個Demo）。

幫助、錯誤提示和肯定信息

我想有了Caroline對問題類型的分類，應(yīng)該有很好的依據(jù)決定什么問題需要怎樣的幫助信息了，需要強調(diào)的是，幫助信息不僅要告訴用戶如何填寫，對于隱私數(shù)據(jù)也需要告知為何填寫，和相關(guān)的保護承諾（法律上的）。

大段幫助信息集中在一起不是個好主意，因為我們很容易瞥一眼后迅速跳到第一個輸入框去，在網(wǎng)上，“耐心”是個稀罕物，無論是動態(tài)還是靜態(tài)，針對情境的幫助都比懶惰的將大段幫助丟在一堆好得多。

星號（*）基本是默認(rèn)的“必填”代號，但放在什么位置卻有很多方式，Caroline的書中提到Eye Track顯示用戶很少會注意到輸入域右端，而集中在輸入域左端，所以，如果你需要標(biāo)注（*），label和Input之間或許是最好的選擇，其次是 Label的左端，最后是輸入域的右端：

對于星號，我的疑問是Screen Reader無法告知用戶它的含義是”必填“，SitePoint的書中提供一種解決方案是：

<label for=”username”>Username

<abbr title=”Required Field”>*</abbr>

</label>

<input id=”uname” type=”text” name=”uname” value=””/>

如何呈現(xiàn)相關(guān)信息？我的想法是盡量避免內(nèi)置于輸入框的幫助，讓相應(yīng)問題與幫助信息在視覺上有明確清晰而簡單的聯(lián)系就好，做設(shè)計要提醒自己多做減法。

之所以說錯誤提示信息，是因為有些網(wǎng)站只告訴你出錯，不給你提示，當(dāng)然如果丟給你一句“系統(tǒng)錯誤”就找不到北了。

有一種情況我很反感的是在你輸入過程中檢測錯誤，從你開始輸入時就看到一個紅紅的叉放在那里，告訴你：“你錯了！”，然后不停的說下去，直到你對了。 就好像一個人不停的罵你：笨蛋，笨蛋，笨蛋…直到最后，它說：天哪，你這笨蛋終于碰對了。而實際上你非常清楚自己輸入的沒錯。

任何交互模式都要看具體的應(yīng)用場景，同樣的情況。作為程序員，無論是后端的PHP，Python，RoR，Java，還是前端的HTML，CSS，JavaScript，都習(xí)慣“inside out”視角：我能做到這么酷的功能，用戶一邊輸入，我一邊檢查，不拿給用戶顯擺一下簡直浪費；可作為設(shè)計者，需要“outside in”，再酷的東西，用在不合時宜的地方，那我也只能打110告你“擾民”了。交互的模式網(wǎng)上的收集、總結(jié)有很多，但只有真正理解用戶、功能和場景，才能把最合適的模式用在最恰當(dāng)?shù)牡胤健?/p>

除了錯誤提示，還有肯定信息，或者叫成功信息。作為程序員可能很少考慮“肯定”：你本來就該正確，我干嘛要肯定你？很多網(wǎng)站在注冊時都會在輸入域失 去焦點后檢查你的輸入，如果符合網(wǎng)站對答案的要求，會在輸入域右側(cè)或下方顯示一個正確的符號。這實在是很貼心的功能，對用戶每一個問題所作出的努力都是一 種肯定的鼓勵。我的思考是，即使是出錯提示信息，是否也能適當(dāng)?shù)膶τ脩舻呐M行鼓勵，而不是單方面感受到的沮喪呢？舉個例子，唯一用戶名，如果用戶不幸 選擇了重復(fù)的用戶名，錯誤提示是否能夠在提示時肯定用戶的選擇：雖然該用戶名被注冊，但確實很“獨特”，很“酷”，而我們建議一些同樣很“獨特”，很 “酷”的用戶名（當(dāng)然，這需要你確實能生成比較“獨特”的用戶名）。

提交按鈕

提交按鈕的放置，Luke給了唯一而明確的建議，和輸入框（左端）對齊（可參見上面的三幅Eye Tracking例圖）。

至于次級按鈕，例如重置，如果確實需要，如Luke所建議，最好有機制能夠讓用戶“撤銷（undo）”重置的操作。

分頁Form的流程設(shè)計和干擾因素：

前面提到分頁的邏輯性是好的交互設(shè)計的基礎(chǔ)，就好像從一個話題轉(zhuǎn)向另一個相關(guān)話題，不會讓人覺得唐突而產(chǎn)生疑惑。這個過程中將其它無關(guān)鏈接、視覺元 素甚至整個網(wǎng)站導(dǎo)航從Form所在頁面去除是很多注冊、支付流程采取的策略，例如Amazon，對于這樣的網(wǎng)站，這些關(guān)鍵流程的完成程度最大化是網(wǎng)站成敗 的關(guān)鍵，而只保留Form相關(guān)元素似乎是得到了Amazon實踐認(rèn)可的成功策略。

涉及到分頁，那么請從一開始就告訴用戶要經(jīng)歷哪些步驟，多長時間，并在每一步告知這一步的內(nèi)容和在總體進展中的位置（一個反面的例子將在下面一篇文章提到），如果你不能肯定主要步驟中會有分支可選步驟出現(xiàn)，那么就不要一步步的數(shù)出來，告訴用戶他們在哪個階段就足夠了。

個人化：

個人化（Personalization）即根據(jù)用戶個人偏好和使用狀況，自動完成Form的部分內(nèi)容填寫（所謂Smart Default），比如Amazon會自動把你最常用的信用卡作為購物的支付方式，但同時也保留了讓你選擇其它信用卡的Form；很多網(wǎng)站根據(jù)用戶IP自 動填寫地理信息等。

個人化確實在多數(shù)時候方便的了用戶，但依然需要考慮保留用戶選擇的權(quán)利。設(shè)置默認(rèn)選項時請多考慮一秒鐘，特別是select類型的輸入域，作為程序 員為了避免用戶漏選，習(xí)慣設(shè)置一個默認(rèn)選項，可如果你沒有把握填寫Form的用戶絕大多數(shù)會選擇某一選項，那么最好還是留給用戶自己選擇（下一篇文章會有 具體的討論）。

Accessibility

Accessibility是最被忽略的設(shè)計因素，不過很可惜，我的導(dǎo)師是這個領(lǐng)域的專家，不把這方面拉出來溜一圈總覺得不好意思，所以雖然知道很多設(shè)計者基本無視這一方面的存在，認(rèn)為他們的工作不涉及這一方面，我還是要多說一點。

英國和美國有專門法案（Disability Discrimination Act 1995 UK,?Section 508 US）， 規(guī)定政府、社會組織等的網(wǎng)站必須提供Accessibility支持，這是社會無歧視的重要一方面。如果社會中的一群人無法像其他人一樣自由無限制的獲取 公共信息、使用互聯(lián)網(wǎng)服務(wù)，那么就構(gòu)成歧視。特別是現(xiàn)在很多國家開始考慮，甚至已經(jīng)將互聯(lián)網(wǎng)、信息的自由獲取作為人權(quán)，那么或許有一天這不僅再是歧視，而 是赤裸裸的侵犯人權(quán)的問題了（為了讓你印象深刻，首先要嚇到你不是）。

在讀HCI時，另一句對我影響很大的語句是：“為Accessibility設(shè)計就是為幾十年后的自己設(shè)計”?；蛟S我們都幸運的沒有在任何方面出現(xiàn) 生理機能上或認(rèn)知能力上的缺陷，你也壓根不想與殘疾人這個社會群體有聯(lián)系，但我們有一天都會變老，步入老年后，人的感官功能和認(rèn)知能力都會大幅下降，無論 是聽覺、視覺、觸覺，還是行動能力、認(rèn)知能力上都會出現(xiàn)問題（更多請參考Web Accessibility for Older Users）：

• 色彩辨析和敏感度：難以辨析深藍(lán)與黑色，相對藍(lán)色與綠色，老年人對紅色和黃色更容易辨識；
• 瞳孔縮?。菏估夏耆诵枰蟮牧炼龋瑢α炼雀淖兊倪m應(yīng)能力也隨之下降。60歲老人年的視網(wǎng)膜對光的接收只有20歲年輕人的40%，而到了80歲則迅速下降到15%；
• 對比敏感度：從40歲開始，在較高空間頻率上的對比敏感度開始下降，直到80歲時，只有原來的15%。

如果我們希望幾十年后的自己還能有質(zhì)量的享有各方面的信息和服務(wù)，那么我們最好能從現(xiàn)在開始讓更多的產(chǎn)品，更多的設(shè)計師意識到Accessibility的重要，并為此做出一些努力。

Form的Accessibility是個很有爭議的話題，很多建議也是自相矛盾，例如Luke建議在Web Form中為鍵盤用戶使用tabindex屬性，而sitepoint的書中認(rèn)為這沒有必要，合理安排元素在HTML中的位置就能保證Tab的順序。就這 一點我的想法與SitePoint類似，良好的HTML結(jié)構(gòu)和語義構(gòu)造是Accessibility的根本（說到語義，HTML5在我看來最大的貢獻就是 對這方面的強化）。accessKey屬性也有類似的境遇，總的來說，除非你的Form足夠復(fù)雜且被用戶反復(fù)使用，否則，我不會考慮遵循Luke的建議， 去為Form添加快捷鍵。

Ajax技術(shù)的大規(guī)模應(yīng)用是讓Accessibility非常頭疼的事情，舉個簡單的例子，如果一個頁面的內(nèi)容動態(tài)更新了，我們?nèi)庋劭梢钥吹剑玈creen Reader要如何知道更新發(fā)生了，而重新閱讀頁面的相關(guān)部分？W3C專門提出了標(biāo)準(zhǔn)試圖緩解類似這樣的問題：WAI-ARIA，如果你對這方面有興趣，可以參考Opera開發(fā)社區(qū)的文章：Introduction to WAI ARIA，讀起來自然比W3C的標(biāo)準(zhǔn)有樂趣點。

說到這里，舉個我在學(xué)習(xí)HCI時反復(fù)聽到的例子，一個典型的在HTML文檔里加強Accessibility的舉措是為每個

當(dāng)然，要保證Accessibility，最重要的依然是用戶測試。你可能拿著一本關(guān)于Accessibility的書把網(wǎng)站全部改造一遍，給每 個加上一個詳細(xì)的alt，但這能保證使用Screen Reader的用戶順利的使用你的網(wǎng)站嗎？想想上一段談到的問題。最后只有真正的用戶才能評價你的網(wǎng)站是否滿足他們的需求，所以，還是別忘了用戶測試！

你自己可以做一些類似的測試，對，我沒開玩笑，這是我自己嘗試過的方法。如果你使用Ubuntu，那么Orca Screen Reader很 有可能已經(jīng)在你的機器上。打開它，然后打開你要測試的頁面，閉上眼，或者找你老婆或女友要條絲襪蒙上眼，看看你能否通過Screen Reader順利的理解頁面，找到目標(biāo)鏈接？還是像沒頭蒼蠅般在Screen Reader的指導(dǎo)下亂飛（如果你不知道Screen Reader的某些工作機制有多奇怪，可以參考SitePoint那本書中關(guān)于legend和fieldset這兩個元素的討論）？這時或許你就會稍許理 解生理機能上有障礙的用戶在生活上有多不便了，我們應(yīng)該在尊重他們堅毅和努力的前提下，幫助他們做得更多。

最后，作為文章的結(jié)束，提供一點擴展資源供參考：

• Luke自己關(guān)于Form Design的一篇文章：Web Application Form Design
• noupe依然非常耐心翔實的匯總了各種資源告訴你如何設(shè)計絕色Form：Beautiful Forms – Design, Style & make it work with PHP & Ajax
• Dey Alexander Consulting公司提供的關(guān)于Form Design的匯總：Form Design
• W3C關(guān)于HTML 5中Form元素的標(biāo)準(zhǔn)：4.10 Forms – HTML 5
• 在線電子書Dive into HTML 5（推薦此書）關(guān)于Form的一章：A Form of Madness – Dive into HTML5

源地址：http://arslanyard.blogbus……74135020.html