規則網絡

by Tiago Romero Garcia

蒂亞戈·羅梅羅·加西亞(Tiago Romero Garcia)

實用的網絡可訪問性規則 (Pragmatic rules of web accessibility that will stick to your mind)

I first started to work with web accessibility back in 2015, at an American retail giant. It had just gotten a hefty lawsuit, as its website failed to comply with the Americans with Disabilities Act (ADA). After that happened, my team and I worked extensively on the ADA compliance, when I was introduced to many web accessibility principles.

我最早是從2015年開始在一家美國零售巨頭從事網絡可訪問性的工作。由于它的網站未遵守《美國殘疾人法案》(ADA)，因此它剛剛遭到了嚴峻的訴訟。在那之后，當我被介紹了許多網絡可訪問性原則時，我和我的團隊就ADA的合規性進行了廣泛的研究。

However, over the next years, I found myself constantly violating such principles, even though I was regularly working with them. Somehow, I would never remember them properly while I was coding. I wouldn't admit it, but I definitely had not fully internalized these principles.

但是，在接下來的幾年中，即使我經常與他們合作，我仍然不斷違反這些原則。不知何故，我在編碼時永遠不會正確記住它們。我不承認，但是我絕對沒有完全內化這些原則。

Eventually, I decided that the time had come to invest my time into boiling things down into simple, pragmatic rules which are easy to remember. I finally did just that, and they have been working quite well for me ever since.

最終，我決定是時候把我的時間花在把事情簡化成容易記住的簡單，實用的規則上了。我終于做到了，從那以后他們一直為我工作得很好。

This article has 2 sections: What is web accessibility? and 3 pragmatic rules of web accessibility. In the first section, I give a refresher on web accessibility and share my experience with it. But if you would rather cut to the chase, then just go straight to the second session: 3 pragmatic rules of web accessibility.

本文分為兩個部分：什么是Web可訪問性？和3個實用的網站訪問規則。在第一部分中，我將重新介紹Web可訪問性并分享我的經驗。但是，如果您想追趕一下，那就直接進入第二節： 3個實用的Web訪問規則。

什么是網絡可訪問性？ (What is web accessibility?)

As I mentioned, back in 2015 my company got sued for not complying with the ADA.

正如我提到的，早在2015年，我的公司就因不遵守ADA而受到起訴。

The ADA is a civil rights law that

ADA是一項民權法，

“prohibits discrimination against individuals with disabilities in all areas of public life, including jobs, schools, transportation, and all public and private places that are open to the general public”.
“在公共生活的所有領域，包括工作，學校，交通以及所有向公眾開放的公共場所和私人場所，禁止歧視殘疾人” 。

This way, the ADA requires that businesses, state and local governments, and nonprofit services providers make accommodations for the disabled public to access the same services as able-bodied patrons. Similarly, federal government agencies are required to comply with a federal law called Section 508.

通過這種方式，ADA要求企業，州和地方政府以及非營利性服務提供商為殘疾人提供住宿，以使他們能夠獲得與身體健康的顧客相同的服務。同樣， 聯邦政府機構也必須遵守稱為第508節的聯邦法律。

In the context of the web, any public website in the USA failing to comply with the ADA or Section 508 is in reality excluding several groups of users with varying degrees of impairments.

就網絡而言，實際上，美國任何不符合ADA或508節規定的公共網站都排除了幾組具有不同程度損害的用戶。

On the other hand, the inclusive practice of making a website's content available to everyone and its functionality able to be operated by anyone is understood as web accessibility, or just a11y.

另一方面，將網站的內容提供給所有人以及所有人都可以使用的功能的包容性實踐被理解為Web可訪問性，或者僅僅是a11y 。

According to the World Report on Disability, published in 2011 by the World Health Organization (WHO), it is estimated that 15% of the global population lives with some form of disability. Of these, 2 to 4% experience significant difficulties in functioning.

根據世界衛生組織 (WHO)2011年發布的《世界殘疾報告》，估計全球人口的15％患有某種形式的殘疾。其中，有2％至4％的人在功能上遇到很大困難。

