翻譯不完整。請協助 翻譯此英文文件

這篇文章給「到底什麼是無障礙網頁」的模塊,開了個好起頭:以下將包括我們該考慮什麼樣的用戶以及理由、不同的人要在 web 用什麼工具互動、還有如何令無障礙網頁成為 web 開發的一部分。

先決要求: 基本資訊能力、還有對 HTML 與 CSS 有基本的理解。
目標: 熟悉無障礙網頁,包含它是什麼、還有它如何影響作為 web 開發者的你。

到底什麼是無障礙網頁?

無障礙是盡可能令更多人,使用你網站的實做:一般來說,我們會認為這屬於身心障礙者的範疇,但它其實會涵蓋其他群體:像是使用行動設備、或者網速很慢的人。

也可以把無障礙想成:所有人,不論他們的能力或環境如何,都要同等看待、並給予同等機會。就如同我們不能把坐在輪椅的人,排除在某棟物理大樓之外:目前的公共建築,通常都會有電梯或輪椅坡道;我們也不能排除視障或手機用戶,使用我們的網站。儘管我們生而不同,但我們都是人,因此,我們都擁有相同的人權。

無障礙是好事,但也是某些國家法律的一部分,也能開啟一些關係到你的服務或產品的市場。

無障礙與其所需之最佳實做將使大家受益:

  • 提昇無障礙的語意 HTML 能增進 SEO,令網站更容易被找到、也更易於銷售。
  • 關注無障礙網頁會展現優良的倫理道德、以增進你的公共形象。
  • 無障礙網頁的一些作法也能令網站易於給其他族群使用,像是手機用戶、低網速……等等。事實上,任何人都能從此類改進中獲益。
  • 我們還要提提某些地區的法律規定嗎?

你在鎖定什麼樣的障礙者?

身心障礙者和非身心障礙者一樣多元,他們的障別也是如此。重點是,不要光用自己使用電腦和 web 的角度去思考這件事:你並不是無障礙網頁的用戶。下文將解釋應當考慮的障別,還有他們訪問 web 內容的特殊工具(通常稱作 assistive technologiesAT輔助工具輔具)。

:世界衛生組織的殘疾與健康指出「超過10億人,約佔世界人口的15%,患有某種形式的殘疾。」、且「1.1億至1.9億成年人有很嚴重的功能性障礙。」。

視覺障礙

視覺障礙包括盲人、低度視覺、色盲……等等。這類的用戶會使用擴視器(screen magnifier,可能是物理擴視機、或是軟體的縮放功能:當代多數瀏覽器和作業系統都有這種功能),也有些人會用螢幕閱讀器(screen reader,朗讀數位文字的軟體):

  • 有些是商業軟體,例如 JAWS(Windows)和 Window Eyes(Windows)。
  • 也有些是自由軟體,例如 NVDA(Windows)、ChromeVox(Chrome、Windows、Mac OS X)、Orca(Linux)
  • 還有些是系統內建,例如 VoiceOver(Mac OS X 與 iOS)、Narrator(Microsoft Windows)、ChromeVox(Chrome OS)、TalkBack(Android)。

熟悉螢幕閱讀器是個好主意;你得設定好螢幕閱讀器、還要會使用它,以理解其工作原理。請參見cross browser testing screen readers guide以深入理解。以下影片提供了簡單的體驗。

在統計方面,世界衛生組織表明:「全球視力受損人數約2.53億:3600萬人患有盲症,2.17億人有中度至重度視力損害。」(請參見視力損害和盲症)。如果網站編寫不正確,你的網站就會失去如此龐大的和重要的用戶群:這大約是全美國的總人口數。

聽覺障礙

聽覺障礙者、或聾人,是指聽力低落、或毫無聽力的群體。聽覺障礙者通常會用輔具(請參見Assistive Devices for People with Hearing, Voice, Speech, or Language Disorders),但沒有給電腦/web使用的專門輔具。

不過,請記得有專門技術,會針對有聲內容,提供閱讀的替代文字。有簡單的文本記錄(text transcript)、也有能在影片出現的追蹤文字(text track),例如字幕。接下來將有文章深入探討。

