Responses to AOL issues raised during third last call of UAAG 1.0

Scott,

The User Agent Guidelines Working Group (UAWG) has almost
finished resolving the issues raised during the third last call
review of the 9 April 2001 UAAG 1.0 [1]. 

This is the UAWG's formal response to the issues you raised on
behalf of AOL, which have been logged in the Working Group's
issues list [4].  The UAWG's resolutions have been incorporated
into the 22 June 2001 draft of the UAAG 1.0 [5].

Please indicate before 19 July whether you are satisfied with the
UAWG's resolutions, whether you think there has been a
misunderstanding, or whether you wish to register an objection.
If you do not think you can respond before 19 July, please let me
know.  The Director will appreciate a response whether you agree
with the resolutions or not.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the UAWG's resolution to each of your issues.

Note: Where checkpoint numbers have changed, I will indicate the
mapping to the 22 June 2001 draft.

Thank you,

 _ Ian

-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------

Per section 5.2.3 [2] of the 8 February 2001 Process Document, in
order for the UAAG 1.0 to advance to the next state (Candidate
Recommendation), the Working Group must "formally address all
issues raised during the Last Call review period (possibly
modifying the technical report)." Section 4.1.2 of the Process
Document [3] sets expectations about what constitutes a formal
response:

  "In the context of this document, a Working Group has formally
  addressed an issue when the Chair can show (archived) evidence
  of having sent a response to the party who raised the
  issue. This response should include the Working Group's
  resolution and should ask the party who raised the issue to
  reply with an indication of whether the resolution reverses the
  initial objection."

If you feel that the response is based on a misunderstanding of
the original issue, you are encouraged to restate and clarify the
issue until there is agreement about the issue, so that the
Working Group may prepare its substantive response.

If the response shows understanding of the original issue but
does not satisfy the reviewer, you may register a formal
objection with the Working Group that will be carried forward
with the relevant deliverables. There are currently two
objections that the UAWG will carry forward with the document in
a request to advance to Candidate Recommendation. Each concerns
the priority of checkpoint 12.1, one that the priority should be
lowered, the other that the priority should be raised. There are
additional supporters of each position.

  Phill Jenkins:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0528
    
  Gregory Rosmaita:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0553

[1] http://www.w3.org/TR/2001/WD-UAAG10-20010409
[2] http://www.w3.org/Consortium/Process-20010208/tr.html#RecsCR
[3] http://www.w3.org/Consortium/Process-20010208/groups.html#WGVotes
[4] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3
[5] http://www.w3.org/TR/2001/WD-UAAG10-20010622/

-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------

------------------------------------------------------------------
Issue 469: Write access to controls that can be changed through
the user interface
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#469
------------------------------------------------------------------

Issue summary: Checkpoint 6.4 requires universal write access,
which may cause security problems.

Resolution: For harmony with checkpoint 6.1 (DOM write access): 

  a) Split 6.3 into read and write, with write access only for
  what can be done through the UI.

  b) Split 6.4 into read and write, with write access only for
  what can be done through the UI.

The revised checkpoint 6.4, provision 2 includes the change.  The
entire checkpoint is:

<22 June 2001 draft>
6.4 Programmatic operation. (P1)

  1.Provide programmatic read access to user agent user interface
controls. 

  2.Provide programmatic write access for those controls that the
  user can modify through the user interface. For security
  reasons, user agents are not required to allow instructions in
  content to modify user agent user interface controls.

  3.To satisfy these requirements, implement at least one API
  that is either defined by a W3C Recommendation, or a publicly
  documented API designed to enable interoperability with
  assistive technologies.
 
  4.If no such API is available, or if available APIs do not
  enable the user agent to satisfy the requirements, implement at
  least one publicly documented API that allows programmatic
  operation of all of the functionalities that are available
  through the user agent user interface, and follow operating
  environment conventions for the use of input and output APIs.
</22 June 2001 draft>


------------------------------------------------------------------
Issue 470: Navigation to disabled active elements
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#470
------------------------------------------------------------------

Issue summary: For checkpoint 9.6 (checkpoint 9.7 in the 22 June
draft), please allow configuration to include disabled elements
in navigation order (for user interface consistency).

Resolution:

   - The assumption of this document is that the content focus
   always designates zero or one enabled or disabled elements
   (but never non-interactive elements).

   - No change to checkpoint 9.6. Mention in the techniques that
   a configuration option to include disabled elements (for
   reasons cited by the reviewer) is fine.

   - Revise definition of focus to set expectations for it. Also
   mention that a "caret", while it takes keyboard input and is
   stateful, is not generally used to activate enabled elements
   and so is not what we are talking about.

------------------------------------------------------------------
Issue 471: Standard versus proprietary APIs for compatibility
with assistive technology 
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#470
------------------------------------------------------------------

Issue summary: Should developers be required to implement
"standard APIs" for communication with assistive technologies?

The reviewer wrote:

   I understand the need for standard APIs and documented APIs
   for non-standard implementations. But because of the way some
   ATs work, custom code has had to be written by both AOL and AT
   developers. The same is true for other software companies. I
   believe a priority one for the implementation of a user agent
   should be "make it work". Priority two should be "make it work
   using standards".

The UAWG discussed this issues at the 18 May 2001 teleconference
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0174

Resolution:

 - Accept this proposal.
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0169

   Note: What was finally integrated into the UAAG 1.0 was an
   edited version of this proposal.

In particular, this proposal includes the following changes:

 - Delete the term "standard API" from the document.

 - The UAWG maintains that the required "cascade" for APIs is:
    a) An API defined by a W3C Recommendation or that was
      designed for interoperability with ATs.

    b) If no such API is available, or if available APIs do not
       enable the user agent to satisfy the requirements, implement at
       least one publicly documented API that allows programmatic
       operation of all of the functionalities that are available
       through the user agent user interface, and follow operating
       environment conventions for the use of input and output APIs
   
 - Add the following Note to 6.4:

    "APIs used to satisfy the requirements of this checkpoint may
    be platform-independent APIs such as the W3C DOM,
    conventional APIs for a particular operating environment,
    conventional APIs for programming languages, plug-ins,
    virtual machine environments, etc. User agent developers are
    encouraged to implement APIs that allow assistive
    technologies to interoperate with multiple types of software
    in a given operating environment (user agents, word
    processors, spreadsheet programs, etc.), as this reuse will
    benefit users and assistive technology developers. User
    agents should always follow operating environment conventions
    for the use of input and output APIs. An API is considered
    "available" if the specification of the API is published
    (e.g., as a W3C Recommendation) in time for integration into
    a user agent's development cycle."

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Cell:                    +1 917 450-8783

Received on Tuesday, 3 July 2001 16:35:55 UTC