WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Alt text (was VIKI - text transcodeing)

for

From: Jared Smith
Date: Jan 22, 2007 4:10PM

On 1/22/07, John Foliot - Stanford Online Accessibility Program wrote:
> In what way Jared? As non-voicing "punctuation", how does the inclusion of
> square brackets go against the spec.? (Serious question - not trying to be
> facetious or difficult)

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. 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?

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.

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.

> I don't disagree, but currently text-only browsers *do not* make the
> distinction, and even if they did, how should they/would they?

Brackets - just as you've prescribed would work nicely.

> I agree with
> Jared that this should *not* be our problem, but currently it is - text-only
> browsers do not distinguish between alt text and standard in-line text

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? 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.

<slightly off-topic rant>
Perhaps what we really need is a strong open-source accessibility
movement where the community and standards drives screen reader and
other assistive technology innovation, rather than hoping and waiting
for the existing industry to be responsive. This could certainly drive
down cost and increase innovation. Look at what Firefox has done to
the browser market - imagine if those efforts had been solely on
assistive technology.
</slightly off-topic rant>

Jared