SC 1.1.1 and 2.4 6 [was: Re: Your comments on WCAG 2.0 Last Call...]

Prior comments whose dispositions this message replies to:

LC-955
LC-956
LC-958
LC-959
LC-971

see also disposition of
LC-1208

The case tree in 1.1.1 as currently framed is too tortured.

http://www.w3.org/TR/2007/WD-WCAG20-20070517/Overview.html#text-equiv-all

We need to start with "associated text" not "equivalent text" and then we can
specialize, not exclude, as we walk the cases.

Define "associated text" as text with a machine-recognizable 
association with the
non-text content (fragment or object).

We do better developing a case tree by looking at the answers to the question
"what can I do (with this [non-text] content fragment)?"

Unless the non-text content (fragment or object) is part of a larger
fragment that has associated text or different-media alternative that
meets all requirements at that level (see response to LC-1208),

Where do = experience (image of artwork, song, etc. media object)
.. required text content identifies the object and AA content describes it

Where do = learn (picture or diagram or other item with articulable 
information to convey)
.. required text content expresses the information that one could 
learn from the non-text
content.

Where do = choose to browse or skip (section, including form or table)
.. associated text (heading) answers "what is _there_?)

Where do = go (hyperlink)
.. associated text answers "where will I go?"

Where do = other (controls and other widgets)
.. associated text answers "what can I do?"

Where information that text is to communicate is "no information," then
associated text may be omitted if this "content free" condition can be
recognized by AT from the encoding of the non-text content fragment.

Note: examples include spacers [, etc. as listed in the current draft]

Where do = complete a required task
.. associated text or task-enabling alternate-media content affords 
the opportunity
to reach the same task outcomes.

Note that the "required task" concept allows a more general statement
of a rule that is in the present draft only represented by the "process"
discussion under conformance.  This is that if some user task is a required
prerequisite for receiving any services of the site, then if the prerequisite
is not accessible (including the option of composite alternatives rather
than just atomic alternatives), no of the content whose use is dependent
on completing the inaccessible task may be claimed to be accessible.
[yes please put in the "at the pertinent level" qualification as at present]

This includes the 'process' case where defined that all subtasks in
the process are required and also more general task graphs but where
some subtask is an unavoidable prerequisite for an outcome or another
task.

[CAPTCHA is covered under this last. -- that can be a note.]

[do not give multimedia a free ride.]

[do not excuse content "that is not presented to users" -- PFWG
and UAWG, in discussions with format specifications (in particular the
resolution of the 'override' issue in SMIL) have taken the position that
authors cannot make the final determination as to whether content is
to be shown to users or not. This falls under the "author proposes,
user disposes" management protocol for show/hide profiling of content.
In other words, authors must treat all hidden content as conditional
content.  It doesn't have to be easy, but the user should have a way
to drill down to the point that it gets displayed.]

Al

Received on Tuesday, 26 June 2007 21:43:08 UTC