I shall begin thusly:
HTML5 and related technologies provide tools with which to enhance accessibility through well-structured, sementically-defined content.
And I will asert this:
Lately, there have been a lot of blog posts, links on hacker news, links on reddit, and elsewhere where someone's showing off their latest application or framework. Javacript application frameworks have never been more popular- like my personal favorite, backbone.
With these tools, it's easy and simple to build single-page applications. One looks at Twitter, or Facebook, or Grooveshark, and admires the clean presentation and seamless(ish) transitions between application areas. So, developers go forth with the intent to replicate this kind of experience. We import a framework like Backbone, and start coding away. Maybe you use something Rails and TDD our way through a nice group of controllers serving JSON right to our client-side models. We use Jasmine, and TDD our way through the client-side, and use all the "best practices" that we've been tought, and we deliver a great product on time.
Googlebot has an API for ajax calls, but you have to conform to their specifications. Search engines work by scraping your site's content; and if you don't have an html representation of you data, it can't scrape anything.
You're going to be alienating a lot of users who use screen readers. Some can watch for new content, but not all.
I can't guess or give you recommendations on how many people you might be ignoring. But I can try to make a case and tell you that there's a right way to build web applications where you won't run into these problems.
- Build your server-side:
- With a RESTful interface. This will let you route HTML request, ajax / JSON requests, and anything else through a common API that you can use internally and have the option to externalize. You're building for the future - you can build any client that can produce a RESTful call, which is pretty much anything. You'll use the same routes whether requesting JSON or HTML, which means you have to change nothing to switch between calls.
- With logicless templating. I can go on forever about how great Mustache is. Fill these views with a flattened-down version of your model (also known as a viewmodel in some circles.) This will allow you to use the same logic and output whether outputting HTML, JSON, XML, or anything. If it's a JSON request, JSONify the viewmodel. If it's HTML, fill a mustache (or erb, or whatever) template with this viewmodel and send that. One line of code difference between request type is the goal.
- Layer on your css. This probably sounds like Progressive Enhancement, because it is.
- Now, add your framework on top. If you're using a framework that supports Mustache templates, you can use the same code on your client that you are on your server - which means no duplication. Same html, same css, same everything.
You're probably doing most of this already anyway. The major thing to take away is that now you're building your templates first instead of implementing your client framework first. With a very small change, if you're already writing well-structured markup (which you can easily check while you're building your css-less templates), you've built yourself a single-page app that's also accessible. You've built an application that can handle any request type, that provides an API, that is easily scalable (thanks to RESTfulness, you can easily replicate it across webservers as quick as you can clone them), and that re-uses as much code as possible, and is therefore easily maintainable.
So my plea: Build in html everything you can. Don't develop Flash in HTML5.
The only thing I can think of that could probably get away from it is a completely interactive experience such as an online game. But even then, giving your players forums, stores, chat rooms, etc. to discuss the game in is just as important to the health and growth of your game as the game itself is. Having these tools available can make a world of difference.