W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2000

Checkpoint 2.5: Proposed rewording and minimal requirement

From: Ian Jacobs <ij@w3.org>
Date: Tue, 09 May 2000 16:22:02 -0400
Message-ID: <3918736A.5DB11C8A@w3.org>
To: w3c-wai-ua@w3.org
Hello,

At the 9 May teleconference, we discussed minimal requirements
for checkpoint 2.5 of the 7 May draft [2]:

<OLD>
Checkpoint 2.5: When the author has not specified a text 
     equivalent for content as required by the markup language, 
     make available other author-specified information
     about the content (e.g., object type, file name, etc.). 
</OLD>

This email consists of two parts: proposed clarification of text
and minimal requirements summary.

1) New text. It is not clear (enough) from checkpoint 2.5
   that the user agent is expected to repair the case where
   the author has not provided any text equivalent. This checkpoint
   is only meant to apply for those objects where the user agent
   can recognize content as being a text equivalent of some other
   piece of content (that's in the applicability provisions
   of the 7 May draft). 

   The checkpoint doesn't say "a text equivalent for non-text
   content". I think we should say that.

   Also, the checkpoint talks about a text equivalent
   "as required by the markup language". I think that is 
   meant to capture "that the user agent can recognize", but
   I don't think that's sufficient for two reasons:

     - Even if the markup language doesn't require it, the
       user still needs it.

      - The author may provide text equivalents in the
        objects themselves, and not in the markup (though
        you can argue that this markup for the object).
        For instance, consider the W3C Note entitled
        "Describing and retrieving photos using RDF and
         HTTP". Some image formats (e.g., JPEG) let
        you store metadata in them, and the user agent
        should make use of this information when available.
       
   Therefore, I propose the following clarification:
  
   <NEW>
    When the user agent cannot recognize a text equivalent
    for non-text content, generate a text equivalent 
    from other author-supplied content.
   </NEW>

   This wording does place a slightly heavier burden
   on the user agent. In the previous wording, the
   user agent wasn't required to do anything if the
   author provides a text equivalent but the user
   agent doesn't recognize it. In the proposed
   wording, as soon as the UA doesn't recognize a
   text equivalent, the repair function applies. 

   Notes:

    - We should state in the techniques that text equivalents
      may come from markup, inside images, etc. User agents
      are expected to recognize equivalents by specification
      (a reminder of what the applicability clause already
       states). 

    - The user agent, by virtue of generating the text
      equivalent itself, knows about the association between
      the generated equivalent and the object. Therefore,
      other checkpoints (e.g., 2.3) that involve recognized
      equivalents would apply for these generated equivalents.

  I also propose that we add the RDF/photos note to the
  list of references in the Techniques document.

2) Minimal requirements. 

   We agreed at the teleconference that the requirement was to
   make available both the resource name and type. This information
   is available from HTTP headers.

   1) Name. This is some or all of the URI of the requested 
      resource. In the case of content negotiation, the
      "Content-Location" header may provide information.

   2) Type. This information is available in the Content-Type header.

 - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0327.html
[2] http://www.w3.org/WAI/UA/WD-UAAG10-20000507/
[3] http://www.w3.org/TR/2000/NOTE-photo-rdf-20000503 
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Tuesday, 9 May 2000 16:23:11 GMT

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