An excellent article by the great Addy Osmani, Accessible UI Components For The Web, spells out the four major areas of disabilities to be considered in the context of a11y:

出色的Addy Osmani的一篇出色文章《 Web的可訪問UI組件》闡明了在a11y上下文中要考慮的四個主要殘疾領域：

1. Visual issues: can range from an inability to distinguish colors to no vision at all.

1.視覺問題：范圍從無法區分顏色到根本沒有視覺。

2. Hearing issues: means a user may have issues hearing sound emitted from a page.

2.聽覺問題：表示用戶可能聽不到頁面發出的聲音。

3. Mobility issues: can include the inability to operate a mouse, a keyboard, or touch-screen.

3.移動問題：可能包括無法操作鼠標，鍵盤或觸摸屏。

4. Cognitive issues: means a user may require assistive technologies to help them with reading text, so it’s important to ensure text alternatives exist.

4.認知問題：意味著用戶可能需要輔助技術來幫助他們閱讀文本，因此確保存在替代文本非常重要。

Keep in mind these are very broad ranges of impairments. This means that one doesn't need to have a severe impairment to need a11y support.

請記住，這是非常廣泛的減值范圍。這意味著不需要嚴重的損傷就可以得到支持。

In order to learn more, I recommend taking the Web Accessibility free course on Udacity, by Google. Here is a video from the course that covers these areas of disability:

為了了解更多信息，我建議參加Google在Udacity上開設的Web Accessibility免費課程。這是本課程的視頻，內容涉及這些殘疾領域：

By the time we got the lawsuit in 2015, there had been an audit which found several a11y issues. Our team went through a day-long accessibility training session, where we learned about the Web Content Accessibility Guidelines (WCAG, currently at version 2.1), which are generally accepted as the standard for a11y compliance.

到2015年我們提起訴訟時，已經進行了一項審計，發現了一些主要問題。我們的團隊進行了為期一天的無障礙培訓課程，在其中我們了解了Web內容可訪問性指南 (WCAG，當前版本為2.1)，該指南通常被公認為是11A合規性的標準。

The WCAG are maintained by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). The same group authored the Accessible Rich Internet Applications (WAI-ARIA or simply ARIA, currently at version 1.1), which is a specification on how to increase the a11y of web pages through additions to HTML as roles and ARIA attributes.

WCAG由萬維網聯盟 (W3C)的Web可訪問性倡議 (WAI)維護。該小組創作了可訪問的富互聯網應用程序 (WAI-ARIA或簡稱ARIA，當前版本為1.1)，該規范說明了如何通過添加HTML作為角色和ARIA屬性來增加網頁的美觀性。

These guidelines are categorized into three levels of compliance:

這些準則分為三個級別的合規性：

A (must support)
A(必須支持)
AA (should support) and
AA(應支持)和
AAA (may support).
AAA(可能支持)。

Many of the accessibility laws around the world are based on WCAG levels. For instance, in January 2017, Section 508 adopted conformance with level AA of WCAG 2.0.

全球許多可訪問性法律都基于WCAG級別。例如，2017年1月，第508節采用了WCAG 2.0的AA級標準。

A great summary of the guidelines can be found at WebAIM’s WCGA 2 checklist, where each criteria indicates its corresponding compliance level.

可以在WebAIM的WCGA 2清單中找到準則的重要摘要，其中每個準則都表明了其相應的合規性水平。

學習WCAG和WAI-ARIA有多難？ (How hard is it to learn WCAG and WAI-ARIA?)

I would like to take a moment to share my experience of learning a11y.

我想花一點時間分享我學習a11y的經驗。

While our training was quite comprehensive, and given by extremely knowledgeable people, we simply sat there for hours while we reviewed the entire WCAG specification, item by item. Their slide deck was humongous, and we moved swiftly through the slides. I will be honest: It was cumbersome, since the WCAG is definitely not small.

雖然我們的培訓非常全面，并且由知識淵博的人提供，但我們只是坐在那里幾個小時，一邊逐項檢查整個WCAG規范。他們的滑梯甲板是巨大的，我們Swift地滑過了滑梯。我會說實話：這很麻煩，因為WCAG絕對不小。

