可访问性和所有这些JavaScript框架

一段时间以来，我一直在研究一些JavaScript框架，例如Backbone.js和Batman.js，尽管我真的很喜欢它们，但我有一个小话题要回头再谈。那个问题是可访问性。

作为Web开发人员，我一直试图使我的网站和应用程序具有可访问性，尤其是使用渐进增强的想法。

显然，这些新的JS框架并不能很好地降级，因此我想知道其他开发人员在此问题上有何想法，您对此打算做什么。毕竟，在许多国家/地区，网站/应用的可访问性并不是一项可选的事情，因为它是法律的一部分。

也许我只是对这个主题过于热心，而没有意识到在可访问性方面已经走了多远。

我在最新站点中使用了js-framework（在我的情况下为spine.js）。不过，我仍然确保非js浏览器（一定不会过分热心：认为SEO）可以导航我的网站并提取内容。

例如，我要搜索一个显示产品的搜索页面。产品可以分页，过滤，排序。当然，这是广义思想的一个例子。

PREREQ：使用可以同时渲染服务器端和客户端的模板引擎。（我用小胡子）。这样可以确保您可以通过服务器端模板来渲染不带js-的模型，并通过客户端模板来渲染带js的模型。

1. 最初：使用服务器端mustache-template渲染产品。还包括一个“ bootstrapJSON”对象，该对象包含JSON格式的相同产品。

2. 最初：所有链接（产品详细信息页面，分页，排序，过滤）都是真实的服务器端网址（没有hashbang网址）

3. 最终结果是一个页面，无需使用JS，就可以使用分页，排序和过滤功能进行100％的导航。

4. 所有分页，排序，过滤URL都会导致对服务器的请求，进而导致呈现一组新的产品。这里没什么特别的。

5. 启用JS-在domload上：

   • 提取bootstrapJSON并从中创建产品模型（使用js-framework功能执行此操作）。
   • 之后，使用相同的胡须模板重新渲染产品，但现在在客户端进行。（再次使用您的js框架）。
   • 在视觉上，什么都应该改变（在使用相同模板的相同模型上完成所有服务器端和客户端渲染之后），但是至少现在客户端模型和视图之间存在绑定。
   • 将网址转换为hashbang-url。（例如：/ products /＃sort-price-asc），然后使用您的js框架功能关联事件。

6. 现在，每个（过滤，分页，排序）URL都应导致客户端状态更改，这可能导致您的js框架向服务器执行ajax请求以返回新产品（JSON格式）。再次在客户端上渲染此视图将导致您更新视图。

7. 在服务器端处理6中的ajax请求的代码的逻辑部分与4中使用的代码100％相同。区分ajax调用和普通请求，并以JSON或html形式吐出产品（在服务器端使用小胡子）。

编辑：2013年1月更新 由于此问题/答案受到了一定的关注，我想我应该分享去年的一些密切相关的想法：

• 分派JSON并使用您选择的客户端mvc（在上面的步骤6.和7.）将其呈现到客户端可能是非常昂贵的cpu方式。当然，这在移动设备上尤其明显。

• 我已经做过一些测试，以在ajax上返回html代码段（使用服务器端的mustache-template渲染），而不是像上面我的答案所建议的那样在客户端上做同样的事情。视您的客户端设备而定，它可能会快10倍（1000毫秒-> 100毫秒），当然，您的里程可能会有所不同。（实际上，不需要任何代码更改，因为步骤7可以同时完成这两项操作）

• 当然，当没有返回JSON时，客户端MVC就无法构建模型，管理事件等。那么为什么要保留客户端MVC呢？老实说，事后看来，即使是非常复杂的搜索页面，我对客户端mvc的使用也很少。对我来说，唯一真正的好处就是它们有助于清楚地分离出客户端上的逻辑，但是您应该已经在自己的恕我直言中做到了。因此，将客户端MVC剥离是必须要做的。

• 哦，是的，我用Hogan（相同的语法，更多的功能，但大多数都具有极高的性能！）进行了Mustache的交易，因为我将后端从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（例如Uki.js）或使用自己专有标记的框架（例如Jo）来生成页面的UI，控件和/或内容。您可以越贴近静态（-ish）语义HTML内容，您的生活就会越好。

• 考虑使用ARIA角色（例如role="application"和aria-live属性）来指示页面的动态区域。随着时间的流逝，辅助设备将支持越来越多的aria角色，因此，当您可以将这些aria属性适当地添加到应用中时，使用这些aria属性是有意义的。

  对于JS库，请检查其源，并查看它们是否输出任何aria角色。它们可能不是很方便访问，但是这表明他们正在考虑使用辅助设备。

• 尽可能将JavaScript视为增强功能而不是必需品。尝试提供替代方法或工作流来访问不需要动态页面更新的重要信息。

• 与您的用户一起测试和验证您的应用！与使用辅助设备或使用网络软件有其他困难的人员进行一些用户测试。没有什么比观看真实的人使用它更能证明您的网站可以访问。

最后一点是最重要的，尽管许多人试图逃避它。无论采用哪种技术，事实都是您正在开发人们将使用的应用程序。没有机器或理论能够完美验证您的应用程序是否可用，但是无论如何您都不是为机器构建它。对？:)

Chris Blouch（AOL）和Hans Hillen（TPG）就jQuery进行了很好的介绍，包括他们在审查可访问性方面所做的工作。通过JQuery使Rich Internet Application可访问性以及有关HTML5和Rich Internet Applications的可访问性的另一个相关演示文稿（http://www.paciellogroup.com/training/CSUN2012/）应该引起您的兴趣。

我的钱是选择最易访问的框架：jQuery提供了许多优雅的降级或渐进式增强后备功能，以及对可访问性的总体关注。另外，我间接地帮助测试和审查几个利用jQuery的系统（Drupal公共和Intranet网站），以便发现为可访问性而发现的缺陷，并将其路由回项目以进行修复。