关于WCAG 2.1草案的反馈

概观

以下是关于的反馈WCAG第一次公开工作草案2.1WebAIM目前支持采用5这些成功标准起草(一些建议改进)将支持其他一些(通过澄清和改进),但不符合目前提出的一致性级别WebAIM不支持,反对或强烈反对采纳所起草的大多数拟议成功标准。

我们缺乏对成功标准的支持并不意味着我们反对所提供的原则或建议,而只是表明我们认为目前无法纳入WCAG。

我们赞扬工作组就其取得的进展所做的努力,但如果要成为一个成功且广泛采用的W3C建议书,则有必要认真考虑WCAG 2.1的现状和未来方向。

许多成功的标准草案非常难以理解,一些近乎不知所云这特别(并且具有讽刺意味)适用于旨在解决认知可及性问题的成功标准如目前提出的那样,大多数这些成功标准几乎不可能被更广泛的受众理解或接受。

此外,许多成功标准不可测试,与现有成功标准相冲突,不符合WCAG自身的要求,或者根本不可能被网络作者采用提议的成功标准中的17个是A,11是AA,没有一个是AAA提出了许多这样的成功标准的严重程度过高水平可能是由作者或标准组织。

没有解决基础WCAG 2.0问题

2.1更新的前提是不会修改2008年最终确定的现有2.0成功标准While we understand the desire for backwards-compatibility, it is disappointing that a more substantive update has not been attempted没有WCAG 2.0在5年前发布了WebAIM的问题在这个草案已经解决我们强烈建议工作组重新考虑解决现有成功标准的差距和不足之处我们认为有必要进行此类更改以解决下面记录的许多问题。

另一个主要问题是WCAG 2.1的一些成功标准基本上会使现有的成功标准无效,因为它引入了更广泛的一致性要求(通常在更高的水平),而不是2.0除非删除或更新无效的2.0成功标准以反映2.1要求,否则这肯定会引起很多混淆作为一个例子,通过要求文本大小级400%,当前文本大小成功标准200% AA将变得毫无意义,因此必须被删除以避免混乱。

SC 1.3.4 - 支持个性化(最低)

While the premise of this Success Criteria (SC) is to ensure that visual presentation is identified via underlying semantics (something already required under 1.3.1, etc.) to allow customization, it additionally requires author inclusion of specific customization via author-settable properties and attributes that do not yet fully exist由于WCAG技术不应该是规范性的,并且因为这些技术尚未在ARIA或其他标准化,可访问性支持的方式中可用,因此需要重要的作者修改或定制选项以使其他符合要求的内容符合WCAG 2.1 A级一致性。

WebAIM不支持采用此草案的SC。

SC 1.4.10 - 线性化

将内容重新回流到单个列中可提供许多好处然而,这个SC应该是指澄清不抑制回流基于用户自定义内容而不是建议作者必须提供用于回流内容的“机制”,例如每个网页上的“线性化页面”控件。

此外,这个SC应该主要应用范围文字内容,一般长文本块如果应用于其他类型的内容,例如水平方向的工具栏,树窗口小部件等,这将需要大量的作者努力,并且将导致非标准的演示,这通常是较少的万才体育网站。

澄清一些重叠的线性化和文本大小可能是必要的没有水平滚动,400%文本大小也需要单列回流吗?

WebAIM支持此SC的前提,但不支持采用此SC作为草案。

SC 1.4.11 - 调整内容大小

主要关注的是,这个A级成功标准要求400%的文本大小调整,这将使现有的1.4.4 AA级成功标准无效,这需要200%的文本大小调整这将导致混淆为什么AA级SC需要比新的A级SC更低的尺寸阈值。

满足此SC将需要许多Web作者的大量努力很少有受欢迎的测试站点接近达到400%的测量阈值。

WebAIM suggests a more practical approach – perhaps 200% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level A, 400% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level AA, and the draft SC as proposed at Level AAA.

