TAT.Kinvix 如何開發無障礙的 Web 網頁應用詳細手冊教程指南
In 未分類 on 2012年10月19日 by view: 26,858
3

Web 無障礙設計(Accessibility in Web design,也叫網站可及性?)是要讓所創建的網站對所有用戶都可用/可訪問,不管用戶的生理/身體能力如何、不管用戶是以何種方式訪問網站。

 

為什么無障礙如此重要(幫助殘障人士)

為什么不是所有網站都能無障礙訪問?你可能也會問自己為什么存在 “無障礙” 的問題,為什么不是所有網站都能讓所有用戶無障礙訪問?要進行無障礙設計有許多不同原因,其中包括殘疾人用戶的需求、不同的人訪問和使用互聯網的不同途徑和方式。

視障用戶

視障用戶包括色盲用戶、完全失明用戶(盲人)。如果圖片不帶有相關文字描述,則視障用戶在理解圖片方面會存在問題。如果圖片沒有文字描述,看不見圖片的盲人用戶就無法知道圖片表達的是什么。色盲用戶在識別設計元素(包括文字)方面也會存在問題,因為色盲用戶所能識別的色彩不足以辨別所有的設計元素(包括背景色和頁面顏色)。

所開發的網站,如果沒有考慮到適應于屏幕發音閱讀器(讀屏軟件, 如 JAWS)或 “非可視” 瀏覽器(或叫聲音瀏覽器、讀屏瀏覽器,如 MozBraille)。讀屏瀏覽器是一個可以發音閱讀出網站的瀏覽器,幫助有視覺障礙的用戶訪問網站。一個在可視瀏覽器(如 IE)上看起來良好的網站,在讀屏瀏覽器下可能聽起來非常糟糕。

聽障用戶

聽障用戶在聽覺上存在問題。用聲音傳達的信息無法被聽障用戶所理解,簡單解決方法是提供另外途徑的信息傳達方式,而不僅僅是聲音,例如用文字描述、用圖片。

殘障用戶(肢體傷殘的用戶)

如果你不是殘障用戶,你無法想象他們(殘疾人)的網絡體驗。例如,你曾經試過不使用鼠標去訪問網站嗎?除非你很幸運的遇到一個無障礙訪問良好的網站,否則你肯定覺得非常困難。殘障用戶經常無法使用鼠標,除非創建網站的導航和輸入方式的需求中就考慮殘障人士的需求,否則殘障人士可能完全無法使用你的網站。

認知和神經障礙用戶

網站往往比較復雜,要想找到我們所想要的信息經常不太容易。如果網站設計的過于復雜、導航不一致、存在讓人分心(抓狂)的重復性動畫,情況會更加糟糕。這些設計元素會導致認知和神經有障礙的用戶的使用問題,甚至會讓這些用戶完全無法使用網站。

 

殘障人士之外(所有用戶都能受益)

前面我們知道如果我們存在某方面殘障,使用互聯網是件困難的事情。然后,web 無障礙訪問不僅僅幫助到殘障人士,良好理解和遵循 Web 無障礙設計,可以讓所有用戶都受益、更好的服務用戶。

Web 無障礙設計還可以讓通過以下方式使用你的網站的用戶受益:

  • 使用移動手機、Web-TV 和信息崗亭的用戶
  • 低帶寬的用戶
  • 在吵雜環境下使用網站的用戶
  • 容易被 “屏幕眩光” 傷到眼睛的用戶
  • 開車時的用戶
  • 低文化水平的用戶
  • 第二語言訪問的用戶(國外用戶)
  • 不同學習方式和習慣的用戶

處理好 Web 無障礙訪問問題也可以改善:

  • 頁面傳輸和網站維護
  • 內容索引
  • 內容搜索

市場機會

讓你的網站具有可及性還有其它原因。根據目前數據,在許多國家殘疾人用戶占到人口的 10%~20%,如果能吸收前面提到的殘障人士成為你的網站的用戶,可以提高你網站的市場占有率。

許多國家的老齡化人口都在增加,年齡的增大會帶來更多的無障礙訪問問題,包括視覺障礙、聽覺障礙、記憶力下降等。如果你的網站能吸收老年人用戶,也會大大提升你網站的市場占有率。

