From @ljwatson:

1. ARIA is complex. To understand ARIA it is necessary to understand accessibility mechanics (the relationship between code, browserer and accessibility API). This is something that many accessibility professionals do not understand, let alone the thousands of working developers actually building things for the web. This means ARIA is often misunderstood and misused.
2. ARIA is unexpected. When something like role="button" is used to explicitly define a role for a <span>, developers expect the transition to be complete. In other words they expect the <span> to functionally be a button in every respect, not just that it is now identified as a button in the accessibility tree. This means they do not provide the necessary behaviour and/or interaction needed to make the thing act like a button.
3. ARIA is only for screen readers plus an inconsequential amount of speech recognition tools. With buy-in from the implementors it could be much more powerful, but whilst it is constrained only to tools that use the accessibility APIs (and then only a subset of those), it exists in a silo. For example, the aria-kbdshortcuts attribute will be used to indicate to screen readers when a keyboard shortcut is available. It will not provide a functioning shortcut, nor (unless browsers decide to implement it otherwise) a visible label to indicate to sighted people that a shortcut is supposed to exist.
4. ARIA is often presented as a solution for everything. This seems like a contradiction of the previous point, but sometimes ARIA isn’t the solution at all. It is often better to look for existing solutions within the host languages (HTML, SVG etc.) or to create them there. This is essentially an architectural problem with ARIA and the way it is expanding/developing.

We will take this up at our F2F meeting in London with Léonie joining us to introduce the topic.