Archive: April, 2007

abbr datetimes in microformats?

James Craig and Bruce Lawson have raised an issue on the Web Standards Project blog today that I’ve been meaning to blog about for a while: accessibility issues raised by the use of abbr elements in the Datetime Design Pattern to provide machine-readable representations of dates in microformats.

In their blog entry, hAccessibility, James and Bruce explain my thoughts on it very well – it saves me writing it all up! It’s well worth a read if you’re into microformats.

To summarise my thoughts…

Basically, I think the expansion of an abbreviation should be human-readable. Inspired by an e-mail from Jim O’Donnell, testing microformatted date and time with screen readers back in October demonstrated that an ISO date format is hardly nice to hear being read out by a screen reader.

Having said that, it’s worth bearing in mind that, if a screen reader user cannot understand what is being said, they may well go through the text character-by-character in order to understand it. If someone does this with an ISO formatted date, it may still not sound great, but might then be easier to understand.

More recently, after discussing this quite a bit with Jon Tan, I settled (at least, for now) on using span for microformat datetimes instead of abbr, which obviously means my microformatted dates may not get parsed correctly. I think it’s a far better solution than using abbr, at least until something better is decided upon.

Jon and I have discussed a couple of alternatives:

  1. Prepending the title attribute of an abbr element with some human-readable text to give context to users, e.g. “ISO date format: YYYY-MM-DDTHH:MM:SS+ZZ:ZZ”
  2. Although this may be a corruption of Web standards in itself, using the lang attribute to declare the date format being used, either following it by the formatted date or putting the formatted date in the title attribute.

Anyway, check out the discussion on the hAccessibility entry. I’m interested in seeing where it leads and to what solution.


29 April 2007

Following comments on hAccessibility, it was proposed that the datetime design pattern for microformats be extended to allow the use of the title attribute on a series of permitted elements, e.g. span, em, etc.

There are problems here:

  1. Losing the abbr means that the “semantic tie” between the marked up text and formatted datetime is lost. We are no longer providing context to the datetime information.
  2. The title attribute may be validly used to provide additional information to an element. As such, wherever a title attribute is already in use on an element, that element cannot be used to also provide a formatted datetime. We don’t want the datetime to get in the way of any valid use of the title attribute. It could also make parsing unnecessarily complicated. The span element is meant to be semantically neutral, so the title attribute on a span is unlikely to carry something functional to users since there is no “semantic tie.”

This is just a cursory observation, but it seems we’re trying to use the title attribute to contain what is essentially metadata meant for machines. Other microformats design patterns have used the rel attribute for meta information. The problem is that rel always contains the context for a (usually human-readable) value specified elsewhere, e.g. the name of a person marked up with XFN is given context by the value of the rel.

What we need is a mechanism by which we can specify a “meta value” – a value that is not appropriate within the context of normal page flow – as you might with meta elements in the head. XHTML 2 adds support for this kind of thing, but what can we do now? Unfortunately, there’s no other attribute more appropriate for this use than the title attribute. The datetime attribute is only permitted on ins and del. If only we could do something like <span class="dtstart" rel="datetime:YYYYMMDDTHHMMSS+HHMM">!

The discussion continues on the microformats discuss mailing list.

30 April 2007

I knew I’d read about this before! Accessify Forum: Use of <abbr> in microformats

Removing alt tooltips in IE with JavaScript

There was a bit of debate on Anne van Kesteren’s blog last year about alt attributes being rendered as tooltips by some Windows browsers, most notably, Internet Explorer.

Following the W3C specifications, there’s no reason for alt attributes to appear as tooltips. However, there’s nothing to say that ‘alt tooltip’ behaviour is wrong. Certainly, alternative text should appear if an image does not render on the page.

Working on a recent project, the client asked why the descriptive alternative text for an image appeared when they moused over the header image that spanned the top of each page of content. They wanted the alternative text to either not appear or be set to text optimised with keywords.

Update: When first writing this article I was under the impression that screen readers would announce all images followed by their alternative text. Consequently, I’d put alternative text in for all images in markup because I’d personally prefer to be told, “Hey, this image is of an old oak tree with twisted branches” than “There’s an image here, but we don’t want to tell you what it’s in it”! I’ve since found out that JAWS will not even announce the presence of an image that has an empty alt attribute. If that behaviour can be relied upon in all screen readers, the most appropriate solution to our problem may have been to leave the alt blank. I think the JavaScript solution I provide below is still useful should you wish to get Internet Explorer to present correct tooltip behaviour.

What could we do?