所以,無障礙訪問是可以直接帶來經濟效益的。

無障礙 Web 標準

Web 無障礙指南(WCAG)2.0 定義了如何使殘疾人士更方便地使用 Web 內容的方法。無障礙涉及廣泛的殘疾癥狀,包括視覺,聽覺,身體,語言,認知,語言,學習以及神經殘疾。盡管這些指南內容廣泛,但它無法有效地滿足所有類型的人群和殘疾程度的人的需要。這些指南也適合老年人上網,還可讓普通用戶更好的使用。
WCAG 2.0 文檔旨在滿足需要穩定的,可參考的技術標準的人群。被稱為支持文檔的其他文檔以 WCAG 2.0 文檔為基礎,可用于其他重要的用途,包括可進行更新的能力,以說明如何將 WCAG 用于新技術的應用。支持文檔包括:

  1. 如何符合 WCAG 2.0?- WCAG 2.0 的可定制的快速參考,包括所有的指南、成功標準以及作者正在開發和評估網頁內容時可用到的技巧。
  2. 理解 WCAG 2.0?- 理解和實施 WCAG 2.0 的指南。對于 WCAG 2.0 的每一個準則和成功標準,這些主要議題都有一個簡短的 “理解” 文檔。
  3. WCAG 2.0 技巧?- -技術和常見失敗集,對于每個技巧和常見失敗,另附一份文檔,其中包括描述,例子,代碼和測試。
  4. WCAG 2.0 文檔?- 對于如何關聯和鏈接技術文檔,給出 圖示和說明。

參見?Web 內容無障礙指南(WCAG)概述?里關于 WCAG 2.0 支持材料的描述,包括 WCAG 2.0 相關的教育資源。附加資源包括了以下主題,Web 無障礙商業案例,改善網站無障礙的規劃實施,和無障礙政策。

 

開發無障礙可訪問的 Web 網頁應用

開發和測試可訪問的 Web 應用主要的有以下幾個步驟:

  • Webking 進行靜態檢查,通常由開發人員在單元測試時進行,檢查 HTML 頁面中不滿足 CI162 所對應列表的項。目前由于 WebKing 不支持 ARIA,很多 ARIA 的標簽不能被正確的識別,所以 WebKing 檢查出的錯誤需要一一去檢查區別是真正的違反 Checklist 還是由于 WebKing 不能識別 ARIA 的標簽引起的。
  • 鍵盤支持,要求所有能通過鼠標完成的操作用鍵盤都能達到同樣的效果。
  • 高對比度的支持:在高對比度模式下,屏幕只有黑白兩色,要保證 Web 應用在這種模式下不丟失信息。
  • 讀屏軟件的支持,通常由測試人員完成。測試人員模擬盲人使用讀屏軟件,要保證頁面上的內容基本都能為讀屏軟件所識別,并且能完成各種操作。

 

頁面頭部必須包含的內容

為了保證頁面的無障礙訪問,首先需要在頁面的頭部加上 DTD 的聲明以及頁面默認的語言。清單 1 列出了如何在 HTML 頁面中加入 DTD 聲明及默認語言屬性,清單 2 列出了如何在 XHTML 頁面中加入 DTD 聲明及默認語言屬性。

清單 1. HTML 頁面中加入 DTD 聲明及默認語言屬性

清單 2. XML 頁面中加入 DTD 聲明及默認語言屬性

 

此外,頁面的 title 屬性值也是必須的,如清單 3 所示。

清單 3. 設置 title 屬性

 

關于 Image

1. 圖片或者動畫均需提供 Alt 信息,使得讀屏軟件可以將圖片動畫的內容清楚的讀出來。如圖 4 所示:

圖 4.Cat 圖片
Image

對應的 HTML 如下:

清單 1. Image 的 HTML

 

2. 對于某些用于裝飾性的圖片,則需設置 alt 為空,使得讀屏軟件可以忽略此元素。如圖 5 的用于裝飾頁頭的圖片,實際并沒有傳遞有價值的信息。

圖 5. 裝飾性圖片
Image

對應的 HTML 如下:

清單 2. 裝飾性 Image 的 HTML

 

必須設置一個空 alt 屬性的目的是為了能通過 Webking 的檢查,并且使得讀屏軟件能夠忽略此元素。

