Re: WCAG2 comment 2615

[personal opinion disclaimer...]

On 10 Sep 2008, at 9:08 AM, Al Gilman wrote:

>
> WCAG WG has requested help from PFWG in responding to the following  
> comment:
>
> <quote
> cite="http://lists.w3.org/Archives/Public/public-comments- 
> wcag20/2008Aug/0013.html">
>
> I propose aligning with the HTML5 draft by saying that an image be
> marked as omissible from non-visual rendering if it illustrates what
> the surrounding prose already says.

PFWG has generally viewed "the surrounding prose" as fatally vague in
this statement.  In other words, the function "assistive technology
uses the proximate prose as the text alternative" is not readily
achievable.  The pertinent prose needs to be isolated or the user
takes a big hit.  Listening to everything to find the pertinent stuff
(unless there are readily machinable rules for the case where there
is only a little and it's all about the picture) is an undue burden
on the user, and isolating the germane stuff without help from the
markup places an undue burden on the AT.

We would like to improve the performance of adapted user experiences
in this case, however, where an image is tightly related to prose
that is near it.

One way to make the association machine-recognizable would be to
wrap one or more <span id=...> elements around the pertinent prose
and cite this/these in @aria-describedby on the image.

Even when such a long discourse in avaiable and associated, I personally
doubt that "marked to ignore" is the highest and best markup of the  
image
itself.  My suspicion is that in the audio rendering it would be
better to have some sort of acknowledgement of the position of the
image in the reading of the information.  This can be terse and  
perhaps as
simple as "the image."  That's best left to WCAG techniques and  
tutorials,
or perhaps the "Author's guide to HTML5" but not the specification of
the format.

On the WCAG side, I don't believe that this case requires any change
in success criteria.

> I propose aligning with the HTML5 draft by saying that if the
> generator of markup does not have a text alternative available, it
> should use the natural-language expression describing the kind of
> content (to the precision known to the generator) as the text
> alternative and use a mechanism provided by the host format for
> marking the text as not really being a text alternative but an
> indication of what kind of non-text content is in question.

In the case that a fully successful text alternative is not available,
but there is recommendable repair text that the markup-producing tool
can synthesize one should not say that "a text alternative is not  
available."
Say "the best available text alternative is not (known / expected) to  
meet
WCAG success criteria..."

Knowing that the text alternative offered is a repair synthesized
by a tool without benefit of human review is potentially of some value
on the client side.  But not that important to drive the whole decision
process.

In particular, although WCAG is transparent to the means the host
language chooses to impart this information, PFWG should be  
recognized as a knowledgeable source
for assessing the burden on AT represented by what hypertext markup  
means are used to
denote this information.

In particular, the insertion of curly braces within the text value of  
the
@alt attribute has negatives that seem stronger than the associated
positives, albeit non-trivial positives apply.

How to address this:

summary: not in WCAG proper (Success Criteria); maybe in WCAG  
techniques,
maybe in HTML5 author guide.  And TBD in HTML5 spec for "this is a
repair" indication.

There should be no barrier to HTML5 telling authors how to do the best
available practice in cases where success is not achieved.  If there
is a transcoder/formatter tool that is generating markup without the
interactive cooperation of an author, it may encounter cases where it
can generate a "probably better than nothing, but probably not success
by WCAG terms" text alternative.

In such a case the HTML5 specification and author guide documents should
make clear that the indicated encoding is not up to WCAG success  
criteria,
but what to do when you can't achieve that.  Whether the instance  
documents
should contain this as metadata is unclear, pending a compelling  
proposal.
My personal opinion is that this is better handled in EARL metadata,  
probably
outside the HTML page.

http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0190.html

There is an alternative that WCAG Techniques be expanded to include
this "close, but no cigar" case.   WCAG could take this on, but if
WCAG declines, it should be with the agreement that the HTML5 author
guide at the very least may include this case.

[and WCAG WG can leave to HTML WG, ATAG WG, UAWG and PFWG to work out  
if and how to
indicate in the document that a repair has been machine-generated and  
is not
trusted by the generator to meet WCAG requirements.]

€ 0.02

Al
/self, no hat implied

> </quote>
>
> discussion and status in WCAG:
> http://trace.wisc.edu/bugzilla_wcag/issuereports/issue_ind.php?id=2615
>
> I'm opening this thread on XTECH because WCAG works on the public  
> record, and
> to have a cross-group conversation to explore issues and options.
>
> Formal feedback will be based on consensus among the PFWG  
> participants, but
> we welcome input by discussion here.
>
> Al
>
>
>

Received on Wednesday, 10 September 2008 14:33:51 UTC