Responses to Dianna Callesen issues raised during second last call of UAAG 1.0

Dianna,

Please find below a summary of how the UAWG addressed your last call
issues (323, 324, and 372-382; refer to original emails [0a and 0b]).

The complete second last call issues list [1] is available
online. The results of the UAWG's resolutions have been
incorporated into the 9 March 2001 draft of the document [2].

  NOTE: The issue titles relate to the 23 October 2000 last call
  draft [4]. In my comments below, checkpoint numbers, etc. have
  been updated to correspond to the 9 March 2001 draft.

Please indicate before 27 March whether you are satisfied with
the UAWG's resolutions, whether you wish the WG to carry forward
any objections to the Director as the document advances, or
whether you require further clarification or comment. If you do
not think you respond before 27 March, please let me know.  The
Director will appreciate a response whether you agree with the
disposition of comments or not. More information about the
process we are following is available in section 5.5.2 of the W3C
Process Document [3].

On behalf of the UAWG, thank you for Adobe's review and comments,

 - Ian

[0a] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0195
[0b] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0294
[1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html
[2] http://www.w3.org/WAI/UA/WD-UAAG10-20010309/
[3] http://www.w3.org/Consortium/Process-20010208/tr.html#last-call
[4] http://www.w3.org/TR/2000/WD-UAAG10-20001023/

===============================================
The UAWG disagreed with you on the following:
===============================================

----------------------
#377: Security issues and communication with other software 

  Comment: The Working Group agrees that security issues are
  important, but did not make any changes to its requirements.
  The Working Group did acknowledge this issue in two ways
  in the document:

  a) Section 1.3 includes "Security" as a known limitation
  b) Section 3.4 has a subsection entitled "Restricted functionality
     and conformance", which states that conformance is not affected
     by a restricted view of a particular document. 

  You are invited to review both of these statements.

#378: Simplify language of document for non-technical audience. 

  Comment: This document is primarily aimed at developers of
  user agents and is therefore necessarily somewhat technical
  in nature. Nonetheless, it must be clearly written. The Working
  Group will not produce a non-technical version of UAAG 1.0
  as part of advancing along the Recommendation track. However,
  the Working Group will add an executive summary to the document.
  We will ask the Education and Outreach Working Group for
  help producing non-technical supplements in the future.
  
  You are invited to send specific comments about passage of the
  document that are difficult to understand.

===============================================
The UAWG agreed with you, but please confirm:
===============================================

<RELATED>
#323: Using accessibility APIs rather than standard APIs to make
non-W3C based content accessible (checkpoint 5.4)
#379: Checkpoint 1.2: Exception when primary output (e.g., graphics)
cannot be handled by the OS?
</RELATED>

  Comment: Checkpoint 6.6 states this desired requirement:"

  "6.6 Implement standard accessibility APIs (e.g., of the operating
  environment). Where these APIs do not enable the user agent to
  satisfy the requirements of this document, use the standard input
  and output APIs of the operating environment."

#372: Limitations of standard APIs in conveying author's intent or
functionality? [Note, this is the same as issue 375, by error.]

  Comment: The rewrite to checkpoint 6.6 addresses this request
  as accessibility APIs are given preference over input/output
  APIs.

-----------------
#376: Requirement that plug-ins be given focus 

  Comment: Checkpoint 9.1 requires that the user be able to move the
  focus to every viewport. If the plug-in is part of the conformance
  claim, then your desired requirement is already addressed. If it is
  not part of the claim, then the Working Group considered it a bug
  rather than an accessibility problem if a piece of software that
  should hand off focus by design does not (i.e., that's what plug-ins
  are for, so not handing off focus is a bug).

-----------------
#381: Checkpoint 2.5: Checkpoint text needs clarification 

  Comment: The new checkpoint 2.7 reads:
 
  "2.7 Allow configuration to generate repair text when the user
  agent recognizes that the author has failed to provide
  conditional content that was required by the format
  specification. If the missing conditional content is included
  by URI reference, base the repair text on the URI reference and
  content type. Otherwise, base the repair text on element type
  information."

  Please note that there is an outstanding proposal to change the
  minimal repair requirements:
    http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0418.html

===============================================
The UAWG answered your question:
===============================================

----------------------
#324: How do developers interpret the phrase "appropriate for a task"
in checkpoint 6.2

  Comment: What is now checkpoint 8.2 has been changed to require
  either W3C specifications OR specifications that allow authors
  to create content that conforms to WCAG 1.0. The checkpoint reads:

  "8.2 Use and conform to either (1) W3C Recommendations when they are
  available and appropriate for a task, or (2) non-W3C specifications
  that enable the creation of content that conforms to the Web Content
  Accessibility Guidelines 1.0 [WCAG10] at any conformance level."

  Thus, if a vendor claims that W3C does not have Recommendation for
  a particular task, a user agent rendering another format may still
  conform to UAAG 1.0 as long as the format allows authors to create
  content that conforms to WCAG 1.0.

----------------------
#380: Checkpoint 2.3: What if equivalency relationship unknowable by
format?

  Comment:

   - The techniques to satisfy 2.3 do not have to be screen-position
   based; Option three (query) is based on the logical document
   structure. Please note that checkpoint 2.3 has been revised (as
   have other checkpoints in Guideline 2). Also, we have introduced
   the term "conditional content", which does not affect your issue
   since the requirement is still to be able to recognize
   relationships from format information.

   - If you don't know where the equivalents are in the content at
   all, then the format is problematic per checkpoint 8.2.


=============================================================
The UAWG sought additional information but did not receive it
=============================================================

#382: Checkpoint 3.2: Hard to do in many cases (e.g., when
scripts used). 

  Comment: On 5 January, I asked for more information about 
  this comment [5], but we have not yet received a reply
  from Adobe. You are invited to send more information to help
  us address this issue, but for now the Working Group has
  not changed the priority of checkpoint 3.2.

[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0028

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Friday, 16 March 2001 20:33:42 UTC