希望工作组还将处理真正文本大小的内容丢失(即,不缩放页面,但只增加文本大小)到合理的水平 - 也许150%这和现有的Resize Text SC一般忽略了这个观众代表38%的WebAIM低视力用户调查受访者

SC 1.4.12——图形对比

我们认为,需要对当前WCAG定义的对比度要求与现代显示器和用户的相关性进行进一步的澄清和研究这些WCAG公式和对比度阈值主要基于2001年在Amiga 1000显示器上进行的研究从那时起,显示技术和用户熟练程度肯定发生了显着变化,但很少有人质疑这项研究对现代网络的适用性WebAIM很快将对人类对比度的感知进行研究,并将此用户数据映射到WCAG阈值,以提供对这些问题的一些了解。

与现有的文本对比成功标准,额外需要清晰定义的可测试性与梯度背景、文本(或者,在这种情况下,图形元素)边界/阴影,“忙”背景,等等在许多设计中,4.5:1阈值将导致非常有限的颜色选项。

WebAIM高度欢迎为图形内容添加对比度要求,但需要额外的清晰度和范围才能使此成功标准可行。

SC 1.4.13 - 打印

的能力(或缺乏)的用户代理正确应用用户放大打印文档不应该是作者的责任这一成功标准远远超出了WCAG的范围This SC would essentially require authors to become familiar with user agent print deficiencies and bugs, and force them to apply user agent specific@media打印解决这些问题的风格。

WebAIM反对采用此SC作为草案。

SC 1.4.14——用户界面组件的对比(最小)

这个SC很难理解为书面形式目前尚不清楚需要测量哪些组件与哪些组件相对应需要进一步澄清尽管目前缺乏清晰度,但是非常欢迎添加用于指示元素的用户交互状态的对比度要求。

SC 1.4.15 - 调整文本

正如许多GitHub评论所指出的那样,这个成功标准在编写时非常成问题,但已经提出了值得注意的改进我们普遍同意大卫在这里提出了措辞,有两个例外......

首先,它应该澄清,“文本页面的样式可以覆盖由用户……”排除这种语言或包含“提供机制......”文本将总是导致作者相信这需要他们通过页内小部件或用户偏好提供功能,而这不是(我们相信)意图。

其次,“字体系列”的用户覆盖为测试打开了太多变量,因此应该删除What if the font characters in the user-specified font are significantly disproportionate to the author-supplied characters in size, shape, etc.? The variations introduced by font family customization are, we believe, adequately covered by the manipulation of line, letter, and word spacing确保一致可测试性的唯一其他可能性是定义特定的字体面(例如,Verdana),其引入其他显着的困难。

WebAIM支持这个成功标准的一般概念,但是需要额外的澄清和考虑为了是可行的。

SC 1.4.16 - 弹出干扰

很难评论这个成功标准,因为为它呈现的描述和方案不匹配成功的标准文本吗It is entirely unclear what the intention of this SC even is, but I’ll attempt to address some of the issues as we understand them.

SC语言明确地免除了用户代理呈现标题文本,但是描述和示例具体且几乎专门针对用户代理呈现标题文本由于标题文本呈现主要由用户代理控制,因此我们认为此SC不应涵盖标题属性呈现。

这些描述涉及放大的鼠标光标,模糊了“工具提示”的内容,并描述了允许多种机制来触发“工具提示”内容(这已经被键盘指南部分涵盖),但SC文本没有解决这些问题。这里显然有一个编辑断开。

假设SC实际上关于模糊触发内容的“工具提示”内容(例如,链接的工具提示模糊了链接文本),这主要由用户代理处理要么似乎不是特定于残疾的问题,而是在可访问性指南中没有的一般可用性和设计考虑因素如果没有人能够看到触发内容,那么残障用户就没有不同的体验当这种交互模型可能是必要的并且符合要求时,要求作者提供关闭工具提示内容的机制也是不合理的。

WebAIM不支持采用此草案的SC。

SC 2.1.4 - 语音输入

“内容的所有功能都不会阻碍......”难以理解和衡量建议的重写 - “可以通过语音输入触发的命令不受作者定义的功能的阻碍。”