聽覺障礙者也是龐大的人口,世界衛生組織在耳聾和聽力損失指出:「全球有3.6億人患有殘疾性聽力損失」。

行動障礙

These people have disabilities concerning movement, which might involve purely physical issues (such as loss of limb or paralysis), or neurological/genetic disorders that lead to weakness or loss of control in limbs. Some people might have difficulty making the exact hand movements required to use a mouse, while others might be more severely affected, perhaps being significantly paralysed to the point where they need to use a head pointer to interact with computers.

This kind of disability can also be a result of old age, rather than any specific trauma or condition, and it could also result from hardware limitations — some users might not have a mouse.

The way this usually affects web development work is the requirement that controls be accessible by the keyboard — we'll discuss keyboard accessibility in later articles in the module, but it is a good idea to try out some websites using just the keyboard to see how you get on. Can you use the tab key to move between the different controls of a web form, for example? You can find more details about keyboard controls in our Cross browser testing Using native keyboard accessibility section.

In terms of statistics, a significant number of people have mobility impairments. The U.S. Centers for Disease Control and Prevention Disability and Functioning (Noninstitutionalized Adults 18 Years and Over) reports the USA "Percent of adults with any physical functioning difficulty: 15.1%".

認知障礙

Probably the widest range of disabilities can be seen in this last category — cognitive impairment can broadly refer to disabilities from mental illnesses to learning difficulties, difficulties in comprehension and concentration like ADHD (attention deficit hyperactivity disorder), to people on the autistic spectrum, to people with schizophrenia, and many other types of disorder besides. Such disabilities can affect many parts of everyday life, due to problems with memory, problem solving, comprehension, attention, etc.

The most common ways that such disabilities might affect website usage is difficulty in understanding how to complete a task, remembering how to do something that was previously accomplished, or increased frustration at confusing workflows or inconsistent layouts/navigation/other page features.

Unlike other web accessibility issues, it is impossible to prescribe quick fixes to many web accessibility issues arising from cognitive disabilities; the best chance you've got is to design your websites to be as logical, consistent, and usable as possible, so for example making sure that:

  • pages are consistent — navigation, header, footer, and main content are always in the same places.
  • tools are well-designed and easy to use.
  • multi-stage processes are broken down into logical steps, with regular reminders of how far through the process you are, and how long you've got left to complete the process, if appropriate.
  • workflows are logical, simple, and require as few interactions as possible to complete. For example, registering and signing in to a website is often unneccessarily complex.
  • pages are not overly long or dense in terms of the amount of information presented at once.
  • the language used in your pages is as plain and easy to follow as possible, and not full of unneccessary jargon and slang.
  • important points and content are highlighted in some way.
  • user errors are clearly highlighted, with help messages to suggest solutions.

These are not "accessibility techniques" as such — they are good design practices. They will benefit everyone using your sites and should be a standard part of your work.

In terms of statistics, again the numbers are significant. Cornell University's 2014 Disability Status Report (PDF, 511KB) indicates that in 2014, 4.5% of people in the USA aged 21–64 had some form of cognitive disability.

Note: WebAIM's Cognitive page provides a useful expansion of these ideas, and is certainly worth reading.

專案引入無障礙

有一個很常見的迷思,就是在專案管理方面,無障礙屬於昂貴的「外加」成本。如果有以下情形的話,這個迷思的確會發生:

  • 針對明顯有障礙的網站,想要「重寫」為無障礙網站。
  • 在專案後期才想到無障礙網頁相關問題時。

如果在專案初期就考慮到無障礙網頁,大多數無障礙內容的成本可以最小化。

When planning your project, factor accessibility testing into your testing regime, just like testing for any other important target audience segment (e.g. target desktop or mobile browsers). Test early and often, ideally running automated tests to pick up on programmatically detectable missing features (such as missing image alternative text or bad link text — see Element relationships and context), and doing some testing with disabled user groups to see how well more complex site features work for them. For example:

  • Is my date picker widget usable by people using screen readers?
  • If content updates dynamically, do visually impaired people know about it?
  • Are my UI buttons accessible using the keyboard and on touch interfaces?

