Web可访问性（为什么经常会忽略W3C标准） _Web

本文概述

1.” 无障碍设计” 是什么意思？
2.如何确保良好的Web可访问性
3.辅助功能测试：从哪里开始？
4. Web无障碍访问中的常见错误

术语du jour是Web可访问性-我认为, 这是Web设计中最常被误解和应用不良的方面之一。普遍的误解是无障碍环境是专门为残疾人设计的。实际上, 每个人都将从可访问内容中受益, 并且通过在不同平台上或以不同方式访问可访问内容, 你的受众将会增加, 因为他们可以使用你的内容而受到的约束更少。
不幸的是, 许多Web开发人员没有使其内容可访问并且不遵循Web可访问性准则。因此, 许多人在使用他们的设计和享受内容时会遇到不必要的困难。在极端情况下, 某些用户群体根本无法有效使用此类网站。
对于任何开发人员, 设计师或内容创建者而言, 建筑无障碍内容应该是第二天性, 就像考虑坡道, 楼梯和升降机对设计新建筑的建筑师一样。
让我们仔细研究一下幕后花絮, 以及为什么这么多开发人员似乎无缘无故地忽略了Web可访问性标准。
1.” 无障碍设计” 是什么意思？可访问的内容是每个人都可以使用的内容。我们不了解用户如何访问我们内容的所有方面, 因此我们需要提前设计可访问性。
正如我之前强调的那样, 这与残疾人无关, 约占世界人口的15％。在现实生活中, 用户通常最终不会像在开发过程中所设想的那样, 完全不消费内容并与设备进行交互。在许多司法管辖区, 出于法律原因, 还需要可访问的内容。阅读” 为你的组织开发Web无障碍业务案例的法律和政策因素” 以获取有关无障碍性合规性的其他信息。
在考虑可能为用户提供的可访问内容时, 请考虑以下情形：

听不清楚。全球有3.6亿人有听力障碍。音频内容应具有转录本, 视频应具有字幕。
看不清楚。据估计, 全世界有2.85亿人视力障碍：3900万人是盲人, 246人是视力低下。视力不佳的用户使用屏幕阅读器(使用合成语音阅读内容), 可刷新的盲文显示器(屏幕内容显示在盲文显示器上, 并且用户可以使用显示器上的键进行导航并与设备互动) -对比模式。
受阅读困难的影响。患有阅读障碍的人在阅读和理解内容时会遇到困难, 尤其是例如合理的文字或全部大写。
受身体限制。并非所有人都能使用所有设备。例如, 内容导航不仅必须适用于鼠标用户, 还必须适用于不能使用鼠标的用户。
使用移动设备。使你的内容适合小屏幕。允许用户缩放或增加字体大小。

2.如何确保良好的Web可访问性人们使用非常不同的方式浏览和使用内容。有些用户需要其他软件工具的支持, 以帮助他们更轻松地访问内容。这些工具被称为辅助技术, 范围从屏幕阅读器到触摸屏和头部指示器。
但是, 你的应用程序和辅助技术需要互相交谈。并非所有用HTML编写的内容对于辅助技术都是完全可以理解的。为了帮助将内容从” 技术语言” ” 翻译” 为更易理解的语言, 已创建了其他可访问性API标准。
这个基本的Web无障碍图应该使你更好地了解辅助技术的工作方式。

文章图片
资料来源：W3C
为了说明其工作方式, 让我们看一个简单的代码示例：

< a href="http://www.srcmini.com/#" class="button"> Delete< /a>

