How Browsers Interact With Screen Readers and Where ARIA Fits in the Mix

I think this article can answer a lot of questions for the casually-interested developer:

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 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.)

Found this in the editors’ draft specs: when you should bother listing the default, or any other, ARIA role:

Form was surprising, the rest seem to make good sense. You can see here the default or “native” roles many elements have.

There were constraints on the lengths of posts originally. Now Bryan has finished the article and goes more in-depth:

Hey poes,

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’ve been doing quite a bit of JavaScript lately and I was like, “Wow, I didn’t even think of this”.

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.