3. 對于圖表文件,alt 屬性的設置則需要簡明扼要的表達出圖表的信息,并不用把里面的細節都詳細得描述出來。例如下面的圖 6:alt 信息設置為銷售額從 1996 年到 2004 年間持續穩定增長,從 400 萬增長到了 1600 萬。并不需要把每一年的增長額都詳細得描述出來。

圖 6. Image 圖表
Image

4. 對于放在鏈接里面的圖片,如果已經有文字的說明,alt 也設置為空,這樣避免讀屏軟件重復同樣的內容。如下面的 HTML:

清單 3. 無需重復設置 alt 的 Image

 

A 的內容已經指明了這是個蘋果手機,IMG 的 alt 屬性就沒必要再設置一次了。否則讀屏軟件會連續讀兩次重復的內容,引起混亂。

5.CSS 將樣式跟結構分離,使得 HTML 代碼結構清晰。很多裝飾性的圖片也都放在 CSS 里面來加載,帶來的一個問題就是在 CSS 里面的圖片在高對比度模式下都無法顯示。如果這個圖片并不僅僅是裝飾性的,還可以觸發功能,那就需要從 CSS 里面拿出來,當成一個獨立的 IMG 或者 INPUT 元素。例如下面的一個提示保存的圖片

圖 7. 保存圖片
Image

寫在 CSS 里面的做法是:

清單 4. 圖片寫在 CSS 里面

 

這樣當用戶切換到高對比度模式,這個圖片就是一片空白,用戶無法再去點擊保存。修改如下:

清單 5. 將 CSS 里面的圖片拿出來

 

6. 在一個圖片列表里面選中某個圖片,區別選中去否我們通常的做法是用邊框的顏色來標識。如下圖,選中的圖片邊框為藍色

圖 8. 圖片被選中的正常效果圖
Image

清單 6. 圖片被選中時對應的 CSS

 

但這樣的一個實現實際上違反了可訪問檢查列表中的一項:不能僅僅通過顏色來區分不同的元素,因為在高對比度下只有黑色或白色,這樣的區分在高對比度下是沒有任何作用的。我們很容易想到的一種辦法就是只有選中的時候才加邊框,未選中時則沒有邊框,這樣就可以區分出來了。修改如下:

清單 7. 圖片被選中時修改后的 CSS

 

這樣引起的問題是,圖片的布局在選中的時候會浮動,增加了 5px 的邊框,看起來效果就很差。那么怎么保證布局又滿足可訪問性的要求呢? 可以在上面 CSS 的基礎上通過 padding 屬性使得布局正確:

清單 8. 圖片被選中時正確的 CSS

 

這樣保證整體的邊界都是 5px,在高對比度下的效果如圖 9 所示:

圖 9. 圖片被選中時的高對比度效果圖
Image

關于 Table

Table 分為兩類:一類是做布局的 table,一類是數據 table。對于布局用的 table,讀屏軟件沒必要知道這是一個表,可以通過設置 role=presentation 使 JAWS 忽略這個表,只關注里面的內容。對于數據表格,則需要設置 caption 屬性,說明整個表是用來做什么的,使得 JAWS 可以告訴用戶這個表的作用。對于每一個單元內的數據,還應該通過 th 屬性使得 JAWS 能識別這個數據的表頭是什么。對于復雜表,可以通過 id 和 header 屬性來標識。如圖 10 所示 :

圖 10. 數據圖表
Image

以第一行的數字 5 為例,正常人可以很容易得看出 5 指的是一年級 Mr.Henry 老師這個班的男生有 5 個,但當 JAWS 面對這個數字 5 的時候,怎么能識別出來呢?通過 header 來標識表頭,header 的值就指向對應表頭的 id。對應的 HTML 如下:

清單 9. 數據圖表

 

關于 Form

Form 元素需要關聯一個 label 元素,所有的 button 都已經有了一個隱含的 label,所以不再需要顯示關聯。對于 Input,Select, Checkbox, Radio button 則都需要顯示一個 label 元素。這樣 JAWS 在面對這個表單元素的時候才能告訴用戶這個表單的作用。例如下面清單 10 中的 input, JAWS 會告訴用戶這個是需要輸入名字的一個輸入框。當 label 屬性不方便使用的時候,還可以通過 title 屬性達到相同的效果,也可以滿足 Webking 檢查的需要。清單 10 中的兩種寫法都可以。但前提是 Name 不需要被顯示出來。當 title 和 label 都設置的時候 title 會被 JAWS 忽略。

