WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Graphics and Captions

for

From: Kynn Bartlett
Date: Jan 20, 2006 8:00PM

On 1/20/06, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> Kynn Bartlett wrote:
> > There are no other "general purpose processing" functions defined.
> So they can be user agent, or even site specific.

Which is an awful, horrible can of worms which isn't even really worth
considering. I mean, embedding semantics into classes on a user-agent
or site-specific basis? Why?

> No, it will not mix presentational markup with semantic markup because
> class attributes are not presentational to begin with. Yes, as you noted
> the primary use of class names is to later use them as selectors to
> define presentation, but class names themselves are not presentational
> (unless of course you use misguided class names like "bold" or "red")

The primary, and only valid use, of class is for creating selectors
for applying styles. This has nothing to do with class naming
practices and everything to do with what it's used for.

Class is acceptable presentational markup. It's the glue that allows
us to "separate presentation from content" in a consistent manner.
But that glue shouldn't be used to impart extra meaning beyond
presentation; doing so in an attempt to compensate for HTML's
deficiencies doesn't help any.

> I would say that I can't see microformats directly benefitting
> accessibility (as in a user agent making direct use of them)...but, when
> combined with tools such as transformers which go through a page looking
> specifically for microformat information and reformatting it
> (server-side...or maybe even client side) to adapt to user preferences
> they can be a good thing from both a usability and accessibility point
> of view.

But, again, that's trying to encode semantic meaning into class, which
is a bad idea. This can be accomplished through other means in some
cases, and in those cases where it can't, it's a bad idea to try to
force the issue.

> And here we are now, working on examples for this "PLUS" that are viable
> *today*, with current technology...not once we have our jetpacks and
> enjoy XHTML2.0+

In both cases you're talking about extending beyond the standard. I
would rather extend in a manner that makes sense, rather than just
trying to patch together something that will have to be torn down
again in the future as harmful.

> I don't see it as a route into the far future...but it's a stopgap
> solution until extensible markup is consistently supported even in IE
> and there are no backwards compatibility worries anymore (IMHO, anyway).

That's not going to happen any time soon, but I don't think the
solution is just to start coming up with clever tweaks that mix
together presentational cues (class) with structured content.

> But again, class names (and id) are not inherently presentational. Their
> common application is to use them to apply presentation in a subsequent
> step. They can quite happily carry meaning, though that meaning may not
> be universally understood by all user agents (in which case no harm is
> done, as it's still within spec) but only by specific server- or
> client-side processing tools.

ID is, of course, a different thing, which is why I'm not talking
about ID. I'm not entirely sure why you're trying to mix ID into this
discussion, except perhaps to obfuscate the point.

Class names can't and shouldn't carry meaning, no more than meaning
should be conveyed only by the color of text: Doing so is harmful to
accessibility and harmful to the development of a rich markup
language. "After all," someone might say. "Why do we need to be able
to identify a caption, if you can just do class="caption" and be done
with it?"

If your client-side or server-side processing tools are so
unsophisticated that they have to rely upon using the class attribute
instead of using proper markup, in this XML-friendly world, then you
need to develop better client-side and server-side processing tools.

--Kynn