Since several readers have found my first post to be Offtopic, let me try again:

A11Y is a standard abbreviation for "accessibility" in software.
Section 508 is a federal statute requiring software purchased/licensed by federal agencies to be accessible.
WCAG is a set of guidelines put out by the W3C for accessibility.

In prior years, Google has lost contracts because their software did not have sufficient work done to meet these requirements. In the past year, the revamp of Google Docs has been targeting WCAG/Section 508.

The lesson here is that modern software should be accessible. Google invested a lot of resources over the past few years to revamp their collaboration suite. The Docs/Drive interface which we all see is just one example. Take a look at the source code beneath. They've coded up ARIA, they've done appropriate testing for keyboard and focus management. Essentially, they followed WCAG2. Funny thing is that it took some embarrassing incidents years ago to get them on this path.

You want another example of how important making usability a focus of software is? Take a look at Apple -- their iPad's accessibility features are far better than those packed into Android tablets. Look at the mobile space: Blackberry thinks a11y is important but not important enough to make it a focus; Google thinks a11y is important but not enough to catch up with Apple. Guess who gets the perks there?

Microsoft certainly thinks a11y is important and as a result they've been the only choice for agencies for a long time. Anyway... that's the lesson.

Content licenses for music have been pretty silly over the years. A standard license for even displaying lyrics requires that the website take basic measures to disable copy and paste. That said, there are many online radio stations on the net operating without DRM. Jango and Pandora come to mind. Then there are stations like Grooveshark that do try to obfuscate their stream. The irony here is that Grooveshark is operating in the gray area whereas Jango and Pandora are appropriately licensed.

Anyway, we'll see where things go. Netflix is sending out a stream and stuck with Silverlight because of their agreements. Hulu is also sending out a stream, but just doing it over Flash. Netflix is closer to a standard model, using HTTP requests for their stream, but uses Silverlight because it has some media expiration features in the packaging format. It's all silly stuff, but once they use a model, it's a hard sale for them to back out of it. Breach of contract and all those kinds of words would be thrown around.

At this point, I'd say Netflix and Hulu are stuck. Lets see what Comcast does. At some point, an online service will pop up using HTML5. Youtube is doing it already with music videos and the like. So that's one win. No luck on movies yet.

The OmegaWiki project provides a multilingual database, is based on MediaWiki and was authored in large part by a Wikimedia staff-member. It's an interesting re-imagining of Wiktionary.

I certainly understand, as a software developer, that freedom does not come with open source. I'm still required to publish and inform every single user when GPL is included in the code base. And that's intentional. Same applies to BSD,

MIT and about everything but public domain, CC0 and the other do what you want licenses.

Now there are easy ways to serve them. You can add an about page, you can do what you must, but the protocol still applies. It's very difficult to create a visual surface on the internet that is truly free. Consider a public domain book.

Can you really publish an application to view and download that book without tripping on licenses? It's very expensive, it's very difficult. Unless you're looking for an ascii reader. And don't get me wrong, I love colorForth. But that doesn't quite reach the level.

There is a fundamental distinction between a computing surface, patents and copyright involved, an open surface, with copyright involved, and a free surface. That last part is expensive, it's difficult, and from a perspective of practice

and pragmatism, it's not something I would wish on anyone. I've spent the cash, it is expensive on an individual or group of individuals to develop a truly free surface. This doesn't even get into the complications [patents] involved in actually touching a surface.

I'd need a half million dollars to even start. And believe it, Intellectual Ventures, or one of many others would have an attack strategy. But at least there, I can deal with lawyers and patents. There's enough ammunition cataloged in the W3C and other patent databases to regain costs on attorney fees.

This semantic is worth saving. An open surface is not the same as open content, but it's the best that most can hope for at this time. I've put up enough money and time to have full confidence.

"I've used applicationCache, and using mobile safari + bookmark is quicker in [all versions of] iOS 4 (prior to 4.3). " iOS Home Screen bookmarks were working poorly prior to 4.3. It's not a new phenomenon. Early on in iPhone development, it was more of a priority. applicationCache was rushed in to support it. It just seems that things haven't improved in home screen bookmarks and offline apps since iOS 3, that they're not as much of a priority. The faster JS engine is a big help to web apps. Hopefully, Apple will look into improving start-up times in future releases.

Bookmarks created on the home screen load much slower than those cached by mobile safari -- I've used applicationCache, and using mobile safari + bookmark is quicker in iOS 4 (prior to 4.3). It's likely intended to keep mobile safari and "apps" separate, should one crash (out of memory), it would not impact the other. But it seems to be poorly thought out / poorly engineered. It is frustrating that users who add to home page get a worse experience than users who add to bookmarks. Mobile safari itself could use some improvements there. Perhaps its own version of the home screen, in addition to the traditional bookmarks list.

Deficits get us to the same place; though less efficient [higher transaction costs] and not distributed equally per capita, they're easier to tolerate, politically. Pragmatic Solution: more deficits.

Hixie has responded, to proposals by various groups to enhance accessibility for screen readers (and other Web Accessibility tools), by saying that text input with the canvas tag is a misuse of the HTML tag. "it may make more sense to stop people from wasting their time writing editors in canvas, which is not what canvas was for, and indeed makes little to no sense." Follow the thread on the w3 archives: lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/