It sounds like you are using a screen reader who has a Forms Mode. In forms mode, buttons and form controls are read out, but non-form text may be skipped.
The problem I am trying to resolve is that when the div shows on screen the screenreader doesn't read the new content, it only reads the okay button (to hide the div). I think if the cursor moved to that div, the screenreader would read the text.
I have to be very very honest here, and you may not like this: your markup is very, very poor. What this means is, YOU are doing a LOT of work that you don't need to do.
I'm not sure if you have a doctype, or if your <html> I saw was you just stating "here's the HTML". This forum uses BBcode, so you can wrap whatever is code inside code tags like
some code here
So first, be certain to have a complete doctype, so browsers the screen reader is using don't go into Quirks or Not-Standard mode. Most browsers have a non-standard mode for missing or incomplete doctypes.
Second: when you have a form, use form tags, label tags, input tags.. and you generally don't need much more than that. Screen readers are generally pretty good with forms. If you want an example of how I would do your markup (based on markup alone since I don't know visually what it's supposed to look like), I can give you one.
Your reader is clearly finding the new content, so this is good.
If the text is relating specifically to the radio button, you can investigate [ARIA roles. Specifically, I'm thinking of the [url=http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby]aria-describedby attribute, which would go on the radio button or its label and would point the reader to the div text (who must have an id matching the aria-describedby attribute) and the most recent versions of the big-name readers would see that text as associated with the form control and could read it out. ([url=http://www.marcozehe.de/2008/03/23/easy-aria-tip-2-aria-labelledby-and-aria-describedby/]Marco's example in English of using the attribute](http://www.w3.org/WAI/aria/faq), though the actual markup used is not great.)
There is also a set of ARIA attributes for alerting users of new page content, with "politeness" settings (how urgent is it that the user go directly to the new content? Or can they finish whatever they're busy doing first?).
Are these radio buttons choosing and answer and then the popup is telling students that the answer is correct or not and why?
Does everyone know they are supposed to hit ENTER when they are on the correct radio button?
NVDA would probably read out your div, but I believe JAWS wouldn't unless you first existed Forms Mode first to read the plain text (but I'm not sure unless I were testing the page).
Anyway I'm thinking right now you have a reader that's reading the text rather blindly (not a bad pun but I mean, with no knowledge of the relationship of the content to each other) and may be switching to a Forms Mode whenever it sees a radio button and only switching back out when the cursor completely leaves the radio.
Also it looks like the JS is adding a table? A whole table for a line or two of text is overdoing it majorly. Plus NVDA bothers telling me every time I hit a row or column, which is not useful information. General rule of thumb: if it's got one cell, you don't need a table. Think table == excel sheet. If the data doesn't look normal in an Excel sheet, you want other tags.
I don't have a lot of user experience with actual popup dialogues, except that the ones created with window.open() work fine IF I don't have a browser that blocks popups, because it's built by the browser, but the modus-window stuff I know less about. Lightboxes use modus-window and they can be accessible but I haven't used a lightbox with text in them besides "close" : )