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

Apologies for top posting:

Al,
As an initial first response, I agree that the narrow response as proposed
is a good one.  I can support this position as well, although I agree with
the minor edits suggested by David Poleman.

JF
*********

Al Gilman wrote:
> <note
> class="inDraft onProcess">
> 
> Earlier discussion on this point can be reviewed at
> http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/thread.html#msg44
> http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/thread.html#msg12
> http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/thread.html#msg47
> http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/thread.html#msg50
> http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/thread.html#msg0
> 
> Please comment on this on the XTECH list.
> 
> PFWG could reach consensus on some variant of this
> statement as early as Wednesday, 6 February or
> it could take longer.
> 
> I suggest that we should let this message go with the narrow topic of
> "is @alt for critical content required?" and deal with the issues
> such as  
> 
> - machine-recognizable associations between media objects and
> mainline text
> - new reserved values for @alt
> 
> .. separately
> 
> Al
> 
> </note>
> 
> The current TR draft for HTML5 contains the following language:
> 
> <quote
> cite="http://www.w3.org/TR/2008/WD-html5-20080122/#alt">
> 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>
> 
> <summary>
> 
> 1.  By the principles, HTML5 wants to support accessibility
> 
> 2.  By their charters, WAI groups (here WCAG) are the go-to experts
> in matters of accessibility 
> 
> 3.  WCAG requires @alt (WCAG1) or the function that in HTML4
> is provided by @alt (WCAG2)  [editorial note -- add links]
> 
> 4.  By the principles, if it 'tain't broke, don't fix it.
> 
> 5.  Conclusion:  barring the introduction of three fresh good reasons
> for a change, the failure of the HTML5 draft to make @alt on <img> an
> across-the-board requirement (even if sometimes it has the value of
> &quot;&quot;) is a bug.  Or do you have reasons?   
> 
> </summary>
> 
> <background>
> 
> 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 Last Call draft it is stated thus:
> 
> <quote
> cite="hhttp://www.w3.org/TR/WCAG20/#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," 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 Tuesday, 5 February 2008 18:48:50 UTC