Back in the old days (maybe in Web 0.9) Analog, the popular web analysis program, automatically added a ‘Valid HTML’ button at the bottom of each report page it produced. This was before the W3 Consortium took up the banner of validation, so the button was provided by a third-party site (webtechs.com). Either through a ‘clerical error’ or an invoice not paid the domain name being used to supply the image lapsed - and it was then taken over by someone else who decided to add in a completely inappropriate picture with the same filename.

If we move forward to the present day, then in Web 2.0 the idea of bringing in content from other sources is the distinct flavour of the month. In some cases this is still just images (for badges), but the norm is either to have RSS feeds (essentially bringing in HTML code, usually with no filtering …

As I was coming to terms with the harsh reality of being awake at the end of last week, I caught an appeal on behalf of the Disasters Emergency Committee (DEC) on the radio. It set me to thinking again (with the aid of coffee) how they could benefit from building a badge/widget response network.

The typical patterns for badges/widgets are either to provide ongoing functionality (e.g. Flickr badges or Google Adsense) or to offer something time-limited for a specific campaign. For someone like the DEC where the timescales are compressed the second option isn’t really worth pursuing. They do have a Rapid Response Network for more traditional media outlets, e.g the main television and radio networks, the national newspapers, etc.

I think they could benefit enormously from providing a badge/widget that is available all the time. If there’s an appeal happening then content connected with that is delivered, otherwise …

One feature of Web 2.0 sites is the opportunity for others to piggy-back on the functionality or content in order to build new services that the original owners hadn’t contemplated or didn’t want to pursue. So for example someone interested in running a music website (err, for instance me) can sign up to the Amazon Web Services which will allow them to perform searches on the Amazon product database and display the results on their own website, etc. The theory is that Amazon increases it’s visibility to those interested in buying, whilst the music website doesn’t need to worry about building a huge database and can get commission payments without being involved in the messy e-commerce business. You might also have come across talk about mashups (I’ll be posting about some new mashup tools in the near future), these use similar technologies.

Much of the focus has been about …

Yahoo’s User Interface Blog has an excellent video showing their Program Manager for Accessibility using a screen reader.

It’s probably aimed more for web developers who need to think about how the overall page is structured, but provides an insight into how someone who can’t see that page finds the content they’re looking for. As you’ll find the text in page titles and links, and the proper use of headings and lists are crucial.

There’s also a link through to a presentation on the history of screen readers which is also worth considering. As with web browsers we can’t assume that our audience has access to the latest, shiniest versions - especially when it comes to assistive technologies such as screen readers since they can also be an expensive investment.