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

Re: Investigating the proposed alt attribute recommendations in HTML 5

From: Jon Barnett <jonbarnett@gmail.com>
Date: Fri, 31 Aug 2007 14:23:11 -0500
Message-ID: <bde87dd20708311223l6a855926h243bbad726214099@mail.gmail.com>
To: "Leif Halvard Silli" <lhs@malform.no>
Cc: public-html@w3.org, "Sander Tekelenburg" <st@isoc.nl>

On 8/31/07, Leif Halvard Silli <lhs@malform.no> wrote:
>
> On 2007-08-31 17:06:51 +0200 Sander Tekelenburg <st@isoc.nl>:

> >> And since the spec is supposed ot be media independent, this goes for
> >> screeen readers as well.
> >
> > Of course.
> >
> >> (Hence, to say that screen readers can just use TITLE with ALT is not
> >> available is backwards.)
> >
> > Indeed. But where does the spec say that?
>
> It doesn't. But some have the last days proposed that screenreaders can simply show the TITLE= when ALT= text is not available. Jon Barnett even suggested that we could change the requiremenst to say that there must be either a TITLE or a ALT [1]:
>
>         My comment about requiring @title would satisfy the need for
>         accessible markup without changing semantics.
>
> and [2]
>
>         (And in turn, I wouldn't be opposed to requiring @title when @alt is
>         omitted)
>
> And I am just pointing out that this is speaking against the media independence aspect. The accessibility aspect is also a media independence aspect.
>
> The draft says:
>
>         If the src attribute is omitted, the image represents whatever
>         string is given by the element's alt attribute, if any, or
>         nothing, if that attribute is empty or absent.
>
> But if one *really* think that it is enough that either TITLE or ALT is availble, then we should add something like this:
>
>             «If the src and alt attributes are omitted, the image represents
>         whatever string is given by the element's title attribute.»

That's a misrepresentation of what I said, so I'll clarify my comment
about @alt and @title with regard to the semantics in the draft.

You quoted my statement: "My comment about requiring @title would
satisfy the need for accessible markup without changing semantics."

You (I believe) pointed out that it's better to provide a "poor" @alt,
or a "descriptive" @alt because without @alt, JAWS falls back to to
using @src.  I suggested omitting @alt and using @title instead
because it gives accessible text without changing the semantics of
@alt (from "alternative text" to "descriptive text")

The draft gives this example:
<!-- This is the correct way to do things. -->
<p>
 You are standing in an open field west of a house.
 <img src="house.jpeg" alt="The house is white, with a boarded front door.">
 There is a small mailbox here.
</p>

An aural UA can announce "You are standing in an open field west of a
house. The house is white, with a boarded front door.  There is a
small mailbox here."

Even without announcing the presence of an image, the image is
completely replaced with the alternate text and the meaning of the
document hasn't changed.  (After all, the draft says, "It is important
to realise that the alternative text is a replacement for the image,
not a description of the image.")

Here's an example from the original post:
<P class=StreamList><A
      href="http://www.flickr.com/photos/11994078@N04/1237874293/"><IMG
      height=75 alt=Sgt.Pepper&amp;Robin2
      src="files/1237874293_8dfcd0cbfe_t.jpg"
      width=100></A><BR>From <A
      href="http://www.flickr.com/photos/11994078@N04/">pinktigger</A> </P>

An aural UA might announce "Seargent Pepper and Robin-two from pinktigger"

By following the semantics in the draft and replacing the image with
the alternate text (and not announcing the presence of an image) the
meaning is changed is changed in a confusing way. (What the hell is a
Robin-two?)

I suggested omitting @alt and using @title instead:
<P class=StreamList><A title=Sgt.Pepper&amp;Robin2
      href="http://www.flickr.com/photos/11994078@N04/1237874293/"><IMG
      height=75 src="files/1237874293_8dfcd0cbfe_t.jpg"
      width=100></A><BR>From <A
      href="http://www.flickr.com/photos/11994078@N04/">pinktigger</A> </P>

An aural UA might announce "[Embedded graphic titled Seargent Pepper
and Robin-two] from pinktigger"

So if the UA falls back to @title in the case of no @alt,
accessibility isn't harmed - the user is presented with something
useful. Semantics aren't harmed - the image isn't replaced with
confusing text, the presence of an image is announced along with
descriptive text.  @title isn't being presented the same way as @alt
(fulfilling the requirement you quoted). (It's never implied the the
image represents the @title text as you said - the image with a title
represents an image with a title)

I really don't know where your statement about media independence
comes from.  I don't know what about this is media dependent.

This gives the aural UA a fighting chance at knowing when to
seamlessly replace an image with some text and when to announce the
presence of an image along with descriptive text.  I think the current
draft moves us further in that direction in a way that's easy for
authors (and authoring tools).  If there's a better way to reach that
same end, it's a valid discussion.

>
> > All I know is that some UAs (Jaws) have been reported to be configurable
> > (might be the default; that hasn't been reported) to present the contents of
> > @title when @alt isn't available. We don't even know if in that case the UA
> > indicates that it is reading @title.
>
> I know. And now we are discussing browser behaviour - not author requirements. That is confusing. In order to test what the author requirements could lead to, Joshue have been performing user tests. When we got the results, some were reacting by saying that Jaws should change its behaviour.

It's clear to me that JAWS's behavior is less than ideal, even in the
HTML4 sense.  For example, seamlessly announcing the @src of an image
just seemed confusing to me, as I would bet that a very small
percentage of images in photo galleries have useful filenames.

As the semantics are better and more specifically defined - however
their defined - one would hope that JAWS and other AT will change
behavior to match those semantics.  (Otherwise it's a futile
exercise.)

--
Jon Barnett
Received on Friday, 31 August 2007 19:23:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC