Suppose for a moment that you have an AngularJS single-page
application, one with view routes managed with then ngRoute module, that
is used by users with different roles. A user in your company's Sales
group has access to certain areas of the application, while a user in
Accounting works in other parts of the application. And there are also
some areas of the application that are common to all users.
Now, you already have the navigation menu wired up so that users only
see the navigation links appropriate to their user roles. And even if a
Sales user somehow ends up in a view meant for an Accounting user, the
server answering the REST calls for the data powering that view is going
to check the security token sent with the request and isn't going to
honor that request. But you'd still like to keep users out of UI views
that aren't meant for them.
You could do a user access check at the start of each controller, or
perhaps within the resolve property of each route, but that would be
repetitive and it's something you could forget to do on occasion.
Sometimes projects take on a life of their own, and you end up with something unexpected.
I set out to create an template for CRUD-focused single page
AngularJS web applications, something I and perhaps my colleagues could
use as a foundation for writing new applications. But under the
momentum of self-applied scope creep, what I ended up creating was a
Grunt-powered codebase library management tool, with my original
template concept as the first codebase of potentially multiple
Last week I participated in a series of lightning talks at the AngularJS DC Meetup, hosted by Difference Engine,
and I thought I'd share the links to the slide decks and demos
presented (unfortunately, the equipment recording the entire event
failed, otherwise I would just share that).
One of the most common uses of the Grunt
task runner is to build a deployment package out of your development
code for your website or web application, and part of that build process
singular (or at least fewer) files for optimal download.
The grunt-contrib-concat Grunt plugin allows you to configure a concatenation task to target individual files or entire directories, like so:
src: [ 'dev/jquery/jquery.js', 'dev/angular/services/*.js', 'dev/angular/directives/*.js' ],
The only drawback is that you have to update the task's "src"
As I was playing around with Grunt on a personal project, I came to
wonder: could I create a Grunt task or set of tasks that could figure
out which files to concatenate based on the <link> and
<script> tags in my code? Here's what I came up with.
Turns out using this new module is drop-dead simple. You don't have to add any code to your markup in order to use it: once you include the ngAria module in your Angular application, it'll automatically add and manage "aria-" attributes on your DOM elements, attributes that help screen readers understand what's going on in your application.
The folks over at Egghead.io have an excellent five minute video that demonstrates ngAria in action: https://egghead.io/lessons/angularjs-using-ng-aria-to-automatically-improve-your-angularjs-accessibility
You can also read more about ngAria on the AngularJS documentation page on accessibility: https://docs.angularjs.org/guide/accessibility
Frankly, I can't see a reason for not including this module in your AngularJS application if you're using Angular 1.3x. It won't solve every accessibility issue, but it's a good starting point.