该成功标准提出了两种情况第一种是当用户说出与页面上的功能元素匹配的单词时,语音控制软件触发该功能元素而无需用户打算这样做假设言论控制实际上这种方式工作(我的经验是,触发功能需要额外的语音激活,如说“点击产品”而不是简单的“产品”),避免这种冲突的唯一方法是作者不提供功能元素或不使用单词来定义它们这显然是站不住脚的这是一个模糊的用户代理问题,不应该与作者有关​​。

另一种情况呈现这样一种情况:在视觉上不会用文本识别文本“提交”的按钮,从而导致语音控制用户不知道如何激活该控件2.0中的其他成功标准略微涵盖了这种情况,但这个提议的SC文本根本没有涵盖重新构建此SC以解决此问题将是一个值得欢迎的改进 - 也许“接口控件具有编程确定的文本,该文本与该控件的可视化呈现的文本或功能相匹配或相当”......或类似。

WebAIM不支持采用此草案的SC。

SC 2.2.6 - 超时

这种A级成功标准通常是不可测试的没有办法客观地衡量“轻松回归”,“简单行动”或“简单易懂的语言”这也省略了时间限制必不可少或不可避免的明显例外情况。

要求作者记录所有用户操作和状态(可能甚至是客户端操作)是不合理或不合适的,然后为放弃然后在一周之后返回活动的用户提供无缝数据丢失在许多情况下,无法跟踪用户状态在许多情况下,这种跟踪将是不道德和非法的 - 示例场景表明旅行网站必须存储然后重新出现一周后用户的信用卡号,即使没有用户许可也是如此。

提前通知用户的要求似乎需要在具有定时组件的所有页面上冗长且混乱的信息性消息 - “您的会话将在20分钟内超时在您注销之前,您将有一个五分钟的警告期,并且有120秒的时间来响应此警告消息。“这种警告的复杂性可能比超时本身带来更多的困难和开销。

超时引入的主要问题已经通过现有的2.1.1 SC(A级)得到了普遍解决。

WebAIM不支持采用此SC作为草案,但可能支持AAA级的澄清和改进版本。

SC 2.2.7 - 来自互动的动画

The impetus for this SC is to address vestibular issues (e.g., dizziness or nausea) associated with parallax scrolling (simultaneous foreground and background scrolling in different directions or at different speeds), but the language does not make it clear that scrolling is “a user action”清晰度是必要的。

此SC规定了明确的阈值(视口的1/3和3秒),没有明确的数据来支持这些特定值的影响虽然触发前庭疾病肯定会对用户产生影响,但需要高质量的用户研究来为A级SC提供理由,这将对网络/移动设计和用户交互产生显着影响。

此成功标准将使许多常见且通常有用的交互模型不一致 - 例如在移动设备上滑动动画,弹出菜单动画,焦点滚动等。

WebAIM将支持采用澄清/这SC的改进版本,但可能在AA、AAA级,除非另外,确定的研究表明一个明确的映射定义的阈值的用户影响显著。

SC 2.2.8 - 中断(最低)

这个成功标准与2.2.1和2.2.6不一致,后者规定弹出窗口和通知以告知超时它还与新的SC 3.2.8(内容更改)冲突,后者要求向用户通知内容更改作者如何通知用户超时或内容的改变以满足此类通知时,将一个成功标准不允许被另一个吗?

“中断”没有清晰的定义Are dynamic form validation messages (such as slightly delayed indications of an unavailable username) “interruptions”? Auto-complete suggestions? Chat messages or new e-mail notifications that are a core function of an application? In cases where interruptions are important, but not an “emergency”, critical functionality could be lost, thus resulting in notable negative impact on the user experience.

在标准机制可用于客户端控制此类中断之前,满足此成功标准的唯一机制是通过用户控件,该控件本身引入了认知负载并且引人注目的作者努力这与现代Web应用程序中的重要和关键消息传递系统不一致。

WebAIM将支持采用此SC,但仅限于AAA级。

