In my blog entry entitled “Practice What You Offer” back on 1st December 2005, I posted about one of the advertisers within a monthly SiteMorse report who:
…delivers some of the best performing and most accessible websites; you’ll find our specialist expertise invaluable in helping you improve the quality of your online service delivery…
Yet had an appalling 1996-era frameset-based website themselves.
Well, I’ve had a few Google search queries for “Amatica website” find me since then and curiosity sent me to take another look and discover that they have redesigned their website. I noted this in the comments section of the original post but after chatting with a colleague at work where we discussed the merits of calling out bad websites we both agreed that it would be a positive move to congratulate good redesigns also. For me, this largely happens over at Accessites where we are looking for highly accessible websites that are also visually stunning but having a little “applause” category wouldn’t go amiss here especially if someone I’ve blogged negatively about comes good.
A new look Amatica was launched on 21 December 2005, from their news release:
David Roberts, Amatica’s director for marketing said “Our customer’s projects always take priority over our own internal projects. We’ve been concerned about the old website’s increasing lack of W3C compatibility and decided that it was time to sort it out. People expect us to practise what we preach!â€.
Yes, indeed we do 
This is a good start but I hope that the dev team can further refine and build on what they have. Quick “raising the bar” issues I see include:
- An XHTML 1.0 Transitional DOCTYPE instead of a Strict HTML or XHTML for a new build?
- A
metatag before thetitletag? - Cascading Style Sheet filters (hacks) for Internet Explorer in the same stylesheet — putting these into an IE-only stylesheet delivered via a conditional comment would allow the main style sheet to validate.
- Bordering on “divitis” perhaps.
- No hover or active states on hyperlinks.
- Footer links using • instead of a semantic, inline unordered list.
- Lastly, and by no means least — lose the accesskeys.
Keep up the good work.
The specs only say there has to be a TITLE element, not that it should be the first child of HEAD. More, if you declare the character encoding inside your document with META HTTP-EQUIV ( for those saving the document on disk or when you haven’t access to the server configuration ), you should do this “as soon as possible in the document”, meaning right after opening HEAD, so the user agent knows how to read the title (cant’t find the URL right now, but it’s somewhere on W3C I18N…). Thus, putting stuff before TITLE is officially kosher.
I find myself delving more into the specs this year to find all these little nuggets of truth to overcome any assumptions I may have.. Many Thanks for clarifying that Dejan
Loose the access keys? Haven’t you heard of Dan Champion’s excellent work on providing non-conflicting access keys based on similar solutions worked out by Rich Pedley and Gez Lemon?
Yes that reminds me I should post about that Grant.
Dan put a lot of effort into that script and it all started over at Accessites where it has been implemented. It also received valuable input, testing and discussion from fellow GAWD members on the discussion list and currently I think this is the best solution to implementing accesskeys in a safe and reliable manner.