翻译正在进行中。

本文以一种很好的方式开始了这个模块,其中包括我们需要考虑的用户群,以及为什么不同的人会使用什么工具来与web交互,以及我们如何使可访问性成为web开发工作流的一部分。

先决条件: 基本的计算机知识,对HTML和CSS的基本理解。
客观: 要熟悉可访问性,包括它是什么,以及它如何影响您作为web开发人员。

可访问性是什么?

可访问性是让你的网站尽可能多的人使用的做法——我们传统上认为这是关于残疾人的,但实际上它也涵盖了其他群体,比如使用移动设备的人群,或者那些网络连接缓慢的人群。

你也可以把无障碍看成是对每个人都一样的对待,给他们同样的机会,无论他们的能力或环境如何。 就像不应该把某人从物理大楼里排除在外,因为他们是坐在轮椅上(公共建筑通常有轮椅或电梯),也不能排除某个网站上的人因为他们有视觉障碍,或者使用手机。我们都是不同的,但我们都是人,因此拥有同样的(人的)权利。

可访问性是正确的做法,但它也是一些国家法律的一部分,它可以打开一些重要的市场,否则就无法使用你的服务,购买你的产品等等。

可访问性和它所需要的最佳实践可以使每个人受益:

  • 语义HTML(提高可访问性)也提高了搜索引擎优化,使你的网站更容易获得。

  • 关心可访问性展示良好的伦理道德,它提高了你的公众形象。

  • 其他一些改善可访问性的好的做法也会让你的网站更容易被其他群体使用,比如移动电话用户,低网速等等。事实上,每个人都可以从很多这样的改进中受益。

  • 我们有没有提到在某些地方法律也是如此?

我们关注的是什么类型的残疾?

残疾人和没有残疾的人一样多样化,残疾人也一样。这里的关键经验是,超越你自己的电脑和你如何使用网络,并开始学习别人如何使用它——你不是你的用户。下面将解释主要的残疾类型,以及它们用于访问web内容的任何专业工具(称为辅助技术或ATs)。

Note: 世界卫生组织(World Health Organization)的残疾和健康状况说明书指出,“超过10亿人,约占世界人口的15%,患有某种形式的残疾”,“1.1亿至1.9亿成年人在功能上存在重大困难。”

有视觉障碍的人

这包括盲人、低水平视力、色盲等。很多人会使用屏幕放大镜(物理放大镜,或者软件缩放功能——大多数浏览器和操作系统现在都有缩放功能),有些人会使用屏幕阅读器,这是一种可以大声朗读数字文本的软件:

  • 有些是付费产品, 比如 JAWS (Windows) 和 Window Eyes (Windows).
  • 有些是免费产品, 比如 NVDA (Windows), ChromeVox (Chrome, Windows and Mac OS X), 和 Orca (Linux).
  • 有些是内置在操作系统中,比如 VoiceOver (Mac OS X and iOS), Narrator (Microsoft Windows), ChromeVox (on Chrome OS),和 TalkBack (Android).

让自己熟悉屏幕阅读器是个好主意;您还应该设置一个屏幕阅读器,并对其进行处理,以了解它是如何工作的。请参阅我们的跨浏览器测试屏幕阅读器,以了解更多使用它们的细节。下面的视频还提供了一个简单的例子,说明了体验是怎样的。

就统计数据而言,世界卫生组织估计“全球有2.85亿人视力受损:3900万人失明,246人视力低下。”(参见视力障碍和失明)。这是一个庞大而庞大的用户群,因为你的网站没有被正确的编码——几乎和美国的人口一样大。

有听力障碍的人

有听觉障碍的人,或聋耳人,这群人有听力水平低甚至听不到的不便。这些人使用 ATs(请访问 Assistive Devices for People with Hearing, Voice, Speech, or Language Disorders), 但是并没有特定的AT为计算机网页技术所服务。

但是,现在有特别的技术提供给那些不方便的人通过语言交流来阅读,通过简单的文本扫描,文本追踪,文本通过语音读取,下面的文章来专门介绍。

听力受损的人可以通过一个有意义的设备来表达自己——“360 全世界百万人将拥有听力”,一个全世界聋哑健康组织声明。

行动障碍的人

       那些有行动障碍的人,也许仅仅深陷于身体的问题(比如肢体或神经方面),或者是神经上的/遗传上的紊乱导致的虚弱或者无法控制身体。有些人也许困于准确移动手臂去使用鼠标,但是有些人却可以使用顺畅。也许很难准确定位到点,当页面使用光标去和电脑交互。

还有一种残疾是因为老了,不仅仅因为创伤或者外部条件,也因为艰苦环境限制,也不能使用鼠标。

办法通常影响web框架工作,需要键盘的控制,我们讨论键盘在稍后的模块,这有益于提炼出有些网址仅仅使用键盘去访问。你能使用tab键移动光标在表单上数码吗?你讷讷个找出更多有用的技巧去控制键盘操作屏幕通过Cross browser testing Using native keyboard accessibility 模块。

依据一个数据,一个对行动障碍者有意义的数据,美国疾病控制中心和疾病阻止和防御中心(18岁以上管控的人)报道美国有15.1%的成人都有一些身体功能疾病。

有认知障碍的人

可能最多的疾病可归统于最后一个分类——精神损伤由于精神疾病难以去学习,难于理解和集中注意力ADHD(注意力受困于脑力调用),对那些孤独边缘,那些精神分裂的人,对许多混乱类型的边缘人。这些疾病可以影响他们生活的方方面面,由于脑力原因,问题解决,理解,注意力等。

