It is easy to get the idea that ARIA fixes everything for accessibility, but the reality is that ARIA serves a very specific purpose, for a very specific audience.
ARIA is only supported in browsers and screen readers. Actually, a tiny amount of ARIA is also supported in recent versions of Dragon, but not enough to make it a credible solution for speech recognition users.
Browser support for ARIA depends on the accessibility Application Programming Interface (API) being used. Fortunately, there is good support for ARIA in all accessibility APIs. The Core Accessibility API Mappings (AAM) specification describes how each ARIA role and state should be implemented in the accessibility APIs.
Of all the available Assistive Technologies (AT), only screen readers (Jaws, Narrator, NVDA, TalkBack, and VoiceOver) properly support ARIA. So to all intents and purposes, ARIA is a screen reader only solution. There is more information about the relationship between the accessibility API, browser, and AT, in What does accessibility supported mean?
Documentation of screen reader support for ARIA is scarce. There is an effort to document Jaws support for ARIA (and other web standards), and PowerMapper publishes an ARIA screen reader compatibility table, but there is little else. This gap in our collective knowledge is a bigger problem than you might think.
ARIA is not tested for screen reader support before the ARIA specification is published. The W3C requires that every feature in a specification, in this case every role, state and property, has at least two working implementations. The purpose of this requirement is to make sure that features are viable for use in the wild.
The catch is that ARIA is tested for support in accessibility APIs, but not in screen readers. In other words, it is possible for a feature to be included in the ARIA specification because it has accessibility API support, but for it to have little or no practical support in screen readers. The
term roles are two such examples.
So test your ARIA implementation with screen readers before you deploy your code. Remember, the experience doesn’t have to be identical in every screen reader, but it does have to be usable in most.