清單 10. Form 元素示例

 

當一個表單元素如果前后都需要描述的時候, label 就顯得力不從心了。ARIA 規范的出現解決了這一問題。aria-labelledby 屬性可以設置多個值,說明這個表單元素是被那些值所描述的, aria-describedby 屬性則更詳細的擴展了這個描述。如圖 11 所示:

圖 11. 需要多個 Label 描述的輸入框
Image

當 JAWS 把焦點放在 10 上的時候,會告訴用戶 10 表示的是 10 分鐘刷新一次。對應的 HTML 代碼如清單 11 所示。aria-required 的屬性標識這個元素是必須的,JAWS 識別此元素并告知用戶必須輸入此元素。我們可以看到中間的 input 元素被多個元素來描述(aria-labelledby 中的幾個 id 值),這樣 JAWS 就能夠識別這個標簽,并且按照這個標簽的順序讀出前后的 label, 并且提示用戶如果還有更詳細的描述以及如何獲取這個更詳細的描述。當用戶需要時,aria-describedby 所對應的元素信息就會被讀出來。增強了視力有障礙人士與普通人了解內容的一致性。

清單 11. 需要多個 Label 描述的輸入框

 

關于 Tabindex 與獲取焦點的順序

Tabindex 屬性的使用可以使得原本無法取得焦點的元素獲取焦點。目的是為了使用戶可以用鍵盤訪問任何可以用鼠標訪問的元素。我們知道,使用 Tab 鍵可以按文檔順序 tab 到所有可以獲取焦點的元素。Tabindex 可以設置為 -1, 0 或者是任何自然數。

  • Tabindex = 0 就使原本無法獲取焦點的元素可以在用戶 tab 的時候獲取焦點,并且按照文檔順序排列。
  • Tabindex = -1 使得元素可以獲取焦點,但當用戶用 tab 鍵訪問的時候并不出現在 tab 的列表里面??梢苑奖愕耐ㄟ^ Javascript 設置上下左右鍵的響應事件。非常有利于應用小部件(widget)內部的鍵盤訪問。
  • Tabindex 設置為大于 0 的數字則可以控制用戶 Tab 時候的順序,一般很少用。

當用戶使用 Tab 鍵瀏覽頁面時,元素獲取焦點的順序是按照 HTML 代碼里面元素出現的順序排列的,有時跟實際看到的頁面順序并不一致。例如圖 12 所示的頁面:

圖 12. 圖片被選中時的高對比度效果圖
Image

按照頁面順序,tab 的順序為自左向右,可實際上操作的時候卻發現 “search all” 出現在了 “go to edit” 的前面。對應的 HTML 代碼如清單 12 所示:

清單 12. 頁面獲取 focus 的順序

 

原來是通過 float:right 達到了布局上的效果,實際文檔順序確實是 search all 在前面的。所以為了不引起混淆,最后能保持代碼的順序與實際呈現出來的頁面上的順序一致??梢孕薷纳厦娴拇a為清單 13 所示:

清單 13. 頁面獲取 focus 的順序 -- 調整后

 

關于隱藏的內容

隱藏的內容分為兩種,一種是為了布局的需要,在條件滿足的情況下才會顯示出來;另一種是只給讀屏軟件讀的內容:有時候我們為了使讀屏軟件更準確的讀取信息,會提供一些額外的描述來達到此效果,但為了不給正常用戶帶來困擾,這些內容對正常用戶來說是隱藏起來的。隱藏內容我們通常用 display:none 或者 visibility:hidden 來表示,但讀屏軟件同樣也會忽略這類內容。那如何隱藏內容又能使讀屏軟件讀出來呢?另外一種隱藏內容的方式是使用絕對定位使得內容不出現在當前屏幕上,如:{position:absolute;top:-30000px;} 所以在選擇使用哪種方式隱藏內容時就需要慎重考慮,display:none visibility:hidden 對任何人都是隱藏的,如果想只給讀屏軟件讀到就需要使用上面的絕對定位方式。例如在圖 13 所示的菜單的選中項上加上如下的 css:
清單 14. 只給讀屏軟件讀的內容

