Jennifer Sutton brought this interesting factoid to my attention today: the single most common HTML validation error is the missing alt attribute.

Of the 100 most common validation errors collected by W3C Love, a missing alt attribute comes it at number one — with almost double the occurrences of the next most common error.

It’s 2012, and the key mistakes in HTML seem to remain the same.

Now, one can’t help but hope — since these are the results of validation tests — that these numbers also reflect a large number of people who went “Oh! Whoops! Better get that information in there.” Of course, some of those people may have then gone on to write in “Spacer.gif. 600 bytes. White line.” as their alt attribute.

Obviously, this raw number of errors doesn’t demonstrate a lot of definitive information. However, the mere fact that this is literally the most common validation the error points to some serious problems in HTML education or in HTML generating tools.

I can understand people providing bad text alternatives. When you read over the guidelines for authoring alt attributes — either in the HTML 5 specs or Steve Faulkner’s slightly-more-easily-understood Techniques for useful text alternatives, it’s easy to get overwhelmed. The chains of instructions: this MUST be done, that MAY be done, this is REQUIRED, that is OPTIONAL…it can be a lot to digest.

But omitting the alt attribute entirely is kind of scary. Yes, it’s true that the HTML5 spec currently (and unfortunately) allows the alt attribute to be excluded in certain very limited situations — but the statement that alt attribute is optional in HTML 5 is far from accurate. It is definitely still required, and omitting the attribute is discouraged in no uncertain terms, as below:

Such cases are to be kept to an absolute minimum. If there is even the slightest possibility of the author having the ability to provide real alternative text, then it would not be acceptable to omit the alt attribute.

Even the most casual search of phrases like “alt attribute optional” brings up many, many results clearly indicating the importance of using the alt attribute without even a suggestion that the attribute is in fact optional, so it seems like somebody would have to work pretty hard to come away with the impression that it was optional.

Why is it left out so frequently?

We need better education. Ignorance is still the primary guiding factor in casual web development. When people are exercising barely-learned skills, they tend to go in the direction of the simplest possible set of instructions — leaving out any portion which doesn’t seem to have any impact. That means that images are included with a src attribute; possibly with width and height; and frequently with some kind of inline style or border instruction. Alt attribute? Why?

Any time you read up on an alt attribute, you’re likely to run smack into the TL;DR problem: explaining how to use alt attributes in any detail means a long, involved explanation. Even explaining the incredible difference between an empty alt attribute and an ommitted alt attribute is over the head of many layman content authors.

We need better decision making tools. It’s necessary to simplify. The experts need to work out the complex details of what, why, how, and when an alt attribute should be one thing or another. For the layman, it needs to be summed up as simply as possible.

Here’s my idea of a generalized alt attribute decision tree:

• Is this image a link or form control?
  • Yes: Alt attribute must communicate the destination of the link or action taken
  • No: Continue on!
• Does this image contain text?
  • Yes: Alt attribute should include the communicative text of the image (not text included for visual effect)
  • No: Continue on!
• Does the image contribute meaning to the current page or context?
  • Yes, and it’s a simple graphic or photograph: the alt attribute should briefly describe the image in a way that conveys that meaning.
  • Yes, and it’s a graph or complex piece of information: the information contained in the image must be included elsewhere on the page.
  • No: the alt attribute should be empty.
• Is the image something other than the above?
  • The alt attribute should be empty.

This very definitely does not cover all cases. But it’s much better than nothing; I hope that somebody is able to make use of it. If you have a quarrel with the wording or instructions, let me know in the comments!

It is incredibly hard to resist covering more and more issues here. But the purpose of this decision tree is to provide a simple and understandable tool to navigate the most common circumstances. This is not the place to explain the entire scope of alternative content.

Even though many elements of HTML 5 have only limited application at this time due to lacking browser support, there’s little reason not to make use of them. The design of the markup language is intended to minimize dependence on user agents, failing invisibly if the browser doesn’t offer that feature, which helps encourage early use of new elements.

Of course, the lack of support does have some consequences. We can’t just go out writing HTML 5 without having significant awareness of this lack of native support — we have to compensate.

Nonetheless, being able to incorporate great new elements like figure, progress, meter, nav to improve semantics or browser capabilities including content prefetching to provide a faster, more seamless experience for users is actually pretty exciting.

The coolest thing coming, in my opinion, is the numerous new attribute values for the input element. It seems like everybody’s always talking about the video element — but, not being somebody who’s all that excited by video, those conversations just make me say “Meh.”

But new input types…cold shivers.

Sadly, they’re also one of the less useful elements at the moment. Until support is available in browsers, they’ll simply fall back to a text field, unless supplemented by scripting to customize their behavior. But hey — easy upgrade, right?

From an accessibility perspective, this is fabulous news. Or rather, potentially fabulous news. These new input types — including date formats, time formats, numbers, ranges, and colors — are intended to provide user-friendly and accessibility-enabled interfaces for inputting these kinds of custom data. Ultimately, they’ll provide replacements (or fallbacks) to the innumerable JavaScripted widgets used to create date input or color selectors. Users, instead of encountering a different style of calendar every time they need to enter a date, could have a consistent user experience. Having the behavior built directly into the browser, and tied from there directly into any accessibility software in use offers a hugely more dependable experience for users of assistive technology.

Now, this all depends on several factors: vendor implementations need to meet user agent accessibility guidelines; interfaces between browsers need to be consistent; and, of course, the attribute values need to be implemented by enough browsers to make their use truly valuable!

Today, support is pretty limited. You can take a look at Roger Johansson’s HTML 5 input type test page and see whether your current browser supports any of them. If you’re using recent versions of Opera or Safari, the answer will be yes — otherwise, you won’t be seeing very much of interest for a while.

But you can implement these input types today.

All of these different input types fallback to a simple text input. If you’re using the HTML 5 doctype, there’s nothing stopping you from applying HTML 5 input types right now. Any browser that doesn’t support them will simply provide a field to enter plain text — so if you’re currently collecting email addresses in a text input (which seems pretty likely,) then you have no excuse not to change now. You may not see the benefits right away, but why wait? You’re not going to see any downsides, either.

Creating forms has long been a thorn in many a developer’s side. Dealing with how to best layout and collect date information, for example, is always a pain. Do you leave it as a simple text field, and have to deal with who-know-what kind of data received from the user? Do you use multiple select boxes, and force the user to walk through three or more fields just to enter the date? Do you use a JavaScript-based tool to provide a calendar, which may not have great accessibility, may behave strangely in some browsers, and may take a lot of development time to massage into providing the functionality you’re looking for?

Even when browser support for HTML 5 input types is fully available, it’s entirely possible that you’ll want to take the route to custom develop interfaces for various fields. However, unlike the past, you’ll only be needing to do this because something particularly unique is required for the project; for lower-budget projects, you can save a lot of labor and provide a solid interface just by using native features.

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!

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.