W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: using an attribute to categorize the @alt state [was Baby Steps or Backwards Steps?]

From: Jon Barnett <jonbarnett@gmail.com>
Date: Thu, 16 Aug 2007 16:50:39 -0500
Message-ID: <bde87dd20708161450x63ca0e2cqc411f12c3fc6d1f9@mail.gmail.com>
To: "Robert Burns" <rob@robburns.com>
Cc: public-html@w3.org

On 8/16/07, Robert Burns <rob@robburns.com> wrote:
>
> This is example example where  Ian hasn't even taken his own advice.  He has
> rightly suggested that we all focus on problems statements and use-cases.
> The changes he's made to the draft certainly reflect an important
> problem-statement /use-case.  However, the solution fails to benefit from
> the WG process.

I don't understand what you mean by this or what you're implying.

In case you haven't seen it, this is Hixie's message tot he WHATWG list:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-August/012378.html
It's just a response to various messages to the WHATWG list, but it
shows some of the reasons for the latest changes.

As a result, we now have a draft that is a much better starting point
for discussion than before.

>
> I can't think of a good name for this attribute, but consider something like
> @embedrel (required) for now (name suggestions welcome). The value of this
> attribute would reflect the scenarios identified in the recent changes to
> the draft. missing, icon, decorative, seecontext, seefallback. The value
> 'missing' would be the default value, unless '@a't had a string (or perhaps
> some other contingencies for content backwards compatibility )  so not
> setting either @alt or @embedrel would be considered 'missing'.
>

I am by no means opposed to a new attribute for indicating that an
image intentionally has no @alt text, i.e. a new attribute to do what
omitting @alt does now.  The suggestion was @noalt, Maciej has
mentioned it in a recent message.  If it can be proven that either (a)
enough UAs treat missing @alt the same as alt="" or (b) enough authors
omit alt when they really mean alt="", then I'd be in favor of that
attribute.

However, I don't understand what specific problems these keywords solve.

For example, alt="" works well when an image is purely decorative - a
blind user can ignore it.  alt="" also works well when an image's
alternate text would just be redundant: <img alt=""
src="home.jpg">Home - a blind user can ignore it.  What problem is
solved by using foo=icon or foo=decorative?  I don't see how
accessibility is served by making the distinction.

Why does an aural browser need to distinguish between various roles of
embedded content?  It's not the aural browser's job to understand the
role of images - it's the aural browser's role job to replace that
image with appropriate content by (a) speaking the alternate content
seamlessly in place of the image (b) saying nothing at all because
omitting the image doesn't change the meaning of surrounding content
or (c) saying something to indicate that an image is missing (and
possibly reading its @title) because that image has no appropriate
alternate text and cannot be omitted from the document without
changing its meaning.

In other words, how should an aural UA actually treat these various
roles by doing something differently?
-- 
Jon Barnett
Received on Thursday, 16 August 2007 21:50:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:04 GMT