Long story short, we were able to write down many action items, and we immediately started working on these fixes. However, this soon became something repetitive, mechanical, a response to stimuli. Stories in, code out. We were drowning in the sea of a11y.

長話短說，我們能夠寫下許多操作項，我們立即開始著手這些修復程序。但是，這很快就變成了重復的，機械的，對刺激的React。講故事，編出來。我們淹沒在a11y的海里。

Everybody knew how well-versed we became in a11y, so nobody would contest our work. The a11y stories stopped to come in, and we got different priorities. The expectation was that we would carry over what we had learned, which actually happened for quite a while.

每個人都知道我們在11年來變得多么精通，所以沒有人會質疑我們的工作。故事停止了，我們得到了不同的優先次序。期望我們將繼續學到的東西，實際上這發生了很長時間。

As time passed, some people left, some people joined, and the new management came in. The market moves fast. We changed our focus and our team spirit. Needless to say, we became so involved with the new things that our a11y compliance slipped far into the background.

隨著時間的流逝，一些人離開了，一些人加入了，新的管理人員加入了。市場發展Swift。我們改變了焦點和團隊精神。不用說，我們對新事物的參與如此之深，以至于我們對a11y的合規性遠遠溜到了后臺。

It was so bad, that six months later we had another audit, only to discover we were still sitting in a big pile of a11y violations! We soon realized that while we fixed the original audited issues, most of the new code we wrote was just as bad on a11y. Not only that, we never adopted a11y as part of our development checklist, and the newcomers were never trained on the subject.

真是太糟糕了，六個月后，我們又進行了一次審核，結果發現我們仍然處于一大堆違反法規的行為！我們很快意識到，在解決原始審核問題的同時， 我們編寫的大多數新代碼在a11y上同樣糟糕 。不僅如此，我們從未將a11y用作開發清單的一部分，而新來者也從未接受過有關該主題的培訓。

Conclusion: We simply allowed it to happen — a11y was being neglected, and the key ideas were not ingrained in us.

結論：我們只是允許它發生-被忽略了，關鍵的思想并沒有根深蒂固。

In other words, we were creating exclusions, which is what happens when we solve problems using our own biases, according to Microsoft Inclusive Design.

換句話說，我們正在創建排除項 ，根據Microsoft Inclusive Design的說法，當我們使用自己的偏見解決問題時會發生這種情況。

遇到排斥 (Experiencing an exclusion)

Sometimes you need to experience things yourself in order to better understand them. That's what happily happened to me.

有時您需要親自體驗事物，以便更好地理解它們。那就是我高興的事。

I donate my platelets regularly, since my blood type is A+, so I can help more people this way. Once, my vein got perforated incorrectly and I got a big and painful bruise on my left arm.

由于我的血型為A +，因此我定期捐獻血小板，因此我可以通過這種方式幫助更多的人。有一次，我的靜脈穿Kong不正確，左手臂上有一塊又大又痛苦的瘀傷。

Typically, regular blood donations last 10 minutes or so, but platelet donations last around 90 minutes. It took us about 20 minutes to notice that I had a blown vein, since my arm was covered with blankets (because blood returns make you feel cold).

通常，定期獻血持續10分鐘左右，而血小板獻血持續90分鐘左右。我們花了大約20分鐘的時間發現我的靜脈被吹斷了，因為我的手臂被毯子覆蓋了(因為血液回流會使您感到寒冷)。

By that time, the damage was done, and we had to interrupt the donation. My arm got quite bloated and very sensitive for a few days. So much that I didn't feel like using my left arm at all to work.

到那時，損害已經造成，我們不得不中斷捐贈。幾天后我的手臂變得非常腫并且非常敏感。如此之多，以至于我根本不想用左臂上班。

Now, I was trying to do everything with my right hand. All of a sudden, I noticed it wasn’t efficient to keep alternating between keyboard and mouse, and I would rather do the whole task at hand using just the keyboard or the mouse.

