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 (HyperText Markup Language) or XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) standards set by the World Wide Web Consortium (W3C (World Wide Web Consortium)). 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.
What do Standards Do?
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 (Cascading Style Sheets)), structural (XHTML) or behavioral (ECMAscript.)
In many (most) cases, web standards do not require best practices — they 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.
How Standards Support Accessibility
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 is irrelevant. Support should follow the standards; not the other way around.
In Conclusion
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 bNote 1, and the “WYSIWYG (what you see is what you get) exemption” on the font element strike me as decisions badly in need of reconsideration.
Notes
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 text
Ryan Benson
I would say no there isn’t good enough justification. Yeah spacer images are an exception, but what else. I thought spacers were more-or-less a thing of the past except for graphic-driven layouts. This is due to the heavy use of CSS (Cascading Style Sheets).
Joe Dolson
The
altattribute isn’t being left out; it’s simply not explicitly a required attribute in all circumstances. In strict HTML (HyperText Markup Language) 4 and XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) 1, thealtattribute must be present for all occurrences of theimgelement. As currently specified in the HTML5 guidelines, there are certain relatively obscure situations in which thealtattribute is NOT required.There is a good justification for it — the question is whether it’s a good enough justification.
Ryan Benson
That is sounds wrong. Does the team actually look at 4.0 docs, and various practices before starting it? I mean leaving out something like alt tags just seems wrong and somebody doesn’t know the area that well.
Joe Dolson
I’m not sure you can say that it’s inadvertent; I feel like the HTML (HyperText Markup Language) 5 spec is going out of its way to attempt to provide that kind of guidance. It’s inadvertent as far as I’m concerned, however — it’s not a specific issue that I’d thought about previously.
The eternal issue that incompetent or lazy developers will misuse the code is, as you say, unsolvable. The best we can do is to make it as clear as possible what the best practice is and why. Not everybody cares to know that many details, but those who do should be able to get it from the source.
The organization and structure of W3C (World Wide Web Consortium) documents is very intimidating. It’s quite apparent why people tend to get their answers elsewhere — the complex organization of the specification framework can be overwhelming.
Mike Cherim
Seems as if you guys have inadvertently defined a need as a product of your discussion: Any specification is going to have to have usage guidelines immediately following each so as to provide a clear understanding of implementation. And done so in a way that invites the typical developer. The W3C (World Wide Web Consortium) can be a scary place until you get used to it. Most don’t developers don’t go there for answers because of this. They get their answers on forums and blogs, where specs are often interpreted, but less-so translated.
Whether the
altattribute is allowed to be omitted from image elements and subsequently misused by careless, lazy, or ignorant developers, or whether it’s required and still misused by careless, lazy, or ignorant developers, is an unsolvable conundrum. Thus a specification must explain the proper way to meet it. And that explanation must take accessibility and usability into consideration — both are integral to the formation of those so-called best practices, after all. Any spec will have to explain how the developer needs to assess an image, which will define the proper action, e.g. decorative > noalt/nullalt. (I do lean towards keeping it as a requirement… a lesser of two evils sort of thing.)Regarding the
qelement, it is a good one — you can give it attributes so that fact alone can be very useful. But, as noted IE (Internet Explorer) has always been so problematic in assisting or motivating developers to adopt web standards or best practices. IE really needs to get with the program… more quickly than they are.Joe Dolson
It seems like a certain degree of “finding the middle ground” is always inevitable — but I agree, I certainly hope that the specification would be something for developers to strive towards rather than a specification which simply meets them where they are!
It’s hard to accommodate backwards-compatible specifications with forward-thinking development…
Gill
Interesting conversation and I can certainly see the problems inherent with setting up these specs. I suppose my main concern is that the teams ensure they don’t end up dumbing everything down to cater for the lowest common denominators, i.e. developers who refuse to consider, or don’t understand, accessibility and browser developers whose products don’t cut it.
Joe Dolson
I do appreciate that coming up with solutions are the hardest part. Thanks for taking the time to discuss this — I’ll certainly be thinking about it!
Ian Hickson
If you can come up with any ways to do this, please do e-mail the proposals to the mailing list. We tried to come up with other solutions, but so far they have all had worse problems than what the spec says.
Joe Dolson
I certainly see a value to treating these cases differently. Obviously, there’s a key difference between trying to learn whatever you can about an image and ignoring it altogether.
I agree that it’s valuable to provide a means to differentiate between them: I don’t see this as the best possible method. One reason is that I feel it has fairly serious legacy consequences — the user agent will suddenly be expected to do a lot of work to accommodate for the thousands of images with missing
altattributes in pre-existing web sites. (Of course, Doc Type switching will probably reduce the problem.)Part of my problem is with the whole idea of “exceptional” clauses in the spec: this is required, but not in x, y, and z specific circumstances. I’d rather see a way created which still makes use of the same attribute in a specific manner to accommodate for those cases, rather than accommodating through absence.
Ian Hickson
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.
Joe Dolson
And, in that case, why allow the
altattribute to be omitted? Why not require it to be empty? From a user perspective, it’s equivalent; providing an empty attribute is fundamentally the same as omitting the attribute. The difference is that the attribute is specified in some way (as a null), rather than simply omitted.In my view, the absence of the attribute indicates nothing; an empty value for the attribute indicates that the image has no
altvalue.I simply fail to see how it’s better to allow the attribute to be omitted rather than require it be left blank in the same situations described in the spec.
I don’t disagree at all with the philosophy describing what is and isn’t useful alternate text, by the way. It’s important that the specification provide some guidelines for how this important attribute should be used.
Ian Hickson
So, given that there are certain specific cases where the producer of the HTML (HyperText Markup Language) doesn’t have enough information to generate useful and harmless alternative text, what should the spec say?
We could say that those pages are automatically invalid, but how would that help? Conformance is useless if there is no way to be usefully conforming and there is evidence that people will do anything to shut up a validator, including putting in completely bogus and harmful alt text. So this would actually be harmful.
What else could we say?
At the end of the day, the important thing is to make HTML useful to authors and end users, including those who can’t (or won’t) view images.
Joe Dolson
Thanks for your comments, Ian. I’m going to have to disagree with you. As currently written, HTML5 strongly encourages the
altattribute, but does not require it. Or, more accurately, HTML5 requires thealtattribute in situations dependent on context and content. As such, you can’t really say that the attribute is “required.”From a testable-syntax perspective you cannot state whether a document is valid or invalid on the basis of either the presence or absence of the attribute.
The HTML5 specification may contain a “soft” requirement of the
altattribute, but it is not a firm requirement, since it cannot be tested.In my view (and I may be wrong) the HTML5 specification is a language and syntax specification. It does also define usage guidelines and semantic values, but is particularly designed to specify the nature of the mark up language. As such, I feel that only elements and attributes which are explicitly required or disallowed in the syntax should be viewed as a firm requirement of HTML5.
Dennis at Web Axe
Great article Joe. Excellent examples of code. I bet if IE (Internet Explorer) supported the , many more people would use it…
Ian Hickson
HTML5 as currently written does require the alt=”” attribute, it just makes an exception for the rare cases where the server simply doesn’t know what the image is, where including bogus alt text is actually more harmful than omitting it and letting the AT figure it out. (For example, Flickr has no idea what alt=”” to give to an image with no caption, no useful filename, no description, no comments, etc. There, it’s better to simply not have an alt attribute than to have a bogus alt attribute.)
I urge you to read the actual text of the spec. We’ve got lots of examples, and only at the very end, and in between strong recommendations to the contrary, do we list specific exceptions where alt=”” can be omitted.
BTW please feel free to send feedback to the working group. See this blog post for details on how to join and take part.
You can also send me feedback directly (ian@hixie.ch).