无障碍和所有这些JavaScript框架

Question

我一直在研究诸如Backbone.js和Batman.js等JavaScript框架，虽然我非常喜欢它们，但一直有一个问题困扰着我，那就是可访问性。

作为网站开发人员，我一直试图考虑到可访问性，尤其是采用渐进增强的思想。

显然，这些新的JS框架初始状态下并不会优雅地降级，因此我想知道其他开发者对此问题的看法以及你们正在采取什么措施。毕竟，在许多国家，网站/应用的可访问性实际上不是可选的事情，而是法律的一部分。

也许我只是在这个问题上过于热衷，没有意识到在可访问性方面已经取得了多大的进展。

- John Polling

Answer 1

我在我的最新网站中使用了一个js框架（例如spine.js），但我仍然确保非js浏览器（特别是搜索引擎优化）可以浏览我的网站并理解其内容。

以搜索页面为例，显示产品列表。产品可以进行分页、筛选和排序。当然，这只是一个泛化的示例。

先决条件：使用既能在服务器端呈现又能在客户端呈现的模板引擎。（我使用Mustache）。这可以确保您可以通过服务器端模板呈现模型，也可以通过客户端模板呈现模型。

1. 最初：使用服务器端Mustache模板呈现产品。还包括一个“bootstrapJSON”对象，其中包含相同的产品，以JSON格式呈现。

2. 最初：所有链接（产品详细信息页面、分页、排序、筛选）均为真实的服务器端URL（没有哈希URL）。

3. 最终结果是一个页面，可以100％使用分页、排序、筛选进行导航，而不需要JS。

4. 所有分页、排序、筛选URL都会请求服务器，服务器会呈现一组新产品。这里没有什么特别的地方。

5. 启用JS - 在domload上：

   • 获取bootstrapJSON并从中创建产品模型（使用您的js框架功能来完成此操作）。
   • 然后使用相同的Mustache模板重新呈现产品，但现在是在客户端进行呈现（再次使用您的js框架）。
   • 在视觉上不应该有任何变化（毕竟服务器端和客户端呈现都是使用相同的模型，相同的模板完成的），但至少现在客户端模型和视图之间有了一个绑定。
   • 将URL转换为哈希URL（例如：/products/#sort-price-asc ），并使用您的js框架功能连接事件。

现在每个（过滤，分页，排序）的URL都应该导致客户端状态的改变，这可能会导致您的js框架向服务器发出ajax请求以返回新产品（以JSON格式）。在客户端上重新呈现后，应该会得到更新后的视图。

处理第6步中的ajax请求的代码逻辑与第4步中使用的代码完全相同。区分ajax调用和普通请求并分别将产品输出为JSON或HTML（使用mustache服务器端渲染）。

编辑：2013年1月更新 由于这个问题/答案正在获得一些合理的关注，我想分享一些去年密切相关的“啊哈”时刻：

• 使用客户端mvc来输出JSON并在客户端上呈现结果（步骤6和7以上）可能会非常耗费cpu。当然，在移动设备上尤其明显。

• 我进行了一些测试，通过ajax返回html片段（使用服务器端mustache模板渲染），而不像我的上面的回答那样在客户端上做同样的事情。根据您的客户端设备，它可以快10倍（1000毫秒-> 100毫秒），当然，您的效果可能有所不同。（实际上不需要进行任何代码更改，因为步骤7可以同时执行两个操作）

• 当然，如果没有返回JSON，则客户端MVC无法构建模型、管理事件等。那么为什么要保留客户端MVC呢？老实说，即使是非常复杂的搜索页面，在回顾过后，我根本没有用到客户端MVC。对我来说唯一的真正好处是它有助于在客户端上清晰地分离逻辑，但是您应该已经自行这样做了。因此，在待办事项上剥离客户端MVC。

• 我用Hogan替换了Mustache（语法相同，功能略有增加，但最重要的是极其高效！）这样做是因为我将后端从Java切换到了Node.js（在我看来非常出色）

- Geert-Jan

---

@Chris：我这里也使用Java。Mustache有一个Java实现。 - Geert-Jan

@RenderIn：至于你的第二个问题：确实有时我需要提供一些状态来区分是在客户端还是服务器端呈现产品。例如，在这个例子中，客户端渲染需要呈现哈希标记URL，而服务器端呈现则呈现“正常”URL。我通过混合（或覆盖）表示产品的js对象文字的属性来解决这个问题。因此，对于URL的更改，我只需为每个产品覆盖product.url属性即可。 - Geert-Jan

使用 HTML5 pushState，如果浏览器不支持，则退回到哈希符号是否更好？这样，您的客户端路由可以完全匹配您的服务器端路由，无需在页面加载时更改 href 为哈希标记，只需拦截链接单击并呈现相应的视图即可。 - Scott Greenfield

@Scott：确实，这是一个不错的额外渐进增强。但我还没有深入考虑过与此相关的SEO影响。如果你的客户端渲染因某种原因明显不同于服务器端（与上述策略相反），会怎样呢？这将在同一URL下根据JavaScript是否启用而产生两个不同的结果。从谷歌的角度来看，这是否被认为是欺骗/不良做法？无论如何，在上述情况下，它都能很好地工作。 - Geert-Jan

那么，我们有没有JS“框架”推荐可以帮助处理PE？我有一个服务器渲染的站点，其中包含PE，但JS可能变得难以控制，我感觉一些处理AJAX响应、重定向、会话管理等的框架/清晰模式将会大有裨益。我不认为我需要像Backbone、Angular、Ember等完整的客户端框架的“强大”功能。 - Ian