The alt text was fit for purpose and we refused to bend the rules for the sake of a bit more SEO. So, we wanted to keep the alternative text but override the tooltip behaviour in Internet Explorer.

Setting an empty alt would have removed the tooltip, but at the expense of accessibility. That’s the obvious option out the window.

Before I go any farther, I thought I’d better point out that alt attributes are a good thing and are required for all images in markup. If you are reading this thinking otherwise, I highly recommend that you read up on appropriate use of alt attributes.

Another option was to add the image as a background with CSS, as it could have been considered a decorative image. Being so close to project finish, we didn’t want to have to go through the site making all the images backgrounds. We also wanted these images to stretch with increases in text size. Next option down.

Internet Explorer will correctly display the contents of a title attribute as a tooltip when one is set on an element. Rather conveniently, an empty title attribute overrides Internet Explorer’s ‘alt tooltip’ behaviour but does not show a tooltip. However, we can’t be sure this will happen in all browsers and I don’t like to muddy my markup.

We opted for an unobtrusive JavaScript solution. This keeps the solution in the behaviour layer and allows us to sniff out Internet Explorer.

Enter the JavaScript

I came up with two JavaScript solutions:

  1. Using mouse events for the image: when onMouseOver is triggered, swap out the existing alt text and set the alt to an empty string, then reinstate the original alt text when onMouseOut is triggered.
  2. Override the tooltip that appears as a result of the alt text by ensuring a title attribute is set on the image — an empty title attribute doesn’t display a tooltip in Internet Explorer, but does override the ‘alt tooltip’ behaviour for us.

The latter was preferential as it didn’t seem to have any immediately obvious accessibility issues.

A bit of a disclaimer: I don’t recommend overriding any behaviour unless you really have a need to do so. I used this solution in a selective manner. If you intend to use JavaScript to override behaviour in any significant way, consider providing client-side options so that users can set a preference.

So, without further ado, here’s the code I used. Feel free to use it, share it, suggest improvements or provide your insight on tooltips displaying alt text.

