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 3:30PM

Jared Smith wrote:
> On 1/22/07, Alastair Campbell < <EMAIL REMOVED> > wrote:
>> With regards to the square brackets, surely this is something that
>> should be left up to the user agent?
>
> I'm really struggling with the idea of the square brackets also. This
> is certainly a user agent issue, not the developer's problem. And it
> certainly seems to go against the specs.

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'm not saying that this is a perfect solution, but I believe it addresses a
situation that exists today and does minimal to zero harm to other users
(i.e. screen reader users). In fact, if you are prepared to give it just a
little latitude, there are 2 Priority 3 checkpoints in WCAG which might
suggest that this is in fact 'a good thing':

13.8 Place distinguishing information at the beginning of headings,
paragraphs, lists, etc. (does an image fit within "etc."? Does wrapping alt
text within square brackets "distinguish" it from standard inline text?)

14.2 Supplement text with graphic or auditory presentations where they
will facilitate comprehension of the page.
(does placing alt text within square brackets "facilitate comprehension" of
a page in text-only browers?)

> Alt text is an alternative,
> not an alternative with additional markers to make it sound or look
> better in user agents that don't know how to provide a
> differentiation between text and alt text.

I don't disagree, but currently text-only browsers *do not* make the
distinction, and even if they did, how should they/would they? Can't use
color alone (this surely breaks the spec), and the equiv of <em> or <strong>
is semantically incorrect. I originally commented on this as the new VIKI
tool was doing the same thing (using square brackets) for alt text as part
of it's re-formatting.

I have proposed a possible solution - it is by no means definitive, or even
"correct", but rather it is a suggestion. I have been quietly using it for
about 8 months now, to zero feedback negative or positive. 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,
which can lead to confusion and "poor rendering" on screen.


> Surely images with alt text should be identified as
> an image with either the word "image" or a beep or a different
> voice... or something. It certainly should not be the developers
> burden to identify images or to fix reading issues in user agents.

Perhaps others on the list could chime in with other ideas? In the absence
of text-only browsers rendering alternative text "differently" from standard
page text, is there a best practice? Is there a recommendation that
user-groups could advocate to developers of such tools? Is it something
that we as content developers should even worry about?

Cheers!

JF