Access Matters

Coming out of retirement briefly, I write to support Glenda Watson Hyatt who yesterday lamented that WordPress still doesn’t get the very first accessibility requirement right. Bluntly, at release 2.8.4, WordPress still does not do ALT text correctly. Bloggers inserting images into their WordPress blogs are not being well served. Good craftsmen everywhere are taught to blame themselves for poor work rather than their tools. In this case, we can blame the tool. It needs sharpening.

Maybe I can cast Glenda a helping hand, not that she needs any help, by approaching the problem from a different point of view, from that of standards compliance, but tempered with explanations that are more easily understood than the W3C specs. In a comment to Glenda’s post, I suggested reading the specs. Yet, people using the WordPress tools are not always developers and shouldn’t have to know or understand those specs.

My intention here is to describe those specs in plain English, and to make suggestions for how WordPress can improve.

The discussion involves two “elements,” IMG and CAPTION, and two “attributes,” ALT and TITLE. Think of “elements” as containers, or envelopes. They are uniform carriers for what is inside them. Think of “attributes” as things inside the containers which offer additional precision.

IMG element

The IMG element is, of course, the container for images. Inside we find a pointer to the image and a number of allowable attributes. For the sake of completeness, the attributes are: src, id, name, alt, lang, title, style, onclick (and 9 other on… attributes), ismap, usmap, longdesc, align, width, height, border, hspace, and vspace. Only two of these are pertinent to our WordPress discussion, alt and title.

alt attribute

The alt attribute is intended for providing an alternate description of an image. The intent satisfies two cases. For browsers that do not or can not display images, the alt text describes the thing that is not seen. The other case is to give blind people a description of what they cannot see. The alt attribute is currently a REQUIRED attribute. It MUST be specified. Beyond the basic HTML specifications, the World Wide Web Consortium’s (W3C) Web Content Accessibility Guide also makes alt attributes for images REQUIRED.

Yes, there are exceptions, but before we get to those, here is what happens to the alt attribute. In browsers that are unable to display images, or have images display turned off, the alt text is used inside brackets or parenthesis to describe the missing image, for example (picture of dog rescuing swimmer). People who are blind use assistive software called screen readers. As the name implies, this software determines what is on the screen and “reads” it through voice synthesis to the blind person.

You can easily find long discussions about what images deserve alt text, which ones don’t, and what constitutes good alt text. Briefly, the only images that do not need alt text are those that are used for positioning, the ever present “spacer” gifs, and those that are purely decorative. Even the picture of the dog rescuing the swimmer might be considered decorative by some. Yet, even with these non-essential images the alt attribute must be coded and should be coded as alt=”". That is, two immediately adjacent quotes with no intervening spaces.

All other images need the alt attribute to describe the image. For the images such as drawings, illustrations, photos and charts, the most succinct brief description is appropriate. For images of buttons or other objects representing actions, the description of the action is appropriate, for example “submit button.” There are many ways to do alt text either very well or very poorly, but I don’t intend to go into those here. See references at the bottom of the article for good suggestions.

Oh, some readers may be aware that the next version of HTML, version 5, might not require the alt attribute. That is really not yet settled and the current draft of HTML 5 offers a variety of conditions. Those interested can read the draft.

title attribute

The title attribute is intended to provide additional information about the image. Title attributes are optional and can be applied to a great many elements other than image and are more generic in their nature. In our simple case of the dog rescuing the swimmer, the title text might be “Spot saving Dan.”

Many of today’s browsers display the title text when one hovers over an element that has a title attribute. A point of historical reference is useful here. The hover capability came from an implementation mistake that Microsoft made with Internet Explorer many releases ago. In that browser, Microsoft displayed the alt attribute as hover text. That was corrected later, making title the source of the hover text. It’s little wonder that people are confused by these.

The point is that title should be used for additional or advisory information, not as a substitute for alt text. As an example of advisory, think of a form full of fields. Some of those fields might have a title of “required information” to encourage correct completion.

Titles are not substitutes for the alt attributes and should not be used as such. Nor should we use the same value for both alt and title. That introduces redundancy that is very annoying for a blind person listening to a screen reader. In fact, because of so many developers who chose to irrationally duplicate alt and title text, many screen readers now have title announcement turned off by default. The redundancy became so annoying that blind people said they would rather do without the title information, even when it might be useful.

