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

Status summary for UAAG 1.0

From: Ian Jacobs <ij@w3.org>
Date: Mon, 15 Jan 2001 17:39:29 -0500
Message-ID: <3A637C21.AEBF23A1@w3.org>
To: w3c-wai-ua@w3.org

Having published the 13 January 2001 draft of
the UAAG 1.0 Guidelines [1] and Techniques, I thought
it might be helpful to summarize where I think we

 - Ian

[1] http://www.w3.org/WAI/UA/WD-UAAG10-20010113

1) There are 26 open issues. See my summary of them

2) Once we have resolved the remaining issues, we 
   need to respond to each reviewer and explain our
   resolutions. If we have not convinced
   a reviewer to withdraw an objection, then we
   present the objection to the Director in our 
   request to advance to the next stage of the process.
   Suggested Action IJ: I will probably be the one to write 
   emails to all the reviewers explaining the WG's 

3) We have to decide whether we wish to return to
   Candidate Recommendation for implementation 
   experience, or request that the Director advance
   the document directly to Proposed Recommendation.
   I think that we will probably discuss that at
   the face-to-face meeting based revisions
   of the guidelines and the implementation report.
   Where we have weak implementation experience, we
   may decide to seek out implementations or to 
   delete some requirements.

   Suggested Action IJ: Prepare a new implementation report
   for the face-to-face meeting. 
   Suggested Action Working Group: Keep sending implementation
   reports to the list!

4) Timeline. This is not an official timeline, just
   a projection by me.
   4.1) We complete our open issues over the next three
      teleconferences: 18 Jan, 22 Jan (a Monday), and
      25 Jan. In order to complete the open issues

     a) You are strongly encouraged to attend the
     b) I include some rough proposals for some of 
        the issues below.

   4.2) During the month of February:
      a) Send responses to reviewers and document
         any outstanding objections.
      b) Prepare a new implementation report.
      c) Create a stable version of the guidelines
         for review by the Working Group before the
         face to face meeting.

   4.3) 1-2 March: Face-to-face meeting in Cambridge.
   4.4) If we decide to request to advance directly
      to Proposed Recommendation, then:

      a) We need to ensure that we have implementation
         experience for all of our requirements. In
         some cases, I don't believe we need to show
         implementation experience because other groups
         are responsible for this (e.g., WCAG or DOM).

      b) Suppose the Director sends the Proposed Rec
         to the Advisory Committee on 21 March (which
         gives us several weeks to deal with issues that
         arise at the face-to-face meeting). That
         means that PR ends 18 April, we allow 3 weeks
         to address issues that were raised, one week to
         prepare the document, and UAAG 1.0 becomes a
         Recommendation around 15 May.

   4.5) If we decide to spend some time in Candidate
        Recommendation, add a couple of months to this

Status of remaining issues and some proposals

321, 322, 358, 359: 
  These are all about definitions and editorial changes 
  (to checkpoint 2.3 and possibly a couple of others).

  Status: Eric, Al, and Ian are still working on a proposal
  to resolve these issues.

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

  Status: Awaiting discussion of proposal from Ian:

327: Add requirement for support of charset expected of each API?

  Status: We resolved to add a requirement at 16 Nov
  face-to-face.  Awaiting discussion of proposal from Ian:

373: Checkpoint 10.5: Propose raising to Priority 1

  Proposed: The reviewer suggests raising the priority of the
  checkpoint to document changes that affect accessibility from
  P2 to P1.

  Proposed by IJ: Don't raise this priority. It's already P1 to
  document all features that benefit accessibility. Therefore,
  while useful, lack of documentation of the changes specifically
  would not make understanding the documentation impossible.

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

  Status: I wrote the reviewer asking for more details and have
  not heard back yet except that the reviewer acknowledged
  reception of my request.
  Proposed by IJ: Since 3.2 is about animated images, not all
  animated effects, scripting is not an issue. No change to the

389: Conformance: Hard to test conformance in an objective

  Status: I wrote the reviewer with clarifications and asked for
  comment. No response yet.

  Proposed by IJ: We have reduced some of the conformance
  requirements as a result of the reviewer's comments. We have
  worked very hard on this conformance scheme and rejected a
  number of others. If the reviewer has specific suggestions, we
  will consider them.

