Wish it also mentioned some other programs like Dragon.
Keep in mind that ARIA is meant as (hopefully) a stop-gap measure. HTML elements are getting (have) their own native roles which would naturally be exposed to the browser anyway. Some elements have more than one role, and there are rules (still developing) determining when roles conflict, who wins.
Example: the new <nav> tag has a native role of "navigation". The ARIA role="navigation" is meant to be placed where the author wants to expose a meaning of "this is the primary navigation area" to the browser. Ideally, instead of ARIA roles, we would be able to use the HTML tag <nav> and this role would be there anyway. Though I like the idea of being able to manually place the ARIA role where it's needed rather than adding what in my view is an "extra" tag around my navigation lists.
The article ends with only a taste of the possibilities regarding interactive elements like buttons, and the potential issues with doing something like
I just finished reading this article "Making an Accessible Dialog Box" and it fits in nicely with the ARIA theme of this thread, so I wanted to share it.
I don't know how well dialog role is supported in screen readers. Aria-labelledby/describedby are pretty well (among those who support ARIA), though be careful if you end up actually having a form somewhere: the ARIA role will override any label you have for an input (none of Nicholas' examples had a form that I saw, but just be aware). But this is exactly the place where ARIA steps up and does what HTML simply does not have the built-in semantics to do, making hand-made widgets workable for more people. Yay.