You can and should keep a note of potential problem areas in your content that will need work to make it accessible, make sure it is tested thoroughly, and think about solutions/alternatives. Text content (as you'll see in the next article) is easy, but what about your multimedia content, and your whizzy 3D graphics? You should look at your project budget and realistically think about what solutions you have available to make such content accessible? You could pay to have all your multimedia content transcribed, which can be expensive, but can be done.

Also, be realistic. "100% accessibility" is an unobtainable ideal — you will always come across some kind of edge case that results in a certain user finding certain content difficult to use — but you should do as much as you can. If you are planning to include a whizzy 3D pie chart graphic made using WebGL, you might want to include a data table as an accessible alternative representation of the data. Or, you might want to just include the table and get rid of the 3D pie chart — the table is accessible by everyone, quicker to code, less CPU-intensive, and easier to maintain.

On the other hand, if you are working on a gallery website showing interesting 3D art, it would be unreasonable to expect every piece of art to be perfectly accessible to visually impaired people, given that it is an entirely visual medium.

To show that you care and have thought about accessibility, publish an accessibility statement on your site that details what your policy is toward accessibility, and what steps you have taken toward making the site accessible. If someone does complain that your site has an accessibility problem, start a dialog with them, be empathic, and take reasonable steps to try to fix the problem.

:我們的 Handling common accessibility problems article 包含了應該進行詳細測試的無障礙網頁規範。

總而言之:

  • 在專案初期就考量到無障礙網頁、還要測試得早而多。一如其他錯誤,無障礙網頁問題在越晚發現時,麻煩也越大。
  • 謹記無障礙網頁,是對大家都有利的。例如說,精實的語意標記不只對螢幕閱讀有利,也利於快速載入與效能,從而對大家有利,尤其對行動設備、或是網速過慢的人。
  • 再網站上標明支援無障礙網頁,並鼓勵身心障礙者參與。

無障礙網頁的指引與法律

有一些針對無障礙網頁的檢查清單和指引能夠用做測試,它們乍看之下可能令人眼花撩亂。我們建議你只要專注熟悉的基本領域、並理解指引裡面,與你最相關的高層次結構。

因此,儘管 WCAG 有所指引,你的國家可能還是有管理無障礙網頁、或最少針對公眾無障礙服務(可能包含了網站、電視、物理空間……等等)的法案。最好先看看所處地區的法律管轄權。如果不好好檢查內容是否無障礙,當身心障礙者投訴時,你可能會面臨法律問題。

聽起來很可怕,但只要在開發時,如上所述地把無障礙網頁議題當作高度優先就可以了。如果真的有疑問,請諮詢合格的專業律師。我們不是律師,所以不會提供更深入的意見。

無障礙網頁 API

瀏覽器使用特殊的accessibility API(由各自的作業系統底層提供)對輔助技術(AT)提供有用的信息:輔助技術傾向使用語義訊息,因此這種訊息不包含樣式化資訊、或是 JavaScript。這種資訊建構成一個稱為 accessibility tree 的訊息樹(tree of information)。

不同的作業系統有不同的 accessibility API:

  • Windows: MSAA/IAccessible, UIAExpress, IAccessible2
  • Mac OS X: NSAccessibility
  • Linux: AT-SPI
  • Android: Accessibility framework
  • iOS: UIAccessibility

如果由 web app 裡面,HTML 元素提供的原生語意訊息出問題了,你可以把它用做 WAI-ARIA 規範的補充:它會把語意訊息添加到 accessibility tree 以增進無障礙功能。你可以在 WAI-ARIA 基礎文章學習 WAI-ARIA。

結論

本文應當使你對無障礙網頁有著概括性的認知、明白其重要性、並在知道如何在工作流程中安排它。你也該對知道如何實做無障礙網頁的細節有興趣。我們將在下個章節開始闡明為什麼 HTML 是無障礙網頁的好基礎。

在本模塊

文件標籤與貢獻者

 此頁面的貢獻者: iigmir
 最近更新: iigmir,