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: Joshue O Connor <joshue.oconnor@cfit.ie>
Date: Thu, 29 Nov 2007 10:59:54 +0000
Message-ID: <474E9BAA.1090806@cfit.ie>
To: Al Gilman <Alfred.S.Gilman@IEEE.org>
CC: wai-xtech@w3.org

Al Gilman wrote:
>> The language "In such cases, the alt attribute may be omitted," may
>> be intended as a fatalistic statement of fact, but it gives the
>> appearance of creating a policy line that is inconsistent with WCAG,
>> whether 1.0 or 2.0. 

Yes it does. People are not machines so they will *perceive* statements
like that to mean various things including, but not limited to, "Oh alt
isn't really that important" IMO.

Michael A Squillace wrote:

> Lachlan Hunt writes, "Making alt technically optional ...just 
> acknowledges the reality of the situation in
> the hope of reducing the prevalence of poor quality, automatically 
> generated alt text." 
> 
> http://blog.whatwg.org/omit-alt
> 
> This argument is especially disconcerting to me as it simply states that, 
> when insufficient tooling for producing the requisite attributes exists or 
> when content authors are simply using attributes (or markup in general), 
> that we simply make the markup optional. 

Agreed. Again the wrong message IMO.

As an aside, while, in principle, I agree that there may be situations
where there just is no suitable alternative textual description
possible, and the main content whether an image a video object or
whatever cannot be described. Then IMO using a alt="" null is fine. In
short, I would rather see authors _continue_ to use alt instead of them
getting the idea that it *may* sometimes be left out.  Even if this *is*
the case. I think this is one cowpath worth paving while suitable better
methods are developed, if only to avoid somehow subtly devaluing alt in
the mind of the author by producing badly authored examples of these
edge cases where alt may be omitted in the spec.

Josh




> 
> The Editor's draft for HTML5 contains the following language:
> 
> <quote
> cite="http://www.w3.org/html/wg/html5/#the-img">
> A key part of the content that doesn't have an obvious textual alternative
> 
> In certain rare cases, the image is simply a critical part of the
> content, and there might even be no alternative text available. This
> could be the case, for instance, in a photo gallery, where a user has
> uploaded 3000 photos from a vacation trip, without providing any
> descriptions of the images. The images are the whole point of the
> pages containing them.
> 
> In such cases, the alt attribute may be omitted, but the alt
> attribute should be included, with a useful value, if at all
> possible. If an image is a key part of the content, the alt attribute
> must not be specified with an empty value.
> </quote>
> 
> The applicable provision in the WCAG 1.0 Recommendation is Checkpoint 1.1
> 
> <quote
> cite="http://www.w3.org/TR/WCAG10-TECHS/#tech-text-equivalent">
> 
> Provide a text equivalent for every non-text element (e.g., via
> "alt", "longdesc", or in element content). This includes: images,
> graphical representations of text (including symbols), image map
> regions, animations (e.g., animated GIFs), applets and programmatic
> objects, ascii art, frames, scripts, images used as list bullets,
> spacers, graphical buttons, sounds (played with or without user
> interaction), stand-alone audio files, audio tracks of video, and
> video. [Priority 1]
> </quote>
> 
> and in the WCAG 2.0 Editor's draft it is stated thus:
> 
> <quote
> cite="http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/#text-equiv-all">
> 1.1.1 Non-text Content: All non-text content has a text alternative
> that presents equivalent information, except for the situations
> listed below. (Level A) How to Meet 1.1.1 Understanding 1.1.1
> 
> Controls, Input: If it is a control or accepts user input, then it
> has a name that describes its purpose. (See also Guideline 4.1.)
> 
> Media, Test, Sensory: If it is (1) synchronized media, (2) live
> audio-only or live video-only content, (3) a test or exercise that
> must be presented in non-text format, (4) primarily intended to
> create a specific sensory experience, then text alternatives at least
> provide descriptive identification of the non-text content, or (5) a
> media alternative to text that is clearly labeled as such. (For
> synchronized media, see also Guideline 1.2.)
> 
> Note: Prerecorded audio-only and video-only files would be covered
> under [Success Criterion 1.1.1], which requires text alternatives
> that present equivalent information.
> 
> CAPTCHA: If it is to confirm that content is being accessed by a
> person rather than a computer, then text alternatives that identify
> and describe the purpose of the non-text content are provided, and
> alternative forms of CAPTCHA using output modes for different types
> of sensory perception are provided to accommodate different
> disabilities.
> 
> Decoration, Formatting, Invisible: If it is pure decoration, or used
> only for visual formatting, or if it is not presented to users, then
> it is implemented in a way that it can be ignored by assistive
> technology.
> 
> </quote>
> </background>
> 
> <finding>
> 
> The language "In such cases, the alt attribute may be omitted," may
> be intended as a fatalistic statement of fact, but it gives the
> appearance of creating a policy line that is inconsistent with WCAG,
> whether 1.0 or 2.0. As such, this needs to be changed. HTML WG should
> re-work the <img> element section to bring it into line as techniques
> for implementing WCAG 2.0. We say 2.0 because of the strong
> likelihood that WCAG 2.0 will precede HTML5 to Recommendation status.
> 
> WCAG WG is chartered to set Accessibility guidelines and HTML
> WG is not; so HTML5 should be careful to create features that support
> WCAG and describe their use in ways that conform to WCAG.
> 
> </finding>
> 
> Al
> /self (chair hat off)
> 
> 
Received on Thursday, 29 November 2007 11:00:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:44 GMT