对于使用屏幕阅读器的人来说, 这段简单的代码意义不大。它甚至具有误导性, 只能作为带有” 删除” 文本的链接阅读。为了帮助用户了解使用哪种方法执行操作, 我们可以使用ARIA(辅助富互联网应用程序)属性(在https://www.w3.org/TR/wai-aria/中指定)覆盖原始角色。我们通过添加属性role =” button” 来更改链接到按钮的含义。这样, 屏幕阅读器会将其阅读为按钮, 而不是链接。哪个更合适。
简而言之, 属性ARIA：

赋予或增强非语义或其他语义元素的语义,
确保动态(实时)内容仍可访问。
提供角色来描述已定义小部件的类型(菜单, 树项目, 滑块, 进度表等)。
提供角色来描述网页的结构(标题, 区域和表格)。
提供小部件的状态(已选中, 具有弹出窗口等)。
提供用于拖放的属性, 这些属性描述了拖动源和放置目标。

Web设计中的可访问性是什么？
每当你设计内容时, 都要考虑两件事：内容的可感知性和可操作性。我们来看一些示例, 以说明Web设计中的可访问性。
假设你要设计一个自定义的select下拉元素。这是设计元素时要考虑的事项：

标记不同的状态：启用, 禁用, 只读。
当元素获得焦点/悬停状态时对其进行标记。
标记每个选项元素的焦点/悬停状态。
当仅将文本放大到200％时, 请确保内容仍然可读。
确保文本和背景之间有足够的对比度。它可以帮助视力不佳的人或处于极端光照条件下的设备(例如暴露于直射阳光下或亮度低的显示器上)阅读内容。

另一个示例可能是选择一种颜色来描述状态。在设计用户可以选择颜色的区域时, 需要考虑以下事项：

有些人很难区分某些颜色。因此, 绿色并不代表所有访客都绿色。要解决此问题, 请为每种颜色添加描述目的的描述。
标记每个元素的焦点/悬停状态。
确保元素之间有足够的空间, 以便可以轻松激活每个元素, 例如在视口较小的设备上。

3.辅助功能测试：从哪里开始？没有一种方法可以检查并确保可以完全访问Web内容。需要使用多种技术来验证和解决可访问性问题。你可以先定义问题, 解决方案和优先级。
定义问题
处理可访问性问题时, 请始终尝试为每个问题创建一张票证且标题清晰。这应该简化对问题的理解并有助于定义优先级。
不良示例：用户无法使用页面上的键盘。
很好的例子：无法在主菜单中使用键盘导航。
这个不好的例子导致一个案例, 很难在短时间内结案。关于多个主题的讨论也可能在注释部分开始, 因为票证标题太笼统了。
很好的例子恰好指出了问题, 仅关注一件事：主菜单中的键盘导航。
优先处理Web可访问性问题
优先级很重要, 因为它们定义了必须首先解决的问题。例如, WCAG分为三个一致性级别：A, AA, AAA, 这意味着你应该从最低级别A开始, 但这并不自动意味着AA和AAA级别仅仅是” 不错” 。所有级别都很重要, 重要的是不要优先考虑仅A级就足够了。
但是, 有时有时很难理解WCAG级别(或任何其他准则), 并且为了简化一点, 还可以考虑以下优先级定义：

严重–阻止用户使用应用程序的问题。没有可用的解决方法。
重大–问题使应用程序难以使用和/或迷失方向, 但不会妨碍用户完成操作的能力。
轻微–令人讨厌但不会妨碍使用的问题, 或者可能对该应用程序进行的增强。
信息–不遵守最佳做法。一般改进建议。

解决方案
指导原则(我的意思是WCAG, 第508节或ADA)都不能为你提供有关应如何解决特定问题的技术代码的直接解决方案。它们仅定义预期的行为。但是, WCAG还定义了测试程序, 应该有助于理解如何重现此问题, 并且有一个自动WCAG监视社区小组, 这是一个W3C社区, 其重点是为自动和半自动的Web可访问性测试开发可靠的规则。
WCAG技术G4的示例(“ 允许暂停内容并从暂停位置重新开始” )：
测试程序
在具有移动或滚动内容的页面上,

使用网页中或用户代理提供的机制来暂停移动或滚动内容。
检查移动或滚动是否已停止并且不会自行重启。
使用提供的机制重新启动移动内容。
检查移动或滚动从停止点是否已恢复。

预期成绩
2号和4号是真的。
我们可以看到, 没有技术解决方案, 但是定义了预期的行为。 Web开发人员如何实现它取决于他们。
Web无障碍指南和W3C标准
遵循基本的Web标准应该是你的起点：

最常见的是称为WCAG的Web内容可访问性指南。 WCAG 2.0是” 稳定, 可参考的技术标准。它有12条准则, 这些准则按照4条原则进行组织：可感知, 可操作, 可理解和强大。对于每条准则, 都有可测试的成功标准, 分为三个级别：A, AA和AAA。”
WCAG 2.0技术是面向Web内容作者的综合指南。
W3C媒体可访问性用户要求—本文档介绍了残障用户对Web上的音频和视频的可访问性要求。
二十一世纪通信和视频无障碍法案– CVAA分为两个主要标题或部分。标题I涉及通信访问, 以使残疾人能够完全使用宽带来提供产品和服务。无障碍法案第二章开辟了新局面, 使残疾人更容易在电视和互联网上观看视频节目。
第508节-信息和通信技术(ICT)的可访问性要求, 适用于所有开发, 采购, 维护或使用电子和信息技术的联邦机构。
《美国残疾人法案》(ADA)第二章下的网站可访问性-在这里, 你将了解ADA第二章的非歧视性要求如何适用于州和地方政府网站。

Web可访问性测试：如何知道我的内容是否可访问？
以下是一些基本的基本检查点, 这些检查点应有助于你从第一步开始就可以更轻松地访问Web内容：

验证你的HTML。确保HTML结构没有错误, 因为辅助技术在解释页面内容时可能会遇到问题。
单独使用键盘进行测试。确保仅使用键盘即可访问所有可操作元素。另外, 你还必须能够使用键盘执行所有操作, 例如提交表单。
使用辅助功能测试工具和验证器进行测试。使用可扫描和验证潜在可访问性错误的工具。
动态内容。通知屏幕阅读器用户有关动态变化的信息, 例如搜索结果发生变化时。
不要依靠颜色来描述含义。将颜色与说明一起使用, 例如[黄框]警告。
请勿将轮廓移开。这是使用CSS属性大纲通常删除的功能：0; 请勿这样做, 因为键盘用户将失去页面方向。你可以考虑删除非键盘用户的焦点轮廓, 但始终为键盘用户提供焦点轮廓。
错误消息。始终告诉用户如何纠正错误。不要只是声明数据无效。
制表符顺序。确保基于选项卡的导航遵循在图形用户界面中建立的约定。至少, 它应遵循应用程序默认语言的阅读方向。例如, 在英语中, 阅读顺序是从上到下, 从左到右；阿拉伯语是从上到下, 从右到左。
放大。在将文本最多放大200％时, 请确保页面内容仍然可读。
关闭图像。你仍然可以舒适地使用该页面吗？所有图像都有替代文字吗？
屏幕阅读器。测试你是否可以使用至少一个屏幕阅读器(例如VoiceOver, Windows Narrator或NVDA)阅读和浏览内容。
高对比度模式。切换到高对比度模式时, 请检查内容是否仍然可读。
字体大小。确保页面上的字体大小不小于10px。

4. Web无障碍访问中的常见错误最常见的错误是无法在开发之前确定可访问性要求。不幸的是, 后来的可访问性将成为开发的一部分, 实施解决方案将变得更加困难。
这是开发人员在实现可访问性时犯的一些最常见错误的列表：

仅使用键盘无法浏览内容。
滥用CSS outline属性。在大多数情况下, 轮廓为：0；使用, 表示每个可操作元素周围的轮廓不再可见。不要使用大纲：0; 或大纲：0！important; 。除非有其他选择, 例如使用border CSS属性, 否则用户在浏览内容时将无法查看当前关注的元素。
例如由于DOM操纵或使用blur()方法而使当前元素失去焦点。对于单页应用程序, 通常会发生这种情况。
屏幕阅读器用户不会收到任何更改的通知, 例如, 已使用XMLHttpRequest API下载了内容, 并且UI上已呈现新更改, 但未通知用户。单页应用程序经常会发生这种情况。
无法访问的日期选择器。在许多情况下, 使用无法访问的日期选择器。用户无法使用键盘浏览日历选项。
使用声称可自动修复可访问性问题的扩展。仔细使用它们并检查结果。滥用它们会带来比解决方案更多的问题。
将索引号大于0的元素添加到元素tabindex属性中。使用索引号大于0的tabindex的目的主要是为了” 纠正” 导航路径。但是, 请考虑更改HTML结构以获取导航的自然路径。使用tabindex对其进行操作可能会导致维护麻烦和无法预测的导航路径。
标题层次结构错误。不幸的是, 它仍然很常见, 但是标头层次结构构建得不正确, 例如< h1> , < h5> 和< h2> 。屏幕阅读器用户正在使用标题来浏览各个部分, 结构不当会造成混淆, 因为难以理解上下文。
缺少高对比度支持。有人在高对比度模式下使用其软件。确保你的内容仍然可识别。
使用无法访问的验证码解决方案。不幸的是, 我所知道的所有验证码都无法访问或很难使用。
太多和/或不可暂停的动画。自动播放视频, 广告或图像轮播会让人分心。
大块文字。在一个很大的单个块中压缩的文本, 没有空格, 逗号或点。很难读。分成较小的块, 更多的段落和子标题有助于更好地组织文本内容。
缩放问题。放大至200％时, 请确保内容仍然可读和可浏览。
依靠颜色。通常, 元素的状态仅用颜色标记, 例如, 警告状态仅用黄色项目符号标记；色盲人不会以相同的方式感知这种颜色。
可点击/可点击的小目标。可点击/可点击区域通常太小。使其更大, 使用户可以更轻松地激活它们。

但是, 如何改善Web可访问性？
定义问题是一回事。修复它是另一回事, 而且通常看起来并不那么容易。这是因为可访问性API的实现不一致, 有时我们需要找到解决方法, 甚至接受在尝试解决问题时根本无法正常工作的事实。
在工具方面, 没有一个工具可以检查所有可能的组合, 但是作为一个良好的开端, 这些工具应该可以帮助：

W3C标记验证服务—只为确保HTML内容没有错误。如果HTML结构有错误, 则说明输出是不可预测的, 无法正确处理, 尤其是使用其他辅助技术时。
https://www.w3.org/WAI/ER/tools/ —一系列程序或在线服务, 可帮助你确定网站内容是否符合辅助功能准则。
我的工具ASLint https://www.aslint.org/可以帮助你找到可访问性问题。

请始终牢记, 无障碍工具无法代替手动测试, 因为并非所有场景都可以完全或完全自动化, 例如, 检查位置为” 固定” 的元素的亮度对比度。
关注阻止应用程序使用的问题, 例如, 用户无法使用键盘浏览菜单。
为什么使内容可访问性很重要
每个人都希望尽可能广泛地传播其内容。从覆盖更大的受众到改善所有用户的用户体验, 可访问性在许多方面都可以在该领域提供帮助。此外, 可访问性不仅仅适用于你传统上认为的残疾人。无论是正在衰老并经历随之而来的身体变化的人, 是在晴天慢跑的人, 需要在手机上进行自动对比度调整, 还是一个父母手里满是购物袋的人想要通过语音发送短信, 都可以访问技术是所有用户可能会不时使用的技术。
此外, 积极的影响是, 完全符合WCAG 2.0标准的可访问内容更容易被搜索引擎抓取和理解, 并且可能对网站的排名产生重大影响。因此, 可访问的设计可以为网站带来更多流量。
最后, 这是你需要考虑的一些统计信息：