No, I totally agree that accessibility is possible if your app is JavaScript based. But if you're unaware of or you forget to add in accessibility features, you run the risk of failing much less gracefully for people who need those features than if there were more static content.
(This is, of course, a generalization; specific use cases may vary.)
I think this is a valid generalization. On a page that doesn't use JavaScript, some links, form fields, and/or buttons may be unlabeled, but a blind user at least knows they're there and might be able to look at some hints to their functionality, such as URLs or element IDs. Moreover, the controls and interactions are standard. What happens if the developer attaches some functionality to a device-dependent event, such as onclick, on an undistinguished element such as a div? The element might be styled such that a sighted user knows it's intended to be clicked, but a blind user doesn't get this same information unless the element has an appropriate WAI-ARIA role. And how many web application developers are going to pay attention to ARIA as they craft their unique JavaScript-powered user experiences? Maybe I'm just cynical, but I'm guessing that outside of companies that have a strong incentive to get accessibility right so they can sell to governments and schools, the answer is "not many".
Today's reasonably-built JavaScript-based applications are built using HTML as templates. They don't use a <div> as a button, they use a <button> as a button. They don't invent navigation using JavaScript, they use <a> tags and a JavaScript-based router.
Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION):
On the front page, every navigation, including the links on top and the links to individual forum posts, are <a> tags with an href.
When you navigate to a forum post, the buttons to reply, flag, favorite, etc. are all <button> elements.
You definitely want to be (1) using a framework that encourages the use of HTML for the view layer, and (2) using a framework that makes URL-based navigation easy. There's nothing about JavaScript-based applications that make semantic markup and URLs impossible, and today's screen readers don't care whether your HTML was rendered using JavaScript or from the server.
I think you're jaded because the previous generation of frameworks (SproutCore, Capuccino, Ext.js) shunned HTML in favor of all-JavaScript UI toolkits, but that framework style has fallen out of favor. HTML is here to stay.
You're right to point out that the current best practice is to use HTML as intended, including semantic markup for links and buttons. Still, some developers attach mouse and/or touch events to semantically undistinguished elements without providing appropriate markup. For instance, the TodoMVC examples do this (including the Ember.js one). I guess it's time for me to start submitting pull requests.
It looks like the Ember one has three {{action}}s:
1) <button {{action "removeTodo"}} class="destroy"> (a button)
2) <button id="clear-completed" {{action "clearCompleted"}} {{bind-attr class="buttonClass:hidden"}}> (a button)
3) <label {{action "editTodo" on="doubleClick"}}>{{title}}</label> - not a button, but a requirement of TodoMVC. It would be nice if TodoMVC had a <button> marked edit that achieved the same goal.
There is also a subclass of <input>, which:
1) Automatically focuses on insertion (native focuses are properly handled by screen readers)
2) Clears out the Todo if the text becomes empty and the user hits return (somewhat screen-reader friendly, and a requirement of TodoMVC)
Absolutely, but the context "afterthought" narrows the situation to a very specific case, that in which you have given no consideration at all about accessibility.
My belief is that if you were able to produce good markup, it would have been accessible from the very beginning, because accessible markup tends to be well-formed and semantically correct.
This would probably rule knowledge of WAI-ARIA out from everyone who fit parent's case.
http://words.steveklabnik.com/emberjs-and-accessibility