394: Checkpoint 2.1: Vague about what cannot be provided through
     a source view.

  Status: Awaiting discussion of proposal from Ian:

443: Checkpoint 1.4: Device indepdent access to pointer (mouse)
     specific events.

  Status: The document currently requires emulation of
  mouse-specific controls by virtue of our requirement that the
  user must be able to do everything through the mouse.

  a) Do we want to require the UA to repair device-specific
  bindings specified by the author?

  b) Do we have evidence that the ability to simulate mouse
  events through the keyboard benefits the user?

444: Guideline 1 rationale needs clarification.

  Proposed: Guideline 1 rationale needs editing based on our
  change to checkpoint 1.1 (and not requiring that the user
  enable mouse-only operation of the user agent in order to
  conform). I believe that this is editorial and that the WG
  doesn't need to spend time on it.

445: Checkpoint 1.3: What about systems that do not use the
     keyboard at all, but provide accessibility solutions?

  Proposed by IJ: UAAG 1.0 is designed to promote accessibility
  of the Web for users with many types of disabilities. Keyboard
  access is considered fundamental for this. This document is not
  designed to promote the accessibility of specialized user
  agents.  Therefore no change to our requirements.

446: Checkpoint 6.1: Consider making the checkpoint scalable
     (variable priority linked to WCAG).

  Proposed by reviewer: Make checkpoint 6.1 a relative priority
  checkpoint with respect to WCAG 1.0.

  Status: We have already discussed this (refer to issue 111 [2])
  and resolved to leave this a priority one checkpoint. The
  rationale has been that if user agents don't implement
  features, authors will never be able to use them. Therefore,
  UAAG 1.0 must "lead".

  [2] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#111

447: Conformance by default w.r.t. configuration requirements

  Status: The reviewer's comment was that the document said that
  the user agent should work by default. But since the document
  requires lots of configurability to meet the different needs
  of users, for which users should the document work by
  default? The problematic sentence in the last call draft was
    "Note: User agent developers are strongly encouraged to
    design software that conforms in the default configuration."

  That statement has been removed from the 13 January 2001 
  draft because it doesn't make sense: You don't "conform" 
  in the default configuration. You simply conform or you don't.

  Therefore, unless there are objections or other comments. I 
  would consider this issue resolved.

448: Checkpoint 5.7: Is CSS read-only or read/write? 

  [This is checkpoint 5.9 in the 13 January 2001 draft.]

  The reviewer's comment was "Is this section referring to
  viewing the page or editing the page? Why would a user need to
  access the CSS when viewing a document?"

  Proposed IJ: Make this requirement read-only access.

   - We already require that a conforming user agent
     allow the user to select and apply user style sheets
     (checkpoint 4.15 in 13 Jan 2001 draft).

   - We require that the user be able to operate the user
     agent through keyboard alone.

   - Therefore, the user should be able to apply user style
     sheets through the conforming UA's user interface. ATs
     do not need to write to user style sheets through
     an API. 

  Can people suggest a scenario where the AT would need to
  write to the conforming user agent's user style sheet
  through an API?

449: Create an executive summary for UAAG 1.0 

  Proposed by IJ: I agree that a 2-page summary of the
  UAAG 1.0 as an appendix would be a useful addition.

  Suggested Action editors: Write an executive summary.

450: If UA is implemented in Java, what system conventions should
     it follow?

  The reviewer's comment: "Several checkpoints refer to using
  operating system conventions. What about a user agent that is
  written in Java? In that case it is up to the virtual machine
  to use the system conventions. Checkpoints that this might
  affect: 1.3, 5.8, 8.6, 9.2. Also, section 3.2."

  Comments from Al Gilman on this topic [3]:

     "I believe that the UAAG as is should win out on this point.
     That is to say, I believe that the UAAG never says simply
     'follow OS conventions.'"

  Status: Several checkpoints in the 13 January 2001 draft refer
  only to OS conventions: 5.10, 5.11, 5.12, and 5.13. 

  Discussion: Should "OS conventions" be "system conventions"
  (where system may include a programming environment) for
  some or all of these checkpoints?


