Sounds obvious doesn’t it, keeping content consistent, but the devil is in the detail. When it comes to writing alt text teams rarely pool their work, let alone have a considered approach to what is appropriate alternative text across websites and mobile.
Screen reader users rely on ALT text to understand content and functionality. On desktop this is well known but on mobile, be it a mobile version of a website or an application, its a different story. If alternatives are not forgotten they’re often badly written, verbose or repetitive which is a problem for voice output users on mobile and tablets such as iOS VoiceOver, Talks/Nokia and Blackberry/Orator and more. Given increasing numbers of screen reader users with mobile devices this can make for an extremely disappointing experience.
To put this into context an organisation’s website may be available as desktop and mobile websites built using Web Standards (HTML, CSS, WAI ARIA etc), W3C widgets (also using Web Standards) or applications for Android phones/tablets, iPhone and iPad – with Android and iOS built using different languages. This is of course a far from exhaustive list.
That’s potentially a lot of technologies to juggle all of which have a means to provide text alternatives for images and objects. It makes sense therefore to use a shared set of text alternatives.
Document images and names
As part of your content strategy document what images your sites uses including logo’s, icons, buttons, thumbnails, background and decorative images. Because we live in an ideal world I’m going to assume you have no images of text, layout or spacer images. Note what images are shared across websites, mobile devices and tablets.
Once done give each image a text alternative that is short and concise, describing what the image is or what it does. Make sure the text alternatives makes sense across your various devices and review your list to see if any images need further explanation in the form of a tooltip. It’s rare they do but sometimes necessary. It may also be that a tooltip is needed on iOS but not necessary on desktop.
The table below shows how three images might be classified:
| Image |
Name |
Type |
Tooltip |
Delivery |
Note |
 |
BBC 4 |
NA |
NA |
Web, Mobile, Android and iOS |
CSS background image with HTML text replacement |
 |
Play |
Button |
Double tap and hold to play (iPad only) |
Web, Mobile, Android and iOS |
Only needs a tooltip on iPad |
 |
Download [item name] |
Button |
NA |
Web, Mobile, Android and iOS |
Must dynamically update with item name |
In the table above you’ll notice that the BBC 4 logo is set as a background image and as such needs to be given an HTML text alternative. The download button also needs to include the name of the item it is downloading as there may be other items for download on the same page. This needs to be made a note of so each team working on each delivery context can implement this.
Someone needs to take ownership of this process working with content editors/developers/product managers from teams delivering apps on various devices. All too often it’s left to the developers having been disowned everywhere else.
Document image attributes according to different devices
Once you have documented text alternatives for images establish how alternatives can be assigned according to different delivery contexts. The table below lists a few delivery contexts and what attributes are used to give the image a name, describe what they are (button, link, image etc) or provide additional explanation in the form of a tooltip.
|
Name |
Type |
Tooltip |
| Web |
alt=”xx” |
Automatically assigned |
title=”xx” |
| iOS |
Label |
Trait |
Hint |
| Android |
android:contentDescription |
Event |
|
| Flash |
Name |
Automatically assigned |
Description |
When assigning names, types and tooltips there are a few things to keep in mind:
Name
All images must have a name. Names should be one to four words, succinct and to the point. They should start with a capital in order to ensure the correct inflection by a screen reader and should never end with a full stop (.).
Information about the ‘type’ of element (button, link, image etc) should never be included in the name. For example ‘Play’ should just be ‘Play’ not ‘Play button’ otherwise a screen reader will announce ‘Play button, button‘.
Type
Type defines what an element is. For example a button, link, text field and so on. In HTML this is already predefined in the surrounding code and communicated by the screen reader. In Flash the type is already hard coded into the object you are naming. In iOS however it needs to be assigned by the developer as a ‘trait’: button, link, search field, static text, image etc.
Tooltip
A ‘tooltip’ is a description and should be used sparingly and only when the name does not adequately describe the outcome/purpose of the image. As descriptions are an explanation and not a command be careful to word them as such. For example a delete button should read “Deletes this event” rather than “Delete event”. You’re not suggesting a user should delete the item you’re simply explaining that the button will delete it. They’re a handy way of including screen reader specific instructions.
In summary
- Document all images used across your sites and share this across different development teams
- Assign a name to all images
- Where required assign a ‘type’
- Assign a description only if the image needs further explanation
Resources