現在，我正嘗試用右手做所有事情。突然之間，我注意到在鍵盤和鼠標之間保持交替并不是很有效，我寧愿僅使用鍵盤或鼠標來完成整個任務。

Soon, I found myself preferring to use exclusively the keyboard for everything, and then I noticed how many sites are simply not there on keyboard support. Then it came to me: I was experiencing an exclusion, even though it was just a temporary one.

很快，我發現自己更喜歡只使用鍵盤來做所有事情，然后我發現有多少站點根本不在鍵盤支持上。然后就來了：我正在經歷一種排斥，即使那只是暫時的 。

And then, exactly at that moment, I remembered the past me working with a11y and letting these exclusions pass. Oh, man!

然后，恰在那一刻，我想起了過去與a11y一起工作并讓這些排除通過的過去。天啊！

排除級別 (Levels of exclusions)

According to Microsoft's Inclusive 101 Toolkit, there are three levels of exclusions:

根據Microsoft的Inclusive 101 Toolkit ，包含三個排除級別：

Permanent: experienced by those who have a disability such as loss of limb, sight, hearing, or speech.
永久：由肢體殘缺，視力，聽力或語言障礙等殘障人士所經歷。
Temporary: experienced by those who have a short-term injury or are going through certain events for a short time, such as looking into a bright light, wearing a cast, or ordering dinner in a foreign country.
臨時的：由短期受傷或短時間經歷某些事件的人所經歷，例如在明亮的燈光下注視，穿石膏或在異國訂購晚餐。
Situational: experienced by those whose abilities can dramatically change in specific environments, such as being unable to hear well in a loud crowd, being visually impaired in a car, or new parents doing tasks one-handed.
情境：那些能力在特定環境中會發生巨大變化的人所經歷，例如在大聲的人群中聽不清，在汽車上視障，或者新父母單手做事。

It was extremely mind opening for me to have a temporary exclusion, since I had never been faced before with such a challenge at work.

因為暫時沒有面對工作上的挑戰，這讓我暫時被排除在外是非常開放的想法。

Nevertheless, I am tremendously privileged since mine was just for a couple of days, while millions of people around the world experience permanent exclusions for their entire lives.

不過，我感到非常榮幸，因為我只有幾天的時間，而世界各地數以百萬計的人一生都遭受永久性的排斥。

編碼變化 (Coding for change)

Finally, it came to me: Implementing a11y means contributing to a more inclusive world! Here are a few things we can do as engineers:

最終，我想到：實施a11y意味著為更加包容的世界做出貢獻！作為工程師，我們可以做一些事情：

Learning how to write code that supports a11y.
學習如何編寫支持a11y的代碼。
Adding a11y compliance as part of your development checklist (just like you would work on unit testing and documentation).
將合規性添加到開發清單中(就像處理單元測試和文檔一樣)。
Talking about a11y with your team, to increase the awareness.
與您的團隊討論a11y，以提高知名度。
Assessing if your team is producing accessible code, and logging a11y issues as defects to be taken up by the team.
評估您的團隊是否正在生成可訪問的代碼，并將所有問題記錄為團隊要解決的缺陷。
Questioning business requirements which are not covering a11y and demanding accessible alternatives.
對未涵蓋所有業務需求的業務提出質疑，并要求提供可訪問的替代方案。
Sharing your experience, and showing your peers how to adopt a11y in a practical way, which is the very reason why I am writing this article. :)
分享您的經驗，并向您的同齡人展示如何以實際方式采用a11y，這正是我撰寫本文的原因。 :)

Web訪問的3個實用規則 (3 pragmatic rules of web accessibility)

So here am I with my mission to distill a11y into 3 practical rules that will stick to your mind. From these rules, you should be able to derive the rest of the knowledge and find guidance on implementing a11y in your project.

所以我在這里的使命是將所有11條實用規則精煉成您要記住的。從這些規則中，您應該能夠獲得其余知識，并找到有關在項目中實施方法的指導。