圖 13. 菜單
Image

這樣當用戶使用 JAWS 瀏覽每一個菜單項時,在選中項上就能聽到哪一項是當前的所選中。

高對比度模式的小技巧

系統切換到高對比度模式,只有黑白兩色,很多在正常模式下依靠顏色來區分的(如界面邊界)都無法辨識了,寫在 CSS 里面的很多圖片也都無法顯示出來。此時就需要在高對比度下增加邊界或者另外 DOM 節點來顯示同樣的內容。Dojo 的 WAIState Api 提供了一種方式來判斷系統是否處于高對比模式,如果是則在 body 上增加 dijit_a11y 的一個 CSS。這樣可以在正常模式下顯示一個 DOM 節點在高對比度下顯示另外一個 DOM 節點,從而方便的區分。如圖 14 所展示的正常模式與高對比模式下的對比:

圖 14. 高對比模式與正常模式的對比
Image

正常模式下如左圖所示,子菜單通過一個圖片標識,但這個圖片是在 CSS 里面設置的,切換到高對比度模式即無法顯示出來。此時,我們增加一個在高對比度模式下才顯示出來的節點,達到如圖右所示的效果,在高對比度下顯示一個 + 號。代碼清單如清單 15 所示,在高對比模式下,dijit_a11y 加在 body 上,dijitMenuExpandA11y 所對應的 DOM 即應用右面的 CSS 得以顯示出來。

清單 15. 正常模式與高對比模式顯示不同的 Dom 節點

 

快速鏈接到主要內容

為了使屏幕閱讀器可以略過頁面中的一些普通元素快速跳到頁面的功能區域,開發人員需要在頁面中添加一些鏈接。在下面的頁面中,主要內容即為左側的導航欄,用戶可以通過點擊導航欄中的鏈接打開相應的頁面。清單 4 和清單 5 列出的代碼可以幫助有視力障礙的用戶快速定位到導航欄。
圖 1. 示例頁面
圖 1. 示例頁面

清單 4. HTML 代碼片段

清單 5. CSS 代碼片段

 

無障礙訪問的表單控件

  • 標簽控件與標題屬性

在 Web 頁面中經常會用到表單進行信息的錄入與更新。大部分的表單控件可以自動與一個標簽控件建立關聯,使得屏幕閱讀器可以將標簽中的文字內容作為表單錄入控件的說明信息,比如提交按鈕。但是諸如文本框,下拉菜單,復選框以及單選按鈕這樣的控件則需要開發人員為其指定一個標簽控件,同時設置標簽控件的 for 屬性值為與其建立關聯的控件的 id 屬性值。清單 6 與清單 7 分別列舉了如何為文本框與下拉列表添加與其關聯的標簽控件。

清單 6. 為文本框的標簽控件設置 for 屬性

清單 7. 為下拉列表的標簽控件設置 for 屬性

 

然而并不是所有的表單控件都適合采用上述方式添加標簽以保證其可讀性,單選按鈕通常是一組按鈕具有同一個 id 屬性值,所以我們無法通過上述方法為每一個按鈕添加標簽,我們可以利用 title 屬性來保證其可讀性。例如:

清單 8. 為復選框設置 title 屬性

 

提示:無需為隱藏控件添加與其關聯的標簽控件。

  • 必輸字段

為了使得屏幕閱讀器可以將必須輸入的字段限制信息傳達給用戶,開發人員可以使用 WAI-ARIA 提供的屬性,示例如下:
清單 9. 設置屬性限制字段必須輸入

 

但是目前 IE8 還不支持這種屬性,由于屏幕閱讀器可以讀出用于錄入信息的表單控件的 title 屬性,所以我們可以將限制信息寫在 title 中。如清單 10 所示:
清單 10. 利用 title 屬性標識字段為必輸項

 

可 “讀” 的圖片

