可访问性和所有这些 JavaScript 框架
我研究一些 JavaScript 框架（例如 Backbone.js 和 Batman.js）已经有一段时间了，虽然我真的很喜欢它们，但我一直在关注一件棘手的事情。这个问题就是可访问性。
作为一名网络开发人员，我一直试图让我的网站和应用程序考虑到可访问性，特别是使用渐进增强的想法。
显然，开箱即用的这些新 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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我在最新的网站中使用了 js 框架（在我的例子中是 spin.js）。我仍然确保非 js 浏览器（当然不要过于热心：想想 SEO）可以浏览我的网站并消化内容。
作为一个例子，我将使用一个显示产品的搜索页面。产品可以分页、过滤、排序。当然，这是广义思想的一个例子。
PREREQ：使用可以同时渲染服务器端和客户端的模板引擎。 （我用小胡子）。这确保您可以通过服务器端模板渲染没有 js 的模型，并通过客户端模板渲染使用 js 的模型。
最初：使用服务器端 Mustache-template 渲染产品。还包括一个“bootstrapJSON”对象，其中包含 JSON 格式的相同产品。
最初：所有链接（产品详细信息页面、分页、排序、过滤）都是真实的服务器端 URL（无 hashbang url）
最终结果是一个可以100%导航、分页、排序、过滤而无需使用JS的页面。
所有分页、排序、过滤 URL 都会向服务器发出请求，进而导致呈现一组新的产品。这里没什么特别的。
启用 JS - 在 domload 上：
现在每个（过滤、分页、排序）url 都会导致客户端状态更改，这可能会导致您的 js 框架向服务器发出 ajax 请求以返回新产品（以 JSON 格式） ）。在客户端上再次重新渲染应该会导致视图更新。
服务器端处理 6. 中的 ajax 请求的代码逻辑部分与 4. 中使用的代码 100% 相同。区分 ajax 调用和普通请求并吐出中的产品分别为 JSON 或 html（使用 Mustache 服务器端）。
编辑：2013 年 1 月更新
由于这个问题/答案得到了一些合理的关注，我想我应该分享去年一些密切相关的顿悟时刻：
吐出 JSON 并使用您选择的客户端 mvc 将其渲染到客户端（步骤上面的 6. 和 7.）在 CPU 方面可能会非常昂贵。当然，这在移动设备上尤其明显。 吐出JSON
我已经做了一些测试，以在ajax上返回html片段（使用服务器端胡子模板渲染），而不是按照我上面的答案中的建议在客户端执行相同的操作。根据您的客户端设备，速度最多可以提高 10 倍（1000 毫秒 -> 100 毫秒），当然您的里程可能会有所不同。 （实际上不需要更改代码，因为步骤 7. 已经可以同时执行这两项操作）
当然，当没有返回 JSON 时，客户端 MVC 无法构建模型、管理事件等。那么为什么还要保留客户端MVC 到底是什么？老实说，事后看来，即使是非常复杂的搜索页面，我对客户端 mvc 也没有太多用处。对我来说唯一真正的好处是它们有助于清楚地分离出客户端的逻辑，但恕我直言，您应该已经自己这样做了。因此，剥离客户端 MVC 是当务之急。
哦，是的，我用 Hogan 交易了 Mustache（相同的语法，更多的功能） ，但最重要的是性能非常好！）之所以能够这样做，是因为我将后端从 java 切换到了 Node.js（恕我直言，这很震撼）
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: 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.
Initially: render the products using server-side mustache-template. Also include a 'bootstrapJSON'-object which contains the same products in JSON-format.
Initially: all links (product-detail page, paging, sorting, filtering) are real server-side urls (no hashbang urls)
The end-result is a page which can be navigated 100% with paging, sorting, filtering without the use of JS.
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-enabled - on domload:
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.
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.
EDIT: 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:
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.
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)
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.
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)
由于我是一名视障用户和 Web 开发人员，所以我会在这里插话。
根据我的经验，只要在可访问性方面采取适当的步骤，这些框架就不是问题。
许多屏幕阅读器都了解 JavaScript，我们作为开发人员可以使用 HTML5 的 aria-live 属性等来改善体验，以提醒屏幕阅读器事情正在发生变化，并且我们可以使用 role 属性向屏幕阅读器提供额外的提示。
然而，使用 JavaScript 进行 Web 开发的基本原则是，我们应该首先在没有 JavaScript 的情况下开发底层站点，然后使用可靠、有效且经过测试的基础来提供更好的功能。购买产品、接受服务或获取信息不应要求使用 JS。一些用户禁用 JavaScript，因为它会干扰屏幕阅读器的工作方式。
从头开始做一个完整的 Backbone.js 或 Knockout 网站而不考虑可访问性将导致类似于“新 Twitter”的东西，这对许多屏幕阅读器来说非常困难。但Twitter有坚实的基础，所以我们可以通过其他方式来访问该平台。将 Backbone 移植到具有精心设计的 API 的现有网站上是完全可行的，而且也非常有趣。
所以基本上，这些框架本身并不比 jQUery 本身更多的可访问性问题 - 开发人员需要打造适合每个人的用户体验。
Since I'm a visually-impaired user and web developer, I'll chime in here.
These frameworks, in my experience, haven't been a problem provided the appropriate steps are taken with regard to accessibility.
Many screen readers understand JavaScript, and we as developers can improve the experience using things like HTML5's aria-live attribute to alert screen readers that things are changing, and we can use the role attribute to provide additional hints to the screenreaders.
However, the basic principle of web development with JavaScript is that we should develop the underlying site first, without JavaScript, and then use that solid, working, and tested foundation to provide better features. The use of JS should not be required to purchase a product, receive services, or get information. And some users disable JavaScript because it interferes with the way their screenreaders work.
Doing a complete Backbone.js or Knockout site from the ground up without regard for accessibility will result in something akin to "new Twitter" which fails extremely hard with many screenreaders. But Twitter has a solid foundation and so we can use other means to access the platform. Grafting Backbone onto an existing site that has a well-crafted API is quite doable, and an awful lot of fun, too.
So basically, these frameworks themselves are no more of an accessibility issue than jQUery itself - the developer needs to craft a user experience that works for everyone.
任何需要 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 属性适当地添加到您的应用程序中时，使用这些 aria 属性是有意义的。对于 JS 库，检查其源代码并查看是否输出任何 aria 角色。它们可能无法完全无障碍，但这表明他们正在考虑使用辅助设备。
尽可能将 JavaScript 视为增强功能而不是必需品。尝试提供替代方法或工作流程来访问不需要动态页面更新的重要信息。
与您的用户一起测试并验证您的应用！与使用辅助设备或在使用网络软件方面有其他困难的人进行一些用户测试。没有什么比观看真人使用您的网站更能帮助您证明您的网站是可访问的了。
最后一点是最重要的，尽管许多人试图逃避它。无论采用何种技术，事实仍然是您正在开发人们将使用的应用程序。没有机器或理论能够完美地验证您的应用程序是否可用，但无论如何您都不是为机器构建它。正确的？ :)
Any webpage that requires javascript in order to get the content out of it will likely be met with accessibility-related challenges. The accessibility of JavaScript frameworks is definitely an issue of contention, though really, any web application suffers drawbacks when content is provided dynamically, regardless of the framework used.
There's no silver bullet to ensure your site will be accessible, and I certainly can't account for every JavaScript framework. Here's a few thoughts about how you can prevent your site from being totally inaccessible when using JavaScript:
Follow the guidelines from WCAG 2.0 on client-side scripting, and WCAG 2.0 in general.
Avoid frameworks that require you generate the page's UI, controls and/or content entirely through javascript such as Uki.js, or ones that use their own proprietary markup, like Jo. The closer you can stick with static(-ish), semantic HTML content, the better off you'll be.
Consider using ARIA roles such as
role="application"and thearia-liveattribute to indicate the areas of your page which are dynamic. More and more aria roles are being supported by assistive devices as time goes by, so using these aria attributes makes sense when you can add them to your app appropriately.In terms of JS libraries, check their source and see if they output any aria roles. They might not be perfectly accessible, but it would demonstrate they're considering assistive devices.
Wherever possible, treat JavaScript as an enhancement rather than a necessity. Try to provide alternative methods or workflows to accessing the important information that don't require dynamic page updates.
Test and validate your app with your users! Do some user testing sessions with people who use assistive devices or have other difficulties using web software. Nothing will help you prove your site is accessible more than watching real people use it.
The last point is the most important, though many try to escape it. Regardless of the technology, the fact remains that you're developing an application that people will use. No machine or theory will ever be able to perfectly validate your application as being usable, but you're not building it for machines anyway. Right? :)
Chris Blouch (AOL) 和 Hans Hillen (TPG) 就 jQuery 做了很好的介绍，包括他们在审查可访问性方面所做的工作。 让丰富的 Internet 应用程序可通过 JQuery 访问该演示以及另一个有关 HTML5 和富互联网应用程序的可访问性的相关演示 (http://www.paciellogroup.com/training/CSUN2012/）您应该会感兴趣。
我的重点是选择最易于访问的框架：jQuery 提供了大量的优雅降级或渐进增强回退以及总体上非常注重可访问性。此外，我还间接帮助测试和审查几个利用 jQuery 的系统（Drupal 公共和 Intranet 网站），以便发现可访问性方面的缺陷并将其路由回项目进行修复。
Chris Blouch (AOL) and Hans Hillen (TPG) had a good presentation on this regarding jQuery, including the work they do in reviewing for accessibility. Making Rich Internet Applications Accessible Through JQuery That and another related presentation on Accessibility of HTML5 and Rich Internet Applications (http://www.paciellogroup.com/training/CSUN2012/) should be of interest to you.
My money is on choosing the most accessible framework: jQuery provides a great deal of graceful degradation or progressive enhancement fallback as well as an overall pretty good focus on accessibility. Also, indirectly I help test and review several systems that leverage jQuery (Drupal public and Intranet websites) such that defects found for accessibility are found and routed back to the project for fixes.