I think this article can answer a lot of questions for the casually-interested developer:
https://www.ssbbartgroup.com/blog/2013/01/02/how-browsers-interact-with-screen-readers-and-where-aria-fits-in-the-mix/
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 role=“checkbox”></i>
(this example above comes from a talk by Derek Featherstone, where he described this as code found on Amazon.com to make a pretty-styled checkbox in a form. The role did not make it a checkbox. It’s still just an i tag and means and does nothing (there was a Javascript onclick even or a :checked test that did something). Meaning it can’t be triggered with the same input means as a real checkbox can be.)