Responses to Opera issues raised during third last call of UAAG 1.0 I

Jonny,

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 Opera, which have been logged in the Working Group's issues list
[4].  The UAWG's resolutions and other editorial suggestions 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 responses to each of your issues.

Note: Where checkpoint numbers have changed, I 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
-----------------------------------------------

Your original comments:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0045

Follow-up:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0079

------------------------------------------------------------------
Issue 502: What constitutes blinking? 
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#502
------------------------------------------------------------------

Resolution:

 - The UAWG decided not to restrict blinking requirements to the blink
   range of 2 Hz to 55 Hz. 

 - Blinking is now defined in terms used in CSS2:
   "Blinking text alternates between a visible and invisible state."

------------------------------------------------------------------
Issue 503: 9.3: Clarification requested: does this mean that 
onfocus events are not triggered? 
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#503
------------------------------------------------------------------

Issue summary: Do the requirements of 9.3 (now checkpoint 9.5) mean
that onfocus events are not triggered?

Resolution: Yes (and more for the case of HTML)

In the 22 June 2001 draft, checkpoint 9.5 reads:

   "1.Allow configuration so that moving the content focus to or from
   an enabled element does not automatically activate any explicitly
   associated event handlers."

The informative Note that follows gives examples for HTML:

   "For instance, in this configuration for an HTML document, do not
   activate any handlers for the 'onfocus', 'onblur', or 'onchange'
   attributes. In this configuration, user agents should still apply
   any stylistic changes (e.g., highlighting) that may occur when
   there is a change in content focus."

------------------------------------------------------------------
Issue 504: 7.2, 10.3, 10.7, 12.3: Default values and inheritance 
from operating environment 
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#504
------------------------------------------------------------------

Issue summary: UAAG 1.0 includes requirements related to default user
agent settings. When the user agent inherits default settings from the
operating environment, do these requirements still have to be met?

Resolution: When default values are inherited through the operating
system settings, the user agent is not required to satisfy the default
settings requirements. Checkpoints 10.3 and 10.7 have been edited
accordingly.

------------------------------------------------------------------
Issue 505: 11.3: Propose that single-key mode would be sufficient 
technique 
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#505
------------------------------------------------------------------

Issue summary: To meet the single-key requirements of what is
checkpoint 11.4 in the 22 June draft, can the user agent provide a
single-key mode (that may be turned on and off, and in which there are
the required single-key bindings)?

Resolution: Yes. Checkpoint 11.4 now reads (in provision 4):

   'The single-key binding requirements may be satisfied with a
   "single-key mode" (i.e., a mode where the current bindings are
   replaced by a set of single-key bindings).'

------------------------------------------------------------------
Issue 514: Checkpoint 1.1: If UA functionalities are keyboard
operable, must all UI controls be? 
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#514
------------------------------------------------------------------

Issue summary: The requirement of checkpoint 1.1 is about keyboard
access. Does this mean that all user interface controls must be
keyboard operable, or is the functionalities they provide access to
that must be available through the keyboard?

Resolution: 

 - The UAWG agreed with the reviewer: it is the functionalities first
   and foremost that must be available through the keyboard.

 - As a result, checkpoint 1.1 was modified and reads in the 22 June
   draft:

     "Ensure that the user can operate through keyboard input alone
     any user agent functionality available through the user
     interface."

   This is consistent with the essence of checkpoint 6.4, which now
   reads:

      "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."

 - The Note after 1.1 conveys the idea that typically, this will
 involve keyboard operation of user interface controls in addition to
 direct keyboard operation of functionalities:

   "Note: User agents may support at least two types of keyboard access
   to functionalities: direct access (where user awareness of a
   location "in space" is not required, as is the case with keyboard
   shortcuts and navigation of user agent menus) and spatial access
   (where the user moves the pointing device "in space" via the
   keyboard). To satisfy this checkpoint, user agents are expected to
   provide a mix of both types of keyboard access. User agents should
   allow direct keyboard access where possible, and this may be
   redundant with spatial input techniques. Furthermore, the user
   agent should satisfy this requirement by offering a combination of
   keyboard-operable user interface controls (e.g., keyboard operable
   print menus and settings) and direct keyboard operation of user
   agent functionalities (e.g., a short cut to print the current
   page). As examples of functionalities, ensure that the user can
   interact with enabled elements, select content, navigate viewports,
   configure the user agent, access documentation, install the user
   agent, operate controls of the user interface, etc., all entirely
   through keyboard input. It is also possible to claim conformance to
   this document for full support through pointing device input and
   voice input. See the section on input modality labels."


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

Received on Thursday, 5 July 2001 10:19:38 UTC