WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Alt Text


From: John Foliot
Date: Feb 25, 2010 3:12PM

Jared Smith wrote:
> I know we've gone the rounds on this a few times in the past. I don't
> think that either of these approaches to alternative text is
> "inaccessible" - we just may differ a bit on details.

We're in agreement here.

> I will say, however, that I think this pattern is primarily
> recommended to account for piss-poor handling by browsers and
> assistive technology. If a screen reader or browser is too incapable
> of identifying or rendering alternative text distinctly, should it be
> the developer's burden to 'hack' the alt text to make it so?

This is likely to get uber-theroretical here.

For me, the base-line goal is to aid in comprehension - a cognitive issue
on the grandest scale that in some ways affects all users, not just users
of AT. I believe that anything an author can do to assist in ensuring a
better understanding of author intent is a Good Thing(tm).

We are actually talking about 2 things here; the use of [square brackets],
and the practice of pre-pending the 'type' of image to the alt text

I will concede that using the [square brackets] feels like a bit of a hack
- perhaps it is - but consider as well that punctuation (any form of
punctuation, including the use of my parenthesis here) serves a cognitive
function. The 'overhead' of adding two extra characters - [] - is
negligible at a technical/file-size level, but *might* aid some sighted
users in their understanding of text and content flow, and the impact on
some forms of AT can be as little as zero (screen readers set to low
verbosity levels will ignore the square brackets). So, near zero pain -
possible gain. It's a pattern, plain and simple; however for patterns to
truly be effective, they must be used consistently.

Signaling what kind of visual element you are using to non-sighted users,
or users of text only user-agents, is also a cognitive mechanism, who's
value (IMHO) outweighs any downside of using *that* pattern. Consider:

Alt="John Foliot"
Alt="Photo: John Foliot"
Alt="Avatar: John Foliot"

(Removing the square brackets to keep the 2 concepts separate for this

The subtlety here is minor, yet measurable; if we were to then query a
group of non-sighted users which of the three examples is not a real
likeness of me, those users could only determine accurately that one is,
one isn't, and the third is "I'm not sure". Is this worth having/knowing?
I believe yes, so again near zero pain - real potential for gain. Once
again, this is a pattern, and patterns work best when they are consistent.

Jared asks: "... should it be the developer's burden..."? Only the
developer/content author can know for sure what the intent of using any
graphical element is; for everyone else we can only hope to understand
that intent as fully as we can. I don't see this as a burden, but more the
challenge and responsibility of the author, just as it's the
responsibility to ensure that the writing is clear, that spell checking
has happened, and that interactions with any given web-page is "technology
agnostic" as much as humanly possible. The ongoing question of "what makes
good alternative text" cannot be answered simply, in part *because* the
intent of any image is the real value for your alt text - yes, we can
formulate some guidelines and examples, but like the proverbial answer to
"what is pornography?" the answer more often than not to "what makes for a
good alt text" has the same answer - we can't say for sure exactly, but we
will recognize it when we see it. To me, what makes "good" alt text is
clarity, brevity and accuracy of intent; 3 things I believe this pattern
fosters with some consistency.

> I think
> this approach turns "alternative text" into "alternative text plus
> some other stuff to make it read/display better".

...Whereas I see this as maximizing alt text to get the biggest bang for
my buck. Knowing that the image is a cartoon versus a photograph is, I
think, an important distinction, and this pattern achieves that with one
word. (Can't get a lower overhead than that)

> Wouldn't our efforts
> be better spent in encouraging browsers and AT to handle alternative
> text better, and in promoting guidelines for rendering of alt in HTML5
> and the User Agent Accessibility Guidelines?

See my comment above re: pornography and what is, what isn't. I would also
add that while the alt attribute is certainly a huge aid to users of some
types of AT, I also chafe at the thought that alt text is exclusively
there for screen reading technology, so any guideline must also be
user-agent agnostic as well.

> While I can accept the pattern as acceptable, I won't use it and can't
> recommend it. If the nature of an image (it's a photo or a chart,
> etc.) is important and is actually CONTENT, then it can and should be
> included in the alternative text. But I think using this approach for
> EVERY image will result in a lot of overhead and extraneous
> information that would be much better handled by the user agent.

Jared, I would never advocate this as being a "MUST", but I think that
your concern over 'overhead' is perhaps disproportionate to the reality
that AT users are accustomed to dealing with, and I circle back to the
need for consistency in patterns to ensure maximum effect. It would be an
interesting question to pose directly to screen reader users however:
perhaps when you are working on V3 of your survey (if in fact there will
be a V3), that a neutral enough question querying users on this might be
of value?

Meanwhile, what do *you*, gentle reader, think?



> Jared Smith
> WebAIM.org