一段时间以来，我一直在研究一些 JavaScript 框架，例如 Backbone.js 和 Batman.js，虽然我真的很喜欢它们，但我有一个琐碎的事情我一直在回顾。这个问题就是可访问性。
作为一名网络开发人员，我一直试图让我的网站和应用程序考虑到可访问性，尤其是使用渐进增强的理念。
很明显，这些新的 JS 框架开箱即用并不会优雅地降级，所以我想知道其他开发人员对这个问题有什么想法，以及你在做什么。毕竟，网站/应用程序的可访问性并不是真正的可选项，因为它是许多国家/地区法律的一部分。
也许我只是在这个问题上过于热心，并没有意识到在可访问性方面取得了多大的进步。
【问题讨论】：
标签： javascript accessibility backbone.js javascript-framework sproutcore
我在我的最新站点中使用了一个 js 框架（在我的例子中是 spine.js）。我仍然确保非 js 浏览器（当然不要过分热心：想想 SEO）可以浏览我的网站并消化内容。
作为示例，我将使用显示产品的搜索页面。可以对产品进行分页、过滤、排序。当然，这是广义思想的一个例子。
PREREQ：使用可以同时呈现服务器端和客户端的模板引擎。 （我用胡子）。这确保您可以通过服务器端模板渲染没有 js- 的模型，并通过客户端模板渲染带有 js 的模型。
最初：使用服务器端 mustache-template 渲染产品。还包括一个“bootstrapJSON”对象，其中包含 JSON 格式的相同产品。
最初：所有链接（产品详细信息页面、分页、排序、过滤）都是真实的服务器端 url（没有 hashbang url）
最终结果是一个不用JS就可以通过分页、排序、过滤100%导航的页面。
所有分页、排序、过滤 url 都会导致向服务器发出请求，这反过来会导致呈现一组新产品。这里没什么特别的。
启用 JS - 在 domload 上：
现在每个（过滤、分页、排序）url 都应该导致客户端状态更改，这可能会导致您的 js 框架向服务器执行 ajax 请求以返回新产品（在JSON 格式）。在客户端上重新渲染它应该会导致您的视图更新。
6.服务端处理ajax-request的代码逻辑部分与4.中使用的代码100%相同。区分ajax-call和普通请求并吐槽JSON 或 html 格式的产品（使用 mustache 服务器端）。
编辑：2013 年 1 月更新 由于这个问题/答案得到了一些合理的关注，我想我会分享一些去年密切相关的 aha-moments：
吐出 JSON 并使用您选择的客户端 mvc（上面的步骤 6. 和 7.）在客户端渲染它在 CPU 方面的成本可能相当高。当然，这在移动设备上尤为明显。
我已经做了一些测试以在 ajax 上返回 html-sn-ps（使用服务器端的 mustache-template 渲染），而不是像我上面的回答中建议的那样在客户端做同样的事情。根据您的客户端设备，它可以快 10 倍 (1000ms -> 100ms)，当然您的里程可能会有所不同。 （实际上不需要更改代码，因为第 7 步已经可以同时进行这两种操作了）
当然，当没有返回 JSON 时，客户端 MVC 就无法构建模型、管理事件等。那么，为什么还要保留客户端 MVC？老实说，事后看来，即使是非常复杂的搜索页面，我对客户端 mvc 也没有太多用处。对我来说唯一真正的好处是它们有助于清楚地分离出客户端上的逻辑，但你应该已经在你自己的 imho 上这样做了。因此，剥离客户端 MVC 已迫在眉睫。
【讨论】：
由于我是一个视障用户和网络开发人员，我会在这里插话。
根据我的经验，只要在可访问性方面采取了适当的步骤，这些框架就不会成为问题。
许多屏幕阅读器都了解 JavaScript，作为开发人员，我们可以使用 HTML5 的 aria-live 属性来提醒屏幕阅读器事情正在发生变化，并且我们可以使用角色属性为屏幕阅读器提供额外的提示来改善体验。
但是，使用 JavaScript 进行 Web 开发的基本原则是，我们应该首先开发底层站点，而不是使用 JavaScript，然后使用该坚实、有效且经过测试的基础来提供更好的功能。购买产品、接受服务或获取信息不应要求使用 JS。一些用户禁用 JavaScript，因为它会干扰他们的屏幕阅读器的工作方式。
从头开始构建一个完整的 Backbone.js 或 Knockout 网站而不考虑可访问性将导致类似于“新 Twitter”的结果，这对于许多屏幕阅读器来说非常失败。但 Twitter 有坚实的基础，因此我们可以通过其他方式访问该平台。将 Backbone 移植到具有精心设计的 API 的现有网站上是非常可行的，而且非常有趣。
因此，基本上，这些框架本身并不比 jQUery 本身更具可访问性问题 - 开发人员需要打造适合所有人的用户体验。
【讨论】：
需要 javascript 以便从中获取内容的任何网页都可能会遇到与可访问性相关的挑战。 JavaScript 框架的可访问性绝对是一个争论的问题，但实际上，无论使用何种框架，当动态提供内容时，任何 Web 应用程序都会遭受缺陷。
没有什么灵丹妙药可以确保您的网站可以访问，而且我当然不能说明每个 JavaScript 框架。以下是一些关于如何防止您的网站在使用 JavaScript 时完全无法访问的想法：
遵循WCAG 2.0 on client-side scripting 和WCAG 2.0 的一般准则。
避免使用要求您完全通过 JavaScript 生成页面 UI、控件和/或内容的框架，例如 Uki.js，或使用自己专有标记的框架，例如 Jo。您越能坚持使用静态 (-ish)、语义 HTML 内容，您的生活就会越好。
考虑使用ARIA roles（例如role="application"）和aria-live 属性来指示页面的动态区域。随着时间的推移，越来越多的 aria 角色被辅助设备支持，因此当您可以将这些 aria 属性适当地添加到您的应用时，使用这些 aria 属性是有意义的。
在 JS 库方面，检查它们的源代码，看看它们是否输出任何 aria 角色。它们可能无法完全访问，但这表明他们正在考虑使用辅助设备。
尽可能将 JavaScript 视为增强功能而非必需品。尝试提供替代方法或工作流程来访问不需要动态页面更新的重要信息。
与您的用户一起测试和验证您的应用！与使用辅助设备或使用网络软件有其他困难的人进行一些用户测试。没有什么比观看真实的人使用它更能帮助您证明您的网站是可访问的了。
最后一点是最重要的，尽管许多人试图逃避它。无论采用何种技术，事实仍然是您正在开发人们将使用的应用程序。没有机器或理论能够完美地验证您的应用程序是否可用，但无论如何您都不会为机器构建它。正确的？ :)
【讨论】：
Chris Blouch (AOL) 和 Hans Hillen (TPG) 就 jQuery 进行了很好的介绍，包括他们在审查可访问性方面所做的工作。 Making Rich Internet Applications Accessible Through JQuery 你应该对 HTML5 和富 Internet 应用程序的可访问性 (http://www.paciellogroup.com/training/CSUN2012/) 感兴趣。
我的钱花在选择最易于访问的框架上：jQuery 提供了大量的优雅降级或渐进增强回退，以及对可访问性的总体关注。此外，我还间接帮助测试和审查了几个利用 jQuery（Drupal 公共和 Intranet 网站）的系统，以便发现发现的可访问性缺陷并将其发送回项目进行修复。
【讨论】：