Comments on: Supporting Standards that Support Accessibility

By: Ryan Benson

Ryan Benson — Tue, 22 Jan 2008 10:33:17 +0000

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.

By: Joe Dolson

Joe Dolson — Sat, 19 Jan 2008 00:33:19 +0000

The alt attribute isn’t being left out; it’s simply not explicitly a required attribute in all circumstances. In strict HTML 4 and XHTML 1, the alt attribute must be present for all occurrences of the img element. As currently specified in the HTML5 guidelines, there are certain relatively obscure situations in which the alt attribute is NOT required.

There is a good justification for it — - the question is whether it’s a good enough justification.

By: Ryan Benson

Ryan Benson — Sat, 19 Jan 2008 00:21:15 +0000

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.

By: Joe Dolson

Joe Dolson — Wed, 02 Jan 2008 16:08:02 +0000

I’m not sure you can say that it’s inadvertent; I feel like the HTML 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 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.

By: Mike Cherim

Mike Cherim — Wed, 02 Jan 2008 05:51:37 +0000

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 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 alt attribute 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 > no alt/null alt. (I do lean towards keeping it as a requirement… a lesser of two evils sort of thing.)

Regarding the q element, it is a good one — - you can give it attributes so that fact alone can be very useful. But, as noted IE 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.

By: Joe Dolson

Joe Dolson — Sat, 29 Dec 2007 22:56:26 +0000

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…

By: Gill

Gill — Sat, 29 Dec 2007 12:11:01 +0000

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.

By: Joe Dolson

Joe Dolson — Fri, 28 Dec 2007 22:49:19 +0000

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!

By: Ian Hickson

Ian Hickson — Fri, 28 Dec 2007 22:44:59 +0000

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.

By: Joe Dolson

Joe Dolson — Fri, 28 Dec 2007 15:11:47 +0000

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.

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 alt attributes 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.