Alternative Text for Significant Images

In the comments from my most recent article, “Supporting Standards that Support Accessibility,” a number of interesting thoughts were raised concerning the requirement (or lack thereof) of the alt attribute in HTML 5.

It’s a difficult issue.

I’ve seen numerous articles around the web which discuss the fact that HTML 5 does not require the alt attribute. To some degree, this is true: HTML 5 provides exclusions to the requirement. In situations where an image is significant but no alternative text can be provided, HTML 5 recommends that the alt attribute be left off as an indicator that the image is significant (not a purely decorational image).

It’s actually quite a bit more complicated than that — - the specification describes detailed guidelines for when the alt attribute should be left off, when it should be given a value, and when it should be provided without a value.

My complaint, and the complaint of many others involved in the web standards world is against the concept of providing any reason that the alt attribute may be left off. Ian Hickson states:

Empty alt text means the image is unimportant (decorative) and should be ignored. Missing alt text means that the image is important, critical even, but that there is no fallback text provided. The user agent is expected to treat the two cases differently.

At least, that’s what the HTML5 spec says at the moment.

I believe that it is important to provide a way to distinguish the two cases above; putting both of them into the empty alt=”” category would be, IMHO, bad for the accessibility of the aforementioned pages.

He’s right, of course — - it is quite important to distinguish between insignificant images such as decorational graphics and between significant but undescribed or undescribable images. The challenge, then, is to come up with a solution to the problem which allows the alt attribute to remain.

So…what are some possible alternatives?

The first thing that comes to mind is to add a signifier attribute. Something which indicates whether an image is significant or non-significant. This would require some revision to HTML generating tools, but certainly no greater a change than that expected for new elements. It would be best to assume a default value when the element is not provided which assumes the image is significant, for backwards compatibility.

A second possibility would be to introduce a key term available to the alt attribute which would indicate significance. This strikes me as a bad idea, since it would have relatively poor backwards compatibility, and would require selecting a term which would become unavailable as normal alt text. Nah, that’s not really going to work.

Third…I’m struggling to come up with another idea…

I’m very open to any thoughts on the subject. Problems with these ideas are welcome, as are suggestions of any off-the-wall idea you may have!

Supporting Standards that Support Accessibility

The justification that a web site is accessible because it “follows standards” contains a serious fallacy. Specifically, the assumption that standards support accessibility.

One root of current standard accessibility practice is conformance to the HTML or XHTML standards set by the World Wide Web Consortium (W3C). This is a fine practice, and certainly should be maintained. Using correct syntax and following a standardized method of communicating information is always a solid best practice. However, this should absolutely not be taken to mean that following these standards is the same as applying the principles of web accessibility.

Web standards only provide accessibility to the degree that they have been designed to do so — - and the guiding principle behind standards development (excluding accessibility-specific standards, of course) has not generally been to support accessibility. Web standards have been designed purely to establish a set, correct method of using the underlying code — - whether presentational (CSS), structural (XHTML) or behavioral (ECMAscript.)

In many (most) cases, web standards do not in any way require best practices — - they merely require conformance. Take HTML, for example. Web standards would permit the usage of table elements for layout, because they do not define semantic usage for the table element. Web standards also permit a variety of presentational elements, such as font, strike, or u. It all depends on what standard you have chosen to follow.

HTML5, most recently, is considering such contrarian steps as removing the requirement that alt attributes be required for images. This ensures the existence of a valid HTML5 web site which can radically fail basic accessibility guidelines. On the other hand, it may reduce the likelihood that some so-called “accessible” web sites will be littered with alt="this is a spacer graphic".

Does this necessarily mean that the standard is wrong or right? No, not as such. Different standards support different needs — - it is important to keep distinct the purpose of the standard. Conforming HTML is just that: Conforming HTML. It means nothing more.

Nonetheless, as an accessibility advocate, I feel that it’s important to support accessibility issues within the development of new standards. Taking the alt attribute issue in HTML5, for example, the lack of any perceived benefit to not requiring the attribute suggests to me that the better path would be to continue to require it. There are numerous examples of important accessibility aspects in HTML5 which are not yet included.

There seems to be a strong element of specious judgement: elements which are not supported by current user-agents are considered not to be needed. This seems a ridiculous expectation: after all, if unsupported elements aren’t needed, than why develop a new specification at all? What we’ve got must work just fine!

Practically speaking, user-agent support and developer use should both be only marginal issues when trying to decide what elements are most needed in a specification. The fact that elements are unused on either end are not a judgement on the value of that element; merely a judgement on the awareness of the element, on the clarity of the existing specification, or on the complexity of the implementation.

Nobody (or almost nobody) uses the q inline element. Does this mean that the element isn’t valuable, and should be discarded? No. It means that Internet Explorer should add appropriate support for it. The same is true for accessibility issues. The standards should support them to their best abilities: if an element or attribute could hypothetically add to the accessibility of a site, then the fact that it is little used or poorly supported should be entirely irrelevant. Support should follow the standards; not the other way around.

At the root of things, my stance is that I am unwilling to support a standard which specifically excludes features which are needed in order appropriately provide best-practice accessibility. HTML5 is still a long way from being done; and even further from being implemented (if it ever is,) but the removal of such attributes as the header from table markup, the inclusion of defined non-semantic elements such as b1, and the “WYSIWYG exemption” on the font element strike me as decisions badly in need of reconsideration.

1. In point of fact, I can accept the inclusion of one inline non-semantic element (span) and one block level non-semantic element (div). I feel there’s ample justification to allow elements which are not specifically defined on the grounds that not all situations can possibly be covered by the specifications of the language. I see no justification, however, for the inclusion of additional explicitly non-semantic elements.

Return to Top