我在网络可拜访性方面的工作是使想要创立可拜访界面的人们更容易应用。对于建设对残疾人如何应用网络的良好了解到提供清晰且通过良好测试的代码示例，有很多办法。
我的意思是，如果您理解人们如何应用鼠标来上网，那么设计适宜他们的鼠标光标或编写代码来实现将变得更加容易。这也实用于键盘，开关控件，语音导航，触摸和屏幕阅读器。
我喜爱可重用组件的性能，因为它们容许制作可拜访性的组件，无论是在框架中还是原生（vanilla）。有一天，Web 平台中可能会有更好的 UI 控件和 / 或浏览器中有更多可拜访的默认值。当初，团队通常会构建本人的组件（无关提醒，请参见 Smashing 指南）。当然，并非所有我的项目团队都能始终每次都构建本人的组件。这不是 ’Nam，有 deadlines。因而，咱们通常应用第三方组件，例如自定义下拉框（custom selects），主动实现（autocompletes）和日期选择器（date pickers）。
在本文中，我将正告您不要自觉地信赖可拜访性申明，并分享一些问题每当你思考加三方库到我的项目中时先问问本人。
“无障碍”并没有阐明所有
作为可拜访性感知的开发人员，咱们可能特地关注可拜访的组件。兴许咱们在网络上搜寻“可拜访的 X”。如果这样做，请留神，比起那些 理论 可用或非常适合残疾人应用的组件，宣称 有更多可拜访的组件。
有时，“可拜访”意味着仅局部可拜访。这是一个问题，因为可拜访性是对于使界面实用于多种残障人士（请参阅多样化的能力和阻碍）。例如，想想一个能够与键盘配合应用但在放大时损坏重大的小部件？它具备完满的色调比照，然而没有 HTML 语义？屏幕阅读器的体验十分好，然而对于用语音控制系统的用户来说，这是一个辣手的问题吗？
有时，“可拜访”意味着“具备一堆 ARIA 属性”。在最佳状况下，“具备完全符合 ARIA 规范的 ARIA 属性和键盘行为”。有时，这是 ARIA 创作实践指南（APG）的 1：1 实现，这是 ARIA 工作组的一个子组编写的一组示例（不是规范）。如果您想晓得如何编写技术上正确的 ARIA，则 APG 是极好的资源。然而……它并没有声称屏幕阅读器的兼容性，请参阅 ARIA-AT 和 / 或 a11ysupport 为了那个起因。它还不会宣称用户体验，因而始终确保与人一起测试模式，或浏览与人一起测试的其他人的博客文章。最初，它也不倡议应用 ARIA 还是只应用 HTML……这只是对于应用 ARIA。有时，纯 HTML 模式对于最终用户来说更容易了解。更多的 ARIA 并不意味着更多的可拜访性。
道歉，我意识到这没有一个特地容易找到可拜访的组件，然而我想诚实说。无论如何：不要放弃。记住莱昂妮·沃森（LéonieWatson）已经说过的可拜访性：“它不肯定是完满的，它必须比昨天好一点”。咱们进行的钻研越多，咱们的抉择就会越理智。
一些问题要问
如果咱们想更加确定组件的可拜访性，则能够做一些查看。
他们如何测试？
当组件的网站解释如何测试组件时，这是个好消息。通常列出了浏览器反对，有时也包含对辅助技术（如屏幕阅读器）的反对。兴许他们曾经实现了正式的 WCAG 测试，或者他们有某种清单。他们可能只运行自动测试，这很好并且有用，但仅限于能够自动测试的货色（大多数 WCAG 不能）。无关测试类型的信息能够帮忙咱们理解组件的可拜访性。
他们和谁一起测试？
测试可拜访性最终与技术无关，而是与确保模式实用于残疾人无关。如果咱们看一个组成部分，是否能够发现他们是否专门包含残疾人？是否包含各种残疾？
代表事项；辅助性能通常须要测试各种人员，残障人士和辅助设施。当 Marcy Sutton 用户测试可拜访路由的模式时，屏幕阅读器，语音导航和开关控件的用户会有各种各样的教训和评论（请参阅从用户测试可拜访客户端路由中学到的常识）。
他们是否对本人办法的利弊持凋谢态度？
可拜访性并不一定总是适宜所有状况，有时可能会给办法带来一些正告，有些事件仍可能是试验性的。如果组件开发人员对此放弃凋谢的态度，这是一个好兆头。有时会呈现无关已知问题和打算的修复的可拜访性申明。
是谁发明的？
有时，如果创立组件的人员或组织为公共利益和 / 或可拜访性而工作，我会特地信赖。政府反对的组件库（例如 gov.uk 设计零碎，新西兰政府设计零碎和美国政府的设计零碎）都有含金量。由可拜访性从业者如 Deque’s Cauldron 和 Tenon UI 创立的模式库也是如此。
更多指标
我也在社交媒体上问了很多！以下是在此分享的一些技巧（❤️谢谢大家！）
查看 GitHub 问题
Marcus 倡议查看无关 WCAG 或可拜访性的 GitHub 问题，“它们的存在将是一个正告信号”。Thea 说，这也可能是“人们关怀的标记”，她倡议着眼于流动和无关问题的探讨。米切尔（Mitchell）批准：“谋求最佳可用性和互操作性从未实现”。马洛里（Mallory）也 + 1 了，并钻研了作者的反馈。
可拜访性是必不可少的
Sara 正告不要将可拜访性视为独自的性能，而不是工作不可或缺的一部分。如果有一个可拜访的版本和一个不可拜访的版本，则他们可能没有通过该测试！
查找细节
Bogdan 将寻找可拜访性申明的细节：咱们正在议论哪个版本的 WCAG？他和 Weston 还说要寻找通过测试的特定屏幕阅读器。
执行根本查看
各种各样的人说，根本的查看会带来很多益处：文档是否甚至提到了辅助性能（Oscar），是否有足够的色调比照（Martin），它是否仅可通过键盘应用（Brent 和 Eric）？
理解承诺
希瑟（Heather）倡议查看组件的网站；那里显著的可拜访性问题阐明了对可拜访性的声称承诺。
亚基姆（Yakim）说，咱们应该钻研一种测试方法，以掂量可继续的可拜访性工作如何：“它们是继续一直的，踊跃的还是被动的？”
阿德里安（Adrian）倡议在他的博客文章“警觉可拜访性供应商的可拜访性保障”（更多是对于工具的可拜访性），倡议他在 Twitter 上搜寻带有标签的公司名称。#a11y
可定制性
如果没有完满的抉择，为什么不进步最有前途的候选人之一呢？Martin 提到许可：有了许可许可，咱们能够本人解决任何可拜访性障碍。他和 Jason 也提到了这一点：如果该组件具备易于应用的 API 和可定制性的挂钩，咱们能够本人解决问题。
包起来
总结：并非所有“可拜访组件”都是平等创立的，对于咱们的最终用户而言，有些组件比其余组件要好得多。在这篇文章中，如果您正在思考应用第三方组件，我列出了许多能够查看的内容。