Disclaimer: These rules don't replace the need to learn a11y. They are also not comprehensive. They simply will provide you a basic yet effective foundation, so you can follow the rest of path on your own.

免責聲明：這些規則并不能代替學習知識的需要。它們也不全面。它們只是為您提供了一個基本而有效的基礎，因此您可以自己遵循其余的道路。

Again, in order to learn a11y I wholeheartedly recommend taking the Web Accessibility free course on Udacity, by Google:

再次，為了學習，我衷心建議您參加Google提供的有關Udacity的Web Accessibility免費課程：

Web Accessibility | UdacityGet hands-on experience making web applications accessible. You'll understand when and why users need accessibility…www.udacity.com

網站可訪問性| Udacity 獲得使Web應用程序可訪問的實踐經驗。 您將了解何時以及為什么用戶需要輔助功能…… www.udacity.com

Now to the 3 pragmatic rules of web accessibility. I hope you can take them with you and apply them every day at work:

現在到了3個實用的Web訪問規則。希望您可以隨身攜帶它們，并每天在工作中使用它們：

1)堅持語義HTML元素或DIY (1) Insist on semantic HTML elements, or DIY)

This one is for me the golden rule of accessibility, hands down.

這對我來說是可訪問性的黃金法則 。

Semantic elements are these which convey a certain meaning along with the content they represent, like <button>, &lt;input>;, &lt;a>, <h1> and <p>. They provide some context to the user agent (browser, device or assistive technology like a screen reader), so it will know how to interact with and what to expect of these elements.

語義元素是傳達一定含義的元素以及它們表示的內容，例如<butt on >, & lt ;in pu t> ;，＆l t;a >，<h1>和<p>。它們為用戶代理(瀏覽器，設備或輔助技術，如屏幕閱讀器)提供了一些上下文，因此它將知道如何與這些元素進行交互以及對這些元素有何期待。

They are different than neutral elements, such as <div>; and <span>, or presentational elements like &lt;center> and <big>, which do not provide such context to the user agent.

它們不同于中性元素，例如<d iv> ; and ; and <S 鍋>，或PR esentational EL ements l IKE＆ lt;ce NTER>和<大>，它不提供這樣的上下文向所述用戶代理。

Semantic elements are already accessible (and SEO-friendly) for the most part. This means they already cover many a11y aspects out of the box, like:

大多數情況下，語義元素已經可以訪問(并且對SEO友好)。這意味著它們已經涵蓋了很多現成的方面，例如：

handling of focus properly through the tab key.
通過Tab鍵正確處理焦點。
responding to keyboard events (as Enter, Esc, space, arrow keys).
響應鍵盤事件 (如Enter，Esc，空格鍵，箭頭鍵)。
representing semantic information (Name, Role, State and Value) so assistive technology will be able to understand it.
表示語義信息(名稱，角色，狀態和值)，因此輔助技術將能夠理解它。
conforming to color contrast requirements with default styling.
符合顏色對比度要求和默認樣式。

However, when not using a semantic element, you are supposed to manually code all of these things in order to make it accessible.

但是，當不使用語義元素時， 應該手動編碼所有這些內容以使其可訪問 。

Which means you would need to do things like:

這意味著您將需要執行以下操作：

add tabindex="0" so the component will be part of the natural tab order, and use focus(), display: none or aria-hidden to avoid focus traps. Learn about tabindex on Using tabindex.
添加tabindex="0"以便該組件將成為自然制表符順序的一部分，并使用focus() ， display: none或aria-hidden以避免焦點陷阱。通過使用tabindex了解關于tabindex的信息。
attach listeners for expected keyboard events. Check the expectations for your component on WAI-ARIA Design Patterns and Widgets.
為預期的鍵盤事件附加偵聽器。在WAI-ARIA設計模式和小部件上檢查對組件的期望。
use a role to provide some semantics and SEO value. Learn all the possible roles on WAI-ARIA Categorization of Roles.
使用角色提供一些語義和SEO值。了解有關WAI-ARIA角色分類的所有可能角色。
provide ARIA attributes to describe the state and value. Find out which ARIA attributes apply each role on WAI-ARIA Definition of Roles.
提供ARIA屬性以描述狀態和值。找出哪些ARIA屬性將每個角色應用于WAI-ARIA角色定義。
watch out for the color contrast and the focus indicator, especially if using outline: 0 (which is not recommended).
注意顏色對比和聚焦指示 ，尤其是在使用outline: 0 (不推薦)的情況下。

