W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2007

Re: DRAFT response Re[3]: Request for PFWG WAI review of Omitting ?alt Attribute for Critical Content

From: David Poehlman <poehlman1@comcast.net>
Date: Thu, 29 Nov 2007 07:08:19 -0500
Message-ID: <001301c83280$885c4450$0701a8c0@HANDS>
To: "Jason White" <jason@jasonjgw.net>, <wai-xtech@w3.org>

I guess this is not an argument for rejecting validity of alt+="", but in 
order to be bypassed, it will be severely abused as is the summary for 

----- Original Message ----- 
From: "Jason White" <jason@jasonjgw.net>
To: <wai-xtech@w3.org>
Sent: Thursday, November 29, 2007 5:47 AM
Subject: Re: DRAFT response Re[3]: Request for PFWG WAI review of Omitting 
alt Attribute for Critical Content

On Thu, Nov 29, 2007 at 10:48:53AM +0100, Charles McCathieNevile wrote:

> I think we should be clearer.
> [[[ If an image is a key part of the content, the alt attribute
> must not be specified with an empty value. ]]]
> Is very important. I think we should request that a missing alt value be
> considered invalid, although for accessibility reasons it is preferred to
> the more serious error of marking meaningful content which requires an
> alternative with alt=""

I support Charles' comments.

Furthermore, the most important concept is that there should be only two
syntactically distinct possibilities:

1. Alt with a non-null string, providing an alternative to the image.

2. Alt with a null string, signifying that the image is an artifact of

There should not be a third - an omitted alt - which ought, as Charles
suggests, to trigger a syntax error that can be detected by authoring tools
and markup validators.

HTML generating applications (including authoring tools) should not output
alt="" unless reasonable measures have been taken to ensure that the image
belongs to the decorative class. This last point is an authoring tool
requirement which I am sure can be handled in ATAG, if it is not there
Received on Thursday, 29 November 2007 12:08:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:28 UTC