W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: alt and authoring practices

From: Smylers <Smylers@stripey.com>
Date: Sun, 4 May 2008 03:01:05 +0100
To: "HTML Working Group <public-html@w3.org>" <public-html@w3.org>
Message-ID: <20080504020105.GE11992@stripey.com>

Robert J Burns writes:

> On May 3, 2008, at 2:37 PM, Smylers wrote:
> 
> > > The initial name of the photo is automatically generated by iPhoto or
> > > my camera and usually in the form IMG_####.jpg. This means the alt
> > > attribute would look like this: ‘alt='view image &quot;IMG_1234&quot;
> > > fullsize”.
> >
> > But that isn't alternative to being able to see the photo.
> >
> > Also it doesn't provide a browser with any additional information;
> > the filename is already in the href of the link -- so a browser's
> > heuristics could choose to show that to the user even without it
> > being set in the alt attribute.
> >
> > So I'm not sure how the author doing that is any better for
> > image-less users than omitting the alt attribute entirely.
> >
> > Image-less browsers can do at least as well by themselves, possibly
> > better.
> 
> This I think is a bit of a technical misunderstanding that needs  
> clarification. Including ‘view image &quot;IMG_1234&quot;’ in the alt  
> attribute is not remotely the same thing as omitting the alt
> attribute.  First, a UA could read the filenames for every photo on
> the page.

Yes -- or at least, only for those with no alt text.

> However, that's a very different user experience than reading the few
> times an author includes that alt text in the document.

It's exactly the same: the author can specify which photos those are by
completely omitting the alt attribute.  For other photos he'll specify
either alt="" or include some alt text, depending on the required user
experience.

> In the latter case, it's now at the author's discretion which content
> gets read to the user.

Which isn't a good thing: because the vested interests are such that for
images which the author flags as being ones for which he can't provide
plausible alt text, image-less browsers are likely to be at least as
good at guessing what to provide in lieu of the image as authors are.

> Secondly, the UA cannot easily determine that it should add the ‘view
> image’ in front of the filename of each graphic.

Yes.  But why should it?  Those seeing the images don't get any
additional clue as to where the link goes, so adding this wouldn't be an
alternative.  Instead put it in the link's title attribute, so it's
available (for example, as a tooltip) to both users with and without
iamges.

> Thirdly, in this case the authoring tool is drawing the alt text not
> from the graphic filename (as you assumed), but from the graphic files
> metadata title.  In this way, every title the author provides is
> immediately made use of by the authoring too.

Clearly author-provided titles (if they are descriptive) should be used
for alt text.  However I don't think that "IMG_1234" counts as an
author-provided title!

> So to underscore this again. This means there is nothing cumbersome or
> burdensome in the requirement to include alt text (at least not in any
> of the examples provided so far).

I agree there is nothing burdensome in automatically providing alt="view
IMG_1234 full size".  However:

* I still don't see how that provides an image-less user with any
  information at all which isn't already elsewhere in the page.

* If that's deemed to be sufficient alt text when an image is unknown,
  it's presumably also sufficient alt text when an image is known --
  when an author could write a phrase describing what can be seen in the
  photo, but just can't be bothered to do so.
  
  Accepting that would be _lowering_ the standard of alt text required
  from that in the current HTML 5 draft, which currently insists on a
  proper alternative.  I don't think lowering the level of acceptable
  alt text like this would be an improvement to accessibility.

Smylers
Received on Sunday, 4 May 2008 02:01:47 GMT

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