Re[2]: meta comments on XML Accessibility Guidelines - n images

At 08:36 AM 2002-12-04, Ian B. Jacobs wrote:
>>  c) in the absence of preferences from the user, the User Agent
>>  should follow author preferences
>
>UAAG 1.0:
>
>  2.1 Render content according to specification. (P1)

The UAAG requirement here depends on the format specification to say the right
thing.  The XAG tries to guide that format spec in what the right thing is
to say.  In this case the UAAG provision does not assure that the XAG provision
is met; if both provisions are met the user will have the access we seek.

>>  d) the User Agent may display more than one, or one other  than the 
>> first  feasible choice, should this be appropriate from what the
>>User Agent  knows of the  delivery context opportunities and preferences.
>
>UAAG 1.0:
>
>  2.3 Render conditional content. (P1)
>  2.9 Render conditional content automatically. (P3)

Here is a case where I don't think that the UAAG requirements cover what XAG
needs to say.

The key, once again, has to do with the discriminants between when you follow
case c) or case d).

Formats have to indicate (in the semantics bound to their syntax) a 
distinction
between behavioral suggestions which have the semantic weight of author
proposals or preferences, and the more limited set of propositions or 
constraints
on User Agent rendering and otherwise binding of the experience which qualify
as bona_fide constraints of the application.

The concept of a notice that must be presented if a related service is to be
exercised is an example of a bona_fide grouping or atomic transaction
requirement.  This is a keep-together constraint which reflects intrinsic
and unavoidable requirements of the application.  On the other hand, the
customary widows-and-orphans-curing "keep together" annotation may be
violated for good reason for example in tiny[1] delivery contexts.  Large
fonts and screen magnifiers (i.e. adaptation strategies typical of the
visually impaired or low vision user) may make a tiny context of almost any
text presentation frame, regardless of the total pixel size of the physical
medium.

The formats further have a burden to attempt to express the constraints in
as repurposable way as possible.  This means eliminating dependencies on the
response time of the user wherever possible, and providing alternates where
not possible.

Yes, that is a burden on the application designer, but the format designer
needs to discover where the patterns of application expression in the format
can systematically reduce any such dependencies, and support authoring tools
in alerting application instance creators in recognizing the need for an
alternate path through the interaction logic where the need arises.

Al

[1] 'tiny' as in "tiny display"  See for example the family of -Tiny 
profiles from W3C.

>DPawson@rnib.org.uk wrote:
>>
>>I like the sense of these comments Al;
>>Could we extract some of it for XAG?
>
>Is this really for XAG?

As I see it, yes; there is stuff that belongs in XAG, but
it may not be obvious until one adds back into the change
proposal a few points that Dave missed, and I may have not
spelled out enough.

Suffice it to say that the things you have recapitulated
are the instance requirements that must be supported, and
these are traceable to existing writ, but that the feasible
range of "how to do this in a format" expressed in the part
of the message

<quote>

In other words, there is a declarative assertion of a bag of
roughly-equivalent resources, an author's expected ordering of
preference for selection of one, and an understanding that some
other optimization to select one or more than one may be appropriate
in some circumstances.

So a select-first-match-from-list default structure with a permissive
escape to processing as the superclass select-multiple-from-bag is a rough
summary of the format structure.

</quote>

gives evidence of a more analytical view of the format design
problem that interprets the instance requirements in terms
of XML dialect constructs.

I actually believe that what I see as appropriate here is more
clear when we apply the remaining XAG guidelines in this scenario.

The point with the multiple images is that the differences between the
alternatives have to be made clear to both person and machine, so there is
an information structure that has to be captured in the format which goes
beyond just a bag of image objects.  This is required under XAG Guidelines 2
and 4 as a response to the guidelines "1. support WCAG" and "3. support
UAAG" [I paraphrase heavily].

The other hard part is that the Accessibility requirement does not resolve
whether the format specification will bind similarity semantics *implicitly*
through collecting the similar items in one container element as in html:object
or smil:switch or indicate the associations through *explicitly* marked
relationships (attributes of type IDREF | IDREFS) or even more indirectly
through relationship assertions outside the primary syntax tree as in
smil:metadata (see also SRGS).

So we may need to be getting into writing queries against infosets as the
medium of expression for what it is that is required.  But there is content
in there, and simply identifying SMIL as the first place to look for prior
art for content control and SVG as the first such reference for grouping and
annotation within the XML syntax, we will have helped format designers a lot.

How can I put it?  I think that the fact that Paul felt moved
to ask shows that there is a use for something beyond the operational
requirements on the instances that are captured in the WCAG and UAAG.

Al


>Looking at Al's comments below (Al, please correct me
>here if I've chosen the wrong checkpoints):
>
>>In order to offer the user multiple images  where
>>  a) the author believes any of these will do the job
>
>WCAG: provide equivalents.
>
>>  b) the User Agent can display at least one if there is one that
>>  meets delivery context constraints.
>
>UAAG 1.0:
>
>  2.3 Render conditional content. (P1)
>
>>  c) in the absence of preferences from the user, the User Agent
>>  should follow author preferences
>
>UAAG 1.0:
>
>  2.1 Render content according to specification. (P1)
>
>
>>  d) the User Agent may display more than one, or one other  than the 
>> first  feasible choice, should this be appropriate from what the
>>User Agent  knows of the  delivery context opportunities and preferences.
>
>UAAG 1.0:
>
>  2.3 Render conditional content. (P1)
>  2.9 Render conditional content automatically. (P3)
>
>
>>Each image should be provided with an appropriate textual alternative.
>
>WCAG, 1.1.
>
>I don't see any format requirements in the above
>statements. For XAG, the requirement is to allow
>the author to specify equivalents. See a long list
>of suggested XAG requirements starting "Allow the author to..."
>in:
>   http://lists.w3.org/Archives/Public/wai-xtech/2002Sep/0028
>
>  _ Ian
>
>--
>Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                     +1 718 260-9447

Received on Wednesday, 4 December 2002 11:19:46 UTC