I highly recommend reading the MDN Site about it. There is everything you need: Documentation, Descriptions, Tutorials, FAQs.

Additionally you might want to take a look at this video series about accessability.

One of the sites I used a lot and see recommended a lot is WebAIM http://webaim.org

The most important thing is to be clear on what ARIA does (and doesn't do) and know all the ways to avoid needing to use ARIA in the first place. Which is another way of saying you need to understand accessibility principles before ARIA will make a whole lot of sense.

The short version is that ARIA describes what the HTML element is doing, without adding or removing any functionality, which is useful when that element is not doing what it normally does; or would normally be replaced with something else. The classic example is to describe the fact a span is acting like a button. Obviously the simpler way to replicate the various properties of a button is to actually use one - the old "you can't style them" argument is out of date.

To give you something more useful: start with the simple things. Does your app have a lot of elements which get shown and hidden? Migrate them away from direct CSS or commong but non-standard class names like hidden.

Instead use aria-hidden combined with this css:

[aria-hidden="true"] { display: none; }

When your app updates the DOM, set the attribute to true or false and now you have nicely-described behaviour making use of ARIA. The huge upside here on top of accessibility is this gives you an explicit state which is useful in tests. I go a bit deeper into the wider benefits of ARIA in this presso - http://www.slideshare.net/200ok/a11y-camparia

After that, start evaluating your code for elements being used in ways that aren't effectively described to assistive tech; and sparingly add roles where required... and so on.

My advice: DON'T!!!

It's hoodoo-voodoo that not ONE legitimate user-agent for people with ACTUAL accessibility needs makes even the slightest use of. It's pointless code-bloat that at BEST should be redundant to your semantics or the content itself, at worst is a snake oil peddled fairy tale NOBODY is implementing to do what it's advertised to do.

If anything the only LEGITIMATE purpose it serves is to satiate the wants and desires of the same metadata junkies who used to make up their own "microformats" bullshit to try and make data scraping easier... and let's be brutally frank and call out data scrapers by their REAL names, "CONTENT THIEVES!"

Much like HTML 5's mind-numbingly idiotic and pointlessly redundant ARTICLE, ASIDE, NAV, HEADER, FOOTER, SECTION, and MAIN, if you have content of value marked up with the EXISTING structural tags of H1..H6 and HR according to the professional writing norms that HTML was based on, they serve NO purpose other than to make lame excuses to just crap more code into the page instead of putting content of value in there as ACTUAL content.

Again as I often say about a lot of the pointless extra garbage that is peddled as accessibility by people that have clearly never used a screen reader or braille reader, it's little more than dumping a can of shellac on a pile.

Though I might just be saying that as I'm not DUMB ENOUGH to crap JavaScript into a page in a manner that doesn't gracefully degrade when scripting is blocked, unavailable, or irrelevant to the user's capabilities. If you actually CARED about users with accessibility needs you wouldn't be writing your pages in a manner that NEEDED "aria roles" in the first bloody place since you'd be progressively enhancing content-upwards so it gracefully degrades!

But I guess if you're crapping Scripting only functionality, scripting only elements into the markup, not bothering to understand why headings have numbers, that paragraphs are for grammatical paragraphs, or why short lists of choices go into lists, whilst crapping all over your HTML with endless pointless presentational classes OOCSS style resulting in two to ten times the HTML needed whilst flipping the bird at accessibility -- throwing more code at it as if that will magically help might make sense.

MUCH like a great deal of HTML 5, Aria roles simply prove the people currently working on the spec never embraced 4 Strict and are unqualified to be making its successor.