CAPTION element

Caption? Why are we talking about caption? The reason I ask is because the CAPTION element is an independent element that is intended to be used with TABLES. In fact, the specification is very precise about this, saying “When present, the CAPTION element’s text should describe the nature of the table. The CAPTION element is only permitted immediately after the TABLE start tag. A TABLE element may only contain one CAPTION element.” From this we know with certainty that the CAPTION element is optional, is associated with tables, and most be coded in a certain sequence for tables.

It is not an attribute for the IMG element and nowhere in the W3C specifications are captions ever associated with images.

On the other hand, some people do like to add caption-like information to pictures. In some cases, it might be a photo credit. In other, it might be yet more information about the image. However, that wasn’t what the HTML designers were thinking when they wrote the spec. Is it fortunate of not that most browsers are forgiving enough to not care about a caption outside of the correct place inside a table specification? The forgiving nature of browsers led developers to use the element for purposes other than those the designers intended.

Where WordPress gets it wrong

Following is the dialog for adding images to WordPress blog entries.

Let us count the problems:

1. There is no way to specify ALT text. Actually, there is, but it is well hidden.
2. The Title field is marked as required when in fact the attribute is optional.
3. To make it easy for people to do the wrong thing most of the time, the Title field is pre-filled with the image’s file name. More often than not, file names are not useful as either title or alt text.
4. There is a Caption field which is valid only for tables, not for images.
5. UNSEEN - If no caption is specified, the Title value is duplicated into the ALT text. I’m guessing the developers though most people would recognize what “title” means, but not what “alt” means, and blindly duplicating is easier than explaining.
6. UNSEEN - If the caption is specified, the caption’s value is duplicated into the ALT text. This is even farther form the spec than using the title text.
7. There’s no help for what any of the fields mean.

For the person in a hurry, who cares little about the details, we end up with what Glenda calls “Worse than Useless.” We have identical alt and title text, both specifying the image’s, usually cryptic, file name.

Ah, but there’s more….

In a very obscure effort to do things right, there’s an Advanced Settings dialog that includes a real, honest to goodness, field for alt text. If you really, really, really know what you are doing and really, really, really want to do it right, you can add an image, and then go to the Advanced Settings dialog to make the alt text correct.

However, getting to it is difficult. First, you have to complete the “Add an Image” dialog by pressing the “Insert into Post” button. Then, you have to find the image in the post and click on it. The, click on the button to “Edit Image.” After that, find and select the “Advanced Settings” tab.

Let’s recap. WordPress has an underlying understanding that alt text is required for images. However, they adopted the very poor practice of thinking title text more important and auto filling alt text from the title text. Then, a couple of releases ago, someone came along and injected the caption element into the mix, both misusing it and abusing it to auto fill alt text. To those of us acquainted with the standards, these combinations, especially the use of optional attributes to auto fill required attributes, are bizarre.

Lastly, there’s yet one more accessibility related standard that has been ignored. The Authoring Tool Accessibility Guidelines talk specifically about how the tools used to build web pages need to be accessible themselves, but also need to generate standards compliant code. WordPress fails here by not doing the right things with the “Add an Image” dialog, and by hiding the right things somewhere people are unlikely to discover.

Suggestions

The fix is simple. Do it right. Include a field for alt text. Make it the required field. Let title be an optional field. For complete standards compliance, get rid of the caption field. Yet, I can understand why some would want to keep it. Maybe the Advanced Settings dialog could be eliminated to make things easier? Lastly, and perhaps as important as all the other changes, provide good help information that informs the typical blogger about why alt text is required and what constitutes good alt text.

For further reading:

• WebAim has an excellent guide: Appropriate Use of Alternative Text
• As does Simon Willison at the Guild of Accessible Web Designers
• and Trenton Moss, writing for WebCrecible
• Current HTML 4.01 Specification
• Web Content Accessibility Guidelines
• Authoring Tool Accessibility Guidelines
• Draft for HTML 5
• Jez Lemon’s excellent article, Requiring the alt attribute in HTML5

This entry was posted on Tuesday, September 29th, 2009 at 4:04 pm and is filed under articles. You can follow responses to this entry through the RSS 2.0 feed. You can leave a response or trackback from your site.