隨著 Web 頁面的友好性不斷提高,圖片的使用也越來越廣泛。然而對于無法親眼看到頁面的用戶需要借助屏幕閱讀器才能夠知曉當前閱讀的內容是一張圖片以及該圖片的作用,對于頁面中所有有意義的圖片,尤其是一些動態的圖片,比如鏈接或是按鈕,開發人員必須要給出其 alt 屬性值。如清單 11 所示:
清單 11. 為圖片設置 alt 屬性

 

提示:請盡量避免使用圖片作為背景,如果需要,請在 CSS 文件中指定。

創建無障礙訪問的數據表格

在 Web 頁面中通常有兩種用途的表格,一種用于頁面布局,另外一種用于顯示數據。

數據表格需要用 <th> 指定行或列的標題行,同時還需要顯式地指定 summary 屬性值,使得屏幕閱讀器可以讀出表的主要用途。如清單 12 所示:
清單 12. 數據表格

 

布局表格的用途是為了頁面布局美觀而使用的,所以在其定義中不應該包含行或列標題行,同時設定 summary 的屬性值為空。布局表格對于屏幕閱讀器應該是透明的。通常情況下,如果表格有至少兩行兩列四個單元格,同時其大小在 200 到 16000 平方像素之間,在 JAWS 中會默認為是數據表。所以如果一個表格是為布局而設置的,請避免為其指定 summary 屬性值。有些屏幕閱讀器偶爾會混淆數據表格與布局表格,為了避免混淆我們可以指定 WAI-ARIA 的 role 屬性值為 presentation。如清單 13 所示:

清單 13. 設置表格的 role 屬性

 

然而并非所有的瀏覽器都支持 WAI-ARIA 屬性,這種情形下,我們可以設定表格的 datatable 屬性值為 0, 這樣 JAWS 也會將其視為布局表格。

清單 14. 設置表格的 datatable 屬性

 

Id 屬性值唯一

在 Web 頁面中必須保證每個元素的 id 屬性值在頁面中是唯一的,如果有重復 id 值,WebKing 會提示出錯。

提供必要的指導信息

頁面中隱式的添加一些必要的指導信息可以使得無法看到 Web 頁面的用戶在屏幕閱讀器的幫助下清楚的了解頁面的功能以及如何快速使用這些功能。如清單 15 所示:

清單 15. 利用 <h2> 標簽設置提示信息

 

在 Web 頁面中,為了保證表單中錄入的數據真實有效,需要對表單中的一些輸入字段加以驗證,為保證驗證生成的反饋信息可以被無障礙的訪問即屏幕閱讀器可以在表單驗證后的第一時間將反饋信息傳達給用戶,需要對頁面代碼做一些修飾。表單驗證可以分為客戶端驗證與服務器端驗證。以下將分別討論這兩種場景。

來自客戶端驗證的信息

  • Dojo 輸入域的驗證

隨著對表單控件功能性需求的不斷提高,Dojo 控件得以廣泛使用。大部分的 Dojo 控件都實現了無障礙訪問,當輸入不符合輸入字段限制的數據時,屏幕閱讀器可以快速捕捉并閱讀錯誤信息。如清單 16、17 所示:

清單 16. HTML 中加入 Dojo 輸入域

清單 17. 借助 JavaScript 實現驗證

 

在上述實例中,當輸入無效的數據時,JAWS 就會閱讀 invalidMessage 屬性值的內容。

  • 使用 WAI-ARIA 屬性實現輸入域驗證

我們可以使用 WAI-ARIA 提供的屬性使得 JAWS 可以讀出驗證消息。以下是一個應用場景示例,使用 JavaScript 將?div 的 role 屬性值設置為 alert。

清單 18. 借助 JavaScript 設置 div 的 role 屬性

 

或者,開發人員可以在 html 代碼中為用于錯誤信息顯式的元素設置 role = alert,在 JavaScript 代碼中更新錯誤信息。如清單 19、20 所示:

清單 19. HTML 代碼片段

清單 20. 在 JavaScript 中設置錯誤信息

 

當驗證后錯誤信息會顯示在頁面中指定的位置,JAWS 會立即閱讀錯誤信息,幫助用戶快速定位到不滿足輸入條件限制的輸入域。

來自服務器端驗證的信息