var objFixIeTooltip = {
	// methods
	init : function() {
		// detect support
		if (!document.getElementById || !document.getElementsByTagName) return;
		// detect IE - leave out if using conditional comments
		var isIE = navigator.userAgent.indexOf("MSIE");
		if (isIE < 1) return;
		// find the image(s) - tweak to your needs
		var elContainer=document.getElementById("header");
		if (!elContainer) return;
		var elImg=elContainer.getElementsByTagName("img")[0];
		if (!elImg) return;
		// if there isn't already a title attribute set on the image, set the title attribute to blank, thus overriding the alt tooltip behaviour
		// use == '' because IE always thinks title is a string (cannot distinguish between undefined and empty attributes)
		if (elImg.getAttribute('title') == '') elImg.setAttribute('title','');

Of course, to avoid using browser detection within the script, you could leave it out and include the script using conditional comments:

<!--[if IE]><script type="text/javascript" src="path/fixIEtooltip.js"></script><![endif]-->

References and reading

On alt tooltips:

On alt attributes and alternative text:

You can find more on alt attributes and alternative text in my bookmarks.

And just for fun – I love this: Wheee!

vCard Tools in Mozilla Thunderbird

I’ve just discovered the MoreColsForAddressBook extension for Thunderbird.

It’s not obvious from its name, but it provides import/export tools and additional entries for contacts in your Mozilla address book, which includes really useful operations that support vCard! This makes a great companion for those of us who use the vCard format to share our contact details with the world.

The extension doesn’t appear to be listed in Mozilla’s add-on repository, so I thought it was worth giving this an airing here. Read more about this extension on its page: MoreColsForAddressBook

I have no style

Having only recently refreshed my CSS files, I’ve now ripped them out. Why? It’s CSS Naked Day!

CSS Naked Day is an annual event with the aim of promoting Web Standards through demonstrating the power of separating content from presentational information. So, marvel at my semantic, well-structured markup.

In the interests of internationalisation and all that, has stripped off twelve hours early – 48 hours of nakedness for the benefit of those for whom it is tomorrow already.

Suddenly the site is looking a lot better in Internet Explorer!

Good blog URL structure

Welcome to version 2.1! I’ve been playing with the site over the last couple of weeks. I’ve done some thinking about the structure of the site and I’ve tried to make better use of space on the home page, adding the last few comments posted. The CSS is a bit busted in Internet Explorer at the moment, but I’m sure you’ll learn to forgive me! For the moment, I want to concentrate on writing instead of playing with CSS!

Right then, URL structures

In the process of tweaking the design and structure of over the past couple of weekends, I’ve modded textpattern to use what I believe to be the most usable and future-proof URL structure. We now have year, followed by month, followed by hyphenated entry title: /2007/apr/good-blog-url-structure

I’ve also ensured that textpattern will redirect (permanent 301) links formatted in my previous URL structure to the new locations. For those interested in how I did this, I’ll do a little write-up soon.

Having discussed information architecture with Jon T over recent months and then reading a few posts about good URL structure recently, I got thinking and began tweaking, so I thought I’d post up my thought process behind the changes.

Take time to think

In the interests of link rot, it’s advantageous to think about your URLs before you have too many of them. With a blog, you can quite easily rack up a bunch of posts and decide you want to restructure things, often leading to a furore into htaccess and a bunch of redirects. That is, unless you like to break people’s bookmarks or screw up your results in search engines.

Blogging systems commonly refer to the location of an entry as its permanent link, so it follows that we should avoid changing that link in the future. I have fallen short of that ideal on this blog a couple of times now as I’ve shifted content around. I guess it’s inevitable that we move things about as our websites evolve or as we learn.

If you’re just starting up a blog, or if you’re rehashing your website, my advice is to take a little time to think about the structure of your URLs. Think about the information that will identify the content of the entries you’ll be writing and is most helpful to readers without being verbose. Doing this early on will save you time in the future. Even if you think you may make changes down the line, you should be in a better position to do so having already thought this through.

Unique identifiers

My appreciation for good information architecture has grown over time, especially since my involvement with Grow. Now, I try to think of blog entry URLs as unique identifiers – permalinks, remember – which we should avoid changing in the future. I try to think about what information actually identifies the content of the entry and what does not.

Entry titles

A prime place for summarising the content of your entries is in their title. I try to think of these as one-liner headlines, as you tend to find in the sidebars of the BBC News website.

I try to take a little time to think about my entry titles before I publish, making sure it sums up the content and avoiding the need to make changes later on.

Entry IDs

The database ID of an entry isn’t terribly useful information to anything other than your content management system. It’s certainly unique to the entry, but I think it looks messy and is not valuable to readers.

Date entry published

The date that you publish an entry ages its content. Including that information in your URL structure means visitors can quickly see how old your entry is. As a reader, I find this useful. Also remember that the content of your entry may not necessitate archiving – old content may still be valid, especially if it has updates attached.

Site sections

The site section an entry belongs in is not unique to an entry and is more likely to change than you might think. For example, I started off just posting under a “blog” section, but I decided to expand, which entailed moving some of my entries out of the blog section. Now I see site sections as a means of navigating to and accessing entries.

I also notice when people post their entries to an archive section as soon as it’s published – does this mean the content is not up to date?

Entry tags

The tags an entry is given can tell you a lot about the content of that entry, but again, they are not unique to an entry. However, I think of such information as peripheral – meta data, I suppose – and as with site sections, a means to categorise and browse entries. Remember that many tags may be applied to any one item – especially so in a community environment like Flickr – making them unfeasible for URLs.

Deciding what to use

So, I like the idea of making the most of entry titles, ensuring that they describe the content. You could just use the title alone to identify an entry in the URL. There are two problems with this for me.

Firstly, all your post titles must be different, which I admit is not necessarily a problem. It may become a problem if you post a regular update, say once a month, with the same entry title.

Secondly, if you decide to change the title in the future, having a single reference doesn’t give your readers a contingency plan. You may well publish more than one entry in any one day or month, but offering a secondary reference in your URLs adds a level of redundancy. This allows your blogging system to look up possible entries when an incorrect or out-of-date URL is accessed.

I think knowing when an entry was published is useful information for readers. Adding the date to your URLs in some form is going to help identify entries and keep your URLs unique.

I decided to go with posting my entries under months and to use the three-letter, textual abbreviations. As mentioned in the comments to Chris Shiflett’s post on URL Vanity, using a numeric month can make URLs easier to skim-read. I’ve noted before that I think months are more useful as text than as numbers:

The argument is that, say, through using the name of a month in place of its numerical representation, a date becomes dependent on the language you are using. By that logic, numerical dates are better for internationalisation. Unfortunately, the simple difference between the typical English and American date formats throws a spanner in the works. Something to think about; surely, if your content is dependent on language, there should be no problem with your dates being dependent on language too, even in your URLs?

So, I’ve decided to try out using months as text rather than numbers. One advantage of making textpattern redirect sensibly is that I can change my URLs back to using numeric months without incurring a headache, so feel free to convince me I’m wrong about that!

Related reading