W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Re: Proposal checkpiont 2.7: Solution for repair text should not be minimal requirement

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 15 Mar 2001 15:45:27 -0500
Message-Id: <Version.32.20010315143008.0413ef00@pop.iamdigex.net>
To: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
At 10:43 AM 2001-03-15 -0500, Ian Jacobs wrote:
[the change seems reasonable and justified to me.]
>
>For the Techniques:
>
>    * Allow configuration so that instead of generating
>      repair text from a URI reference, the user agent
>      retrieves the resource at that URI and extracts
>      meaningful text (e.g., a title) from the resource
>      as the basis of repair text. [It would even be
>      possible to build a database of useful repair text
>      to be consulted whenever a resource included by
>      URI lacked required conditional content.]

Querying RDF space for metadata is a separate technique from recovering and
inspecting the resource for suitable placeholder text.

Since PICS is operational and we are not committed to two competing
implementations of techniques promote this from an apologetic asside "it would
even be possible..." to just a technique among other techniques.  Link to the
Semantic Web activity home page.

>Comments:
>
> a) I also think that any of the three pieces (URI 
>    reference, content type, element type) should suffice
>    (hence or rather than and).
>

Agreed.  If you imply they must use multiple this exceeds minimum requirements
in a way you didn''t need to.  So leave the example at "any of the
following." 
PS:  The 'also' is confusing in your comment, as this is what is said in the
proposal, not over and above what is said in the proposal.

> b) In general, content type is provided by HTTP headers,
>    not in markup, and I would rather not require the UA
>    to do a HEAD or GET call to find out the content type
>    of a Web resource.

This comment is confusing.  Maybe the checkpoint is too easy to
misunderstand. 
The contemplated User Action algorithm uses type indications within the
currently held document data, in the element referencing the external media
object.  This is the type information that is meant to be used in this case. 
Various HTML/XML elements give information about the type of content involved
where content is imported by URI reference.

Adding any Net traffic to satisfy this checkpoint is supposed to be above and
beyond the minimum requirement, yes.  But just saying "type" was not meant to
commit the user agent to discovering the actual type of the recovered value of
the resource just to generate a placeholder.  If you want to say "locally
indicated type" or "type indicated with the content reference" that could be
clearer.

> c) I realize that this may make it harder to verify that
>    the user agent has satisfied the intention of the 
>    checkpoint. I hesitate to say that the repair text
>    should meet WCAG expectations, because this is generated
>    text and there is no guarantee that it will be useful.
>    I don't think it's worth saying "the repair text needs
>    to be useful to the user," though clearly that's the 
>    intention.
>

This is correct.  The standard for User Agent generated text here is lower
than
the threshold for questions to the author in the AERT.  If the User Agent
can't
say anything smarter than "[application]" that's OK.

> d) I propose deleting the last sentence of the Note:
>
>    "When the author does not provide this required content, 
>     the user agent is required by this document to generate 
>     repair text."
>

[works for me]

Al

> - Ian
>
>[1]
<http://www.w3.org/WAI/UA/WD-UAAG10-20010309/>http://www.w3.org/WAI/UA/WD-UA
AG10-20010309/
>[2]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0345.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0345.html
>-- 
>Ian Jacobs (jacobs@w3.org)  
<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>  
Received on Thursday, 15 March 2001 15:24:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:38 GMT