Actually using a screen reader is a difficult skill to master. It is unlikely that you would be able to get a QA resource who is expert enough in using a screen reader to know whether a problem using the tool is actually a bug or not. In my experience, you would be much better off focusing on ensuring you are following best practices than by trying to simulate the use of accessibility tools.
IE's developer tools include a "Validate | Accessibility" menu option.
There are tons of other free tools that will validate HTML for you with a focus on accessibility and most do a pretty good job. Many are listed here: http://www.w3.org/WAI/ER/tools/complete.html
After reading a few of the other answers, I wanted to expand on my answer. Let's suppose you do use Jaws to test the accessibility of your web site. Let's say that Jaws has a bug, a flaw in the way it uses the accessibility data on your site. You see that there is a problem, assume it is a bug with your web site's accessibility and "fix it" for Jaws, thereby breaking it for all other screen readers. Jaws has flaws, just like any other software, especially with the HTML 5 changes being rolled out and implemented differently in different browsers. Accessibility tools are currently undergoing a lot of churn and change and will definitely have bugs that need to be addressed.
So, I will again stick with my assertion that ensuring you are following accessibility best practices is more cost efficient, more reliable and simpler.