前几天我与一些前端人员聊天,讨论为什么这么多公司难以构建可访问的网站。为什么可访问的网站如此难以构建? 我们学习 HTML,确保内容语义化,然后——瞧!——我们就拥有了一个可访问的网站。在谈话过程中,有人提到了 达美乐披萨的法律案件,这可能是公司因缺乏可访问性而被起诉的最公开的例子。
以下是从该链接中获得的一个有趣的信息片段
据CNBC报道,去年因网站不可访问而提起的诉讼数量比 2017 年增加了 58%,超过 2200 起。
网站不可访问不仅是设计师和工程师需要考虑的问题,也是公司法律团队面临的严重问题。值得庆幸的是,似乎越来越多的此类案件将被提上法庭,而且(我个人希望)这将促使人们更加关注语义和前端开发最佳实践。虽然我想,公司会为了网络的最佳利益而构建符合 基本要求 的网站,而无需面临法律威胁,但我们绝对需要将不可访问的网站非法化,以便人们真正关注这个问题。
但是!我也担心将可能仅仅是缺乏知识归因于恶意。我认为很多网站的可访问性很差,并不是因为人们不在乎,而是因为他们根本不知道存在问题。随着我与前端工程师的谈话继续,我意识到,可访问性没有得到认真解决的原因可能与带宽、经验或金钱无关。
我认为问题在于,网站的可访问性可能会被隐形地、悄无声息地破坏。
举个例子:在开发网站时,JavaScript 错误可能会被捕获,因为如果出现问题,一切都会崩溃。CSS 错误也会被捕获,因为某些内容看起来会不正常。但是,网站的可访问性或性能可能会在一夜之间从良好状态变成糟糕状态,而且没有任何警告。修复这些隐形损坏的唯一方法是首先使它们可见。
所以,这里有一个想法:如果我们的文本编辑器能够捕获可访问性问题并在开发过程中向我们显示它们会怎么样?它可能看起来像这样

