可访问性和所有这些 JavaScript 框架 [英] Accessibility and all these JavaScript frameworks
问题描述
一段时间以来，我一直在研究一些 JavaScript 框架，例如 Backbone.js 和 Batman.js，虽然我真的很喜欢它们，但我有一件琐碎的事情，我一直在回顾.这个问题是可访问性.
I've been investigating a few of the JavaScript frameworks such as Backbone.js and Batman.js for a while and whilst I really like them, I have one niggling thing that I keep coming back to. That issue is accessibility.
作为一名网络开发人员，我一直试图让我的网站和应用程序具有可访问性，尤其是使用渐进增强的想法.
As a web developer I've always tried to make my websites and applications with accessibility in mind, especially using the idea of progressive enhancement.
显然，这些新的 JS 框架开箱即用并不会优雅地降级，所以我想知道其他开发人员对这个问题有什么想法，你正在做些什么.毕竟，网站/应用程序的可访问性并不是一个可选项，因为它是许多国家/地区法律的一部分.
Clearly out of the box these new JS frameworks don't gracefully degrade, so I was wondering what are other developers thoughts on this issue and what are you doing about it. After all the accessibility of a website / app isn't really an optional thing as it's part of the law in many countries.
也许我只是在这个主题上过于热心，并没有意识到在可访问性方面已经取得了多大进展.
Maybe I'm just being overly zealous on this subject, and not appreciating how far things have come in terms of accessibility.
推荐答案
我在我的最新站点中使用了一个 js 框架(在我的例子中是 spine.js).我仍然确保非 js 浏览器(当然不会过于狂热:想想 SEO)可以浏览我的网站并消化内容.
I use a js-framework (spine.js in my case) in my latest site. Still I make sure that non-js browsers (certainly not over zealous: think SEO) can navigate my site and digest the contents.
作为一个例子，我将使用一个显示产品的搜索页面.可以对产品进行分页、过滤、排序.当然，这是广义思想的一个例子.
As an example I'm going with a search-page with products being shown. Products can be paged, filtered, sorted. Of course this is an example of the generalized idea.
PREREQ:使用既可以渲染服务器端也可以渲染客户端的模板引擎.(我用小胡子).这确保您可以通过服务器端模板渲染没有 js 的模型，并通过客户端模板渲染带有 js 的模型.
PREREQ: use a template-engine that can both render server-side and client-side. (I use Mustache) . This makes sure you can render models without js- through server-side templating, and render models with js through client-side templating.
最初:使用服务器端 mustache-template 渲染产品.还包括一个bootstrapJSON"对象，其中包含 JSON 格式的相同产品.
Initially: render the products using server-side mustache-template. Also include a 'bootstrapJSON'-object which contains the same products in JSON-format.
最初:所有链接(产品详细信息页面、分页、排序、过滤)都是真实的服务器端 url(没有 hashbang url)
Initially: all links (product-detail page, paging, sorting, filtering) are real server-side urls (no hashbang urls)
最终结果是一个页面，可以在不使用 JS 的情况下通过分页、排序、过滤进行 100% 导航.
The end-result is a page which can be navigated 100% with paging, sorting, filtering without the use of JS.
所有分页、排序、过滤 url 都会导致对服务器的请求，从而导致呈现一组新的产品.这里没什么特别的.
all paging,sorting, filtering urls result in a request to the server, which in turn results in a new set of products being rendered. Nothing special here.
启用 JS - 在 domload 上:
JS-enabled - on domload:
- 获取 bootstrapJSON 并从中制作产品模型(使用您的 js-framework 功能来执行此操作).
- 之后使用相同的 mustache 模板重新渲染产品，但现在在客户端进行.(再次使用您的 js 框架).
- 从视觉上看，应该没有任何变化(在所有服务器端和客户端渲染都是在相同的模型和相同的模板上完成之后)，但至少现在客户端模型和视图之间存在绑定.
- 将 url 转换为 hashbang-url.(例如:/products/#sort-price-asc )并使用您的 js-framework 功能来连接事件.
现在每个(过滤、分页、排序)url 都应该导致客户端状态更改，这可能会导致您的 js 框架向服务器执行 ajax 请求以返回新产品(在JSON 格式).在客户端上再次重新渲染应该会导致您更新视图.
now every (filtering, paging, sorting ) url should result in a client-side state-change, which would probably result in your js-framework doing an ajax-request to the server to return new products (in JSON-format) . Rerendering this again on the client should result in your updated view.
6.服务端处理ajax-request的逻辑部分与4. ajax-call和普通请求的区别并吐出的代码100%相同JSON 或 html 中的产品(使用 mustache 服务器端).
The logic part of the code to handle the ajax-request in 6. on the server-side is 100% identical to the code used in 4. Differentiate between an ajax-call and an ordinary request and spit out the products in JSON or html (using mustache server-side) respectively.
2013 年 1 月更新由于这个问题/答案得到了一些合理的关注，我想我会分享去年的一些密切相关的啊哈时刻:
UPDTATE JAN 2013 Since this question/answer is getting some reasonable traction I thought I'd share some closely-related aha-moments of the last year:
吐出 JSON 并使用您选择的客户端 mvc(上面的第 6 步和第 7 步)在客户端渲染它在 CPU 方面的开销非常大.当然，这在移动设备上尤为明显.
Spitting out JSON and rendering it client-side with your client-side mvc of choice (steps 6. and 7. above) can be pretty costly cpu-wise. This, of course, is especially apparent on mobile-devices.
我已经进行了一些测试，以在 ajax 上返回 html 片段(使用服务器端 mustache-template 渲染)，而不是像上面的回答中所建议的那样在客户端执行相同的操作.根据您的客户端设备，它可以快 10 倍(1000 毫秒 -> 100 毫秒)，当然您的里程可能会有所不同.(实际上不需要更改代码，因为第 7 步已经可以做到)
I've done some testing to return html-snippets on ajax (using server-side mustache-template rendering) instead of doing the same on the client-side as suggested in my answer above. Depending on your client-device it can be up to 10 times faster (1000ms -> 100ms) , of course your mileage may vary. (practically no code changes needed, since step 7. could already do both)
当然，当没有返回 JSON 时，客户端 MVC 就无法构建模型、管理事件等.那么为什么要保留客户端 MVC 呢?老实说，事后看来，即使是非常复杂的搜索页面，我对客户端 mvc 也没有太大用处.对我来说唯一真正的好处是它们有助于清楚地分离客户端的逻辑，但您应该已经在自己的 imho 上这样做了.因此，剥离客户端 MVC 是当务之急.
Of course, when no JSON is returned there's no way for a client-side MVC to build models, manage events, etc. So why keep a clientside MVC at all? To be honest, with even very complex searchpages in hindsight I don't have much use for client-side mvc's at all. The only real benefit to me is that they help to clearly separate out logic on the client, but you should already be doing that on your own imho. Consequently, stripping out client-side MVC is on the todo.
哦，是的，我在 Mustache 中与 Hogan(相同的语法，一个更多功能，但最重要的是性能非常好！)之所以能够这样做，是因为我将后端从 java 切换到 Node.js(恕我直言)
Oh yeah, I traded in Mustache with Hogan (same syntax, a bit more functionality, but most of all extremely performant!) Was able to do so because I switched the backend from java to Node.js (which rocks imho)
这篇关于可访问性和所有这些 JavaScript 框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