SC 2.4.11 - 单键快捷键

对成功标准的解释表明它旨在阻止与语音控制软件在页面中触发单键快捷方式的冲突这似乎明显属于语音控制用户代理的区域,以区分听写输入和用户控制的激活如果语音控制软件在任何时候触发“A”快捷方式,则该字母或包含该字母的单词被表达(至少没有限定词 - “点击A”),这显然是用户代理缺陷,而不是创作问题。

然而,SC的语言(“单个字符的快捷方式并不是唯一的方式激活控制,除非…”)一般不会帮助在这个场景中,作者只是需要为用户提供一个额外的“方式”这个功能例如,所呈现的“Y”触发Gmail的“存档消息”功能的场景永远不会失败,因为可用于执行此功能的附加接口选项(例如,“存档消息”接口按钮)作者依赖它是相对罕见的完全在快捷键上触发此类功能。

此SC应另外澄清为仅适用于作者定义的快捷方式,而不适用于用户代理快捷方式并且仅限于字母数字快捷键,而不是Esc(关闭菜单/对话框)或空格(触发复选框),例如否则,这将导致作者覆盖用户代理功能,例如创建自定义选择输入,因为浏览器另外提供单键功能(例如,在状态选择菜单上点击“U”跳转到“犹他州”)这也可以解释为禁止自动完成功能(例如),其为每个按键提供不同的控制/选项。

此SC还不鼓励使用单键快捷键,这对于许多其他残疾用户非常有用,主要是依赖于高效键盘交互的视觉或运动障碍用户It would be very atypical for a Level A SC to discourage a technique that provides long-standing, accessibility-supported functionality for many users in order to address the needs of a small audience of users in an extremely narrow scope of applicability – when users with voice control software (that is incapable of differentiating user input from activation of user controls) errantly voice a command that matches a single-key short defined in an application that doesn’t have an alternative for that functionality or an option to customize or disable that shortcut这似乎更适合AAA或作为咨询技术。

WebAIM不支持采用此SC作为草案,但可能支持AAA级的澄清和改进版本。

SC 2.5.1 - 目标尺寸

术语“目标”应该阐明这适用于用户激活的链接或控件的交互区域这个词目前相当模糊“主要目的或功能”也很模糊,难以衡量。

当链接/控件“具有其目标确实满足最小大小要求的备用链接/控件时”定义了一个例外。考虑到页面底部的脚注部分的上标单个字符链接对于这个SC来说,这将是一个非常普遍的失败这个脚注内容很容易通过滚动浏览器来实现虽然不像链接的适当大小的目标那么容易,但我们认为,这比要求作者在满足此大小要求的同一页面上提供“替代链接/控制”更有用。应该考虑为页内的内容已经万博体育官网网址没有激活控制。

由于许多现有的符合性Web内容在采用此SC时会变得不符合要求,因此WebAIM支持在AA级采用此SC,并进行如上所述的其他说明。

SC 2.5.2 - 带有附加传感器的指针输入

当附加指针传感器信息对功能至关重要时,应添加例外WebAIM否则支持采用此SC作为草案。

SC 2.5.3 - 触摸辅助技术

这就要求作者不引入功能与屏幕阅读器冲突覆盖的触摸事件(或提供一种替代机制,如“移动菜单按钮”)主要困难在于,无数当前且尚未定义的屏幕阅读器触摸事件是作者无法完全测试或考虑的因此,该SC似乎基本上要求不使用触摸事件或总是提供替代机制我们不相信这是意图。

这似乎主要是用户代理问题 - 它们应该允许用户指定触摸事件是由辅助技术处理还是传递到平台(就像Windows屏幕阅读器中的关键事件一样)。

我们很可能误解了这个SC的一个方面,但它似乎不适用于WCAG。

SC 2.5.4 - 指针手势