Still on semantic elements, here are a few more things to keep in mind:

仍然在語義元素上，還需要記住以下幾點：

use sectioning tags to structure your page into sections, otherwise you need to provide landmark roles.
使用分區標記將頁面分為多個部分，否則您需要提供地標性角色。
use heading tags to organize your text content, so you can express the relationship between sections and their order of importance. For the record: There must be only one <h1> on each page.
使用標題標簽來組織您的文本內容，因此您可以表達各節之間的關系及其重要性順序。作為記錄：每頁上只能有一個< h1>。
use <label for="..."> with form fields as &lt;input&gt;, &lt;select&gt; and <textarea>.
使用形式為ds as & <label for=".. ”> ds as & lt ;input&g t;，＆ lt;select& gt; 和<textarea>。
use the right tool for the job, for instance if it’s a link, use <a href=""> and never <span onclick="...">, and if it’s a button, use <button> and never <a href="#" οnclick="...">.
使用適合該工作的工具，例如，如果是鏈接，則使用<a href= href=" "">而never <span oncli ck =“ ...”>，如果是button,使用<but ton> and never <a hr ef="#" οnclick="...">。

Well, semantic elements seem way more convenient, don’t you think?

好吧，語義元素似乎更方便，您不覺得嗎？

2)提供圖像，顏色，聲音和運動的替代方法 (2) Provide alternatives for images, color, sound and movement)

Assistive technology deals best with text. When using anything else, always provide a text alternative, for instance:

輔助技術最能處理文字。使用其他任何內容時，請始終提供替代文本，例如：

For images, provide a text alternative. You can use alt="description" for informative images (those which have a meaning, like a picture or a standalone icon) and alt="" for decorative images (those which don’t have a meaning, like an icon inside a button and right next to its text). This is especially important on image links.
對于圖像，請提供替代文本 。您可以將alt="description"用于內容豐富的圖像 (具有含義的圖像，例如圖片或獨立圖標)，將alt=""用于裝飾性圖像 (具有含義的圖像，例如按鈕內的圖標)并在其文字旁邊)。這在圖像鏈接上尤其重要。
Still on images, when relying on them for user interaction, provide an audio alternative, or explore how to stop relying on them. You can check Google reCaptcha, for instance.
仍然在圖像上，當依靠它們進行用戶交互時，請提供音頻替代方案 ，或者探索如何停止依賴它們。例如，您可以檢查Google reCaptcha 。
For colors, when indicating a validation state, a designated area or simply distinguishing elements, add a secondary indicator such as informative text, an icon or even a tooltip.
對于顏色，當指示驗證狀態，指定區域或簡單區分元素時，添加輔助指示符，例如信息性文本，圖標甚至工具提示。
Still on colors, find out the contrast ratio of your text and check if it meets the standard you are following. For instance, the level AA of the WCAG requires a minimum of 4.5:1 for regular text and 3:1 for large text.
仍然在顏色上，找出文本的對比度 ，然后檢查其是否符合您所遵循的標準。例如，WCAG的AA級別要求普通文本至少4.5：1，大文本至少3：1。
For audio tracks and video, provide text captions or a transcript when they are available. For action sounds, provide a visual alternative.
對于音頻曲目和視頻，提供文本標題或成績單可用時。對于動作聲音，請提供視覺替代 。
For user movement, any time we expect the user to perform specific gesture movements, make them optional or provide interaction alternatives through the keyboard.
對于用戶的移動，我們希望用戶在任何時候執行特定的手勢移動，使其成為可選動作或通過鍵盤提供交互方式 。
For automatic movement, avoid flashes, blinking, moving content, and new windows. When it’s unavoidable, add controls to adjust the time, pause or hide this content. Also, use aria-live so the screen reader can notify the user whenever an interruption happen.
對于自動移動，請避免閃爍，閃爍，移動內容和新窗口。如果不可避免，請添加控件以調整時間，暫停或隱藏此內容。另外，使用aria-live，以便屏幕閱讀器可以在發生中斷時通知用戶。

