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