For touch interfaces, because 2.5.3 (above) seemingly requires alternative mechanisms (such as a “a mobile menu button”) for all simple pointer gestures (and, presumably, all complex ones too), this seems to be a moot requirement if 2.5.3 stands as isWhy would an author provide a simple gesture alternative for a complex gesture when both the simple and complex gestures require a standard button alternative? Or perhaps we’re misinterpreting all of this.

这将产生显著的影响在许多标准和(可能)否则一致的接口,如谷歌地图,许多移动接口等WebAIM支持此成功标准的一般意图,但似乎最符合AA级。

SC 2.6.1 - 设备传感器

WebAIM支持采用SC的起草。

SC 2.6.2 - 方向

此成功标准似乎主要侧重于用户代理的灵活性,而不是创作实践用户通常不可能完全限制设备的方向网页内容And if this is or were made possible, would it not be incumbent on the user agent to allow end user override or customization of this (just as they should allow resizing of pixel-defined text, pinch-to-zoom functionality, etc.)?

此成功标准正在解决的问题通常是Web内容通常不存在,或者需要澄清,以便作者了解要避免哪些技术。

SC 3.1.7 - 简单语言

此成功标准具有以下问题:

  • 几乎是不可能的测试由于高水平的主体性和无法测量提供的模糊的术语和定义。
  • 令人困惑的是,(具有讽刺意味的是)不符合其对简单或具体语言的要求
  • 它不适用于各种Web内容
  • 许多的需求似乎任意定义和缺乏研究的证据(例如,为什么1500年最常见的字最多?)
  • How would the 1500 most common words be defined in a way that is accurately testable? Would these be defined in normative WCAG for all languages? If not, the changes to external lists of common words would cause the conformance of content to be subject to changes in language usage over time这将需要进行大量且频繁的测试,以确定所使用的所有单词是否仍在“公共”列表中。
  • 它依赖于用户定义的内容自定义机制(例如,使用文字替代方法自动替换非文字文本),这些机制尚不存在如果没有这样的技术,作者必须提供非常繁琐的机制来以编程方式提供这样的替代方案(并且这些控制本身对于用户来说本身就很复杂)。
  • 它强加的编辑和内容限制远远超出了WCAG的范围,特别是对于A级一致性

虽然显然是善意的(其中许多是这样的最佳做法肯定会为提高许多用户的可理解性做很多事情),这个成功标准过于严格,限制性太强,太主观,不能被作者合理地应用于大多数网络内容。

WebAIM不支持采用此草案的SC。

SC 3.1.8 - 可管理块

与3.1.7一样,此成功标准可能不适用于许多内容实例它似乎过于严格,难以理解和测试需要对这些定义的阈值进行额外的研究这是否适用于口头/听觉“语句”以及文本“语句”?

WebAIM支持采用此SC,但仅限于AAA级。

SC 3.1.9 - 额外符号

虽然在关键控件的开头添加符号可能对某些用户有帮助,但它肯定会增加许多其他用户的认知负担和难度,特别是在相关或通常理解的符号不可用于该关键功能的区域中。

条款如“相关主题”、“重大经济损失”,“一个病人的病情恶化或有效的权利”,“安全、风险、隐私、健康或机会”,等等是非常主观和无法衡量的。

WebAIM不支持采用SC的起草,但可能会支持另一种AAA级,充分解决这些问题。

SC 3.2.6 -意外激活

Additional clarification of “single-pointer activation” is warranted, otherwise WebAIM supports adoption of this success criterion, though it seems best aligned with Level AA.

SC 3.2.7 - 熟悉的设计(最低)

很难评论这个成功标准,因为它几乎无法理解和不可测试。

How does one measure “easily identifiable and available”? This is not defined.

Why were only “help, navigation to help, and search forms” identified for this design requirement? Is this based on research?

Does this require that all pages provide these three items? Or does this only apply in cases where these are already present?

How can a “platform specific user interface design” apply to web content which is, by its nature, not platform specific? How would an author know what these design patterns are (short of defining them all in normative content)? When platform specific design patterns change, does content that was previous conformant suddenly become non-conformant?