This is perhaps the most efficient rule, so when you let something pass from the two rules above, this one should catch it.

這可能是最有效的規則，因此，當您讓上述兩個規則中的某些規則通過時，這個規則應該會被抓住。

I am listing here several a11y tools. Give them a try, run them on your website, see what you learn from them and try to stick around with them.

我在這里列出了幾種工具。嘗試一下，在他們的網站上運行它們，看看從中學習到的知識，并嘗試堅持下去。

There are basically 3 types of tools I recommend that you adopt:

我建議您基本上采用3種工具：

a) For your development checklist

a)為您的開發清單

aXe chrome plugin: An easy-to-use a11y checker which finds issues and provides suggested fixes.
ax chrome插件：一個易于使用的a11y檢查器，可以發現問題并提供建議的修復程序。
Wave: An a11y evaluation tool which provides visual feedback about the accessibility of your web content by injecting icons and indicators into your page.
Wave ：一個a11y評估工具，它通過在頁面中注入圖標和指示符來提供有關Web內容可訪問性的視覺反饋。
DevTools (Accessibility pane, Contrast ratio and Audits): These 3 DevTools features allow to navigate the accessibility tree and see a11y properties for each element, to verify the color contrast ratio for text elements, and to perform full-page audits on accessibility (and other metrics).
DevTools(可訪問性窗格，對比度和審核) ：這三個DevTools功能允許瀏覽可訪問性樹并查看每個元素的所有屬性，以驗證文本元素的顏色對比度，并對可訪問性進行全頁審核(和其他指標)。
NoCoffee chrome plugin: Simulates the problems faced by people with slight to extreme vision problems.
NoCoffee chrome插件：模擬有輕微到極端視力問題的人所面臨的問題。
High Contrast chrome plugin: Lets you browse the web with your choice of several high-contrast color filters designed to make it easier to read text, so you can check how your website fares for users that need high-contrast support.
高對比度鍍Chrome插件：讓您可以選擇幾種高對比度濾色鏡來瀏覽網頁，這些濾鏡旨在使文本閱讀更加輕松，因此您可以檢查網站對需要高對比度支持的用戶的收費。

b) For manually testing with real screen readers

b)使用真實屏幕閱讀器進行手動測試

Mac VoiceOver (included in macOS).
Mac VoiceOver (包含在macOS中)。
Windows NVDA (free) and JAWS (paid).
Windows NVDA (免費)和JAWS (付費)。

c) For automated auditing

c)用于自動審核

Google Lighthouse: Automated auditor, similar to DevTools Audits.
Google Lighthouse ：自動審核程序，類似于DevTools審核程序。
aXe: Automated checker for the same a11y rules found on aXe chrome plugin.
ax ：自動檢查ax chrome插件上相同的a11y規則。
Pa11y Dashboard: A web interface which helps you monitor the accessibility of your websites.
Pa11y Dashboard ：Web界面，可幫助您監視網站的可訪問性。

學到更多 (Learn more)

508, ADA, WCAG: What’s the difference?
508，ADA，WCAG：有什么區別？
WHO's World Report on Disability
世衛組織《世界殘疾報告》
Accessible UI Components For The Web
Web的可訪問UI組件
Microsoft Inclusive Design
微軟包容性設計
Web Accessibility free course on Udacity, by Google
Google提供的有關Udacity的Web Accessibility免費課程
WebAIM’s WCGA 2 checklist
WebAIM的WCGA 2清單
Using tabindex
使用tabindex
WAI-ARIA Design Patterns and Widgets
WAI-ARIA設計模式和小部件
WAI-ARIA Categorization of Roles
WAI-ARIA角色分類
HTML5 Sectioning Elements
HTML5分區元素