服務器端驗證的反饋信息與客戶端有所不同,當頁面提交經過服務器端驗證后會重新生成頁面,所以 WAI-ARIA 所提供的 role=alert 無法支持屏幕閱讀器去閱讀驗證信息。對于服務器端驗證的場景,在這里給出幾種實現方案。

  • 借助頁面標題提示信息

頁面重新加載后,JAWS 會首先閱讀頁面的標題,所以我們可以在頁面標題中加入提示信息提醒用戶當前頁面校驗存在錯誤信息。在下面的示例中,錯誤信息是在服務器端校驗后動態生成的。

清單 21. 在 <p> 中顯示錯誤信息

清單 22. 借助 JavaScript 修改頁面標題

 

  • 借助焦點定位提示信息

當頁面重新載入時,JAWS 會首先閱讀第一個獲得焦點的頁面元素。但是有些頁面元素是無法獲取焦點的,比如 <div> 和 <p>。如果錯誤信息是在 div 中顯示,我們可以通過設置 tabindex 的值為 -1 使得 div 可以在 JavaScript 中設置其獲取焦點。如清單 23、24 所示:

清單 23. 在 <div> 中顯示錯誤信息

清單 24. 在 JavaScript 中設置焦點

 

當頁面元素的 tabindex 值為 -1 時,這個元素并不會被包含在 tab 隊列中。開發人員只能通過代碼控制其獲取焦點。如果用戶需要將其包含在 tab 隊列中,可以將其 tabindex 值設置為 0.

多個驗證消息的處理

如果有幾個輸入字段同時驗證出錯 , 我們可以以鏈接的形式顯示錯誤信息,屏幕閱讀器通過閱讀鏈接幫助視力有障礙的用戶快速定位到出錯字段進行更正。每個需要校驗的輸入字段都需要有與其關聯的 <label>。如清單 25、26 所示:

清單 25. HTML 頁面中的輸入域示例

清單 26. 在 JavaScript 中設置錯誤信息的鏈接目標

 

提示 :從上述示例中可以看到如果在當前頁面顯示錯誤信息并且保證其可讀,會增加代碼的復雜性。在滿足需求的情況下可以嘗試在特定的錯誤頁面中顯示錯誤信息,這樣可以降低代碼的復雜性。

伴隨頁面功能性需求的不斷提高,人們也越來越關注頁面的美觀性。但是在設置頁面的顏色方案時要保證頁面的字體顏色與其相應背景色的深淺度對比要至少達到 5:1,開發人員可以利用 Contrast Analyser 驗證當前頁面的顏色對比度是否滿足這個比例。

圖 2.Contrast Analyser 驗證
Contrast Analyser 驗證

 

如何測試無障礙的 Web 網站應用

目前有很多用于測試無障礙訪問(AVT,Accessibility Verification Test)Web 應用的工具,較為常用的有

  • NVDA:絕大部分讀屏軟件都是收費的,而 NVDA 是一個免費開源的讀屏軟件,而且做的很不錯,NVDA 2011.2 中文用戶指南
  • WebKing:是由 Parasoft 發布的一款靜態掃描工具,用戶可以在該工具中指定需要掃描的 web 頁面文件的目錄實現批量掃描。
  • JAWS:是由 Freedom Scientific 發布的一款屏幕閱讀器, 它通過閱讀頁面的文字幫助使用者快速了解頁面功能,完成相關操作。

Web 開發人員可以借助這幾種工具驗證所開發的 Web 頁面是否可以實現無障礙訪問。

 

總結

本文介紹了開發測試可訪問無障礙的 Web 應用的工具,步驟以及開發中的最佳實踐。應用這些最佳實踐與小技巧能幫助您在開發中迅速的為您的 Web 應用提供 A11Y 的支持。

文:IBM

 

原創文章轉載請注明:

轉載自AlloyTeam:http://www.absolute-shop.com/2012/10/how-to-develop-accessible-web-site-application/

  1. sjy47 2015 年 11 月 9 日

    關于這一方面的參考和實踐本來就少,費心了(殘障人士需要更多關注)

  2. tcdona 2012 年 10 月 26 日

    支持學習,還是第一次看到無障礙的實踐指南。

  3. 藍面小生 2012 年 10 月 24 日

    不得不承認,在無障礙方面 dojo 走在所有人的前面~~

發表評論