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

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

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.

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.

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.

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

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.

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.

For example, the ngClick directive 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

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

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

With ngAria, this becomes:

<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 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.

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

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.

Your biggest issues with AngularJS and accessibility will be:

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

Other than that, it is just another HTML application.

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