SDL Tridion and Alt Text. You're probably wrong, but still doing it right.

Alt text is fairly important to companies concerned about accessibility and Web standards. In the United States, companies that provide services for the federal government must comply with Section 508 laws, which are roughly equivalent to the W3C's Web Accessibility Content Guidelines 1.0's Priority 1 items.

The half-dozen customers I worked with last year were all interested in alt text, and most seemed to understand it. Only a few called it an "alt tag" (it's really an attribute).

Common Practice (it's "wrong")

However, I often see this setup and by itself, it's "wrong."

Adding an alt text to Multimedia components seems to be correct, right?

The correct place for alt text is in the context an image is used. So the SDL Tridion (or any CMS) "best practice" should be to set alternative text from the linking component or rich text format area.

Right Practice

Theoretically you can only know how an item is used in a given context, especially since images can be re-used. Good alt text describes the function an image serves or the content it provides. If it's purely decoration or doesn't add additional information, then alt="" is perfectly valid. So the right practice should be:

Actually the theoretical best practice is to add alt text in the context an image is used.

Remember: every image tag must have an alt attribute to be valid. It's value, however, can be empty when the image doesn't add information already in the context of the surrounding text. Learn more about alternative text best practices at WebAIM.

Practical Practice

But in practice, images aren't always re-used, so sometimes it's perfectly fine to set alt text in Multimedia Components' metadata. So you weren't so wrong after all. :-)

But if images aren't re-used, it's practical to put the alt text with the multimedia component. Update: except of course if you want to simplify your translation maintenance (thanks for the reminder, Mark!).

Good Practice

But what about the flexibility to choose? Or maybe the right to not choose. Shouldn't we have good defaults? A good CMS pattern is to provide authors the ability to override a value in a certain context, but by default have a backup. This gives us the following Good Practice(TM):

A good practice lets authors override a default fallback value (in the multimedia metadata) as needed.

1. Image Multimedia component has alt text in metadata
2. Author has the option to override (replace) this from a link component or in RTF
3. Component Template (CT) code checks the nearest "context" and uses the alt text in the linking component or RTF by default
4. If this is not set, then the CT uses the Image's metadata.

You can use the same approach for other sets of contextual information. The classic example is a page title, which you may get from a component on a page, but if it's empty resort to a component linked from page metadata, but if that's empty, recursively check structure groups up to the root structure group or publication metadata.

Ultimate Practice?

But maybe authors don't like empty fields that auto-magically get values or get filled in later, what then? You could possibly populate the alt text in your linking component with the alt text from the multimedia component, but that will just double the amount of work.

If you're looking for such an ultimate practice, I'd first confirm the business value and if it's worth it, consider simply displaying the alt text (it will show in Experience Manager since your template logic will add it, otherwise you're looking at code such as a GUI extension or Event System if you prefer to duplicate the value).

The most content author-friendly approach lets authors enter an override, but also see the fallback value in context.

Four Steps for Following SDL Tridion and Alt Text Best Practices

Confused? Let's simplify this.

With SDL Tridion, either always put the alt text in the linking component (not recommended) OR...

1. Empty is Easy. Set all decorative images that don't add additional content, bullet images, etc to an empty value (e.g. alt=""). If you have alt="picture of smiling family and their dog" or "red bullet" you're doing it wrong. If possible, add such images with CSS. Remove unneeded fields.
2. Functional Images. Set images used in links such as an image link to home to its function (e.g. "home" for the top-left logo instead of "company logo"). Same applies for navigational icons, image buttons, and maybe file type icons within a link (e.g. "pdf file"). Template the values if possible and remove unneeded fields.
3. Templated. For times your author just copies text or the alt text value matches a title, either use an empty alt text value or template the value. This might add redundant information, but it'll save you time and effort. Remove unneeded fields.
4. Universal Context. For infrequently used image or images that will always have the same alt text (might not be likely, anyone have an example?) then you might put a field on the multimedia component. Remove the fields in the linking components.

So all that's left really is in rich text format areas, where authors can add in-context alt text as needed. There, some four scenarios (one duplicate), four steps, and now you've saved authors a few thousand fields they won't need to fill out and increased your sites accessibility a little bit. Accessibility, standards, and good Web practices take time. Take the time to understand what alt text is really about.

If you're missing context, re-read the WebAIM article.

Update: Dominic Cronin posts a great follow-up describing the practicalities of these approaches and what he's seen with customers. He also points out, "it's about the requirements. Requirements, requirements, requirements!" Definitely, when has it not been?