451: Checkpoint 2.6: Generalize to decorative content, not just
     null alt
  (Checkpoint 2.7 in 13 January 2001 draft)

  Proposed by IJ: This proposal came from the WCAG WG, which is
  working on requirements in WCAG 2.0. For the moment UAAG 1.0 is
  based on WCAG 1.0, and this is a repair checkpoint for when the
  author has not met the WCAG 1.0 requirement of providing an
  equivalent. I propose that we not increase the scope of the
  checkpoint in this version of the document, and consider a
  broader checkpoint in a later version of UAAG that would be
  based on WCAG 2.0. We have edited 2.6 to make it more format

452: Checkpoint 2.2: Review minimal requirement (three options?) 

  The reviewer writes: You need to provide more options to
  companies to address different types of situations and uses for
  timing. Suggest a 3 option approach 1 - user can turn off all
  timing OR 2 - user can adjust the timing to 5 times (or 10
  times) the default setting. OR 3 - user is offered more time
  and has at least 10 seconds to respond to offer.

  Proposed by IJ: We resolved that the minimal requirement was
  to pause the presentation since we could not determine
  with certainty that fixed time delays (or multiples as the 
  reviewer suggests) would be useful. This sounds like a useful
  configuration option for the techniques document. 

453: Checkpoint 3.5: Generalize to "programmatic objects" 

  Status: For issue 364 [4], we resolved to include plug-ins.
  Refer to Ian's request to review this resolution [5] since
  plug-ins are not author-supplied. 

  Proposed by IJ: I don't know what "programmatic objects"
  includes besides scripts, applets, and plug-ins. Why 
  exclude more? There are no other checkpoints that would use
  the term "programmatic objects", so I'd prefer to be explicit
  rather than abstract here unless there are other programmatic
  objects that aren't covered.

  [4] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-364 

454: Checkpoints 3.6/3.7: Should these be Priority 1? 

  (These are the redirect checkpoints, currently P2

  Discussion: If the user can't control redirects and refresh,
  will access to some content be impossible?

  Comment by IJ: I can see the reviewer's point. However, I am
  reticent to raise the priorities at this stage.

455: Guideline 4: Change to "Ensure user control of

  Proposed by IJ (Editorial):

  - Move checkpoints 4.15-4.19 to Guideline 8. These seem
    to be more about viewport, focus, and other UI behavior,
    rather than styles.

  - Change Guideline 4 title to "Ensure user control of 
    rendering and styles". I prefer not using the term
    "presentation" since we use that term in the context
    of multimedia presentation.

456: Editorial: Need to clarify in section 3.2 that we do not
     mean system APIs.

  The reviewer's comment: "It was my understanding of this
  section that if a standard accessibility API does not exist for
  an operating system, that the developer must create and use
  their own. This would cause an AT developer to learn a
  different API for each browser on a platform that did not have
  an accessibility API."

  Comment by IJ: Section 3.2 of that draft was about using
  OS features as part of conformance. I don't understand the
  reviewer's comment w.r.t. that section. I would note that
  our current checkpoint 5.6 states:
    "5.6 Implement standard accessibility APIs (e.g., of the
    operating system and supported programming languages)."

  This doesn't mean that if one doesn't exist you have to
  invent your own; it wouldn't be standard.

457: Checkpoint 5.4: Ambiguity about what exactly required:
standard APIs only?  

  Checkpoint 5.4 is about read/write access to UI controls
  through standard APIs.

  Discussion: From Wendy's comment and after discussion with
  Charles, it seems that this checkpoint is not clear: is access
  to UI controls required even when there is no std API for doing

458: Do link highlighting requirements apply to all zones of an
image map? What is required granularity?

  Proposed IJ:
   - User must be able to activate all links.
   - For image maps specifically, I would argue that the
     image map as a whole needs to be highlighted, but not
     individual links.
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Monday, 15 January 2001 17:39:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:29 UTC