最普遍的方法就是这些残疾人使用网络最难的在于理解怎么去完成一个任务,记得怎么去做意见以前做过的事,或者提高消化那些使人混乱的工作流程或者那些矛盾的布局,导航,或者其他页面结构。

不像其他相似的网页问题,那也许不可能规定去快速修复那些相似的问题产生于认知失能。最好的改变就是你掌握设计网页的能力,坚持,然后实践,所以尽可能做到以下几点:

  • 页面风格一致——导航、头部、页脚、主要内容在一个规整的位置。
  • 使用易于设计和简便的工具。
  • 多个网页之间易于出问题在于逻辑设计,和有规律的提示失败于个人,多久你能完成进度,如果合适的安排。
  • 工作流是有逻辑的、简单的、需要尽可能相互作用去完成。例如:注册和登录通常诶有很大的关联
  • 页面没有必要很长或者繁杂为了一次性展示很多信息。
  • 页面使越简单的语言越容易让人注意,不要放很多专业术语或者流行语。
  • 重要的点和文本通常可以高亮显示。
  • 用户错误明显突出,给点提示信息操作。

这些本身都不是易访问性技术-他们有很好的设计能力。他们有益于每个使用你的网站和将成为你的工作准则。

依据数据,增加数据是非常有意义的。康奈尔大学2014 Disability Status Report (PDF, 511KB)指明在2014年,在美国年龄在21-64岁之间的人有4.5%有认知障碍。

提示WebAIM's Cognitive 页面提供对这些观点非常有用的扩述,确实非常值得阅读。

将无障碍接入到你的项目中

有一个通用的传言说,将无障碍化接入到项目中去是一个代价高昂的“额外部分”。这个传言倒也不假,如果你是如下面这两个情景:

  • 你在一个已存在的有众多无障碍问题的网站上试图“翻新”。
  • 你在项目的最后一步才刚刚开始考虑无障碍化和处理相关问题。

然而如果你能在项目的开始阶段就考虑到无障碍化的话,使大部分内容无障碍的代价就会变的相当小。

当为你的项目列计划时,将无障碍测试分解开来并加入到你的测试管理中去,就像测试任何其它重要目标受众部分(例如桌面目标或者移动浏览器)。早早测试经常测试,理论上运行自动化测试来捕捉可编程察觉的遗失功能(例如缺少图像独一无二的文本或者坏链——具体请看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.

Note: Our Handling common accessibility problems article covers accessibility specifics that should be tested in more detail.

To summarize:

  • Consider accessibility from the start of a project, and test early and often. Just like any other bug, an accessibility problem becomes more expensive to fix the later it is discovered.
  • Bear in mind that a lot of accessibility best practices benefit everyone, not just users with disabilities. For example, lean semantic markup is not only good for screen readers, it is also fast to load and performant, so better for everyone, especially those on mobile devices, and/or slow conections.
  • Publish an accessibility statement on your site and engage with people having problems.

Accessibility guidelines and the law

There are numerous checklists and sets of guidelines available for basing accessibility tests on, which might seem overwhelming at first glance. Our advice is to familiarize yourself with the basic areas in which you need to take care, as well as understanding the high level structures of the guidelines that are most relevant to you.

  • For a start, the W3C has published a large and very detailed document that includes very precise, technology-agnostic criteria for accessibility conformance. These are called the Web Content Accessibility Guidelines (WCAG), and they are not a short read by any means. The criteria are split up into four main categories, which specify how implementations can be made perceivable, operable, understandable, and robust. The best place to get a light introduction and start learning is WCAG at a Glance. There is no need to learn WCAG off by heart — be aware of the major areas of concern, and use a variety of techniques and tools to highlight any areas that don't conform to the WCAG criteria (see below for more).
  • Your country may also have specific legislation governing the need for websites serving their population to be accessible — for example Section 508 of the Rehabilitation Act in the US, Federal Ordinance on Barrier-Free Information Technology in Germany, the Equality Act in the UK, Accessibilità in Italy, the Disability Discrimination Act in Australia, etc.

So while the WCAG is a set of guidelines, your country will probably have laws governing web accessibility, or at least the accessibility of services available to the public (which could include websites, television, physical spaces, etc.) It is a good idea to find out what your laws are. If you make no effort to check that your content is accessible, you could possibly get in trouble with the law if people with diabilities complain about it.

This sounds serious, but really you just need to consider accessibility as a main priority of your web development practices, as outlined above. If in doubt, get advice from a qualified lawyer. We're not going to offer any more advice than this, because we're not lawyers.

Accessibility APIs

Web browsers make use of special accessibility APIs (provided by the underlying operating system) that expose information useful for assistive technologies (ATs) — ATs mostly tend to make use of semantic information, so this information doesn't include things like styling information, or JavaScript. This information is structured in a tree of information called the accessibility tree.

Different operating systems have different accessibility APIs available :

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

Where the native semantic information provided by the HTML elements in your web apps falls down, you can supplement it with features from the WAI-ARIA specification, which add semantic information to the accessibility tree to improve accessibility. You can learn a lot more about WAI-ARIA in our WAI-ARIA basics article.

Summary

This article should have given you a useful high level overview of accessibility, shown you why it's important, and looked at how you can fit it into your workflow. You should now also have a thirst to learn about the implementation details that can make sites accessible, and we'll start on that in the next section, looking at why HTML is a good basis for accessibility.

In this module

文档标签和贡献者

此页面的贡献者: ChuckZhang, Mangone, ziyunfei, 651584008, DennisWang
最后编辑者: ChuckZhang,