WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Alt text (was VIKI - text transcodeing)

for

From: John Foliot - Stanford Online Accessibility Program
Date: Jan 22, 2007 4:30PM

Jared Smith wrote:
>
> I think that adding additional information into such elements, even
> though it may not be violating the specs, certainly goes against the
> spirit of the guidelines.

Perhaps, but I also stand behind those two Priority 3 guidelines in terms of
attempting to ensure clarity of content. Sure, it's a bit of a stretch, but
it is also "in the spirit"...

> While an extreme example, if alt="[alt
> text]" is alright, why not make it alt="[[[[[***!!!!~~~~ ALT TEXT
> ~~~~!!!!***]]]]]]" to REALLY highlight and draw attention to this
> VERY important alt text? All of the characters are not read by screen
> readers, so it's OK, right?

LOL - Jared, of course not, certainly not like that - and neither is USING
ALL CAPS TO GET A POINT ACROSS. But don't confuse exaggeration with
striving for clarity - they may be at times similar, but they are not the
same.

>
> A similar conversation is occurring elsewhere regarding microformats
> use of <abbr> to store computer readable date/time. Yes, it's within
> spec, but it certainly does not seem to be a very true and friendly
> use of the element.

While I have not seen this thread, I do concur that using the ISO date
standard that microformats insists on is the only way to be truly machine
interoperable (it's a STANDARD!), however it's not that user-friendly to
print out. Whether or not the <abbr> element is correct or not... I
probably would stand with you, and suggest <span> instead. But this strays
somewhat...

> Also, there is no rule that makes the brackets (or any other
> characters) non-voicing. The one (or maybe two) major screenreaders
> just happen to not voice it. What about future screen readers? Less
> popular screen readers? Other text browsers? It just seems like such
> a hack to me.

Well, perhaps. I like to think of it as a "work-around", one that
intersects pragmatism with altruism, but yes, it is a hack. But for now, if
200-300 committed web accessibility-minded developers adopted it as a
best-practice, it might start to see some up-take, and gain a position where
the user-agent community might even consider implementing it into their
tools. Right now, I suspect that they don't even know or acknowledge that
there *is* an issue, let alone how to fix it.

>
> But I say, let's MAKE IT the user agent's problem. Don't you think it
> would be easier and more logical to get a couple of text-only browser
> developers to provide this distinction, rather than to get millions
> of web developers and dozens of design tools to provide this
> distinction within content?

Agreed 101%. However, given the relatively small user-base of both
text-only browsers, and users, this may be harder than it sounds. I suppose
a Firefox extension could be written for when users disable images, and
Opera's user-scripting capacities could perhaps also come into play. If it
gained traction then maybe Internet Explorer would also follow. But again,
first we as a community of accessibility committed developers need to show
that there is an issue, and that it can be fixed relatively easily.

> Gone should be the days when developers
> account for the user agents poor implementation of accessibility and
> specifications. Yes, we're currently far from this point, but if we
> want accessibility to become more widespread, we need it to be
> easier. And hacking our way around user agent weaknesses is not the
> way for this to happen.

Fundamentally, I agree with you. But meanwhile, the problem still exists,
and while we can hope 'for the day', we also need to live (and work) for
*today*. It's a chicken or egg problem...

Cheers!

JF