Most developers tend to overuse Ajax for the sake of the large amount of features and enhancements that can be added to a web application through this widespread technology. However, this abuse poses some major accessibility problems that I'd like to outline here by taking the jQuery library as an example of Ajax-enabled framework.
The problem of updated content
With jQuery is really easy to update the content of a given HTML element to reflect a change in the Ajax response. For example, we can use the load() method to insert some HTML code on a target element. The problem with this approach is that the overwhelming majority of screen readers won't be able to properly read the new updated content. A screen reader usually comes with an internal feature called virtual memory, that is, a buffer-based portion of its memory where it can load the entire content of a document and store it for later use.
Unfortunately, all screen readers have this option disabled by default, so if a user doesn't activate it, the entire document won't be kept in memory. From an Ajax perspective, this means that when you update an element with an Ajax response, the screen reader won't even notice it and it will continue to read the normal content. A simple solution in this case would be the WAI-ARIA roles. The problem with this solution is that is still under development and it will take some time to get a massive adoption by browsers and screen readers.
Further, a screen reader could even get confused and start reading the whole document again. Imagine what might happen if your page contains a lot of content.
The problem of links
Link targets should not be empty. Most developers use links with an empty href attribute and this is a bad practice. If a user-agent doesn't support Ajax, an empty link make it reload the entire document. Further, also dynamic links should be avoided. For dynamic links I mean those links created via JavaScript. Remember that screen readers can handle properly only certain DOM events, such as load. If your links are generated through a call-to-action that is fired with an event that screen readers don't support well (or don't support at all), then your links won't be generated.
You can use anchors (hashes) to make your links point to an effective portion of your page. This will avoid the problem of empty links and offer some kind of reference for browsers or agents that don't support Ajax.
The problem of widgets
Progress bars, spinners and the like are all nice Ajax widgets. However, since they're all made for a presentational purpose, they should not be inserted in the markup. Further, they should not convey any semantic information that could be possibly relevant for the correct use of a document. In other words, you should not rely on them, because it's always a good practice to provide alternate ways of informing a user.
The problems of events
Screen readers don't support DOM events very well. There's no universal rule to use with screen readers, because there are many differences among them. The only thing that we know for sure is that they support the load event. For other events, there's no rule of thumb for dealing with them, so you're warned.