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

This gets my vote but I've changes inserted with dp:

----- Original Message ----- 
From: "Al Gilman" <Alfred.S.Gilman@IEEE.org>
To: <wai-xtech@w3.org>
Sent: Tuesday, February 05, 2008 12:04 PM
Subject: DRAFT response Re[4]: Request for PFWG WAI review of Omitting alt 
Attribute for Critical Content





<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 dp: I think: ain'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.  dp: drop this as it is 
redundant..."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
dp: Take out one of the h 
below.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 17:20:55 UTC