构建站点时，tota11y可帮助你实现可视化，属于一个辅助技术。详情参见6月8日的发布日志。最初的目的是为了减少a11y测试时的缺陷。 Accessibility (a11y) 的测试进程往往是冗长和混乱不清的，在许多的案例中，开发者必须有一定的Accessibility知识才能弄懂结果。
当前，越来越多的软件开发人员意识到可访问性 (Accessibility) 的重要性，发布的网页或应用程序必须能够被多种用户特别是残疾人群无障碍使用，Web站点如何做到用户使用的无障碍性，是值得Web开发人员重视及思考的问题，页面需要在任何解释环境下都具有良好的易读性不容忽视。 下面，我们就来看下这款tota11y插件的缘起，以下为官方发布日志的摘译：灵感 Accessibility的难解决有很多原因，尽管当前的工作提供一种检查许多Accessibility violations的机制，但仍然有大量的问题，尤其是开发者对于所困惑的问题依旧无解——许多这些错误无法实实在在看见，事情对我们正常人没多大的影响，另一方面也无完美的修复方案。 tota11y的目标是解决这些问题，并通过一种有趣和交互的方式来看见可视化后的问题。不仅是实现Web端很好地访问，而且开发者也应获得一定的能力来修复和预防accessibility violations的发生。 背景故事 在1月，我们就着手提供提高Khan Academy的无障碍访问性，在这段时间，我们提升了很多，获得了每一个页面bug的第一手信息，也想出了很多的办法来修复。John和我对这些新发现做了细心的研究，写了一个测试和检测violations的工具——Chrome’s Accessibility Developer Tools，并应用于工作中。 几周后，我们已经修复了我们网站上的一些重大的accessibility错误，并且学习到了大量关于辅助技术的知识。 最困难的阶段来了！ 我们觉得有能力修复我们网站上的大多数accessibility violations，但是我们无法有效地传播这些经验给其它的团队。我们不能让每一位Khan Academy employee参与进来，他们不愿报告和修复accessibility violations。 我们开启谈话、写文档和发送邮件，但是效果甚微，此外我们也没获得与我们所做工作想对应的尊重。￣へ￣ 简单来说，我们的开发团队一直无法完全理解正遭受困扰人的问题所在，也就无法找出修复的方法。 遇见tota11y 大约一月前，我们开始开发tota11y，一个Khan Academy的”Web Frontend” 团队的内部项目。 目标是让开发者尽可能简单地实现手工accessibility测试，且作为他们日常工作的一部分。而不再需要开发团队针对不理解的violations去做冗长复杂的审核报高，我们想要提供简单的可视化，在他们眼前的浏览器上就好。 接着，我们有了”annotations”的想法，高亮出当前文件部分就好，以及指出错误、成功或者仅仅标注出重要的tags，如headings或ARIA landmarks。 tota11y早期的证明型概念。 后来，我们进一步加强和扩展”annotations”的想法，所以你将看到更详细的错误信息、修复建议，以及更多。 tota11y的实现 tota11y是一个single JavaScript file，你可以在的文档中看到包含如下的内容： 一旦你看到窗口底部的这个眼睛，即刻开启： tota11y目前包括以下的插件：
更多细节参见：Google Chrome’s Accessibility Developer Tools 许多tota11y插件也会给出修复这些违规的建议和方法。 GitHub地址：http://khan.github.io/tota11y/ |