Measuring whether a “design was used successfully by users in a prior version” may not be possible to authors lacking access to a time machineWhy would success in a prior version be relevant to success in the current version? How would an author know that a user needs the fall-back to the prior version short of the user indicating this? Or must the fall-back always be provided (thus making it the primary version, not a fall-back)? Providing a fall-back to a prior “successful” version for only these critical elements would likely violate 3.2.4 which requires consistent identification of such items.

如果理解正确,这将为Web内容和应用程序中最常见和最重要的项目(通常是可用性)规定非常具体和严格的设计约束。

WebAIM强烈反对通过该草案的SC。

SC 3.2.8 - 内容的变更

Web通常支持此SC但是,目前尚不清楚“每分钟5次通知”豁免的适用情况Because these notifications would generally be triggered by user activation, if the interface allows more than 5 activations per minute, does this success criterion no longer apply? Because one can’t generally control the number of user activations, how is this testable?

Or is this suggesting that after 5 notifications in a minute that the author can disable the notification and still be conformant? In this case, can the notifications be disabled from thenceforth, or must they be re-enabled as soon as the “5 per minute” threshold no longer is applicable (e.g., no longer than 1 minute after the last activation)?

Or is this only intended for notifications that are not user activated, such as an interface that updates content automatically more than 5 times per minute? Clarification on this exemption is needed.

作为编辑说明,“程序通知”的定义与成功标准无关。

假设澄清了上述内容,WebAIM支持采用此成功标准。

SC 3.3.7 - 最大限度地减少用户错误

这需要以可能违反数据完整性和可用性的方式操纵用户输入的数据(例如,3.2.2输入 - A级的潜在故障)。

如中所述编者注, “common input error” needs additional clarity without relying on non-normative content.

“已经报告或记录的错误”[原文如此]有一次“无法衡量这也将创建一个场景,符合内容由用户可以立即呈现的不只是报告一个错误如何定义或衡量“报告”?

“......并且有一种已知的方法来识别它们”知道谁以及以什么方式?

对“可以可靠地进行修正的地方”的解释会有很大差异,肯定会受到背景,文化和技术的依赖。

WebAIM反对采用此SC作为草案。

SC 3.3.8 - 撤消

“Users are provided with the ability…” Does this require author-supplied mechanisms? Is the Back button sufficient?

“明确标记”是主观的,无法衡量的“......回到他们所处的地方”是模棱两可的Which place? For how long after the action must the user be able to undo and be returned to “the place”? Must a vendor allow a user to “undo” a financial transaction?

“……意外丢失数据”是主观的给用户,不是作者,因此无法计量的。

这个提议级别3.3.4 SC通常呈现现有(AA)水平和3.3.6(AAA级)关于错误预防争议,因为这将需要更高水平的错误恢复。

除非有重大变化和澄清,否则WebAIM强烈反对采用此草案。

SC 3.3.9 - 提供支持

“提供的内容可以帮助用户理解......”仅这一点就使得这个SC无法控制What types of content? How is this content provided? How can one measure whether content helps or does not help user understanding? How much must it help? Which users?

是否有应提供“内容”类型的示例以帮助用户理解“表单”?

Is there some research-based metric for defining “long documents” as over 300 words? How would providing additional content always aid in understanding content that is already “too long”?

要求额外的内容会增加认知负担,并可能降低一些有认知或学习障碍的用户的可理解性造成此类潜在冲突的WCAG成功标准通常在AAA级定义。

虽然善意且旨在提供最佳实践指导,但这一成功标准对大多数Web内容来说都是混乱,不可测试和站不住脚的WebAIM反对采用此SC作为草案。

评论

  1. 劳拉希尔兹

    WCAG 2.1的最新草案发表4/19/2017,不包括SC(建议),打破了这个页面上的一些链接请参阅2017年2月28日之前发布的WCAG 2.1草案,查看[建议] SC:https://www.w3.org/TR/2017/WD-WCAG21-20170228/

  2. 杰瑞德史密斯

    劳拉 -

    谢谢你指出这一点我已更新链接以指向2.1的快照版本。