The dialog and alertdialog roles turn off all virtual navigation features in some screen readers. This can be confusing and can actually prevent some people from using the page. These roles are very nice because they cause the screen reader to read the contents of elements referenced via aria-labelledby and aria-describedby attributes when a focusable item inside the container gains focus. The downside is that all virtual navigation is turned off, so all the user can do is tab from control to control; text between cannot be read. Jaws does not turn navigation off, but NVDA and VoiceOver do (other screen readers unknown). The spec says that it should be turned off.
Read more about this issue and a partial solution here.
The solution described in the above-referenced document does not cause dialog title and dialog message (i.e. elements referenced via aria-labelledby and aria-describedby on the overlay container) to be read automatically, but it does keep the browser keyboard focus and screen reader's virtual focus within the container.
My first try at a solution used live region markup on overlay title and message and code to rewrite the live region when the overlay was opened, but this proved flakey with respect to timing and worked inconsistently across screen readers. See the live region method here.
This code instead retains the role="alertdialog" on the overlay, and wraps all contents within a div with role="document" which turns on virtual navigation. We now get the best of both worlds: the alertdialog role performs its magic when an object within the overlay container gains focus, and the inner wrapper with role of document turns on the virtual navigation removed by the alertdialog role on the parent. We also keep keyboard focus within the dialog, and return focus to the triggering button when dialog closes.