javascript 使用像 angularjs 这样的框架对可访问性有什么影响？

What are the accessibility implications of using a framework like angularjs?

提问by S Farron

Where we stand

我们的立场

We are under a push for web accessibility in order to conform to certain laws governing public/educational institutions. Until now we've been getting by just making sure:

我们正在推动网络可访问性，以符合管理公共/教育机构的某些法律。到目前为止，我们一直在确保：

1. our layouts were logically ordered ;
2. images had alt=""tags. but are quickly learning that we need to get in gear and really think about this.

1. 我们的布局是合乎逻辑的；
2. 图像有alt=""标签。但我们很快就知道我们需要做好准备并认真考虑这一点。

What we are considering

我们正在考虑的

We've been looking at AngularJSas a framework for dynamic web applications, but are concerned about what it may mean for our accessibility standing.

我们一直将其AngularJS视为动态 Web 应用程序的框架，但担心它对我们的可访问性地位可能意味着什么。

I understand that a browser with no JavaScript will likely break a highly dynamic Angular app (e.g. expressions such as {{ item.something }}embedded in the markup, using ng-repeatto build lists from a single <li>, client-side partial views as empty tags, etc.).

我知道没有 JavaScript 的浏览器可能会破坏高度动态的 Angular 应用程序（例如，{{ item.something }}嵌入在标记中的表达式，ng-repeat用于从单个<li>客户端部分视图构建列表作为空标签等）。

Question

问题

I'm wondering if there is a well-understood best-practices or information resourcesfor these kinds of frameworks that rely heavily on dynamic markup and inline-tagging that could be perceived as gibberish to something like a screen-reader or even a browser with JavaScriptand CSSturned off.

我想知道这些严重依赖动态标记和内联标记的框架是否有一个很好理解的最佳实践或信息资源，这些框架可能被认为是诸如屏幕阅读器甚至浏览器之类的乱码JavaScript和CSS 已关闭。

采纳答案by AlastairC

All the same principles apply, such as using alt text for images, good use of headings, use the appropriate HTML(5) structures for content.

所有相同的原则都适用，例如对图像使用替代文本、正确使用标题、对内容使用适当的 HTML(5) 结构。

You might be creating it via JavaScript, but screen readers of the last ~5 years understand that, and use the browser's accessibility API to access the DOM. The non-JavaScript aspect is simply not an accessibility issue. The number of screen reader users without JavaScript is the same as the general population, therefore it comes across as fully formed HTML rather than the raw markup you see in development.

您可能通过 JavaScript 创建它，但过去大约 5 年的屏幕阅读器理解这一点，并使用浏览器的可访问性 API 来访问 DOM。非 JavaScript 方面根本就不是可访问性问题。没有 JavaScript 的屏幕阅读器用户的数量与一般人群相同，因此它是完全形成的 HTML，而不是您在开发中看到的原始标记。

NB:I consider progressive enhancement a good approach, but with Angular.js you are deciding up-front not to take that approach. If you want to know about performance and progressive enhancement, I think this answered it.

注意：我认为渐进增强是一种很好的方法，但是对于 Angular.js，您预先决定不采用这种方法。如果你想了解性能和渐进增强，我想这已经回答了。

Of course, you don't use Angular.js just to create standard content pages, so you need to get up to speed with the WAI-ARIA specification, and how to use ARIA in HTML. The specifies how to dynamically markup things that are not covered by traditional HTML practices, such as tabs, trees, grids etc.

当然，您不会仅仅使用 Angular.js 来创建标准内容页面，因此您需要快速了解WAI-ARIA 规范，以及如何在 HTML 中使用 ARIA。指定如何动态标记传统 HTML 实践未涵盖的内容，例如选项卡、树、网格等。

For a practical example of WAI ARIA techniques in practice, I would have a look at the Whatsock technical style guide.

有关 WAI ARIA 技术在实践中的实际示例，我会查看Whatsock 技术风格指南。

One difference compared to traditional websites are how you manage page updates, as you manage the keyboard focus rather than refresh the page. But apart from that, WAI-ARIA is the thing to read up on.

与传统网站相比的一个不同之处在于您如何管理页面更新，因为您管理键盘焦点而不是刷新页面。但除此之外，WAI-ARIA 值得一读。

回答by Marcy Sutton

Traditionally, Angular did not encourage developers to code user interfaces "the right way"–it was too easy to create inaccessible custom element directives (such as ngClick on a div) and no accessibility support was provided. However, it has improved with the release of Angular 1.3x and the ngAria module. Now, by including ngAria in your application, certain ARIA attributes are automatically applied so that you don't have to manage them.

传统上，Angular 不鼓励开发人员以“正确的方式”编写用户界面——创建不可访问的自定义元素指令（例如 ngClick 上的 a div）太容易了，并且没有提供可访问性支持。但是，随着 Angular 1.3x 和 ngAria 模块的发布，它得到了改进。现在，通过在您的应用程序中包含 ngAria，某些 ARIA 属性会自动应用，因此您不必管理它们。