Answer 2

由于我是一位视障用户和Web开发人员，所以我想在这里发表一下我的看法。

就我的经验而言，只要针对辅助功能采取适当的步骤，这些框架并不会成为问题。

许多屏幕阅读器能够理解JavaScript，作为开发人员，我们可以使用像HTML5的aria-live属性来提醒屏幕阅读器有事情正在改变，并且我们可以使用角色属性来为屏幕阅读器提供额外的提示。

然而，Web开发使用JavaScript的基本原则是，我们应该先开发没有JavaScript的基础站点，然后使用该稳定、可工作和经过测试的基础来提供更好的功能。使用JS不应该是购买产品、接收服务或获取信息所必需的。一些用户禁用JavaScript是因为它会干扰他们的屏幕阅读器的工作方式。

如果完全从头开始构建Backbone.js或Knockout网站而不考虑无障碍性，将导致类似于“新Twitter”的失败 ，这在许多屏幕阅读器上表现非常糟糕。但是Twitter有一个坚实的基础，因此我们可以使用其他方式访问该平台。将Backbone植入具有精良API的现有站点是完全可行的，也非常有趣。

因此，这些框架本身并不比jQUery本身更具有无障碍性问题，关键在于开发人员需要设计一个适用于所有人的用户体验。

- Brian Hogan

---

完全同意这一观点，JS应该是后期添加的一层，在功能性网站中不是必需品（渐进增强）。不幸的是，最近我与一些开发者讨论时得知，他们认为Web应用程序与网站有所不同，对于Web应用程序来说，用户必须预期需要JS才能正常运行。 - John Polling

你有没有使用服务器生成的模板来引导视图，然后使用JS进行后续渲染的经验？具体来说，是指batman.js... - Avishai

问题是针对您的，@http://stackoverflow.com/users/107134/brian-hogan，如果我们使用aria-live来处理出现或更改的项目，那么对于通过jQuery Show/Hide点击出现的div，我们是否也会使用aria-expanded？我们需要100％无障碍，没有例外。 - isaac weathers

Answer 3

任何需要使用javascript才能获取内容的网页都可能面临无障碍相关挑战。JavaScript框架的无障碍性肯定是一个争议问题，但实际上，无论使用哪种框架，当提供动态内容时，任何Web应用程序都会遇到缺点。

没有银弹可以确保您的站点可访问，我当然不能考虑每个JavaScript框架。以下是一些关于如何在使用JavaScript时防止您的站点完全无法访问的想法。

• 遵循WCAG 2.0关于客户端脚本以及WCAG 2.0的指南。

• 避免使用需要通过javascript生成页面UI、控件和/或内容的框架，例如Uki.js，或者使用自己专有的标记语言，例如Jo。尽可能接近静态（-ish），语义化的HTML内容，你会更好地处理这些问题。

• 考虑使用ARIA roles，例如role="application"和aria-live属性来指示页面中动态区域。随着时间的推移，越来越多的辅助设备支持ARIA roles，因此在适当的情况下添加这些ARIA属性是有意义的。

  就JS库而言，请检查它们的源代码并查看它们是否输出任何ARIA roles。它们可能不是完全可访问的，但这表明他们正在考虑辅助设备。

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

• 与用户一起测试和验证您的应用程序！与使用辅助设备或其他难以使用Web软件的人进行一些用户测试会有所帮助。观察真正的用户使用它将有助于证明您的网站是可访问的。

最后一点是最重要的，尽管许多人试图逃避它。无论技术如何，事实仍然是你正在开发一个人们将使用的应用程序。没有任何机器或理论能够完美地验证您的应用程序是否可用，但您毕竟不是为机器而建立它。对吧？ :)

- Chris

---

我完全同意这一点。我担心的是像Backbone.js这样的流行工具正在迅速发展，但似乎没有人谈论无障碍问题。这可能是因为开发人员不关心，或者只是想尝试新的闪亮工具。 - John Polling

总的来说，未经训练的人往往不会充分考虑无障碍性；这是他们看不到、听不到或不知道的事情，而且他们可能既不理解也不在乎。编写框架的人和一般编写JavaScript的人同样容易受到此影响。 - Chris

场景中有一些大嗓门的人试图将可访问性问题置于前台。Steve Faulkner和Bruce Lawson就是这样的人。总的来说，我认为行使对可访问性的谨慎不会成为普遍做法。这是一个巨大而棘手的话题，在一般情况下很难做到完美。 - Chris

mm 开始输入评论，但我会写一个答案代替。必须在这里写点什么，因为我无法删除它。 - Geert-Jan

Answer 4

Chris Blouch (AOL)和Hans Hillen (TPG)就jQuery的相关问题做了一个很好的演讲，包括他们在审查可访问性方面所做的工作。通过JQuery实现富互联网应用程序的可访问性 这个以及另一个有关HTML5和富互联网应用程序可访问性的演示文稿（http://www.paciellogroup.com/training/CSUN2012/）可能会对您有兴趣。

我认为选择最具可访问性的框架是最好的选择：jQuery提供了大量优雅降级或渐进增强的回退功能，以及对可访问性的全面关注。此外，间接地，我帮助测试和审查了几个利用jQuery（Drupal公共和Intranet网站）的系统，以便发现并修复可访问性缺陷。

- Norman B. Robins0n