Testing for accessibility is generally testing that needs to be done by people. Tools exist but are limited. Generally the tools expect to go through markup; since you're making things in Flash, it would have to be things that can interact with Flash the way Accessibility Technology (AT) does... and I don't know that much AT interacts well with Flash. Especially if these are web-based Flash.
Karl Groves recommends starting with automated testing first because it's cheap, easy and finds all the stupid stuff first: http://www.karlgroves.com/2012/02/02/web-accessibility-testing-do-automatic-testing-first/ but while I know he personally has worked with many tools, he doesn't list them here. I only know the outdated and broken tools so I won't list them.
However while automated testing tools can find easy stupid things (again, not sure at all about Flash), you then MUST use actual human testers.
Here's a more recent article by him: http://www.karlgroves.com/2012/09/15/accessibility-testing-what-can-be-tested-and-how/ where he lists actual WCAG guideline sections and marks which parts he believes can be dealt with by tools and what needs human testers... but again I'm thinking he's primarily thinking of the web (with a DOM, like HTML or SVG, and likely also PDFs) rather than Flash.
You might have to go through the Guidelines yourself, which in WCAG 2 simply list "success criteria" (can a user do X) and you may need to go through those yourself and check that way. If you do that you might want to start with an easy, clear checklist (here's Roger Hudson's: http://www.usability.com.au/resources/wcag2checklist.cfm and WebAIM's: http://webaim.org/standards/wcag/checklist <--again, HTML).
If you're on LinkedIn, there's a group called Web Accessibility and from there I learned there's a group more specific to e-learning and online education and accessibility. You might want to check that out, people in the group discussing specific problems they run into, tools they use, etc. Very useful.