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.

Following up on tables and CSS, the grid model of layout execution is part of the CSS level 3 working draft. The specifications for the grid layout module being discussed were released on September 5, 2007.

This module describes integration of grid-based layout (similar to the grids traditionally used in books and newspapers) with CSS sizing and positioning. Document Abstract

Semantically, the grid layout system is a nice development — it is a system explicitly and exclusively designed for layout, which has no required HTML component. An excellent companion to the div element.

Read more: CSS3: On Grid Positioning and Layout

Recently, it seems like I’m writing a lot about web standards from an unusual perspective (for me). Rather than evangelizing techniques such as CSS and Web Standards, I’m trying to give every argument a fair discussion. I want to evangelize thinking. This is the result of a notable shift in thought: I’ve been moving in a slightly different direction in my way of approaching web development principles. I believe it’s a more sophisticated way of thinking, but I could be wrong….

On that subject, Jeff Croft came out with an interesting opinion piece today on differentiating between “standards” and “web standards”. It’s interesting, and definitely worth reading. There’s one particular comment in it, however, which particularly got me thinking:

[...] I’ll say this emphatically: I don’t care about standards. Not at all. Not even a little bit.

Read more: Care about standards? No, not exactly…

In my last post, Accessibility and Client Expectations, a major point was on the practice of implementing accessibility as a site “add-on,” rather than developing a web site from the ground up with accessibility in mind. Some of the features which are implemented in this manner fall into a gross category I’m inclined to describe as “pseudo-accessibility.”

In general, pseudo-accessible features are those which:

• Solve the symptom, not the problem.
• Create additional accessibility problems in their implementation
• Reinvent the wheel by duplicating browser functionality

Read more: Pseudo-Accessibility: Reinventing the Wheel

Last night, I participated in a group discussion on the current working draft of WCAG 2.0 with Jared Smith of WebAIM and the hosts of the WebAxe podcast, Dennis Lembree and Ross Johnson. Mike Cherim was also supposed to be involved, but technological difficulties prevented it, unfortunately.

The new podcast from WebAxe is now posted, so give it a listen to hear what we think about the latest changes to WCAG 2.0.

In May of 2006, after the release of WCAG 2 for public comments, Joe Clark published an article in A List Apart in which he damned the new guidelines to hell. At the same time, he announced the formation of an independent group to review WCAG 1 and author a set of errata (and extensions) to that document. The WCAG Samurai have now released their errata document for public review.

They have also invited reviews from a couple of prominent authors and developers in the web accessibility community, Alastair Campbell and Gian Sampson-Wild. Neither of these reviewers are members of the WCAG Samurai, and have each provided exemplary and honest reviews of the document.

Read more: WCAG Samurai: Draft Errata Released