he Dashboard is a collection of HTML sidebar panels liberated from the browser window and placed anywhere on your screen. The “Web pages as widgets” concept is really just a logical extension of the Web sidebar panel metaphor fused with Exposé.
A logical way of solving these sidebar panel usability problems is to free those panels from the browser window and make them accessible anywhere on the screen (both invokable and dismissable with the touch of a key).
Hence, not only do we have Safari the browser, we shall shortly have Dashboard the browser-based widgets. For any of these widgets that deal with Web content, they will become user agents, as Safari already is.
I mentioned before that Apple is sitting on three separate evaluations of Safari against the User Agent Accessibility Guidelines. When the announced spoken interface – now called VoiceOver – finally emerges, Apple will have no choice but to release a Safari version that complies with UAAG.
But it will also have shipped various other Dashboard widgets that are also user agents, and will have seeded developers with the ability to create others. This is way more than Hyatt can handle.
IBM has several teams of accessibility developers. Microsoft has a large contingent. Sun has a few. You’ll find a few people working at Oracle, Adobe, and small firms here and there. But it is now time for Apple to hire an accessibility developer strictly for WebKit-based products, like Safari and Dashboard. (And the iTunes Music Store, which is not HTML and is not WebKit.) There’s too much work to do, and Apple needs to show it is genuinely serious.
No, I can’t and won’t do the work. But somebody’s got to.
The next step involves accessibility developers for hardware, system software, and application software. And if you think that’s too many bodies working on such a small topic, you must not be aware how large the topic actually is.