我相信还有很多其他方法可以使可访问性问题更加公开和可见。已经存在诸如 Lighthouse 和浏览器扩展之类的工具,但将可访问性(甚至性能,另一个无声的失败)作为我们分秒必争的工作流程的一部分,可以确保我们不会忽略它。这样的工具可以鼓励我们了解问题,为我们提供潜在解决方案的链接,并鼓励我们所有人关注前端开发中一个相对不被理解的部分。
能够为混合点击/键盘事件提供原生支持,专门用于复制链接行为,这也将非常棒。
我同意你的观点,但使用 polyfill 就足够了(假设允许相关的鼠标和键盘事件冒泡到 DOM 的顶部)。只需将“click”和“keydown”事件的处理程序附加到文档(),如果在链接或按钮/复选框/单选按钮上发生了点击或键盘按下(链接使用 Enter 键,按钮、复选框和单选按钮使用空格键),则从原始元素分派您的“混合”事件。然后,您可以将混合事件的监听器附加到任何所需的链接或按钮。
我写过一些非常不可访问的代码,这并不是因为我不在乎。事实上,当我开始尝试编写可访问的代码时,我让情况变得更糟了。
我建议从 Web 开发(和设计)教育的伊始就教授 Web 可访问性,并且公司应该要求并支付认证费用。此外,我们需要国会真正将 WCAG 作为法律要求。尽管网站受 ADA 涵盖,但与实体空间不同,目前还没有 Web 可访问性的法律标准。
我知道你的意思,让事情变得更糟 :-D
我认为这很有挑战性。我记得在处理一个项目时,对结果非常满意。问题是,由于我对正在发生的事情有非常清晰的了解和认识,我的大脑将这些点连接了起来。当一位视力受损的同事来帮助我时,我很快就幻灭了 :-D
同意!新开发人员没有学习正确的/可访问的语义 HTML5,也没有学习 ARIA。我担任可访问性 SME 已有 20 多年。a11y 教育是一个问题。
我认为为什么它们不可访问有很多分层的答案。
根据我的个人经验,以下是一些原因
遗留网站 – 我们有一些建于 2007 年的网站仍在生产中。它们的业务优先级较低,因此常常被忽略。
内容贡献者 – 我们使用一个内容管理系统,许多能力各异的人员都在使用它。并非所有人都尽职尽责。我们试图去捕捉这些问题,但这并不意味着我们总是能看到所有问题。
带宽 – 只有少数几名开发人员负责 60 多个网站。而且我们承担着“开发人员”以外的许多职责。
第三方 – 我们使用第三方来处理诸如电子商务系统之类的事情。有些对我们的反馈反应不佳。当它们与遗留 POS 系统等系统绑定时,更换它们并不容易。在其他情况下,他们承诺的东西完全符合 WCAG AA,但我发现一些鲜为人知的规则存在问题。
缺乏法律清晰度 – 没有真正的规则,只是很多关于使用 WCAG 2.0 AA 的讨论。但是,即使您满足了该标准,也不能保证我们不会违反 ADA 合规性。我们能做的最好的事情就是避免成为容易被攻击的目标。
Matterhorn、PDF 和电子邮件又如何呢?
也许我们不需要将其委托给文本编辑器,而是需要一个 HTML5 可访问性 linter。我相信 React 的 JSX 有类似的东西,但快速搜索没有找到任何针对更广泛的 HTML 的内容。
linter 可以与各种开发环境(更重要的是)CI 管道集成,拒绝不符合可访问性基本规则的提交。
linter 只能捕获某些内容,并且可能会导致人们编写大量多余的代码(请参阅有关 ARIA 角色误用的博文,了解这种情况是如何发生的以及如何导致问题)。可访问性测试套件是一个更好的选择,因为它可以捕获围绕交互的问题,而这对于 linter 来说要困难得多。
我希望看到将可访问性审计作为 CI 流程的一部分的选择。由于可访问性回归导致构建失败将非常棒,尽管我绝对可以看出实现这样的功能可能很棘手,因为当界面变得越来越复杂时,a11y 会变得非常复杂的事情来进行审计。
大多数可访问性问题都是上下文相关的。我是盲人。如果您不添加适当的上下文,列出 HTML 是无用的。
错别字:意思是 linting。
前端开发人员可以使用哪些浏览器扩展/工具来帮助更轻松地解决可访问性问题?说有工具很容易,但提供一些链接将很有帮助!
WAT
WAVE
aXe
(beta 版)“Visual Studio Code 的 Webhint 扩展”可能会有所帮助……
https://webhint.io/docs/user-guide/extensions/vscode-webhint/
它使用了“Axe 可访问性检查”(基于 axe-core)
https://webhint.io/docs/user-guide/hints/hint-axe/
另请参阅:“从 Visual Studio Code 获取提示”
https://medium.com/webhint/getting-hints-from-visual-studio-code-69118e48de1b
我花费大量时间向设计师或客户解释色盲或悬停和焦点样式。通常,这些讨论会得到“客户想要什么”或“我们可以在发布后修复”的回应。因此,我认为可访问性在开发前就经常出错,并且可以 100% 理解为什么,部分原因是由于此原因,一些开发人员不费心使可访问性成为优先事项(或者在某些情况下,学习如何使可访问性成为优先事项)。
我们是 MSFT 粉丝吗??Webhint 虽然知名度不高,但它是一个不错的工具。非常可定制。
帖子不错。我发现我的问题在于实际的设计,而不是编码实践。让同一个网站对有视觉障碍和没有视觉障碍的人来说都具有吸引力,这是我个人一直在努力解决的问题。许多可访问性规则限制了颜色和色调的使用、大量图像的使用、每个页面上的内容量等。
在编码方面,不仅仅是基本的 HTML 代码,现在还有 WCAG、ARIA 和结构化标记需要实现。代码很快就变得非常丑陋。
至于代码提示,VS Code 有几个扩展可以提供帮助。
那是真正的 Atom 插件还是只是模拟?
它是 VSCode,但不确定 linter 工具。
那是 Visual Studio Code,我相信它是一个模拟。
这就是 ember-template-lint 的作用。值得一试。还有一些 VS Code 扩展可以做类似的事情。
Axe 提供了许多工具,包括浏览器扩展和可用于测试的引擎。
https://www.deque.com/axe/
https://github.com/dequelabs/axe-core/blob/develop/README.md
Siteimprove 浏览器扩展
https://chrome.google.com/webstore/detail/siteimprove-accessibility/efcfolpjihicnikpmhnmphjhhpiclljc?hl=en-US
“……我们绝对需要将无障碍网站非法化,才能让人们真正关注这个问题。”
是的,让我们取缔糟糕的设计实现。这将提高人们对前端开发的兴趣,并为该行业带来更多人才。哦,嘿,这也将解决可访问性协议差的问题!
我发现很难提供美观且可访问的解决方案。你需要了解 a11y 组件,而且它非常庞大。当我第一次查看 a11y 文档时,有数百页需要阅读,在某些时候不可能不感到厌烦。。
网络可访问性至少五年来一直是我关注的重点。我已经实现了 WAI-ARIA 在其创作实践中提到的几乎所有自定义组件的版本,尽管我拥有所有这些知识,但制作可访问的网站仍然非常困难。开发人员将面临的最大挑战之一是辅助技术和浏览器之间缺乏一致性和合规性(有时操作系统也会影响这一点)。
我经常会完全按照规范实现某些东西,却发现它只在 25% 的辅助技术/浏览器配对中有效。当开发人员无法相信屏幕阅读器和浏览器会根据规范工作时,他们必须开始创建测试结果表来确定他们是否应该尝试以比 WAI-ARIA 建议的更hacky但可能得到更多支持的方式来使事情正常工作,这是一个大问题。当这些工具的制造商提供不完整的实现时,我真的不认为强加这种负担给开发人员是公平的。大多数开发人员将是编写可访问组件的新手,这会使问题更加严重。如果他们不能确定自己做对了,即使试图自己测试它,因为也许他们的工具根本不起作用,这使得学习变得更加困难。
“我们学习 HTML,我们确保语义正确——瞧!”
说起来容易做起来难。
我是我目前公司为数不多的 a11y 支持者之一,解决我们系统上的语义错误/问题是一个相当大的挑战。首先,这是一个旧的代码库,没有遵循任何风格指南,也不关心用户流程。我们一直在逐步“现代化”它,通过将 FE 代码分离到可重用组件中。组件很酷,但是当我们开始组合布局时,控制语义方面(如标题顺序和地标)变得很困难。
一种解决方案可能是使用包装组件,允许传递可选的 props(如标题级别)。
我认为 a11y 不仅仅是学习 HTML 和语义的问题,它需要整个团队的努力,而 UX 设计师是解决方案(或问题)中非常、非常重要的一部分。
也许 HTML5 可以引入调试模式。例如,像 Dreamweaver 这样的工具不会让你错过这样的事情(在非常基本的层面上),它会告诉你你缺少 alt 标签,例如 lol。
在我看来,网站上存在几类错误,包括……
破坏性错误 - 网站因它们而无法正常运行
视觉错误 - 网站可以工作,但边距错误,按钮大小错误等。
可访问性错误 - 网站执行了它应该执行的所有操作,并且看起来不错,除非您使用辅助技术。
问题在于,如果您在第一个错误上出错,客户将不会付钱给您。网站需要正常工作。如果您有一些视觉错误,您可能会仍然获得报酬,但客户可能会抱怨一点,您可能也希望在下一次修复它们。如果您存在可访问性错误,那么您需要付出额外的努力才能知道它们的存在,客户 90% 的时间甚至都不会注意到。
所以,可访问性可能并不难,我不认为这是问题所在。如果网站在可访问性问题得到解决之前无法正常工作(即无法运行),那么我们都将在本周末成为可访问性专家。
我做网页设计将近二十年了,我确信一家没有符合标准的网站的公司几乎 100% 是由于缺乏知识而不是恶意造成的。我的团队中没有一个网页设计师——有些刚从大学毕业,有些和我一样做了这么久——知道 ADA 合规网站的法律和要求是什么。这不是大学里教授的东西,在线博客(如这个)上也没有真正涉及过,而且你真的从未在其他任何地方听到过关于它的讨论。
老实说,而且很惭愧,直到大约一周前我读到多米诺骨牌的案例,我甚至不知道确实存在我作为设计师必须遵守的法律和要求。当然,我知道 alt 标签等等,但我一直认为这只是对使用屏幕阅读器或其他任何东西的用户的一种便利。我并没有意识到这是法律规定的。
可悲的是,我在过去的一周左右时间里多次搜索过实际的法律和法规是什么,但我所能找到的只是一堆法律术语或似乎由律师撰写的网站。我找不到任何东西——即使是从像 Mozilla 或 Google 这样传统上易于使用的公司——它们简洁、易读、易于理解或用户友好。我并不是要求一个我可以勾选的规则要点清单,但找到任何不令人沮丧地难以理解的东西都是不可能的。
我知道你没有要求清单,但我认为 Vox Media 确实有一个很好的清单:https://accessibility.voxmedia.com/ 我特别喜欢它涵盖了整个产品中的可访问性——这不仅仅是开发人员的责任。大学和政府机构也经常有关于无障碍网页实践的良好文档,因为它们在很长一段时间以来一直处于这种考虑的前沿。
此外,Google 在其网络基础知识材料(作为文档和 Udacity 上的免费课程)中包含可访问性:https://developers.google.com/web/fundamentals/accessibility
最后,如果您想提升您的可访问性知识,我推荐这个每周通讯:https://a11yweekly.com/ 它总是有一个针对可访问性新手的部分,并且是让可访问性成为开发人员首要考虑因素的好方法。
确实。WCAG 在大学里没有教授。作为一名可访问性开发人员,我在完成学位多年后,通过参加一些课程和与澳大利亚视觉机构合作学习了 WCAG。我很高兴我这么做了,因为在线可访问性是网络开发的未来,它在我的业务中发挥着核心作用,未来每天都一片光明。
所以,我一直在研究如何使我构建的东西更易于访问,我遇到的问题是时间。我没有时间测试它,老实说,我对所有不同的可访问性测试方法都不了解。因此,我可以开始一个项目,旨在将其打造成可访问性的杰作,但随着截止日期的临近,我被迫只专注于语义标记。
关于可访问性的第二部分是,它不仅仅是关于屏幕阅读器和颜色对比度。那里存在着各种各样的残疾,而不仅仅是使用屏幕阅读器的用户。因此,如果整个团队没有考虑这一点并朝着这个方向努力,那么无论你的代码多么易于访问,它仍然不符合标准。
我们需要更多可以帮助我们所有人(开发人员、设计师和内容创建者)的工具和资源。我们需要像上面提到的方法来帮助我们进行质量保证,是否有针对辅助技术的 Browserstack?我们还需要我们的产品负责人和利益相关者了解,完成所有这些工作需要更多时间,但这将为他们的产品打开一个新的受众群体。
可访问性也很难,因为可访问性是关于个人的“访问”——而这具有巨大的差异,任何规则集(迄今为止)都无法完全涵盖。这就是 WCAG 使用“指南”而不是规则的原因。不可能涵盖网络可访问性的每种可能情况,因为它与每个人一样个性化,随时间变化,并最终随着技术和工具的改进而变化。
Heydon Pickering 的这次谈话解决了我的大部分关于可访问性的担忧。(警告,有些脏话)
我从中学到的关键点(关于可访问性)是,简单的 HTML 默认情况下是可访问的。因此,您编写的代码越少,使其可访问就越容易。
在某些方面,可访问性不会悄无声息地崩溃,只要您持续使用辅助技术(AT)访问您的网站。我尝试定期仅使用键盘、闭上眼睛并打开屏幕阅读器等方式访问我的网站。因此,如果某些内容出现故障,在我注意到它之前不会持续太久(理想情况下)。
因此,我认为解决方案的一部分是教育初级 Web 开发人员,至少要以他们使用鼠标和眼睛测试频率的三分之一的频率进行无鼠标和无视觉的测试;将其作为一种习惯和常规,而不是“高级”最佳实践。习惯以这种方式浏览也将帮助他们同情并更深入地了解残疾用户,并更好地了解在遇到可访问性问题时该怎么做。
可访问的网站根本不难构建。它只需要一点意识和教育。我喜欢您关于在代码编辑器中标记可访问性问题的想法,尽管已经有一些工具(例如 pa11y)可以轻松地集成到开发人员的工作流程中 https://pa11y.org/
我喜欢的是不做这件事的理由——时间和资源一直是两个被使用的借口,这在当时有效地束缚了我的手脚。而现在,由于客户现在坚持要求(尽管他们不应该这样做),才有了时间来做这件事。此外,尽可能高的标准要求您的网站/应用程序在禁用 JS 的情况下也能正常工作 :)
此外,什么是可访问的?键盘可访问?色盲人士的对比色是否足够高?它如何与屏幕阅读器配合使用?对于不使用键盘甚至不使用鼠标进行导航的用户来说,它如何工作?如果您要实现可访问性,首先要做的事情——进行可访问性审查——有一些公司专门从事此领域。然后查看您需要交付的内容,以及您正在考虑的最低级别。然后,在您开发完成后——再次进行审查。更多开发,更多审查,等等。这是一个持续的过程,尤其是在您添加新功能/功能时。
并且一致性声明几乎是关键,这将告知您的最终用户,您到底支持什么(例如 https://www.bbc.co.uk/guidelines/futuremedia/accessibility/)
我是一名前端开发人员转型为可访问性顾问,我完全同意是知识缺乏,而不是恶意,导致了这个问题。我可以用一只手数出那些对我提出的意见有偏见或怀有敌意的人,而迄今为止在我 8 年的职业生涯中遇到的其他人只是想知道该怎么做才是正确的。我非常希望在初学者级别教授可访问性,我认为这将产生巨大的影响。人们可以提供帮助的另一个地方是确保他们的教程和工具也能产生可访问的结果。CSS Tricks 始终在这方面表现出色!
不是每个人都能负担得起顾问,所以我写了一个关于可访问性的学习计划——它仍然是草稿,如果您有任何改进建议,我非常乐意听取。 https://github.com/stringyland/a11y-learning-plan WebAIM 提供的 WCAG 的通俗易懂版本也很好: https://webaim.org/standards/wcag/checklist
但我并不认同“太难了”的说法。人们一直在学习新的框架、新的功能。他们重写了整个代码库以包含钩子或本周流行的新事物。Web 开发人员很聪明,并且有能力付出学习可访问性所需的努力。
在美国以外,立法也极大地促进了数字访问。它创建了一个每个人都可以努力实现并共享资源的通用标准或基线。我希望
“如果我们的文本编辑器能够捕捉到可访问性问题并在开发过程中向我们显示它们会怎样?”Webhint.io 正是这样做的。 :)
对于 VS code,我应该说,使用 aXe 可访问性规则。
除了在 Chrome Lighthouse 的可访问性测试中获得相当高的分数之外,是否还需要做其他事情?
没有任何应用程序能够识别或推荐超过 15-20% 的可访问性问题的修复方案。我应该知道。我是盲人,我与微软和许多联邦机构合作过,应对过诉讼。要么你懂,要么你不懂……而且大多数 UI/UX 人员仍然一无所知。
我想这意味着我有一份有保障的工作。
大多数可访问性测试都查看静态页面——因此它们确保您使用语义 HTML、您的图像具有 alt 文本并且对比度合适。这些都是重要的考虑因素,但它们未能测试交互——屏幕阅读器用户能否分辨出您的汉堡菜单是打开还是关闭?屏幕阅读器是否会朗读表单错误消息?等等,等等。
这些需要更自定义的测试或手动可访问性测试。
是的,因为Lighthouse 虽然很棒,但它只能检查由代码格式错误导致的问题。还有一些与内容和交互相关的问题需要手动测试。您需要检查 WCAG 2.1 标准列表中的所有项目——WebAIM 发布了一个简短版本: https://webaim.org/standards/wcag/checklist 并且 A11y 项目也提供了关于基本手动测试的良好入门指南: https://a11yproject.com/
好吧,我当然可以理解其中还有更多内容,我们需要做更多的事情。但是,手动列表无法帮助我们实现目标——人们根本不会使用它们。我们还使用了 WAVE 和 Axe(Chrome 扩展程序)。我们使用它们的次数越多,我们学习和将这些技术融入我们标准网站构建流程中的次数就越多。从您的角度来看,这些工具在解决实际问题方面如何?
嗨,Sean,答案是肯定的——必须做更多的事情。Lighthouse 的 a11y 审计旨在或多或少地引导您朝正确的方向前进,并让您了解您的工作做得有多好。并非为了煽风点火,并试图贬低 Lighthouse 的 a11y 团队的工作,但当有人操纵审计工具并在一个不可访问的网站上获得 100 分时,这篇博文就在网络上传播开来。请在此处阅读。
https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/
当然,也出现了一些 Twitter 线程,但其中提到的一件事——并且被忽略了——是 Google 补充说,它“Lighthouse 审计无法测试所有内容”并且“我们还包括一整套手动审计,并附有说明如何执行这些审计的文档。”(来自 Rob Dodson)。
大多数 a11y 专业人士都会告诉您不要过度依赖自动化工具。它们很有用,但某些情况总会被人遗漏。我碰巧与 Rob 就此进行过对话,我认为这个问题的一部分——我认为——是分数。人们像对待金牌一样紧紧抓住它。因此,100 分感觉像是你完成了——但实际上你并没有。
关于您关于现有工具有多大用处的第二个评论……我想说 Chrome 的 Lighthouse 是我最喜欢的,因为它非常易于使用,但 aXe 和 WAVE 也很好(我听说 WAVE 即将发布一个新的更新!)。它们在各自领域表现出色,并且提供了良好的修复建议。但是,自动化工具只能涵盖 20% 到 25% 的潜在问题。尽管如此,这仍然是您不必像几年前那样手动处理的 20%。不匹配的原因是可访问性是一个基于人类差异和灵活性的问题,而自动化则完全关乎复制和模式匹配。它确实需要在开发之前(在设计和内容中)以及开发人员测试我们在离开我们整洁的开发环境后事物在现实世界中实际如何工作时的人为关注。绝对要继续使用 Lighthouse!但也要深入了解其关于手动测试的建议,或者研究 Microsoft 的 Insights 以获取更多可遵循的手动测试流程。
我可以证实,开发人员不实践可访问性的原因仅仅是人们对此一无所知。在我自己转向可访问性审计之前,我曾担任 4 年的 Web 开发人员承包商,从 2012 年开始。从一个为期 3 个月或 6 个月的短期合同转向另一个短期合同,包括与一些非常著名的拥有大型网站的大公司合作。在那段时间里,我从未听到任何人说“我们没时间做这个”,或者“我们负担不起”,或者类似的话。事实是我在整个四年里从未听到任何人提到过“可访问性”这个词!也没有“WCAG”这个首字母缩略词。一次也没有,无论是同事开发者、设计师还是管理层。
可访问性根本不是任何人知道的事情。直到那段时间快结束时,我才通过在互联网上看到一些偶然的参考并探索它是什么来自己发现它。因此,我在一家最大的可访问性咨询公司找到了一份工作,后来又开始了自由职业。
我认为这种知识的匮乏是我这个新兴职业未能教育世界其他地方的失败。我们花费大量时间互相教学,偶尔也会发布一些供开发者阅读的内容,如果他们碰巧发现了。但我们几乎没有花费时间向行业和商业中的决策者,向管理层和董事会宣传它。有时他们只有在收到诉讼通知时才会了解到它。
小心依赖自动化工具。在 Lighthouse、Axe 或您使用的任何其他工具上获得 100% 的分数,**并不**代表网站完全无障碍。它仅仅表明您正朝着正确的方向前进。
尝试获得真正用户的参与。自己使用屏幕阅读器,在没有鼠标的情况下进行测试,应用颜色滤镜来测试 8 种主要类型的色盲,检查文本的阅读年龄/水平,查看元素的大小,并思考手部不便的人如何导航。
我完全同意,但我认为如果开发者在他们的编辑器中经常收到关于这些内容的提醒,那么普遍意识的程度将会大大提高。他们可能会开始像对待其他任何代码质量问题一样对待它。
如果您使用 Visual Studio Code 的 Webhint.io 扩展,就可以实现这一点。它会在具有无障碍问题的元素下方显示波浪线。
您好,Robin 和访客们,
为您的“想法:如果我们的文本编辑器能够捕获无障碍问题并在开发过程中向我们展示它们会怎样?”表示赞赏。并附带一个醒目的警告,即并非**所有**问题都能够自动发现,并且不可避免地需要进行更多测试。
– 也感谢评论中提出的教育建议!
工具
虽然没有嵌入文本编辑器中,但只需点击一下即可使用一些便捷的工具。就像您在开发过程中每隔一段时间就会检查 HTML 验证器和 CSS 验证器一样,用于检查错别字和其他更严重的问题,您可以在同一时间检查无障碍性(在一定程度上);并且像 HTML 和 CSS 验证器的备注一样,这些工具的提示并不总是充分的。
将此作为开发过程中的习惯,如果其他所有工作都已完成,您就不需要重新构建页面的主要结构!
至今已有 10 多年了,例如
伊利诺伊大学有一个“FAE:功能无障碍评估器”,它可以为网站提供详细的无障碍报告(注册一个免费用户帐户),并附带如何解决问题的说明。请参阅:https://fae.disability.illinois.edu/
对于单页面使用,FAE 有一个 Firefox 插件版本(无需注册):https://addons.mozilla.org/en-US/firefox/addon/ainspector-wcag/
另一个工具来自 WebAIM(WebAccessibilityInMind,https://webaim.org/):WeB 无障碍评估工具 WAVE,https://wave.webaim.org/,可在线使用。
Firefox 和 Chrome 浏览器也提供了 WAVE 扩展程序:https://wave.webaim.org/extension/
注意:我同意Ashley Sheridan 和其他人的观点:“小心依赖自动化工具”。
教育
这两个验证器也可以在无障碍教育实践中提供出色的服务。
更多信息:W3C 的 Web 无障碍倡议 (WAI),https://www.w3.org/WAI/,对涉及无障碍相关人员的不同角色的必要资源进行了描述:从政策制定者到设计师、开发者、测试人员、教育工作者等,以及 Web 用户。请参阅:https://www.w3.org/WAI/roles/。
另请参阅:教学和宣传概述,https://www.w3.org/WAI/teach-advocate/
标准
WCAG(Web 内容无障碍指南,https://www.w3.org/WAI/standards-guidelines/wcag) 提供了许多可用的无障碍技术。WCAG-2.1 是最新版本:2018 年 6 月 5 日的建议。
同时,W3C 开发了“无障碍一致性测试 (ACT) 规则格式 1.0”(https://www.w3.org/TR/act-rules-format/),这是 2019 年 7 月 30 日提出的 W3C 建议。摘录自其简介
“目前有许多测试程序和工具可供使用,它们可以帮助用户测试 Web 内容是否符合 Web 内容无障碍指南 [WCAG] 等无障碍标准。随着 Web 在规模和复杂性上的发展,这些程序和工具对于管理 Web 上可用资源的无障碍性至关重要。
此格式旨在使人们对如何测试 WCAG 和其他无障碍要求文档的一致性有统一的理解,并促进无障碍测试结果的一致性。规则格式旨在描述手动无障碍测试以及无障碍测试工具执行的自动化测试。”
因此,对普遍无障碍性的关注正在增长!
许多人甚至不知道 Web 无障碍倡议发布了创作工具无障碍指南(https://www.w3.org/WAI/standards-guidelines/atag/),该指南为用于生成 Web 内容的软件和服务设定了无障碍标准。
这些指南不仅涵盖工具本身的无障碍性,还要求工具执行本文中建议的内容:帮助作者(无论是开发者、设计师、撰稿人还是其他任何人)创建无障碍内容。这些指南常常被忽视,我认为许多代码编辑器以及流行的内容管理系统可以通过熟悉这些指南并将其用于实践来变得更好。
VS Code 有一个 Web 无障碍扩展程序(https://marketplace.visualstudio.com/items?itemName=MaxvanderSchee.web-accessibility),它可以识别 HTML 模板中存在问题的元素,但它不适用于 Vue 等 JavaScript 框架模板。
我收回刚才的话——它确实适用于 Vue,只是不适用于 Pug 模板。
显然您不知道,即使**这个**页面对我来说也是**无法访问的**。前两个折叠是菜单,内容从第三个折叠的顶部开始。此外,内容以“一家公司因缺乏无障碍而被起诉的最公开的例子”开头,这告诉我菜单前两个折叠下方隐藏了内容。
如果您要坚持强调需要解决的问题,也许您应该先从自己的网站开始,然后再谴责其他人。或者用我母亲的话说,在抱怨邻居家的窗户有多脏之前,先把自己的窗户擦干净。
哇,你真是激动过头了。深吸一口气,重新阅读这篇文章。这里没有谴责——仅仅是指出创建无障碍网站很困难,并质疑其原因。没必要在茶话会上扔手榴弹。
您好。我是一名专门从事 ADA 无障碍诉讼(包括网站诉讼)的律师。您之所以感到困惑是正确的,因为法律并不明确。对于某些政府网站,有一项法规遵循 WCAG 2.0 AA,航空公司网站也遵循相同标准,但对于大多数商业网站,没有可遵循的法规标准。规则(不会让任何人满意)是,网站必须为任何残疾人士提供“对网站商品和服务的有效访问”。为方便起见,律师和一些法院转向 WCAG 2.0 AA,这是构建无障碍网站的最佳起点;您只需要知道,完全符合标准并不能保证网站满足 ADA 标准,因为没有人确切地知道该标准是什么。
我同意使用自动化工具测试网站的观点。软件工具无法检测某些类型的无障碍问题,还会产生误报,因为它们无法执行诸如区分装饰性图像和具有意义的图像等操作。测试网站的唯一方法是让残疾用户系统地测试每个可能的用户交互,以查看其是否有效。
实际上,认为仅通过残疾用户测试网站是唯一方法是一种普遍的误解。它不是唯一的方法,甚至不是测试无障碍性的最佳方法。虽然将用户测试作为整体测试策略的一部分肯定非常有用,但您需要一位经过培训且经验丰富的无障碍测试人员来完整地测试网站——但必须是能够看到屏幕上内容的人。
本次对话中的一位参与者刚刚抱怨——并且非常正确地抱怨——我们现在所在的这个 CSS-Tricks 页面的顶部部分无法访问,一直到第二个折叠!这是一大块内容,屏幕阅读器无法测试。
再举一些其他非常常见的例子——屏幕阅读器有时无法访问主菜单链接,导致整个页面无法访问。购物车经常无法通过键盘或屏幕阅读器使用,或者有时甚至无法访问。或者网站上另一种非常常见的模式,即“按钮”只是一个 SVG 图标或 div 内的背景图像,因此屏幕阅读器无法宣布任何内容,阅读器用户无法知道它是否存在。它需要专业的无障碍测试人员以视觉方式查看其是否存在,对其进行检查,并告诉开发者如何解决它。
而且,失聪人士在检查视频时,不幸的是,无法判断字幕中是否应该包含噪音或屏幕外事件,但实际上却没有包含。因此,当然要让所有具有各种残疾的用户测试人员参与进来。但是,您需要一位经过培训的 WCAG 测试人员或顾问来进行网站的主要无障碍性测试。
实际上,认为仅通过残疾用户测试网站是唯一方法是一种普遍的误解。它不是唯一的方法,甚至不是测试无障碍性的最佳方法。虽然将用户测试作为整体测试策略的一部分肯定非常有用,但您需要一位经过培训且经验丰富的无障碍测试人员来完整地测试网站——但必须是能够看到屏幕上内容的人。
本次对话中的一位参与者刚刚抱怨——并且非常正确地抱怨——我们现在所在的这个 CSS-Tricks 页面的顶部部分无法访问,一直到第二个折叠!这是一大块内容,屏幕阅读器无法测试。
再举一些其他非常常见的例子——屏幕阅读器有时无法访问主菜单链接,导致整个页面无法访问。购物车经常无法通过键盘或屏幕阅读器使用,或者有时甚至无法访问。或者网站上另一种非常常见的模式,即“按钮”只是一个 SVG 图标或 div 内的背景图像,因此屏幕阅读器无法宣布任何内容,阅读器用户无法知道它是否存在。它需要专业的无障碍测试人员以视觉方式查看其是否存在,对其进行检查,并告诉开发者如何解决它。
而且,失聪人士在检查视频时,不幸的是,无法判断字幕中是否应该包含噪音或屏幕外事件,但实际上却没有包含。因此,当然要让所有具有各种残疾的用户测试人员参与进来。但是,您需要一位经过培训的 WCAG 测试人员或顾问来进行网站的主要无障碍性测试。
为什么可访问性如此困难?这里谁成功地把牙膏塞回管子里了?几乎没有人。
当你事后处理可访问性之类的事情时,它比一个经过良好优化的网站更难实现。真正的 a11y 专业人士会告诉你,最好的测试是使用真实用户。这需要时间 *和* 正确的计划——这两者都从未得到资源分配。
也就是说,它可以在没有真实用户的情况下完成,但它仍然必须被视为所有最简单计划(以及理想情况下的测试)的一部分。无论你如何切分它,可访问性挑战都可能随着网站复杂性的增加而增加。你编写更简单的代码,并且更有可能更容易地使内容可访问。Tenon.io 的 Karl Groves 发表了一个关于 a11y 中一些主要问题的精彩演讲。Web AIM 还发布了一篇很棒的文章,详细介绍了对 100 万个网站进行审核的结果——必读。 https://webaim.org/projects/million/
最后,我们很幸运地在多伦多有一个令人难以置信的聚会,他们还组织了一年一度的 a11y 营地(免费,为期一天的多轨)并且我们上周刚刚举办了完整的 a11y 大会——为期两天的国际演讲。如果你喜欢 a11y 教育学,请收藏此页面。 https://conf.a11yto.com
BBC 有一个可访问性标准检查器,它可以在 npm 上使用,并利用 Node.JS: https://github.com/bbc/bbc-a11y。它可以用于开发项目,并针对 URL 使用。它遵循 BBC 的可访问性标准,该标准非常详细: http://www.bbc.co.uk/guidelines/futuremedia/accessibility/
各位网页极客和前端极客们,大家好!
只想提一下。我认为我们需要谨慎对待和利用这个问题……就像作为一个社区一样。
在我看来,OP 问题的答案是预算。这意味着所有这些年来,各家公司(在我作为纯粹的 Web 开发人员的案例中)严重低估了 Web 开发和 Web 设计的预算。尽管 Web 设计的预算较少。
我提到要小心,因为像达美乐披萨案这样的合法法律威胁正是大多数公司需要重新评估生产运营的推动因素。所以,这是我针对那一刻的解决方案/补丁
建立一个 Web 设计系统,要求所有当前和新添加到系统中的内容(在 UI 类别中)在添加到系统之前都必须与可访问性标准完全集成。这样,在实践中,以及当员工使用设计系统制作内容时,每个代码片段都已用可访问性属性标记,以及它们的值之间的关系。
省去思考,把它当作基本标准对待。把它们当作 html、head 和 body 标签一样对待。全天候,一年 365.25 天。
这种简单的转变彻底改变了这个问题的动态。因为现在设计师和开发人员必须手动删除可访问性属性才能使该组件或元素不可访问。否则,所有内容都已存在,只需要正确的副本或选择器!
但关键在于 IRL,强制 Web 设计系统成为所有公司构建的唯一真相来源(在不同项目中使用相同系统的变体)。没有例外。因此,重新部署你的 Web 设计系统并教会公司从那里拉取和安装是最简单的。就是这样。现在,设计师也真正“理解”了敏捷。太棒了。
在这一点上,可访问性成为页面上每次操作的正常部分。现在,我们不必担心等待自动化解决方案……因为我们只需作为一个勤奋的团队通过渐进式设计系统改进就能更好地解决这个问题。保持简单。
祝大家编码愉快!:)
我发现 WUHCAG(不要与 WCAG 混淆)是一个非常有用的网站,它以清晰明了的方式解释可访问性标准。当尝试了解可访问性时,它帮助我理解了每个标准。
达美乐披萨事件是一个特殊的案例,它超出了正常范围。他们很可能做出了一个有意识的决定,选择不为可访问性支付额外费用,并认为多种沟通渠道就足够了。
前期额外成本肯定远低于之后支付 300 多万美元的改造费用以及法律费用和民事诉讼赔偿金。不过,这是典型的企业行为,并不奇怪会发生这种情况。我们在英国石油公司漏油事件中也看到了同样的情况,他们选择偷工减料,节省了 1000 万美元,结果却不得不支付诉讼费用和 200-250 亿美元的赔偿金。两年前加州发生的火灾,该地区的电力公司设备存在故障,在旱季引发了火灾,他们决定不支付设备升级费用,后来被发现是火灾的起因,因此不得不处理大量的民事诉讼、政府罚款,并且仍然不得不升级他们的设备。
企业文化心态——“法律不适用于我们”
我不能不同意达美乐的企业文化,但他们的案例也基于移动应用程序。我还认为,重要的是要了解,可访问性诉讼并非由真正可访问性问题驱动;它是由从中获利的律师驱动的。典型的诉讼始于法律助理对网站运行软件工具以查找 WCAG 2.0 AA 错误。如果出现任何问题,一位可能参与数十甚至数百起诉讼的盲人原告会访问该网站并四处查看。他或她可能会也可能不会遇到网站问题,但这并不重要,因为诉讼的依据是软件报告,律师并不关心报告是否包含误报。他们只需要一点掩护,以防有人声称他们恶意提起诉讼。诉讼被提起,律师事务所要求支付 10,000 美元到 50,000 美元不等的费用,外加一项承诺在 18 到 24 个月内修复网站的承诺,以便撤销诉讼。成功辩护的最低成本超过 10,000 美元,因此除了最顽固的企业外,其他企业都会付款,同意修复网站并继续前进。即使网站完全可访问,他们也可能会付款,因为证明它可访问的成本高于向原告律师支付费用。使网站可访问是良好的商业行为,但它与诉讼或避免诉讼无关,因为该领域的诉讼是由贪婪驱动的,而不是对可访问性的关心。
将可访问性视为开发问题是它被认为难以实现的原因之一。(我不再认为它很难了)
当我们通读 WCAG 检查点以及来自具有辅助功能需求的真实用户的可访问性测试报告时,很明显,可访问性在内容、设计和实施之间进行了相当平衡的三方划分。
自动化测试不足以检测内容中的可访问性问题,例如,如果某个站点有多种语言,它可能在一门语言中测试良好,但在另一门语言中则不然。
即使开发人员精通使解决方案可访问的内容,他们也需要设计师和内容作者的参与。
如果人们真的了解语义和渐进增强意味着什么。如果他们了解这些内容,那么他们就可以在可访问性错误成为问题之前理解并修复它们。
所有这些框架和 UI 构建器都会生成垃圾标记:一堆 div 和 span,哦,我们还会在这里添加一些我们不理解的 aria,并且我们甚至无法看到它的影响,因为我们没有使用屏幕阅读器,哦,但以后有人会解决它,我们会迭代。
Ugh!