For example, the ngClickdirective now applies tabIndex="0"and ngKeypress(as long as those options are not disabled) so that it is not as easy to create inaccessible click events. ngAria will also soon add role="button"to communicate the purpose of a clickable element: this can be overridden for other roles. See this pull request for more information: https://github.com/angular/angular.js/pull/10318

例如，该ngClick指令现在适用tabIndex="0"和ngKeypress（只要这些选项未被禁用），因此创建无法访问的点击事件并不容易。ngAria 也将很快添加role="button"来传达可点击元素的目的：这可以被其他角色覆盖。有关更多信息，请参阅此拉取请求：https: //github.com/angular/angular.js/pull/10318

Another way ngAria can help is by adding aria-disabledto any use of ng-disabled. This ensures custom controls disabled by the framework will be accessible by default, such as:

ngAria 可以提供帮助的另一种方式是添加aria-disabled到任何ng-disabled. 这确保了框架禁用的自定义控件在默认情况下可以访问，例如：

<md-button ng-disabled="true">

<md-button ng-disabled="true">

With ngAria, this becomes:

使用 ngAria，这变成了：

<md-button ng-disabled="true" aria-disabled="true">

<md-button ng-disabled="true" aria-disabled="true">

For the whole list of supported attributes, refer to the ngAria API docs: https://docs.angularjs.org/api/ngAria

有关支持的属性的完整列表，请参阅 ngAria API 文档：https://docs.angularjs.org/api/ngAria

ngAria will continue to evolve (and I wish it was just baked in instead of a module), but it's great to see accessibility finally supported by the core framework.

ngAria 将继续发展（我希望它只是被烘焙而不是模块），但很高兴看到核心框架最终支持可访问性。

It's still up to each of us to keep accessibility in mind and code responsibly, but Angular should not get in your way any longer. Alistair's answer to this question has fantastic resources: I would definitely refer to those for tips on keyboard focus management, using ARIA in HTML, and so on. You can also refer to the new Angular.js Developer Guide for ngAria: https://docs.angularjs.org/guide/accessibility

牢记可访问性并负责任地编写代码仍然取决于我们每个人，但 Angular 不应再妨碍您。Alistair 对这个问题的回答有很多很棒的资源：我肯定会参考那些关于键盘焦点管理、在 HTML 中使用 ARIA 等的提示。您还可以参考 ngAria 的新 Angular.js 开发人员指南：https://docs.angularjs.org/guide/accessibility

And one more thing: if anyone has ideas for ngAria, by all means create a Github issue or submit a pull request! It's a community-driven effort.

还有一件事：如果有人对 ngAria 有想法，一定要创建一个 Github 问题或提交拉取请求！这是社区驱动的努力。

回答by unobf

Your biggest issues with AngularJS and accessibility will be:

您在 AngularJS 和可访问性方面的最大问题是：

1. Focus management - as soon as your route causes a section of content to be updated and that section contains the focus, the browser will send focus to the top of the document and screen reader and keyboard-only users will get lost. You will have to actively manage your focus
2. Announcements of dynamic updates - data binding allows updates to occur to the DOM with no interaction with your JavaScript. If these updates are important, the screen reader users will have to be informed about these updates using aria-live regions. Getting these to work properly - especially on iOS will be tricky.
3. Form validation - the AngularJS example all use elements for the error messages that get displayed when form validation fails. None of the associations are correct with the input fields and the same issues as mentioned under #2 will have to be addressed if displaying these automatically (especially when done using blur)
4. title attribute updating - when your router changes your URL, you should be updating the title of the document

1. 焦点管理 - 一旦您的路线导致更新部分内容并且该部分包含焦点，浏览器会将焦点发送到文档的顶部，屏幕阅读器和仅使用键盘的用户将丢失。你必须积极管理你的注意力
2. 动态更新公告 - 数据绑定允许在不与 JavaScript 交互的情况下对 DOM 进行更新。如果这些更新很重要，则必须使用 aria-live 区域将这些更新通知给屏幕阅读器用户。让这些正常工作 - 特别是在 iOS 上会很棘手。
3. 表单验证 - AngularJS 示例都使用元素来显示表单验证失败时显示的错误消息。输入字段的任何关联都不正确，如果自动显示这些，则必须解决与 #2 中提到的相同问题（尤其是在使用模糊完成时）
4. 标题属性更新 - 当您的路由器更改您的 URL 时，您应该更新文档的标题

Other than that, it is just another HTML application.

除此之外，它只是另一个 HTML 应用程序。

This Github repo has some Angular.js directives and services for dealing with some of these problems https://github.com/dequelabs/ngA11y

这个 Github 存储库有一些 Angular.js 指令和服务来处理其中一些问题https://github.com/dequelabs/ngA11y